Timing Analysis

[kumar.anand743@gmail.com]

hi,

I had a query regarding constraining path which is a clock driving the modules further. (Please find the attachment).

I am using the Spartan 6 SP605 platform and ISE 13.2 is the tool.

I have found an answer in the answer records of xilinx http://www.xilinx.com/support/answers/18877.htm.

I wanted to know whether this answer holds good if I use global route(BUFG) on the data of a flip flop driving clock pins of forthcoming modules from it. 

Thank you.

[eteam00]

The diagram you posted should work.  The Answer Record is also correct: generating a clock in this manner will result in large skew between the original clock and the generated clock.

Have you considered generating a clock enable for use with the primary clock, rather than generating a lower frequency clock?  Do you understand how clock enable works, and how it might apply to your design?

-- Bob Elkind

[kumar.anand743@gmail.com]

Hi Bob,

If I use CE, then the design might probably look something like the one shown below (Correct me if I am wrong since I have not used CE earlier, I would use DCM to divide clocks but in this case a clock of few KHz needs to be generated hence unable to use DCM as the dividing factor is out of range).

But if I use CE, wont there be a problem of skew b/w CE and sys_clk  as shown below?

(Higher freq being that of sys_clk and lower one being that of CE) 

         +------------+           +------------+           +------------+           +------------+           +------------+           +------------+

____|                  |_____|                  |_____|                  |_____|                  |_____|                  |_____|                  |_____|                  

 <skew>   <skew> <skew>

               +--------------------------------------------+                                                              +--------------------------------------------+

______ |                                                             |___________________________|

 In such situation as shown above (if at all it is possible),  I would never get the anticipated rising edge is it right ?

[eteam00]

If I use CE, then the design might probably look something like the one shown below.

Your block diagram is correct, your timing/waveform diagram is incorrect.

But if I use CE, wont there be a problem of skew b/w CE and sys_clk  as shown below?

The CE signal is not a clock.  Consider it a select signal for a 2:1 MUX.

CE = 0 :  FF.data = FF.Q (register is unchanged)

CE = 1 :  FF.data = new data

CE must meet the same timing requirements (setup and hold) as the data input to the (same) register -- no more and no less.

CE is a single-cycle pulse which occurs at a XXX frequency rate.

         +---+   +---+   +--           --+   +---+   +---+   +---+

CLK  ____|   |___|   |___|   ...         |___|   |___|   |___|   |___                   

          +-------+                           +-------+

CE  ______|       |________  ...      ________|       |____

-- Bob Elkind

[kumar.anand743@gmail.com]

Hi Bob,

thanks again for providing pretty useful information and clean understanding. I think CE is a much optimized solution.
I had this one doubt though - the following is my understanding: CE ticks the flop supposed to run at slower clock/derived clock, however it should not incur setup-hold violations at the launching flop(flop running at system clock driving CE into the flop in front) running at higher speed, and the data at the capturing flop(driven by CE ticks) at the receiving end should be analyzed for timing with regards to the slower CE frequency.

Is my understanding/analysis correct ?

[eteam00 · Accepted solution]

With respect to signal timing there will be two challenges, in particular:

• How to distribute the 200MHz rate CE clock enable to the entire fabric?

This is solvable.  It is easier to solve if the master clock isn't running quite so fast as 200MHz, or if the scope of logic which uses the CE clock enable is limited.  The solution is to allow ISE to duplicate -- as many times as it sees fit, to meet timing requirements -- the final register which drives the CE clock enable.  There is a ISE project property which specifically permits or prevents such register duplication.  Related constraints and attributes:  Max Fanout, Register Duplication (see UG627).

• How to tell the timing analyser to provide useful timing analysis based on the much slower CE rate (rather than 200MHz master clock rate), selectively and where appropriate.

This is also solvable, especially if your logic is implemented with modules which do not mix "slow" and "fast" logic together.  The solution is in the use of Multi-Cycle Paths timing constraints (see UG612, section titled "Multi-Cycle Paths", and section titled "From:To (Multi-Cycle) Constraints"), using named logic groups.  The slower timing path constraints should only be applied to logic paths between "CE" registers.  Timing paths between "CE" and "non-CE" registers must work at full master clock bandwidth (200MHz).

-- Bob Elkind

[ywu]

Just thought to mention that all logic driven by a net (the clock enable in this case) can be easily grouped together with TNM_NET constraint. Check  UG625 Constraints Guide for more details on the TNM_NET constraint. (By the way, download Xilinx Document Navigator to manage all Xilinx documents)

---

eteam00 wrote:

• How to tell the timing analyser to provide useful timing analysis based on the much slower CE rate (rather than 200MHz master clock rate), selectively and where appropriate.

This is also solvable, especially if your logic is implemented with modules which do not mix "slow" and "fast" logic together.  The solution is in the use of Multi-Cycle Paths timing constraints (see UG612, section titled "Multi-Cycle Paths", and section titled "From:To (Multi-Cycle) Constraints"), using named logic groups.  The slower timing path constraints should only be applied to logic paths between "CE" registers.  Timing paths between "CE" and "non-CE" registers must work at full master clock bandwidth (200MHz).

-- Bob Elkind

---

[alexhip3]

Thanks for the information and the diagram.

I'm not doing anything like that but gave me some ideas that comment as just.

From time to learn.
Have a nice day :D

[bassman59]

---

kumar.anand743@gmail.com wrote:
Hi Bob,

thanks again for providing pretty useful information and clean understanding. I think CE is a much optimized solution.
I had this one doubt though - the following is my understanding: CE ticks the flop supposed to run at slower clock/derived clock, however it should not incur setup-hold violations at the launching flop(flop running at system clock driving CE into the flop in front) running at higher speed ...

Is my understanding/analysis correct ?

---

Think of it this way -- the clock enable you generate using synchronous logic design techniques has the same setup/hold requirements as any other logic. One way to think of a clock enable is that it's "a second input to a D-flip-flop" and as such has to meet setup/hold just like the D input.  So the flip-flop itself is clocked by the fast clock, but it changes only when the CE is true, and the CE is just another logic input.

The good news is that if your clock enable is the output of some flip-flop-based divider, it has some amount of clock-to-out time built in, and as long as the routing delays are shorter than your period constraint (the fast clock), then you win.