FONT SIZE : AAA
Figure 26 shows the basic flow that we follow in the FPGA-based prototypingprocess:
Let’s quickly look at each of these steps in turn.
• Synthesis: may e performed before or after partitioning. The process ofconverting RTL into an FPGA netlist. The synthesis process generates anFPGA netlist for the device of choice, and the implementation constraintsto be used by the FPGA back-end tools. In addition, some synthesis toolsprovide early estimation of the expected performance, which allows the
modified to better fit the FPGA technology and the specific prototypingplatform. Typical modifications to the SoC RTL include the removal ofblocks not to be prototyped, replacing some SoC-specific structures withFPGA structures like clock generation and other IP, and resizing blockslike memories to better fit in FPGA.
• Partitioning: the process in which the FPGA-ready version of the SoCRTL design is divided into blocks that map into individual FPGAs. Thisstep is needed for designs that do not fit into a single FPGA. Partitioning can be done manually or using partitioning tools. A number of approaches to partitioning were explored in chapter 3.
• Constraint generation: this is a convenient point in the flow to enter the various implementation constraints such as timing and pin placements. Although constraints may be generated and applied to the back-end tools after synthesis, doing so prior to the synthesis step allows synthesis to produce an FPGA netlist that is more optimized to meet the area/speed constraints after place & route.
• Place & route: the process of converting the FPGA netlist and the user constraints into an FPGA bit stream which will be loaded into the FPGA to provide it with the design functionality. This is often simply referred to as place & route, but in fact involves a number of steps such as mapping, place & route and timing analysis.
We will take a closer look in particular at all of the implementation steps but we do not plan to cover the verification stages in this book except to recommend that as much as possible of the existing SoC verification framework is maintained for use during the prototyping project.
At all points in the flow it is important to have ways to verify our work to that point. Re-using the original RTL testbenches and setup may require some adaptation to match the partitioned design. For example, after partitioning, a top-level netlist is required to link the partitioned FPGA netlists into a whole SoC design; often this top-level can be generated by the partitioning tools themselves.
Even if not for the whole design but for only sub-functions, maintaining a verification framework will pay us back later when we need to check functional issues seen in the design on the bench.
Manufacturer:Xilinx
Product Categories: FPGAs (Field Programmable Gate Array)
Lifecycle:Active Active
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: FPGAs
Lifecycle:Active Active
RoHS:
Manufacturer:Xilinx
Product Categories:
Lifecycle:Active Active
RoHS: -
Manufacturer:Xilinx
Product Categories: FPGAs
Lifecycle:Active Active
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: Embedded - FPGAs (Field Programmable Gate Array)
Lifecycle:Active Active
RoHS: No RoHS
Support
