FONT SIZE : AAA
There are situations where we may need to include logic modules in the design for which there is no RTL available, but the same functionality is available from another source. FPGA vendors, including Xilinx, offer a wide range of IP cores that can be placed into the design in place of the core instantiated in the SoC. These cores are often optimized for FPGA and should give better performance and area results than would have been achieved by simply porting the RTL of the original SoC IP. Note that these Xilinx® IP cores may not be used in the SoC (Xilinx only licenses its IP for use in its own devices).
Some examples for such IP are specialized memories, processors, communication controllers, multi-gigabit controllers and many more. The cores are in the form of a low-level FPGA netlist, either generated with a Xilinx supplied tool (CORE Generator tool) or from previous FPGA implementation. The IP is instantiated into the RTL source before synthesis which supports the inclusion of FPGA IP blocks in the following ways:
• Plain text netlist: the preferred method for including IP in the design, where synthesis reads the core’s FPGA-level netlist, optimizes it as necessary and includes the results in the output netlist. It also passes down timing constraints to the place & route tools if supplied by the user.
• White box: usually used when secured IP is included in the design and synthesis reads the core’s netlist to obtain timing information for the IP boundary, but does not optimize the core’s logic.
• Black box: usually used when secured IP is included in the design, and the black box attribute is specified. Modules defined as black boxes are treated by synthesis as “space holders,” where it does not read the core’s netlist (hence won’t optimize it). The IP/core will be included in the design at the place & route stage, when the associated pre-generated netlist will fill in the “black box” space. The tool however will pass to the place & route timing constraints if specified by the user.
The example we shall use is a PCIe-to-SATA bridge that was developed at the Synopsys IP development lab near Dublin, Ireland. Synopsys IP teams have used FPGA-based prototyping extensively to validate IP and its connectivity with external systems. In order to do so, demonstration and early-adopter platforms are created which need to closely resemble as many of the eventual targets for the IP as possible. The references give more details but the block diagram of the design is shown in Figure 132.
This example used the Virtex®-5 LS330 device on a HAPS-51 board to implement both the PCIe and SATA interfaces and the bridge between them; another testimony to the scale of modern FPGA devices. The interfaces use the built-in fast serial transceivers on the FPGAs and have bespoke blocks to drive from the cores to the FPGA-specific hardware, we can see the special FPGA-ready modifications labeled as pipe2v5gtp and sata2v5gtp. Pipe is an intermediate interface between the PHY of a PCIe interface and the rest.
This arrangement allowed the prototypers to fully test the two sub-systems with real world data and realistic speeds.
In an ideal world we would want to be able to clock IP at any chosen speed, from DC to 1GHz+ to allow us to fully validate the systems features and enhance debug and development. However, we know that a crossover point normally occurs at about 20-100MHz when we need to migrate from a simple clocked design to Figure 132: Top-level implementation of PCIe-to-SATA bridge design FPGA-Based Prototyping Methodology Manual 311 something that requires internal clock generation and de-skew logic as mentioned in chapter 8. This requires the use o PLL and MMCM type blocks but this will enforce a minimum operation speed on test chips and FPGAs alike. This is limited by the PLL/MMCM operating specification and it is risky to try to go slower than that, even if it may seem to work in the lab.
On another related note, the PLL in the SoC and the replacement in the FPGA may have different jitter, duty cycle, and even different frequencies of operation, drift, and accuracy, Therefore we need to be sure that the use of the MMCM or other clock circuitry is accurate and close enough to the SoC infrastructure give meaningful results. That is not usually in doubt for regular digital prototypes running within spec.
Manufacturer:Xilinx
Product Categories: CPLDs
Lifecycle:Active Active
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: CPLDs
Lifecycle:Active Active
RoHS:
Manufacturer:Xilinx
Product Categories: FPGAs (Field Programmable Gate Array)
Lifecycle:Obsolete -
RoHS:
Manufacturer:Xilinx
Product Categories: FPGAs
Lifecycle:Active Active
RoHS:
Manufacturer:Xilinx
Product Categories: FPGAs
Lifecycle:Active Active
RoHS:
Support
