Why FPGA will jumpstart shift toward ESL
Hello, I'm Mike Kendrick.
I am the guy who writes the requirements for the SW design tools .
Given the scope of the FPGA design flow, as you would expect, I don’t do this by myself. I also don’t do it in a vacuum. My main objective of writing this blog is to spark some conversation with designers on some of the current directions that FPGA based design could and should go.
Historically, FPGA design flow has been in the wake of the ASIC design flow. As they say, “Today’s ASIC designer issue is tomorrow’s FPGA designer’s issue”. That is not entirely true as many of these issues are addressed with the design of the FPGA chip itself. For example, a designer using an FPGA has a low skew clock tree available as a feature of the FPGA, but they have to build that as part of their ASIC development (and thus, there are tools in the ASIC flow which enable this).
But many design challenges faced by a designer targeting FPGA were first encountered by the ASIC designer. I would expect that basic trend to continue, and we will continue to look at the design issues in the ASIC world for our planning. I am extremely interested in designer’s thoughts on what issues they have or anticipate emerging.
I also see where the FPGA designer will face issues that were not faced by the ASIC designer. These relate to FPGA applications that for various reasons were not ASIC applications. ASICs are characterized by high fixed costs to get the first chip built, and design changes are costly. ASIC is not a technology that lends itself to experimentation, unless that experimentation can be accomplished solely through software running on the ASIC. FPGAs are now big enough where they can be used unlike an ASIC could realistically ever be used. For example – ESL.
ESL stands for Electronic System Level, and I think was originally coined by Gary Smith at Gartner/DataQuest. It’s a term that has been applied to many things and many products (by many marketing people). My personal definition of it is, “the thing which is the next abstraction after RTL”. It’s not taking a big risk to forecast that a design paradigm will eventually emerge that will be at a higher level of abstraction, thus allowing mere humans to design even more complex systems. This has been the inevitable march of engineering (remember schematic?).
The basic promise of ESL is that it would allow designers to describe the function of their system, and design automation tools would convert that to an implementation. Some tool flows were developed (e.g. CoWare, Cadence SPW, Synopsys CoCentric Studio) and targeted at the ASIC designer. However, given the economics of ASIC, all the experimentation with implementation had to be done in simulation. Other than being slow, this also created a need for simulation models which take time and resources to develop.
FPGAs can go after the ESL problem with quite a different paradigm. Different system implementations can quickly be evaluated in-system to analyze system throughput. Given their size, it’s now possible to see the system-level results of making system level changes such as: moving functionality between the SW and HW, changing the communication structure (e.g. shared bus vs. point-point). In my mind, FPGA is a much better technology for realizing the potential of ESL. A potential hurdle to progress is the size of the available pool of engineers which have the system level expertise to work with both HW and SW in their chip implementation.
Comments