Implementation tools needed during prototyping

We have now explored the capability of the FPGA devices in some detail but these are of little interest if they cannot be readily employed in our prototype project. In the prototyping utility boxes above we have already mentioned that some resources are automatically employed whereas others will need some particular consideration. The ability of EDA tools for FPGA to make good use of the device resources is equally important as the resources themselves. We will now give an overview of the main EDA tools in the FPGA flow today, namely synthesis tools, partitioning tools, place & route tools and debug tools. We aim to keep the explanations as generic as possible and in each case give only small examples of tools from our own companies. More specific detail on tools available from Synopsys ® and Xilinx ® is available via the references. There is also more detail on the use of the tools in other chapters, particularly in chapters 7, 8 and 11. 

Synthesis tools

As with almost every EDA tool flow, at the heart we find synthesis. For FPGA-based prototyping, we find synthesis converting the SoC RTL into a number ofFPGA netlists to be used by the back-end tools, which then finally place and routethe FPGA. However, at the same time the synthesis process is expected to inferregular structures from the RTL, optimize them and efficiently map them into theFPGA, meeting both space and performance goals.

As a brief illustration of this process, Figure 27 shows a screenshot of a SynopsysFPGA synthesis tool, and three views of the same small ALU design. In the bottomleft is a text editor showing the RTL and the behavior extracted from that during thefirst stage of synthesis is shown above it. We can see a mux selecting the result ofthree different operations upon the inputs dependent upon an opcode and its outputpassing to a register. On the right of the screenshot we see a part of the final logiccreated by the synthesis, in particular note the use of LUTs for the multiplexing, FFsfor the register and a DSP48 block used by default to implement the multiplier.

Figure 27: Synplify Pro ® FPGA synthesis screenshot

In the above example, we might decide that we do not want to waste such apowerful resource as a DSP48 block to implement a simple multiplier, so we could add an extra command, called an attribute, into the RTL or a parallel constraint filein order to override the default mapping. This is exactly the kind of control that asynthesis user has upon the way that the RTL is interpreted and implemented.

Let us a look a little more closely at the way that synthesis maps RTL to FPGAresources.

Mapping SoC design elements into FPGA

This section describes the tool’s features that support mapping of the SoC design into an FPGA, making use of our example FPGA devices from the Xilinx ® Virtex-6 family. Many of the FPGA’s resources are supported transparently to the user because the synthesis tool automatically infers FPGA structures to implement user’s RTL with minimal or no intervention by the user. 

Logic mapping

As logic is the primary resource for logic prototyping, mapping RTL into CLBs is an elementary function. For example, for the Xilinx ® Virtex-6 architecture, synthesis should be able to do the following: 

• Infer LUT6 where up to six input functions are needed. LUTs will be cascaded or split when more or less inputs are needed. For example, dual LUT5s will be inferred automatically when two functions sharing up to five common inputs can occupy the same CLB. 

• Memory usage in SLICEM type slices will be inferred to implement distributed RAM and fast shift registers. 

• Clock enables will be inferred, with the ability to re-wire low-fanout clock enable to LUTS to maximize slice utilization. 

• Set/reset, synchronous or asynchronous will be inferred including prevention/arbitration of simultaneous set/reset assertion, avoiding unpredictable behavior in silicon. For example, Synplify Pro detects such a possibility, issues a warning and then generates a logically equivalent single asynchronous reset logic. 

Memory block mapping

SoC designs include many and varied memory elements and we need to map theseefficiently to avoid wasting our FPGA resources. Synthesis should be able toperform the following:

• Automatically infer single and dual ported memory structures into blockRAMs.

• Pack adjacent input and output registers of pipeline stages into theBlockRAMs automatically.

• Make use of BlockRAM operational modes including read-first, write-firstand no-change: preserving the initial value of either of the RAM’s input oroutput ports – as required to match the SoC’s behavior.

• Automatically split larger memories beyond the capacity of a BlockRAMinto multiple blocks and add the necessary logic to split and merge addressand data as required. The topology of the split (i.e., optimized for speed orarea) should also be controllable.

DSP block mapping

Many SoC designs include blocks which make extensive use of arithmetic andalgorithmic function. If the tools can map these into the DSP blocks in the FPGA bydefault then a significant proportion of the FPGA resources can be liberated forother purposes.

• Adders/subtractors: FPGA logic elements have simple gate structures orconfiguration modes which more efficiently map carry functions enablinggood implementation of basic arithmetic. Synthesis will automatically usethese structures.

• Multipliers: Synplify automatically infers the use of DSP blocks formultiply and accumulate functions and operators in the RTL (see section3.3.1 above for an example).

• Pre-adder: synthesis should infer an optional 25-bit adder before themultiplier in a DSP48 in a Xilinx ® Virtex-6 device.

• DSP Cascading: for wider arithmetic in the RTL, synthesis shouldautomatically infer multiple DSP blocks using dedicated cascadinginterconnect between the DSP blocks when present, for example the portsbetween the DSP48E blocks in a Xilinx ® Virtex-6 device.

• Pipelining support: if pipeline registers are present in an arithmeticdatapath then these will automatically be packed into the DSP blocks ifappropriate.

As we can see above, the FPGA synthesis tools have intimate knowledge of theFPGA architecture and so as prototypers, we can rely on most of our SoC RTLbeing mapped automatically and efficiently without having to carve out swathes ofRTL and replace it with FPGA-equivalent code.

