How To Close Timing With An eFPGA Hosted In An SoC

eFPGAs are embeddable IP that include look-up tables, memories, and DSP building blocks, allowing designers to add a programmable logic fabric to their SoC. The Speedcore IP can be configured to any size as dictated by the end application. The SoC supplier defines the number of LUTs, memory resources, and DSP64 blocks for their Speedcore instance. A short time later, Achronix delivers the IP as a GDS plus supporting libraries, models and documentation. Once this custom Speedcore block is embedded in the SoC, the end user can use the Achronix CAD Environment (ACE) design tools which are traditional FPGA design tools and workflows to target the embedded FPGA. For more details on the roles and responsibilities in an eFPGA engagement, see the blog post Who’s Who in the Zoo.

SoC timing closure is generally a complex task — a task that is further complicated by an eFPGA in the SoC. In this case there are no traditional I/O buffers at the interface of the fabric to the host ASIC that create a clear boundary from a timing perspective, nor does the end user control the logic connecting to the eFPGA instance as they would with a standalone FPGA mounted to a PCB. The SoC supplier must deliver the design files to the end user describing the timing at the interface to the Speedcore instance plus the defined pin out, in effect turning the rest of the SoC into a complex I/O ring for the Speedcore instance.

Figure 1: Speedcore Integration with Host ASIC

The first decision that the SoC supplier must make is which timing closure scenario to follow, simple mode or advanced mode.

Simple timing mode
In the simple timing mode, the timing between IP in the host ASIC outside the Speedcore instance terminates at the register in the interface cluster in the Speedcore boundary ring (shown below). In this scenario, delays are not dependent on the design hosted in the Speedcore instance. In this case, timing closure is performed by the SoC supplier using standard tools (e.g. PrimeTime) where the .lib files represent timing data (setup/hold/clock-to-q) to/from boundary flip-flops. ACE design tools may require clock insertion delay information in this scenario.

Advanced timing mode
As the name implies, this scenario is more complex, with timing closure between the Speedcore eFPGA and the IP outside shared between the SoC supplier (e.g. PrimeTime) and ACE design tools (shown below). In this scenario, the .lib files do not contain delays to a specific flip-flop in the Speedcore fabric, but rather represent a range of flip-flops, chosen such that timing closure using the hardware .lib files correlate to timing closure in ACE. The .lib files still contain one setup/hold/clk-to-q value for each pin. In this mode, final timing sign-off comes from ACE, completed by using a suite of user designs containing critical paths representative of actual end-user designs.

Speedcore timing flow
After the SoC supplier has placed the Speedcore instance and connected all of the appropriate signals between IP in the host ASIC and the pins of the Speedcore instance, they must next ensure that clocks routed to more than one cluster are routed with minimal clock skew between them. Then the SoC supplier must:

1. Close timing with static timing analysis (STA) between all IP blocks and the Speedcore instance, using settings and PVT corners recommended by Achronix.
2. Once timing looks achievable, the final pin list is used to create the constraint file (PDC) for ACE to place IPINs/OPINs and CLK_IPINs/CLK_OPINs at those sites.
3. Write out a preliminary timing for each of these pins (data and clock). For the advanced timing mode, clock skew should be measured from a common point of divergence to all Speedcore pins and all external flip-flops, and data delays should be measured from launch flip-flops.
4. Run a set of user designs through ACE with these constraints to ensure that reported performance is acceptable.
5. Run digital simulations on the ASIC side to ensure functional correctness.
6. Use Achronix-supplied scripts to generate an SDC file representing the data and clock insertion delays at the Speedcore boundary.

The end user view
The SoC supplier delivers the placement file (PDC) representing the pin out of the Speedcore instance, plus an SDC file with input/output delay and clock latency constraints for the IPINs and OPINs. The end user can then complete their design using ACE similar to any other FPGA design.

To learn more
For more information on Speedcore eFPGAs, visit Introducing Speedcore eFPGAs. For details on how to integrate Speedcore IP into a host ASIC, and the associated timing issues, download Speedcore ASIC Integration and Timing User Guide (UG064) (registration required).