cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
10,471 Views
Registered: ‎04-26-2013

what's the differences among NET, INST, PIN key words in a UCF file

Jump to solution

Hello,

   I want data output from doutb ports of a ram writing into a reg doutb_q in 5ns, so I add a constrain like this:

 

INST "doutb" TNM = "doutb";

INST "doutb_q" TNM = "doutb_q";

TIMESPEC "TS_doutb_to_doutb_q" = FROM "doutb" TO "doutb_q" 5 ns;

 

but translate report tells that there is no signal match "doutb_q" in the design.

please give me some advise about:

what's the differences among NET, INST, PIN and how to add a reg in a verilog HDL source into a timing group in UCF.

thank you

1 Solution

Accepted Solutions
Highlighted
Guide
Guide
14,093 Views
Registered: ‎01-23-2009

So, a couple of things...

 

When it is said that a FROM TO constraint has higher prioirity than a PERIOD constraint, it simply means which one will be used when the two cover the same path. If a PERIOD constraint covers a path with a 10ns period, and a FROM TO covers the same path with a 12ns constraint, then the path will end up with a 12ns constraint (since the FROM TO has higher priority than the PERIOD constraint). It does not determine how hard the tools work on the path (or anything like that).

 

If your path is failing timing, you need to understand the root cause. You need to analyze the timing report of the failing path and determine why it is failing. If the path is from BRAM to BRAM (with a bit of combinatorial logic between them) the path could be failing due to placement - BRAMs can be fairly far apart from eachother if they get into different columns. You would see this in the timing report - you would have a net with a long delay and a small fanout.

 

In this case, your choices are to try and LOC (or floorplan) the RAMs to "better" locations (although the tools have probably placed the BRAMs in their locations for a reason) or to pipeline your design further to allow another clock cycle for the path.

 

Remember, the clock->Q times of the RAM outputs are quite long - something like 2.5ns. So, 1/2 of your 5ns period is already gone. If you can tolerate another clock of latency, you could consider setting the DOA_REG (or DOB_REG) instead of adding pipelining. This increases the latency by one clock, but gives you a much faster clock->Q.

 

Avrum

 

 

 

 

View solution in original post

0 Kudos
7 Replies
Highlighted
Explorer
Explorer
10,462 Views
Registered: ‎01-16-2013

Hi,

 

INST is an element such as a flip flop, register or pad in a design.

NET is a signal path, a route between one point (such as a flip flop, register or pad) to another.

The PIN constraint in conjunction with LOC defines a net location.

The PIN/LOC UCF constraint has the following syntax:
PIN "module.pin" LOC="location";

Regards,

Vishal

Highlighted
Guide
Guide
10,453 Views
Registered: ‎01-23-2009

An INST is an instance - it refers either to a primitive instance (like a flip-flop or BRAM or SRL or LUT) or to a hierarchical instance (the instantiation of a module/entity).

 

A PIN is a pin on an instance - again, either a primitive instance or a hierarchical instance. So the D and Q on a flip-flop are pins. Also when you instantiate a module/entity that has a port (say, named A), when the module/entity is instantiated, the instance has a PIN named A.

 

A NET is something that connects pins together.

 

Now, the more important thing to ask is "what can you do with them". For timing constraints like the TIMESPEC command you can only place constraints on paths; these start and end at clocked elements. The TNM command is for Timing NaMe, which is the way that we create groups of endpoints for the TIMESPEC. Therefore, only clocked elements can be in the TNM. The INST/PIN/NET format for TNMs mean different thing

  - INST on a primitive object - put that object in the TNM - but only if it is a clocked element (FF, LATCH, SRL, RAM, DSP...)

  - INST on a hierarchical object - put all clocked elements in that hierarchical object in the group

  - NET - put all clocked elements that are combinatorially reachable from that NET into the group

  - PIN - put all clocked elements that are combinatorially reachable from that PIN into the group

 

In your case, the doutb_q is a FF, so it can be put in a TNM, but the doutb is a pin of the RAM, and hence cannot be put in a group - it is not a clocked element. The RAM itself can be put in a group if you need to...

 

However, what you are trying to do is very strange. WHY do you want the path from the RAM to the FF to be 5ns. Normally, you use a RAM as part of a synchronous system - the RAM to the FF should (and probably must) be clocked by the same clock (or at least a related clock). If this is the case, then the constraint is naturally done using a PERIOD constraint on the clock (or clocks) involved - not using a FROM TO, which is an "exception" constraint.

 

So, why do you think you need this constraint?

 

Avrum

Highlighted
Visitor
Visitor
10,443 Views
Registered: ‎04-26-2013

