Design partitioning flows

Even though FPGA capacity has increased in line with Moore’s Law, the SoC designs themselves have also increased in size and complexity so SoC designs are still usually larger than today’s largest FPGA devices. As a result, the first law of prototyping is as true now as it was when first proposed at the start of the millennium and the prototyper is faced with the task of partitioning the SoC design into multiple, smaller FPGA devices. 

There are two main approaches to partitioning: pre-synthesis or post-synthesis. We will consider each in turn here along with a less common approach of partitioning the actual SoC netlist. 

Pre-synthesis partitioning flow

When the partitioning is performed on the design before synthesis, the input format is the RTL of the SoC design. The partitioning task is a process of creating FPGA- sized sub-designs from the overall design tree and can be automated to some degree. Figure 29 shows the steps in a pre-synthesis partitioning tool flow. 

Figure 29: Pre-synthesis partitioning flow 

The flow is often performed top-down, which requires that the partitioning tools and the workstations upon which they run have the capacity to accommodate the whole SoC design, which can amount to gigabytes of data. Therefore, tool efficiency and runtime can become important factors and consideration needs to be given to the turn-around time from RTL changes to having a new version of the designpartitioned and running on the prototype board.

Originally, the pre-synthesis partitioning approach dictated that compilation andsynthesis occurred on the whole design, potentially resulting in long runtimes anddemanding large server resources. However, recent advances mean that the FPGAsynthesis is performed on all FPGAs in parallel. This requires that the partitioningmakes an estimate of final results for each FPGA in order to infer timing budgetsfor the IO on each device. The benefit is that total runtime is greatly improved byrunning multiple synthesis tools in parallel. Turn-around time for each RTL changeand bug fix is reduced accordingly, especially if incremental synthesis and place &route techniques are used. More detail of incremental flows is given in chapter 11.

The drawback of this flow is that it is actually a two-pass flow. To make a correctpartition, some knowledge of final FPGA resources required by each RTL moduleis required. If possible, and if timing-driven partitioning is our aim, then a timingknowledge at each module boundary would also be useful. This accurate knowledgeof resources and timing can only come from synthesis (or preferably from place &route). We therefore need to skip ahead and pre-run synthesis before feeding backthe results to the partitioner. In the Certify ® tool, that is precisely what is done. Thesynthesis is run in a quick-pass automated mode in order to estimate resources andtiming. Thus, although a two-pass flow, the pre-synthesis in effect seems like anextra “estimate” step in a single-pass flow.

The case where top-down pre-synthesis partitioning can be most powerful is whenperformance, especially inter-FPGA performance, is crucial. By working top-downand using the system-level constraints, a pre-synthesis partitioning flow allows fortiming to be budgeted and constrained across multiple FPGAs at the same time. Thesynthesis is also more able to account for board-level delays and pin-multiplexing inorder to correctly constrain the individual FPGAs later in their respective flows.

Post-synthesis partitioning flow

As the name suggests, post-synthesis partitioning takes place after synthesis at the netlist level. Figure 30 shows how individual modules are synthesized and mapped into FPGA elements individually, resulting in numerous gate-level netlists. The netlists are combined into a hierarchy and then re-grouped into FPGA-sized partitions. At the same time, the netlists are conditioned for FPGA (e.g., gated clocks are changed to enables) and wrappers are created for modules which will be modeled externally (e.g., RAMs). We will discuss wrappers in detail in chapter 7. 

The main advantage of post-synthesis partitioning is that only those RTL source files which have changed are re-synthesized, the results of the other RTL files being adopted without change. The resultant netlists are merged and the partitioning results are also likely to be reusable except in cases where module boundaries have altered. This lends itself to easier automation and scripting as a flow.

Figure 30: Post-synthesis partitioning flow

Another advantage of post-synthesis partitioning comes from the flow being a

Table 5: Comparing partitioning flows

natural single-pass flow. That means that by the partitioning stage, the design isalready mapped into FPGA resources and timing information is accurate enough toallow more accurate partitioning decisions. There is therefore no need for a pre-runon the synthesis in order to estimate resources.

