The practice of retargeting an existing design from one FPGA technology to another has received a lot of attention. Why should design teams consider this strategy? By Sreedhar Mallela.

Recent supply chain issues are leaving many developers who use FPGAs in the lurch. Many device manufacturers have been compelled to hold off on market plans or production until the targeted FPGAs become available, creating a severe negative impact on the company’s bottom line.

To get around the supply chain issue, designers may have to resort to designing their devices to operate with FPGA devices that are currently on hand or available in the market. But doing so can add months if not years to the project. By the time the redesign is complete, the supply chain issues may no longer be of consequence.

There is another scenario that many design teams must contend with and that is dealing with designs targeted to obsolete FPGAs that are still functionally viable.

The old FPGAs that are operating these designs are no longer available to support the design and sometimes acquiring these obsolete FPGAs is cost prohibitive. Like the supply chain issue example, the time, resources, and cost of redesigning older FPGA designs for newer FPGAs may not be practical.

Adding to the dilemma is the fact that modern FPGA technology offers significant benefits that obsolete technology does not have in terms of safety, security and trust, and power-saving features, making these designs on obsolete technology inadequate to meet the demands of today’s market.

Why Not Re-synthesize?

Re-synthesizing the RTL to meet the desired new technology may also not be feasible. The latest RTL synthesis tools may not produce equivalent results because the tools’ interpretation of the RTL will most likely not be the same as that of the original synthesis tool.

Old synthesis bugs may have impacted the original netlist, and it is unknown whether and how these bugs will manifest themselves during re-synthesis. Any IP blocks and cells that have been instantiated in the RTL, such as DPSs and memories, may not be available in the new FPGA technology.

Further complicating the ability to re-synthesize RTL is that the original code may no longer be available, use obsolete proprietary HDL constructs, or does not provide the desired functionality as engineering change orders (ECOs) have been implemented on the FPGA netlist but not backported to the RTL.

A Different Approach

Retargeting these designs to newer FPGA technology can help to side-step the supply chain issues as well as extend the life of legacy designs. Retargeting also ensures that designs are brought up to the latest safety and security standards while reducing power consumption. This technology can have very practical applications in the mil/aero industry where legacy designs are widely used.

Retargeting takes the final netlist from the original design and generates a functionally equivalent final netlist in the modern or alternative target FPGA technology. Months of engineering time can be alleviated.

The only solution currently on the market is OneSpin FPGA Retargeting Solution.

The three general retargeting approaches are:

  1. Retargeting a netlist in an obsolete or unavailable technology to a netlist in modern or market available technology,
  2. Equivalence with RTL, if available
  3. RTL retargeting

The technology is first applied to the original netlist to produce the retargeted netlist. The retargeted netlist is then re-synthesized using an FPGA implementation flow for the updated specified FPGA technology to create the final netlist for the new FPGA. Equivalence checking qualifies the equivalence of all the steps used in the flow. The flow includes two implementation steps.

  1. The transformation from the original obsolete or unavailable input netlist to a netlist targeting the same device technology.
  2. The actual retargeting step yielding a final netlist targeting an updated or available target device.

To support the formal equivalence check, the library cells for the obsolete netlist need to be available. Especially for older devices this might not always be the case and thus they need to be written as part of the retargeting.

The obsolete netlist may contain syntax that modern synthesis tools do not accept as input. For these cases, the obsolete Verilog netlist should be syntactically modified to provide a format that the modern synthesis tools will accept. A parser needs to be written to convert the unsupported obsolete netlist to the retargeted obsolete netlist.

To ensure no functional errors are introduced by the parser due to the syntactic changes, an equivalence checking tool can be used to check the functional equivalence of the original obsolete netlist with the retargeted obsolete/older netlist.

The retargeted obsolete/older netlist can be synthesized using the modern synthesis tool to generate synthesized and place and route netlists. The FPGA equivalence checking ensures the functional equivalence of the retargeted obsolete netlist against modern/updated final netlist.

In addition to proving the obsolete/older netlist vs. modern/updated netlist, the FPGA equivalence checking tool proves the functional equivalence of the RTL to the obsolete netlist if it has not been manually modified to meet the requirements of the original specification.

The following considerations need to be considered to prove equivalence:

  • If there are any constraints used during synthesis, then similar constraints should be used during verification.
  • If the obsolete/older device netlist is manually modified, then corresponding equivalent modifications need to be done in RTL.

If the RTL is available for the obsolete/older device netlist and the user decides to use the RTL for synthesis and retargeting and wants to verify the obsolete device netlist vs. the final netlist (synthesized using RTL), then the RTL retargeting can be used.

The flow for RTL retargeting is as follows:

  • Synthesize the RTL for the modern/updated device
  • Create (if necessary) and apply formal models for the modern/updated device netlist
  • Prove functional equivalence for RTL against the modern/updated device netlist using an FPGA equivalence checking tool
  • Create (if necessary) and apply formal models for the obsolete/older device netlist
  • Prove functional equivalence of the obsolete/older device netlist against the modern/updated device netlist using an FPGA equivalence checking tool

During the synthesis of the RTL to modern/updated device netlist, use the same constraints if any were used during synthesis of the obsolete netlist.

After proving equivalence of RTL vs. modern netlist, the next step is to prove the equivalence of the obsolete netlist vs. the modern netlist.

With the RTL retargeting, the exchange of (single) IPs in the RTL can be reliably proven. To do so the obsolete IPs in the RTL need to be replaced with the modern version. Constraints to the IPs may need to be added.

Next, an RTL equivalence checking tool (like OneSpin 360 EC-FPGA) is employed to prove equivalence between the RTL with obsolete IPs against the version with modern IPs. If the equivalence is proven, the steps described above can be applied (proof RTL against synthesis result, etc) to ensure that the synthesis result is equivalent to the RTL.

Lastly, the RTL with obsolete IPs should be validated via an equivalence checking tool against its synthesis result. If all those steps (RTL to RTL, RTL to netlist with modern IPs, RTL to netlist with obsolete IPs) are reported to be equivalent, it is ensured that the obsolete netlist has an equivalent behaviour to the netlist created with modern IPs.

Here we have discussed different approaches to retargeting an obsolete/older or unavailable device netlist to a modern/updated or available device netlist.

The retargeting flow prevents costly, time-consuming, and resource draining redesign. Because this flow is independent of the capabilities within the modern/updated target device, the trust and security, safety, and power saving features of the modern FPGA devices are all supported.

The RTL retargeting flow can be used to ensure that the obsolete device netlist functionality is retained in the modern/updated device netlist, resynthesized using the original RTL.

Author details: Sreedhar Mallela is a Field Application Engineer, OneSpin: A Siemens Business