Hi, Avrum:

  thanks for your explanation, it's detailed and helpful. I know what are"NET/INST/PIN" now.

  actually as what you said, the RAM and the FF are clocked by the same clock. But when I use a PERIOD constraint, the STA tells that the setup path doesn't match the demand. In my project, "doutb_q" is another BRAM's input buffer and there is some simple logic between "doutb" and "doutb_q" like "doutb_q <= 2'b1 - doutb" in some special if/case conditions. I got some information that local constraints have higher priority than global constraints, so I tried to use a local constraint like FROM TO to make sure my part's timing performance will not affected by other parts. Will this constraint be useful or should I optimize my source code in some other ways?

0 Kudos
Highlighted
Guide
Guide
14,094 Views
Registered: ‎01-23-2009

So, a couple of things...

 

When it is said that a FROM TO constraint has higher prioirity than a PERIOD constraint, it simply means which one will be used when the two cover the same path. If a PERIOD constraint covers a path with a 10ns period, and a FROM TO covers the same path with a 12ns constraint, then the path will end up with a 12ns constraint (since the FROM TO has higher priority than the PERIOD constraint). It does not determine how hard the tools work on the path (or anything like that).

 

If your path is failing timing, you need to understand the root cause. You need to analyze the timing report of the failing path and determine why it is failing. If the path is from BRAM to BRAM (with a bit of combinatorial logic between them) the path could be failing due to placement - BRAMs can be fairly far apart from eachother if they get into different columns. You would see this in the timing report - you would have a net with a long delay and a small fanout.

 

In this case, your choices are to try and LOC (or floorplan) the RAMs to "better" locations (although the tools have probably placed the BRAMs in their locations for a reason) or to pipeline your design further to allow another clock cycle for the path.

 

Remember, the clock->Q times of the RAM outputs are quite long - something like 2.5ns. So, 1/2 of your 5ns period is already gone. If you can tolerate another clock of latency, you could consider setting the DOA_REG (or DOB_REG) instead of adding pipelining. This increases the latency by one clock, but gives you a much faster clock->Q.

 

Avrum

 

 

 

 

View solution in original post

0 Kudos
Highlighted
Visitor
Visitor
10,419 Views
Registered: ‎04-26-2013

You are so NB! What you said is really what I met! There is a net with a long delay and a small fanout in timing report, and it connects the doutb port of a RAM and the reg "doutb_q". The forward RAM with the reg "doutb_q" for input buffer is on another column far from source RAM. I also noticed the output of a RAM has a delay of about 2.5ns but did not know what to do with it! I am now tring to fix RAMs of my part in one area and it seems working. I'm considering to set a DOB_REG if there are still problems.

but I still want to confirm two things:

If a PERIOD constraint covers a path with a 10ns period, and a FROM TO covers the same path with a 8ns constraint, what constraint will the path end up with?

Whether a path crossing different columns will take longer time than that crossing different rows?

 

thanks for your great help!

0 Kudos
Highlighted
Guide
Guide
10,414 Views
Registered: ‎01-23-2009

If the PERIOD constraint is 10ns and the FROM TO is 8, then the path will be constrained to 8ns. However, this will not make any difference.

 

If the tool cannot meet the 10ns constraint, changing it to 8ns will just mean that it violates by 2ns more - the tool can't work "harder" on it becuase it fails by more.

 

One thing that confuses this is that the place/route process is "chaotic" - if you change anything, you can end up with a different result. If you change any line of code, you may end up with a different placement, and that new placement will have different timing (and may even meet timing - just by chance). Changing the constraint is changing "something" so it can occasionally happen that you put this additional constraint in, and, just due to luck, you meet timing - however, there is no cause and effect to this - it just happened.

 

Furthermore, if the tool can meet the 10ns requirement on some run, then having it constrained to 8ns will

  - make the tool run longer

  - generate a failing timing report that you have to interpret to see if it would work in system

 

In general, it is not recommended to over-constrain a path at the implementation stage.

 

As for whether going between colums takes longer than going between rows, the answer is yes, but not because of anything inherent in the horizontal/vertical direction. If you look at the FPGA composition, it is made up of columns of resources. In the case of BRAMs, you have a few columns of BRAMs in your device. These colums are distributed between many many columns of LUTs. So if you look at any one BRAM, the closest BRAM in the same column is right above it (and right below it) - not very far away. However, if you look at the next BRAM on the left/right, it is very far away - on the other side of a whole bunch of columns of LUTS. It is this distance that makes the route long.

 

Look at the layout of the device in planAhead or in FPGA Editor - you will be able to see how far the BRAM columns are from eachother.

 

Avrum

Tags (2)
Highlighted
Newbie
Newbie
3,703 Views
Registered: ‎01-11-2018

Hi,

https://www.xilinx.com/support/answers/29362.html

Can you put this into context. It says that the PADGROUP should be on the left and REGISTERGROUP should be on the right of the OFFSET IN constraint.

I am getting syntax error on doing so.

0 Kudos