Understanding QoR in FPGA synthesis

We’ve all heard this claim: “Our FPGA synthesis tool produces better quality of results (QoR).” If you’re just hoping for a tool to do that automagically, you’re probably doing it wrong. Getting better QoR depends on understanding what an FPGA synthesis tool is capable of, and how to leverage what it tells you.

Synopsys took an in-depth look at the bigger picture around FPGA synthesis QoR in a recent webinar. Paul Owens, senior customer application engineer, steps through the process and explores where one should look for trouble spots. Here are some highlights from that discussion.

His opening point is a good one: designers, even with the best of tools, can end up in a loop of tweaking constraints, running synthesis, running place & route, and seeing if timing closed. Owens points out just how expensive that can be, suggesting as a general guideline that if synthesis takes X hours, place & route takes 3x hours.

Live. Die. Repeat. It makes for a pretty good sci-fi story and big-budget action flick, but is much less fun when the FPGA design clock is ticking. We’ve discussed constraints before, and Owens doesn’t mince words here: he says writing correct timing constraints is the most important technique for achieving timing QoR. Finding clocks, creating groupings and relationships, and properly constraining where needed, including multi-cycle and false paths, are essential steps.

In a brand-new synthesis project, Synopsys Synplify Premier has a “fast synthesis” feature that quickly generates information on inferred clocks, and can aid in creating an FDC (FPGA design constraint) file. After an initial synthesis run, a “constraint check” utility generates a report on constraint syntax, clock relationships, unconstrained start/end points, non-locked I/O, and I/Os with no constraints.

One plus of a vendor-independent tool is understanding of multiple FPGA architectures. Synplify Premier provides forward annotation of constraints in target vendor formats, for Xilinx a netlist .edif plus constraints in _edif.xdc, and for Altera a netlist .vqm plus constraints in TCL and SCF format.

Once constraints are set up, “fast synthesis” is disabled and Synplify Premier can take a full pass. Owens suggests several coding guidelines for state machines, RAMs, and DSP blocks that can help avoid problematic constructs. An interesting suggestion is to keep DSP code in a separate module, which can help with inference and packing. Attention should also be paid to byte-enabled RAMs, which may be able to map to block RAM for better performance.

After synthesis, placement-aware place & route can take over – again, a little understanding goes a long way here. A quick check Owens recommends is to open the Synthesis Timing tab before letting P & R rip, and look at the performance summary section. If it shows a “System” clock (that is, one likely not named in your RTL but defined during synthesis), some I/O constraints have likely been overlooked.

The other report Owens cited as making a huge difference in QoR is the Timing Correlation tab. By looking at how well P & R did versus what synthesis thought the optimal timing should be, the paths with worst slack can be examined and correlation mismatches can be quickly identified. This can help in the hunt for missing start or end points, or some missing multi-cycle or false path constraints. There are also several “cheats”, such as one that allows tightening of paths affected by a clock without changing the FDC file.

Brendan Leonard may be talented enough to shoot an entire show in one take, but most FPGA designers will be making multiple synthesis passes on a design to get both the RTL and the constraints right. The idea here is to reduce the number of relatively expensive P & R runs, with better timing correlation, and shorten the overall time from start to finish.

To view the entire webinar, register here:

Increase FPGA Performance with Enhanced Capabilities of Synplify Pro and Premier

Using “fast synthesis” mode to establish a baseline set of constraints, plus the numerous design guidelines Owens discusses, can minimize surprises in the FPGA design process and help get the desired QoR.

lang: en_US