Table 5 makes a short comparison between pre-synthesis and post-synthesispartitioning flows based on the discussions above.

The choices are between a faster turn-around time and more automation on the onehand, and best results on the other hand.

Alternative netlist-based partitioning flow

There are some teams that advocate an alternative flow for FPGA-based prototyping in which the synthesis is performed by the normal SoC synthesis tools and it is the resultant gate-level netlist, or hierarchy of netlists, that becomes the input for the rest of the flow. Figure 31 shows this netlist-level flow. Here we note that normal SoC synthesis is used and the design is mapped into the same cell library as for the final SoC. The task of mapping the design into FPGA elements is performed at a cell-by-cell level, via an intermediate format where the .lib cells are replaced with their functional equivalent. During the SoC synthesis, netlists may be manipulated using built in group and ungroup style commands to do the job of partitioning. The same top-level tasks still need to be performed as in the other partitioning flows i.e., 

objects unsuitable for FPGA implementation need to be isolated and doing this at a netlist level might be too complex for many users.

Figure 31: Alternative SoC netlist-based flow

Nevertheless, netlist editors exist that allow very powerful manipulation of the design under the control of scripted netlist editor commands. Some find this preferable to changing RTL in order to do the same thing. We should understand that a netlist-based approach is likely to achieve lower performance and use more FPGA resources than the other flows because FPGA synthesis is limited to mapping a very fragmented design into FPGA low-level cells, missing many chances for optimization. All possibility of automatically inferring the high-level resources, such as DSP blocks or SRL functions of the logic elements from such a low-level netlist is lost. 

We shall cover more about our uses of partitioning tools in chapter 8 but let us now move on from the front-end steps in our FPGA-based prototyping tool flow and consider the remaining steps in the flow that take our partitioned synthesized design into the FPGAs themselves. 

Partitioning tool example: Certify®

Usually provided by third-party EDA vendors, these tools are used to automate and accelerate the partitioning of a single RTL code into multiple FPGAs. While partitioning can be done manually, for example by using group and ungroup commands and selective net-listing of subsets of the design, dedicated EDA tools significantly simplify and speed-up the initial partitioning and allow subsequent partitioning modification with ease. 

Figure 32: Screenshot of Certify partitioning environment

Partitioning tools such as Synopsys’ Certify, pictured in Figure 32, perform a mix ofautomatic, interactive (drag-and-drop) or scripted partitioning. These kinds of toolsallow what-if exploration of the partitioning options which is important becausesome designs will not appear to have obvious partition boundaries to begin with.Tools that allow quick trials and provide immediate visibility of utilization andconnectivity can guide the users to better partitioning decisions than workingcompletely manually at the netlist level.

For example, in the Certify screen shot we can see an interactive partitioningsession is in progress. The top-level of the RTL is shown schematically in the centrepanel. Here we see the core of the design and a simple chip-support block alongside,in this case just clock and reset (we shall explain more about top-level partitioningin chapter 8). At the top panel, we see a representation of the board resources intowhich we can partition. In this case, a simple board with two FPGAs, a RAM,external IO connectors and a clock source. On the left of this panel we can also seethe board’s resources in a nested-list view, common to many EDA tools. In that listview and in the top-level diagram and other places we can see our progress as weassign various design elements to relevant board resources. We can also see otherassignments into each FPGA, such as our debug instrumentation (in this case,Xilinx ® ChipScope tools).

At each step, we get immediate feedback on how we are doing, for example, in thisshot, the FPGAs have histograms showing proportion of logic, memory and IO usedso far. Another useful guide for interactive partitioning is the connectivity matrix,showing the inter-block connections at this level of the design; this shot shows thatthere are 128 connections between the core of the design and the system-levelinterface (i.e., external IO).

Some further detail of the use of Certify tools, including pin multiplexing, fine-grainpartitioning by logic replication and clock domain rationalization is given in chapter7 and 8.