Let's talk about the difference between Xilinx's vivado IP generating globe and out of context per IP
Let's talk about the difference between xilinx distributor's vivado IP generating globe and out of context per IP
When using vivado of Xilinx to generate IP, there are two options: globe and out of context per IP, as shown in the following figure:
So, which one to choose?
1 Globe -- IP generated files will be integrated with other user files
2: Out of context per IP -- out of context mode, which only needs to be synthesized once and generates. DCP (Design) When the project needs to use IP, you only need to parse the corresponding IP netlist file from the. DCP file, and do not need to re synthesize the IP. This way can speed up the integration. The gobal selection is that each time the project is integrated, the IP core will be integrated with the project, and the integration time is very long, and the. DCP file will not be generated. OOC also uses a constraint file that is useful only in OOC mode_ ooc.xdc ”。 In addition to generating. DCP files, OOC will also generate an HDL file ending with "stub. V". It is a black box file of current IP design, with only input and output ports. When the project calls this file, it is actually parsing the net list file in. DCP, and then continues to synthesize and layout the lines.
However, if there are three states (high resistance state) in the design, the integrated operation of OOC will be affected
FPGA only supports the high resistance state of I / O output port, which is not allowed inside the device
If you use OOC synthesis, the vivado tool does not know whether a specific signal is connected to the I / O output or is connected inside the device
Finally, the synthesis tool converts the high resistance signal into a logical value instead of the highest resistance state for synthesis
For example, the following code will have a bad effect:
assign my_ signal = enable?din1:1’bz;
After OOC synthesis, my_ Signal signal value will not be high resistance value Z
Vivado synthesis has two options:
1. The comprehensive operation is in accordance with HDL code
(when the module unit is connected to the rest of the unit, if the signal is the most I / O output, then there is no effect.)
2 No reservation of three states
The vivado tool chooses item 2 because it's best to let the user know before any problems are likely to occur
This OOC usage mode is more popular with IP developers, but if there is a problem in IP integration into large-scale systems, it will be more troublesome, so item 1 should be avoided
At the same time, it will bring us the following problems:
If my_ How about signal signals only connected to external output I / O?
For example, in all available cases my_ Signals are all connected to the I / O interface, and I want it to drive a three state
I also hope to be able to use OOC mode to synthesize this part of the module - while retaining three states
The way to meet the above requirements is to instantiate a three state buffer in RTL
The details are as follows:
OBUF u1（.l（din1）， .T（n_ enable）， .O（my_ signal））;
In this way, it can ensure that even if the OOC integrated mode is adopted,Also Altera Distributors is look like. my_ The signal will also maintain three state values
Vivado is the second by default, out of context per IP refers to allowing vivado to synthesize IP separately and generate. DCP files. When IP is needed in engineering, it is only necessary to parse the corresponding IP netlist file from the. DCP file without re synthesizing the IP, which can speed up the speed of integration. The gobal selection is that each time the project is integrated, the IP core will be integrated with the project Sample synthesis takes a long time, and the global option will not generate. DCP files, because the source code of IP core is integrated during engineering synthesis.
(2) Add IP to your own project. Here we assume that the synthesis is carried out using out of context per IP. If we want to add IP and IP to our own project, we need the top-level design module of IP core. However, when using out of context per IP, only. DCP files containing netlist will be output, so the source code module will not be called directly when IP is used in the project. Instead, it will call a * stub. V black box module. This module value contains the input and output definitions of IP and top-level modules. On the surface of the project, this module is called, but in fact it is used to parse the net list in the. DCP file, so that the project can be integrated.
Copyright © 2020 fpgamall.com All rights reserved
评论
发表评论