cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
493 Views
Registered: ‎02-14-2020

Clocking constraints problem: How to overwrite auto-generated constraints

 

 Hello,
I'm struggling with some funny clocking architecture I need to implement, I've attached a sketch to try to explain the problem. We are using the GTH in transmit mode. There are two main modes of operation, one (mode A in my picture) which runs at 297MHz, and another Mode B which runs at 200MHz in the GTH, but the actual logic needs to run at 10/9x faster than this, i.e. 222.222MHz. We've got an MMCM to generate the 222MHz clock, and a gearbox to cross back to the 200MHz domain when in mode B. I don't care about the output of the mode B logic when I'm in mode A, and vice versa. I'm having trouble telling vivado that the clock at point "A", on the input of the x 10/9 MMCM is at 200MHz - it always overwrites anything I tell it and goes with the worst case 297MHz. In reality I don't care what the MMCM or mode B logic does in that case. Unless I can convince vivado that the clock at point A is at 200MHz, I'll need to optimize all the mode B logic to go faster, when in reality it will never be run that fast. Do you have any suggestions?

Thanks,
Alex

 

 


Clocks_sketch.jpeg

0 Kudos
5 Replies
Highlighted
Xilinx Employee
Xilinx Employee
429 Views
Registered: ‎05-14-2008

Try use -combinational option of create_generated_clock at point A and see if that works.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
354 Views
Registered: ‎02-14-2020

OK - but I can't see how on it's own "-combinatorial" would help. I need to somehow tell Vivado that the clock is 200MHz rather than 297MHz.

I am trying something today, where I pass the clock through some logic on the FPGA fabric then pass it through a BUFG to get it back into the clocking network. I'm hoping that because Vivado doesn't know what I've done to the clock in th efabric, I might be able to trick it into thinking it's MAX rate is lower than what it is in reality. I've attached a picture to explain what I'm trying.

 

clk_trick.jpeg

0 Kudos
Highlighted
346 Views
Registered: ‎02-14-2020

FYI: I get

CRITICAL WARNING: [Common 17-170] Unknown option '-combinatorial', please type 'create_generated_clock -help' for usage info. [/home/bristolbuild/.jenkins/workspace/nefario_hdmi_2_1/chaz/syn_dl_sdi_8k/timing.xdc:27]

I'm running with Vivado 2018.2

 

Alex.

0 Kudos
Highlighted
345 Views
Registered: ‎02-14-2020

Ahaha It's because it's spelt wrong!!!

0 Kudos
Highlighted
271 Views
Registered: ‎02-14-2020

OK I think I have a solution that will work:

1) Put the 200/297MHz clock into the MMCM directly.

2) Choose MMCM settings such that if there were a 297MHz ref clock it outputs a frequency just above my desired 222.2MHz. In reality I got it to go about 242MHz. This means Vivado will synthesize all my Mode B logic at 242MHz. Near enough.

3) Make a state machine to use DRP when the block comes out of reset to overwrite the MMCM settings. The new settings are such that with a 200MHz ref clock, the MMCM will generate 222.2MHz exactly.

With this scheme I can see the tool is synthesizing the logic at 242MHz, but I've yet to debug the rest of the system and make it actually work! I'm confident this is a solution that will work.

Seems a bit weird that I can't just overwrite auto-generated constraints, and it's a shame to have to throw LUTs at the problem. Does anyone from Xilinx has any better suggestions? When I have more time I could come back and try to fix it in constraints?

0 Kudos