When creating vivado IP of Xilinx, the options of globe and out of context per IP are different

from：https://www.fpgamall.com

Recently, I have a puzzle. When I use vivado ofXilinx products to generate IP,

There are two options: globe and out of context per IP, as shown in the following figure:

Which one should I choose?

1: Globe -- IP generated files will be integrated with other user files

Xilinx distributor stock,Authorized distributor of Xilinx products|Fpgamall

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

We can provide high-value solutions of part XCZU7EG-1FBVB900I Stock

Please send us a RFQ of XCZU7EG-1FBVB900I

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, my_ The signal will also maintain three state values

At the same time, if the module is connected to other parts, the connection is not available (for example, my)_ Signal signal is connected with "internal" module), and error will be reported in the synthesis process.

That's google site:https://sites.google.com/view/fpgamallcom/%E9%A6%96%E9%A1%B5
Tumblr:fpgamall-tumblr

You can chick it and tell me how you can do it 

Our  Component Hot products:

XC2V1000-4FG456I | XCZU7EV-1FBVB900E | XCZU7EV-1FBVB900I | XCZU7EG-1FBVB900E | XCZU7EG-1FBVB900I |