Synthesis and the three “laws” of prototyping

So far we have seen that synthesis tools have the task of mapping the SoC design into available FPGA resources. The more this can be automated, the easier and faster will be the process of building an FPGA-based prototype.

Table 4: The three “laws” of prototyping

Law 1: SoCs are larger than FPGAs

Law 2: SoCs are faster than FPGAs

Law 3: SoC designs are FPGA-hostile

In effect, the synthesis has the task of confronting the so-called “three laws of prototyping” as seen in Table 4 below. 

The clear ramifications of these “laws” are that: 

a) the design will probably need partitioning, 

b) the design may not be able to run at full SoC speed, and 

c) the design may need some rework in order to be made FPGA-ready. 

Admittedly, these are really more challenges than laws and they are sometimes broken, for example, some SoC designs do indeed need only one FPGA to prototype, thus breaking the first law. However, the three laws are a good reminder of the main problems to be overcome when using FPGA-based prototyping, and of the steps required in making the design ready for FPGA. 

The following sections describe the main features available in synthesis tools, with some reference to Synopsys tools, but for further information on these, please see the references. 

One of the most important reasons to perform prototyping is to achieve the highest possible performance compared with other verification methods such as emulation; however, poor synthesis (or poor use of synthesis) can jeopardize this aim. It is tempting to use a quick-pass low-effort synthesis, or to reduce the target for synthesis in order to achieve faster runtime and indeed, some synthesis tools allow for exactly this kind of trade-off. In some design blocks, however, the best possiblesynthesis results are essential in order to meet the overall performance target for theprototype.

The most important requirement for the synthesis is to overcome the implications ofthe third law of prototyping i.e., the removal or neutralization of the FPGA-hostileelements in the SoC design. Only then can we map the design efficiently into thetarget FPGA’s resources and we will explain these fully in chapter 7.

There are a number of features of synthesis tools which are often beneficial toprototype developers. These include:

• Fast synthesis: a mode of operation in which the synthesis tool ignoressome opportunities for complete optimization in order to complete thesynthesis sooner. In this way it is possible for runtime to be made 2x – 3xfaster than normal at the expense of FPGA performance. If a synthesisruntime is measured in hours, then this fast mode will save many days orweeks of waiting over the duration of a prototyping project. Fast synthesisruntime is also useful during initial partitioning and implementation trials,where only estimated design size and rough performance are required.

• Incremental synthesis: a feature in which the tool collaborates with theincremental implementation of the place & route tool (described below). Inthis mode of operation, the design is considered as blocks or sub-treeswithin each FPGA. The synthesis tool maintains a historical version ofeach sub-tree and can notice if new RTL changes impact each of the sub-trees. If the incremental synthesis recognizes that a sub-tree has notchanged then it will avoid re-synthesis and instead use the historicalversion of that sub-tree, thus saving a great deal of time. The decisions ofthe incremental synthesis engine are forward annotated to the back-endplace & route tools as placement constraints so that previous logicmapping and placement is maintained. A considered use of incrementalsynthesis can dramatically reduce the turn-around time from small designchanges to final implemented design on the FPGA boards. Further detailsof incremental flows are given in chapter 11.

• Physical synthesis: a feature in which the synthesis is optimized forphysical implementation where the tool accounts for actual routing delaysand produces logic placement constraints to be used by the place & routetools. This feature generally yields a faster and a more accurate timingclosure for the designs. This may seem contradictory to our considerationof fast synthesis above but it is often the case where one particular FPGAin a prototype struggles to reach full speed and so selective use of physicalsynthesis is one way that an FPGA can be brought more swiftly to timingclosure.

Synthesis tools are available from third-party EDA vendors and also from FPGA vendors. We will focus on Synopsys’ synthesis tools as necessary for our examples in this chapter but not to any great detail. For specific information on Synopsys FPGA synthesis, please note the references at the back of this book. 

Gated clock mapping

One function of synthesis beyond mapping to FPGA resources is the ability to manipulate the design automatically in order to avoid RTL changes. The most significant example of this is the removal of clock gating in the SoC design in order to simplify the mapping to FPGA. 

Clock gating is common in SoC designs but is not a good choice for FPGA technology where dedicated low-skew clock distribution nets deliver un-gated clock to all registers on the die. Instead of gating clocks found in the RTL, the Synopsys Synplify ® tool removes the combinatorial gating from the clock nets and applies the gating logic to the clock enable pin available on most sequential elements in the FPGA.

Figure 28 shows a few examples of clock-gating translations but there will be much more description of the manipulation of gated clocks in chapter 7. Synthesis needs to be guided in which clocks to preserve, how sequential elements, including RAMs, can handle clock enables and even how black-box items can be manipulated. This is all achieved without altering the RTL. 

The resulting implementation after clock gate removal is logically equivalent to the input logic, but is more resource efficient and virtually eliminates setup and hold time violations due to the low skew clock distribution. 

Finally, the synthesis is only part of the flow and an important consideration is how well the synthesis can collaborate with the other parts of the flow, particularly the place & route back-end in order to ensure that all tools work towards common goals. Let’s look now at the important subject of tools that perform design partitioning. 

Figure 28: Examples of gated-clock removal performed by synthesis.