cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
5,070 Views
Registered: ‎07-24-2016

Confused on timing constraints

Jump to solution

Hi everyone,

 

I have a design with a component that creates packets, and a FIFO (at a different hierarchy level) that accepts the data. I assert the FIFO's wr_en from the packet formatting instance and I want to constraint its datapath. Both instances are clocked by the same clock.

 

I tried adding this line at the .xdc:

set_max_delay -from [get_pins {packet_formation_instance/daqFIFO_wr_en_reg/Q}] datapath_only -2

But I get this warning:

 

[Common 17-165] Too many positional options when parsing '2', please type 'set_max_delay -help' for usage info. ["/home/Documents/done/constrs_1/constraints.xdc":1]

 

I have a feeling that I am doing something very wrong. If both instances are clocked by the same clock do I have to use set_max_delay? Is there a better solution for this? Another command?

 

Thanks!

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Teacher
Teacher
9,534 Views
Registered: ‎03-31-2012

>> 

set_max_delay -from [get_pins {packet_formation_instance/daqFIFO_wr_en_reg/Q}] datapath_only -2

 

this should be "-datapath_only 2" for the command to work properly.

 

But for the case "Both instances are clocked by the same clock" you don't need this at all. The timing engine is capable of timing this path.

For the single clock case, you just have to create a clock (create_clock) pointing to the source of the clock and its period. That will tell the timing engine how to process all relevant paths.

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

View solution in original post

4 Replies
Highlighted
Teacher
Teacher
9,535 Views
Registered: ‎03-31-2012

>> 

set_max_delay -from [get_pins {packet_formation_instance/daqFIFO_wr_en_reg/Q}] datapath_only -2

 

this should be "-datapath_only 2" for the command to work properly.

 

But for the case "Both instances are clocked by the same clock" you don't need this at all. The timing engine is capable of timing this path.

For the single clock case, you just have to create a clock (create_clock) pointing to the source of the clock and its period. That will tell the timing engine how to process all relevant paths.

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

View solution in original post

Highlighted
Adventurer
Adventurer
5,037 Views
Registered: ‎07-24-2016

muzaffer,

 

Thank you for your fast and precise reply. It really helped. As you have understood, I don't have serious .xdc/constraining experience and I am currently reading ug903 for more info.

 

Can I ask another more general question? Suppose that I have two different instances that are in different hierarchy levels (like my original post, the packet formation instance and the FIFO). Would it be a good choice to create a custom IP out of these two? Does a custom IP have more "strict" constraints in its internal circuitry? Does vivado implement it as a block and therefore packs its registers/LUTs/rams closer together? Because if it does, wouldn't that be a good alternative over constraining every single datapath between the previously separated blocks?

 

Thanks again

0 Kudos
Highlighted
Explorer
Explorer
5,011 Views
Registered: ‎11-25-2015

@cbakal

 

Even if you create the custom IP, you should specify the IP constraints. Refer http://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_2/ug1118-vivado-creating-packaging-custom-ip.pdf for more details.

 

Thanks,

Sravanthi

Highlighted
Teacher
Teacher
4,998 Views
Registered: ‎03-31-2012
>> Would it be a good choice to create a custom IP out of these two?
If you plan to use it again in the future probably so.

>> Does a custom IP have more "strict" constraints in its internal circuitry?
Not really or not that I am aware of.

>> Does vivado implement it as a block and therefore packs its registers/LUTs/rams closer together?

No. At least not because they are in the same custom IP. Vivado considers connectivity for packing & other placement. So even if they are not in the same custom IP, they would be packed together if connectivity suggests so.

>> Because if it does, wouldn't that be a good alternative over constraining every single datapath between the previously separated blocks?

Again, for a synchronous single clock system with edge based registers, there is no reason to constrain "every single datapath". You need to create one clock constraint which the timing engine enforces on every path created by this clock.
- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.