Webinar: Optimizing QoR for FPGA Design

You might wonder why, in FPGA design, you would go beyond simply using the design tools provided by the FPGA vendor (e.g. Xilinx, Intel/Altera and Microsemi). After all, they know their hardware platform better than anyone else, and they’re pretty good at design software too. But there’s one thing none of these providers want to support – a common front-end to all these platforms. If you want flexibility in device providers, making a vendor change will force you back to an implementation restart. Which is one reason why tools like Synplify Premier from Synopsys have always had and always will have a market.

REGISTER HERE for this webinar on October 25[SUP]th[/SUP] at 10am PDT

The other reason is that a company whose primary focus is in design software, and which started and still leads design synthesis market, is likely to have an edge in synthesis QoR, features and usability over the device vendors. Of course, the physical design part of implementation still comes from the vendors, but Synplify tightly couples with these tools, not just in the sense of “you can launch Vivado from Synplify” but also in the sense that you can iteratively refine the implementation, as you’ll see soon.

As an example of what you get in synthesis from a tool in the Synopsys stable, Synplify Premier will handle optimization for state-machines (including recoding to other styles such as Gray encoding), resource-sharing, pipelining and retiming. And of course, they support DesignWare IP.

This webinar provides a fairly detailed overview of what is possible using Synplify Premier as your FPGA design front-end. Much of this will be familiar to ASIC designers or to FPGA designers already familiar with tools from device vendors. One topic is on optimal RTL coding styles, for FSMs (for optimization to the target device, to map away unreachable states, add safe recovery from invalid states or to change coding), math and DSP functions for efficient packing (for filters, counters, adders, multipliers, etc) and optimized RAM inferencing based on availability of resources (block RAMs etc).

Static timing analysis will look very familiar, except that the Synopsys constraint format is called FDC (FPGA design constraints) rather than SDC. Synplify Premier provides a nice feature to automatically create a quick set of constraints in early design to help you get through the basic flow-flush. Naturally you’ll want to work on developing real constraints (real clocks, clock groups, I/O constraints, timing exceptions, etc) before you move to physical design.

I mentioned earlier that interoperability between Synplify Premier and the vendor physical design tools isn’t just about compatibility in libraries, tech files and data passed from the synthesis tool to the vendor tool. A great example is in congestion and QoR management. These problems happen for well-known reasons – high resource utilization, over-aggressive constraints, logic packing problems and others.

One particularly important root cause can happen on Xilinx device which are multi-die (each die is known as super-logic region/SLR) on an interposer connected by super-long line (SLL) interconnects. You already know where this is going; there are only so many SLLs, which means they can be over-used (I assume there might also be reduced timing margin on SLLs). So lots of congestion and timing closure problems can happen – no news to implementation experts. What is interesting here though is that Synplify Premier can take this information from Xilinx or Intel project files and use it to drive re-synthesis to reduce congestions and timing closure problems. It also can drive many runs in parallel on a server farm so you can quickly explore different implementation strategies. That’s real and very useful interoperability.

If you’re not familiar with Synplify Premier, this should be a must-see. Remember to
REGISTER HERE for this webinar on October 25[SUP]th[/SUP] at 10am PDT