cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
zomby99
Visitor
Visitor
888 Views
Registered: ‎06-28-2020

Timing analysis when using multiple clock enable signals

Jump to solution

Hi,

I have a design which contains a fast clock domain and a slow clock domain. I am implementing the slow clock domain by generating a clock enable signal from the fast clock (by counting rising edges). This controls one set of components in the slow domain. I am also generating a shifted clock enable signal to control a second set of components in the slow domain. So the situation looks something like this:

 

Counter                  0       1        2       3       4        5        0       1        2       3       4        5        0       1        2       3       ...

Fast clock:              |```|__|```|__|```|__|```|__|```|__|```|__|```|__|```|__|```|__|```|__|```|__|```|__|```|__|```|__|```|__|```|__

Clock en:                ________________________|```````|_______________________|```````|___________________

Shifted clock en:    __________|```````|_______________________|````````|______________________ |````````|____

 

In the slow domain, data gets transferred from registers which run with the clock enable, into memory components which run with the shifted clock enable. When I increase the fast clock frequency and adjust the counter values to account for this, I would expect that the setup and hold times for these register and memory components would not change. However, when I implement the design and look in the timing summary, I am seeing that the WNS drops significantly.

My fast clock is generated by the Zynq 7 PS, and I am not providing any timing constraints. Do I need to? Or is there a fundamental problem with the way I'm doing this?

Any help appreciated! Thanks.

0 Kudos
1 Solution

Accepted Solutions
richardhead
Scholar
Scholar
802 Views
Registered: ‎08-01-2012

markg@prosensing.com 

Surely, creating the faster clocks actually can produce more of a headache? everything will need to go through safe CDCs to get data around. Using the clock enables means you can time everything within the same domain but you can use multicycle path requirements to ease the setup and hold times for the registers on the MCP (multi-cycle paths).

Using either will require some careful constraint planning.

For the MCP method, you're going to have to get used to writing constraints and learning the commands needed, and reading the tcl reference manual (https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug835-vivado-tcl-commands.pdf)

1. You will always need a constraint for the base clock.

2. You will need a setup constraint for each regisiter where the source AND destination register use a clock enable, equal to the number of clocks between each enable

3. You need a hold constraint for every path above of one less that the number of clocks between enables.

2 and 3 might look like something like this:

# Set 6 clock MCP from clk_en
set_multicycle_path -setup 6 -from [get_pins clk_en_reg/C] -through [get_nets clk_en]
set_multicycle_path -hold 5 -from [get_pins clk_en_reg/C] -through [get_nets clk_en]

#3 cycle MCP from clk_en to shifted_clk_en
set_multicycle_path -setup 3 -from [get_pins clk_en_reg/C] -through [get_nets shifted_clk_en]
set_multicycle_path -hold 2 -from [get_pins clk_en_reg/C] -through [get_nets shifted_clk_en]

MCPs can take a lot of load out of the routing when it knows it has a slacker constraint in which to do the routing, but you have to be really careful you define the MCPs and paths correctly. Adding MCPs to incorrect paths could put a large delay on a path where a short one is needed.

All of this can be tested on the TCL console on a synthed or implemented design to ensure you get path names correct, and it will even update the timing results for input commands.

View solution in original post

5 Replies
830 Views
Registered: ‎01-22-2015

@zomby99 

You've got some interesting ideas!  However, with your "clock en", I think you are trying to do things that are best left to Vivado timing analysis.

I am not providing any timing constraints. Do I need to? 
Yes, you must (as a minimum) write timing constraints to tell Vivado about the clocks you are using.  Otherwise, timing analysis cannot run correctly.

I am implementing the slow clock domain by generating a clock enable signal from the fast clock (by counting rising edges). 
It sounds like you have created signals that look like clocks  - but they are not real clocks.  Using these "not real clocks" will make it difficult for your design to pass timing analysis.  

I suggest that you do the following to create a slow "real clock" for your design and use it (instead of enable signals) to clock your registers and memory components:

  1. Use the the Clocking Wizard IP that is described in Xilinx document PG065 to setup a MMCM clock module on the PL side of your Zynq.
  2. The input to the MMCM is your fast-clock
  3. The output of the MMCM is your slow-clock

When you use the Clocking Wizard to setup the MMCM, it will automatically write a create_clock constraint for the fast-clock and it will automatically write a create_generated_clock constraint for the slow-clock.   These two timing constraints are all you should need.

Once you've done this, again run timing analysis.  If your design is failing timing analysis then show and describe to us the paths that are failing timing analysis.

Cheers,
Mark

 

 

 

richardhead
Scholar
Scholar
803 Views
Registered: ‎08-01-2012

markg@prosensing.com 

Surely, creating the faster clocks actually can produce more of a headache? everything will need to go through safe CDCs to get data around. Using the clock enables means you can time everything within the same domain but you can use multicycle path requirements to ease the setup and hold times for the registers on the MCP (multi-cycle paths).

Using either will require some careful constraint planning.

For the MCP method, you're going to have to get used to writing constraints and learning the commands needed, and reading the tcl reference manual (https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug835-vivado-tcl-commands.pdf)

1. You will always need a constraint for the base clock.

2. You will need a setup constraint for each regisiter where the source AND destination register use a clock enable, equal to the number of clocks between each enable

3. You need a hold constraint for every path above of one less that the number of clocks between enables.

2 and 3 might look like something like this:

# Set 6 clock MCP from clk_en
set_multicycle_path -setup 6 -from [get_pins clk_en_reg/C] -through [get_nets clk_en]
set_multicycle_path -hold 5 -from [get_pins clk_en_reg/C] -through [get_nets clk_en]

#3 cycle MCP from clk_en to shifted_clk_en
set_multicycle_path -setup 3 -from [get_pins clk_en_reg/C] -through [get_nets shifted_clk_en]
set_multicycle_path -hold 2 -from [get_pins clk_en_reg/C] -through [get_nets shifted_clk_en]

MCPs can take a lot of load out of the routing when it knows it has a slacker constraint in which to do the routing, but you have to be really careful you define the MCPs and paths correctly. Adding MCPs to incorrect paths could put a large delay on a path where a short one is needed.

All of this can be tested on the TCL console on a synthed or implemented design to ensure you get path names correct, and it will even update the timing results for input commands.

View solution in original post

790 Views
Registered: ‎01-22-2015

@zomby99 

In the slow domain, data gets transferred from registers which run with the clock enable, into memory components which run with the shifted clock enable. 

In the above sentence, do mean that the fast clock is routed to the clock (C) pin of the registers and the memory component?  -and that the "clock enables" are going to the CE pin of these devices?

I may have misunderstood what you are doing.  For some reason, I understood you were using the "clock enables" as slow clocks or gated clocks (ie. routing them to the C pin of devices).  Are you doing this?

Please describe the "memory component".

 

zomby99
Visitor
Visitor
745 Views
Registered: ‎06-28-2020

Thank you both for your replies.

markg@prosensing.com 

Yes the fast clock is routed to the clock pins of every device. The clock enable and shifted clock enable then go to the CE pins of the register and memory components, respectively. I am not using the clock enables as gated clocks . I understand that gated clocks are generally a bad idea? Apologies for the confusion.

The memory components are synchronous rams.

@richardhead 

Thanks for your advice with the constraints for multi-cycle paths. I need to consider which method is best in my case. There are quite a lot of registers, so the MCP method would mean a lot of constraints. In contrast, the area of the design where the two clock domains meet is quite small, so I'm now thinking it might be better to follow markg@prosensing.com's advice and use the clocking wizard to get a slower clock. It seems like this would require a smaller amount of logic/constraints to ensure safe CDCs. Does that seem like a reasonable way to assess it?

It'll probably be the weekend before I get the time to have another look at it, so I'll likely be back with more questions then! Thanks again to both of you for your help.

0 Kudos
737 Views
Registered: ‎01-22-2015

@zomby99 

I understand that gated clocks are generally a bad idea?
You are correct.

Yes the fast clock is routed to the clock pins of every device. The clock enable and shifted clock enable then go to the CE pins of the register and memory components.
Your initial explanation was good - I just didn't read it carefully.  @richardhead has understood what you wanted and has given you good advice about using multicycle constraints.

However, as you say, it might be simpler (and successful in terms of timing analysis) to change the design.  Instead of using clock-enables, use a small clock crossing and then a slow-clock domain for the registers and ram.