cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
14,107 Views
Registered: ‎01-02-2008

Timing constraint for this situation

Jump to solution

Hi guys, 

I have a design that includes 2 modules, syncrhonous to each other, A & B, using the same clock "clk". 

 

However, A has to run in 2 modes where the clock "clk" may be either 150 or 300MHz.

In 150Mhz mode, Both A & B run, A & B talk to each other.

In 300MHz mode, the whole module B is not used,  and will be disabled. 

 

Question: how to set constraint  the clock inside B to be 150M and the clock outside B 300MHz.. I don't like to have any buffer. Any idea?

 

When I apply constraint to the clock net under B, it overwrites the previous clock setting, for example

 

create_clock -name shared_clk -period 3.333 [get_nets clk]

create_clock -name B_clk -period 6.666 [get_nets instance_B/B_clk]

 

Then the shared_clk disappear. 

 

What's the correct way to set constraints for this situation?

 

Thanks!!!

 

Jeff

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
23,208 Views
Registered: ‎11-28-2007

Hi Jeff,

 

I agree that in your case Brucey's suggestion won't work.

And I don't think Deepika's suggestion will work as well, as -add will only cause an additional 150MHz clock, not overload the 300MHz clock.

 

I think the following should work:

1) constrain everything as 300MHz

2) constrain everything as 150MHz

3) overload (do not specify -add) the clock input of module B with only a 150MHz clock

4) make sure Vivado doesn't see cross-clock paths between 300MHz and 150MHz

 

create_clock -name clock_300MHz -period 3.333 [get_nets clk]
create_clock -name clock_150MHz -period 6.666 [get_nets clk]
create_generated_clock -name B_clk -source [get_pins instance_B/B_clk] \
-divide_by 1 [get_nets instance_B/B_clk] -master_clock clock_150MHz set_clock_groups –physically_exclusive –group clock_300MHz –group [get_clocks clock_150MHz -include_generated]

 

 

Best regards,

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.

View solution in original post

9 Replies
Highlighted
Xilinx Employee
Xilinx Employee
14,102 Views
Registered: ‎03-24-2010

How about:

create_clock -name shared_clk -period 6.666 [get_nets clk]

create_clock -add -name A_clk -period 3.333 [get_nets instance_A/A_clk]

Regards,
brucey
----------------------------------------------------------------------------------------------
Kindly note- 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.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Adventurer
Adventurer
14,092 Views
Registered: ‎01-02-2008

Hy Brucey,

Thanks for your suggestion.

However, I have other logic running at the top above A & B using the shared_clk which should run at 300MHz. 

:-s

 

Thanks

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
14,072 Views
Registered: ‎09-20-2012

Hi,

 

Did you try below in that case

 

create_clock -name shared_clk -period 3.333 [get_nets clk]

create_clock -name B_clk -add -period 6.666 [get_nets instance_B/B_clk]

 

How are you choosing between the 150Mhz and 300Mhz clocks? Do you have a MUX? did you check set_case_analyis constraint?

 

Thanks,

Deepika.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
23,209 Views
Registered: ‎11-28-2007

Hi Jeff,

 

I agree that in your case Brucey's suggestion won't work.

And I don't think Deepika's suggestion will work as well, as -add will only cause an additional 150MHz clock, not overload the 300MHz clock.

 

I think the following should work:

1) constrain everything as 300MHz

2) constrain everything as 150MHz

3) overload (do not specify -add) the clock input of module B with only a 150MHz clock

4) make sure Vivado doesn't see cross-clock paths between 300MHz and 150MHz

 

create_clock -name clock_300MHz -period 3.333 [get_nets clk]
create_clock -name clock_150MHz -period 6.666 [get_nets clk]
create_generated_clock -name B_clk -source [get_pins instance_B/B_clk] \
-divide_by 1 [get_nets instance_B/B_clk] -master_clock clock_150MHz set_clock_groups –physically_exclusive –group clock_300MHz –group [get_clocks clock_150MHz -include_generated]

 

 

Best regards,

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.

View solution in original post

Highlighted
Adventurer
Adventurer
14,042 Views
Registered: ‎01-02-2008

Hi Vemulad, 

I've tried that but it didn't work as what I want. 

