Wouldn’t it be great if there were more options in FPGA tools? For decades now, the FPGA community has decried the lack of FPGA design tool options. You’d think that a technology that has been evolving and maturing for over thirty years would have long ago reached the point where there were a wide variety of competitive programming options to choose from. However, we are still basically at the point where there is one and only one option for doing your FPGA design – the tool suite sold and distributed by the FPGA company itself.
It’s not that the third-party and open-source communities haven’t tried to find ways to produce viable alternative design flows. They have. Numerous EDA companies, from fast-moving, highly-motivated, innovative startups to big lumbering institutionalized EDA vendors have poured creativity, energy, determination, and piles of cash into efforts to build a third-party ecosystem for FPGA design. Well-minded communities have unleashed proven formulas for open-sourcing solutions to complex problems, looking for an alternative to proprietary tools. All to practically no avail.
Why is it so hard to create a viable alternative FPGA design flow?
If you are looking for villains, there are plenty of options. EDA companies were quick to blame the FPGA vendors themselves, of course, for everything from withholding important technical data, making it difficult or impossible for a third party to create working tools, to trashing the market by offering competitive tools for free. These theories have some merit. EDA business models would have tools selling for significant amounts of money. The EDA business model really requires at least five-digit price tags for a sale, although they can sometimes trim things up and get by with four-digit pricing. But FPGA companies don’t want such a huge barrier to entry for their devices, so they really do need to have a “free” tool option for designers and teams who don’t have enterprise-grade budgets.
Regarding the proprietary information, there is a fine line that FPGA companies must walk in providing technical data to third-party tool developers. They have hard-earned intellectual property that they don’t want to expose to the world, and a very rich level of detail is required for a typical design tool to do its job. Furthermore, just gathering all the data into a form that would be useful to tool developers is a monumental task.
But, beyond the finger pointing, there are formidable technical barriers to the creation of a viable third-party ecosystem.
First, an FPGA is not a microprocessor. Processors, by and large, can be well characterized by their instruction set. If you know the instruction set, you can make a compiler. If you can make a compiler, you can build an entire development suite on top of it. These days, in fact, you don’t really even need the instruction set. With the proliferation of hypervisors and the like, it takes very little to connect higher levels of software abstraction to the bare-metal logic of the processor.
In the FPGA world, there is no hypervisor. There is no instruction set. There is a complex physical array of components, whose behavior depends not only on their logical structure but also on their physical location. And simply changing the number or arrangement of components has a dramatic impact on the upstream tool chain. To be specific, FPGAs are made up of look-up-tables (LUTs), and “other stuff.” The “other stuff” includes hardened cells for doing arithmetic (multiply, accumulate, etc for digital signal processing applications), memory in various sizes, widths, and configurations, various types of IO, and sometimes even processors and peripherals.
While the output of a software compiler is essentially an ordered list of instructions, the output of an FPGA implementation tool is a complex physical arrangement of components and interconnect. This important difference gives rise to a multitude of problems. On top of that, FPGAs are doing their work in a fine-grained, highly-parallel environment. A processor can tick along doing its job based on a single clock, and that clock can generally be sped up or slowed down with no important changes in the function of the design. An FPGA, however, could have a multitude of clocks, some synchronous and some not, with branches of irregular-length logic chains timed to complete (hopefully) within one clock cycle. So, while the output of a software compiler is basically independent of clock speed, the output of the FPGA flow is most certainly not.
In the old days, this duo of issues was mitigated by the relative speed of interconnect. If you were stacking several layers of logic functions between two registers, the propagation delay through the chain of logic would depend primarily on the logic functions themselves. As geometries got smaller, however, a greater proportion of the total delay was spent in the interconnect – the wires between logic elements. Over time, the interconnect delay became so dominant that the delay picture really depended more on the “wires” between components than on the components themselves.
Why does this matter?
The primary steps in the FPGA implementation flow are synthesis and place-and-route. Synthesis used to be called “logic synthesis” because it converted a (supposedly) human-readable hardware description language (HDL) file and synthesized it into a network of interconnected logic components. Synthesis is the closest thing in an FPGA flow to a “compiler” because it converts a human readable description of an algorithm into a much more detailed but equivalent logical description. Unlike a compiler, however, a synthesis tool must also worry about the timing aspects of the resulting design – making sure that each stack of combinational logic can complete its work in the duration of one clock cycle (in the relevant part of the circuit). That means synthesis also needs to perform a detailed timing analysis of the logic design it is creating.
Now, remember when we said the timing now depends more on the interconnect than on the logic? Well, the synthesis tool has no idea what the interconnect delay is going to be. That will be determined by where the components are placed during the place-and-route phase, and how the router decides to route the interconnects that make up each net. This creates a chicken-and-egg problem where synthesis cannot know the timing until place-and-route has done its job, and place-and-route cannot begin until synthesis has created a netlist of components. This dragon-eating-his-own-tail scenario has gotten worse as designs have gotten larger, interconnect delays have increased, logic delays have decreased, and timing has become more critical.
The implications on the tool chain are probably obvious. It has become almost impossible to do a good job if the synthesis and place-and-route steps are performed separately by separate tools. Doing the optimal design all but requires a single tool and data model that can iterate internally to find the best combination of logic structure, placement, and routing that will maximize performance, minimize power, minimize resource utilization, and reliably meet timing constraints. The model where the FPGA company produces the place-and-route tool, and a third, independent party produces a synthesis tool is fundamentally flawed. Of course, there are examples when third parties such as EDA companies have, in very close cooperation with FPGA companies, produced synthesis tools that work well with FPGA-company-produced place-and-route, but those examples are few and are extremely difficult to maintain.
But, why are place-and-route tools produced only by the FPGA companies?
In the ASIC world, just about every place-and-route tool comes from an independent EDA company. The various silicon vendors have crafted their libraries and processes around the idea of independent place-and-route. The FPGA problem, however, is much more complex. Since each FPGA family (or at least each FPGA company) has a unique structure for its fundamental logic element, and since each device has a unique configuration of those logic elements and the interconnect between them, place-and-route must practically be co-designed with the silicon itself.
When an FPGA company is developing a new chip, they typically run huge suites of designs through place and route, iterating both the place-and-route tool and the physical layout of the chip until they reach a combination where utilization (the percent of the logic on the chip that can be effectively utilized) and routability (the probability of getting 100% completion of all required routes) are acceptable. This co-design of the layout tools with the silicon is essential to getting competitive results with today’s technology in today’s markets.
It’s a small leap of logic to see that: if there is an enormous advantage to having the silicon and the place-and-route co-designed, and there is an enormous advantage to having the place-and-route and synthesis co-designed, there is probably an enormous-squared advantage to having all three elements designed together. This conclusion is backed up by the fact that Synopsys, Synplicity, Mentor Graphics, Exemplar Logic, and many other companies have tried and failed to make a significant, sustainable business doing third-party FPGA synthesis.
There have also been numerous attempts to create open-source solutions for FPGA design. But, in addition to the problems cited above, there is also a major problem with engineering expertise. In the open-source software world, the creation of software tools for software engineers is a perfect storm of expertise. The people who are motivated to participate in the open-source effort are software experts, and they are creating tools for software experts like themselves. They have both the expertise to create the tools and the insight to know what tools should be created and how they should work.
In the hardware-centric world of FPGA, however, the end users of FPGA tools generally do not have the expertise to actually write tools. The community of engineers with both the software skills to create complex tools and the algorithmic and hardware-engineering skill and understanding to make those tools work is very small and is mostly gainfully employed at either an EDA company or an FPGA company. The number of free agents in the world with that particular combination of expertise and experience is vanishingly small – especially compared with the number of engineers required to create and maintain a fast-evolving design tool suite.
Also, in the software world, software engineers working in other areas can justify “volunteering” their time to support open-source projects that directly help themselves and their colleagues in their “normal” jobs. But since the audience for FPGA tools is different from the community of engineers required to develop them, no such virtuous cycle exists. There just has never emerged a critical mass of capable developers with the time, energy, and resources required to create a viable, sustainable open-source FPGA tool ecosystem.
So, for the foreseeable future, we are left with a situation where the tools for FPGA design (at least the implementation portion) will be predominantly supplied by the FPGA companies themselves. Competition that might push those tools to evolve will be competition between the entire ecosystems – tools combined with silicon, IP, reference designs, boards, and support. So, rather than choosing an FPGA tool you like, or even an entire FPGA tool suite you like, you’re really left with choosing only an FPGA company that you like.
Of course, as we move up the chain above the level of implementation tools – to high-level languages and synthesis, model-based design, graphical and other design creation methods, simulation, emulation and other debugging and verification tools, there is much more diversity and many more options – owing to the cleaner separation between these software tools and the bare metal of the FPGA itself. In this realm, there is definite hope for a robust, competitive environment for selecting the tool that best suits your team’s needs and preferences.
Leave a Reply
You must be logged in to post a comment.