Embedding FPGA IP

The appeal of embedding an FPGA IP in an ASIC design is undeniable. For much of your design, you want all the advantages of ASIC: up to GHz performance, down to mW power (with active power management), all with very high levels of integration with a broad range of internal and 3[SUP]rd[/SUP]-party IP (analog/RF, sensor fusion, image/voice recognition and many more). But for an increasingly important range of applications requiring significant configurability, such as hardware accelerators, software configurability alone can’t meet performance needs and pure FPGA solutions fall short on power and system cost. In these cases, keeping all the ASIC advantages while also having the advantages of an embedded FPGA (eFPGA) block for configurability can look pretty attractive.

Sounds interesting, but how do you work with an eFPGA IP, especially during the chip design process? This is a specialized piece of functionality – a hard macro customized to your objectives, along with a customized version of the software to design/program the FPGA and the logic you must add to you design to support programming. Achronix recently released a white-paper detailing a typical flow you would follow in evaluating then building their Speedcore eFPGAs into your design.

They note up-front a couple of important consideration to ensure a streamlined flow. Physical constraints should be finalized early, including resource mix and size for the instance, also metal stack constraints. They also note that while your ASIC may run at GHz, the eFPGA is going to run at speeds around 300-500MHz so you need to think about separate clock domains and speed matching/clock domain crossing management at interfaces.

Your first step starts before you commit to a contract. Here you want to benchmark representative logic designs you expect to see in the eFPGA. You can do this through their ACE design tools, where you can perform all the usual FPGA design tasks starting from an RTL design and you can also size requirements for LUTs, memories and DSP blocks. ACE will provide feedback on size and performance as you perform these experiments. And naturally you would compare these stats with experiments you would perform on standalone FPGA alternatives. Once you complete your resource selections, Achronix will provide you with a finalized size, power and performance specification.

If you proceed to a contract, Achronix will then provide you with preliminary instance data, including a preliminary LEF file for floorplanning and a .v file including configuration and debug pins as well as signal pins (I think a pin-accurate black-box model at this stage as far as ASIC simulation is concerned), also a list of signal pin locations which you can change and feedback to Achronix for the next phase delivery. You also get a preliminary version of the ACE toolkit for your instance and a preliminary power estimator which they recommend you use in your ASIC power planning even at this early stage.

In phase 2 you get a final LEF file (remember to get your pin locations final in phase 1) and an updated version of the ACE toolkit, offering timing models accurate to within 5% of silicon. At this stage they also support RTL simulation of the eFPGA instance with the full ASIC. And you get preliminary models of the configuration circuity which you will need to fold into your ASIC design (how you want to drive this is up to you).

In the final phase of deliverables, Achronix provides a .v file for simulating the programming sequence, files for full timing closure (you can also develop these yourself using the ACE toolkit), a DFT simulation netlist and ATE vector files and a final version of your custom ACE toolkit, now supporting bitstream generation.

For timing closure the white paper notes two possibilities – cases where signals are registered in the eFPGA boundary ring and cases where register boundaries may be inside the core. In the first case Achronix will provide a .lib file with timing for the instance and you can use standard tools to close timing at the ASIC level (they note a couple of additional constraints). In cases where paths are registered inside the core, timing closure depends on a collaborative effort between you and Achronix involving an iterative analysis between your standard timing tools and ACE-analyzed timing.

There’s a lot more detail in the white paper which you can access HERE. This looks like a compelling option where you must have some hardware configurability in your ASIC solution. Certainly design with an eFPGA looks like a very manageable task through this flow (I’d personally try to avoid the second timing closure option, but that’s me).