What it does is : it creates 2 names for the same net and analyzes 2 clocks. The slow clock meets timing with huge positive slack. The fast one doest meet timing in both A & B modules. 

 

In this situation, what i really want is: the tool should not try to route the module B to meet 300MHz. It should relax the routings for B and give "space" to the module A. 

 

The shared clock is returned from GTX, depending on the line rate, I will get either 150MHz or 300MHz. 

 

Thanks. 

 

Jeff

0 Kudos
Highlighted
Adventurer
Adventurer
14,041 Views
Registered: ‎01-02-2008

Hi Dries, 

This sounds reasonable.

I'll try and let you know.

 

Regards, 

Jeff

0 Kudos
Highlighted
Adventurer
Adventurer
14,028 Views
Registered: ‎01-02-2008
Awesome!!!!
IT WORKED !!!
THANKS!!!
KUDOS!!
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
14,018 Views
Registered: ‎11-28-2007

:-)

I'm happy to hear that!

 

- Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
0 Kudos
Highlighted
Visitor
Visitor
8,961 Views
Registered: ‎02-24-2014

I'm sorry to reopen this, but I have the exact same scenario, but unfortunately, driesd's solution doesn't seem to work for me (using Vivado 2014.4):

 

The first create_clock command is fine, but the second create_clock command returns with a critical warning:

CRITICAL WARNING: [Constraints 18-1056] Clock ' clock_250' completely overrides clock ' clock_500'.

 

"all_clocks" only returns the last clock (clock_250), not both.

 

The third command "create_generated_clock" fails with

ERROR: [Vivado 12-672] Cannot specify -master_clock without specifying -add.

 

My guess this is a problem with the my Vivado version 2014.4.

 

I tried a few things, but unfortunately without success so far:

 

The following test:

 

create_clock -period 2 -name clock_500 [get_ports clk_in]
create_clock -period 4 -name clock_250 -add [get_ports clk_in]
create_generated_clock -name fir_clk -source [get_pins design_1_i/hier_slow/aclk] -divide_by 1 -add -master_clock clock_250 [get_nets design_1_i/hier_slow/aclk]
set_clock_groups -physically_exclusive -group clock_500 -group [get_clocks clock_250 -include_generated]

which gave no warnings, but still resulted in Timing errors in design_1_i/hier_slow/, which showed that a 2ns period constraint was applied to hier_slow

 

The following test:

 

create_clock -period 2 -name clock_500 [get_ports clk_in]
create_clock -period 4 -name clock_250 [get_ports clk_in]
create_generated_clock -name fir_clk -source [get_pins design_1_i/hier_slow/aclk] -divide_by 1 -add -master_clock clock_250 [get_nets design_1_i/hier_slow/aclk]
set_clock_groups -physically_exclusive -group clock_500 -group [get_clocks clock_250 -include_generated]

gave a CRITICAL WARNING: [Constraints 18-1056] Clock ' clock_250' completely overrides clock ' clock_500', and  set_clock_groups  failed, because the clock_500 was no longer there.

 

 

The following test:

create_clock -period 2 -name clock_500 [get_ports clk_in]
create_clock -period 4 -name clock_250 [get_ports design_1_i/clk_in]
create_generated_clock -name fir_clk -source [get_pins design_1_i/hier_slow/aclk] -divide_by 1 -add -master_clock clock_250 [get_nets design_1_i/hier_slow/aclk]
set_clock_groups -physically_exclusive -group clock_500 -group [get_clocks clock_250 -include_generated]

gave no Critical warning and implementation gave no timing errors, so it first seemed to work, but when duplicating hier_slow as hier_fast (connected to design_1_i/clk_in), timing errors should have occurred in hier_fast, but suprisingly timing was met, so I assume, also hier_fast was constrained with 4ns from clock_250, instead of 2ns from clock_500.

 

It looks as if the constraint generated by create_generated_clock command is also applied to hier_fast, which is bad, as this part still needs to run at clock_500.

 

Any other ideas on how I can achieve the setup mentioned in the first post to relax timing constraints only for a block B (hier_slow), but keeping strict timing constraints for block A (hier_fast)?

 

Thanks!

 

Matthias

 

0 Kudos