Who’s Who in the Zoo

Authored By:
Steve Mensor
Vice President, Marketing

Posted On: Jun 28, 2017

While the concept of eFPGA IP is fairly straightforward, the number of parties involved and their responsibilities may not be clear at the outset. It is the very programmable nature of an eFPGA that can cause confusion of who is responsible for what. With a standalone FPGA, there are three parties involved: the FPGA vendor, the foundry and the end user. The relationships between each are straightforward and well understood. Communication happens between the FPGA vendor and its foundry, but not between the end user and the foundry. The FPGA vendor communicates directly with the end user, delivering design tools and silicon. With an eFPGA, there are more entities involved with different lines of communications and deliverables between them. And depending upon the situation, some of these teams may be in separate companies or groups within larger corporations. This post describes these various roles, their interactions and deliverables.

Fundamental Differences in a Speedcore eFPGA Engagement versus a Standalone FPGA

With standalone FPGAs, the FPGA vendor determines the characteristics of the FPGA, defining logic count, memory resources, specialized IP, pinout, and packaging. An end user selects an FPGA from a catalog of defined resource, pin counts and packaging options. Then the end user, using software delivered by the FPGA vendor, writes RTL targeting the selected FPGA.

With an eFPGA engagement, there are more parties involved in the process. There is the SoC supplier, which is the company that purchases the Speedcore IP from Achronix and integrates it into their SoC. The Speedcore architecture is modular, which means the SoC supplier defines the resource count of the eFPGA core needed for their application. Achronix then builds and delivers the Speedcore IP to meet the SoC supplier’s requirements.

The end user uses the Achronix ACE design tools to configure the Speedcore eFPGA functionality hosted inside the SoC to meet their functional requirements. The end user can be the SoC supplier or a customer of the SoC supplier. For example, the SoC supplier may want to use the eFPGA functionality to create different products with different product SKUs. In this case, the SoC customer may never know that there is an eFPGA in the SoC. On the other hand, the SoC supplier may want their end customer to use the ACE design tools to customize the SoC for their end use case.

The Teams Involved with Delivery and Using Speedcore eFPGA

As stated, there are number of parties involved in an eFPGA engagement. In some cases, these parties may be part of the same corporation, but regardless, each group has a different set of responsibilities and deliverables. For a Speedcore eFPGA engagement, these roles are:

  • Achronix – responsible for delivering the Speedcore IP that includes GDS II, Lef, Lib files, Spice netlist, CPM model, documentation and ACE design tools that supports the Speedcore IP. The functionality of the Speedcore IP is based on the requirements defined by the SoC company
  • Front-end Design Team – the engineering team responsible for the SoC architectural definition, RTL, timing constraints and functional verification.
  • Back-end Design Team – the engineering team responsible for the physical design, timing closure, physical verification and sign-off.
  • ASIC Foundry – the foundry responsible for the actual fabrication of the SoC. This team delivers the necessary design rules for the process to both the front-end design team and Achronix.
  • End User – the end user of the SoC. Engineer(s) that write RTL targeting the Speedcore instance, who then compile the designs using the ACE design tools to create bitstreams for programming the embedded Speedcore IP in the end ASIC product.

Now a picture is worth a thousand words, so to help illustrate these roles, the following diagram should help.

Speedcore Engagement

Speedcore IP represents a game-changing solution for a new class of SoCs, allowing end users to customize an SoC to their application. Understanding the various roles and responsibilities of the parties involved in this solution will help everyone involved.