How to constrain my design

[Altera_Forum]

Hi, 

 I'm not sure how I should constrain my design and which timequest commands I should use.  In my design there are 5 clock domains. The are clock domain crossing from 4 clocks to the 5th. So to clarify:   A, B, C, D and E are my clocks. Clock domain crossings are : [A <-> E], [B <-> E], [C <-> E] and [D <-> E].  There is only a single 32 bit databus crossing the clock domains and with the databus is a write strobe, which has been synchronized to the new clock domain.   I know, from calculations, that the shortest amount of time from the source write strobe to the destination write strobe is 12 ns. So I believe that my data needs to be stable before 12 ns in worst case.  But I'm not sure how I write this in my SDC file. I've been looking at the set_max_delay and set_min_delay, but I'm not sure how to use them properly.  Can someone please advice?

[Altera_Forum]

I suggest you start with a TimeQuest tutorial, so you get a grasp of the basic constraints 

On the Wiki you also find a very clear guide written by forum member Rysc: http://www.alterawiki.com/wiki/timequest_user_guide IMHO this is even better than the standard TQ tutorial from Altera

[Altera_Forum]

--- Quote Start ---   There is only a single 32 bit databus crossing the clock domains and with the databus is a write strobe, which has been synchronized to the new clock domain.    --- Quote End ---    So you have an interlocked handshake? Eg. something like:  1) Clock domain A writes the data to the data register, and asserts the "data is ready" signal.  2) A synchronizer synchronizes the "data is ready" from the clock A domain into the clock E domain.  3) Logic in the clock E domain enables a register to capture the data from the clock A domain.  If that logic is in place, then *you* have taken care of the clock synchronization issues, and so you need to communicate this to TimeQuest by telling it to ignore signals that cross the clock domains, eg.,   # Clock A and virtual clock for I/O constraints create_clock -period 10MHz -name clk_a create_clock -period 10MHz -name vclk_a # Clock B and virtual clock for I/O constraints create_clock -period 25MHz -name clk_b create_clock -period 25MHz -name vclk_b # Clock groupings set_clock_groups -exclusive -group -group   The clock groupings separate the analysis of clock A and B, and tell TimeQuest that you've taken care of clock crossing.  Let me state that again just to emphasize it; that "YOU" have taken care of clock crossing. If you forget to include synchronizing logic, or you do it wrong, TimeQuest will not tell you :)  Cheers, Dave

[Altera_Forum]

Hi Dave, 

 You are correct about your assumption. I actually tried your proposal, but like you said "I" have taken care of the clock crossing and TimeQuest will not tell me if I messed up somewhere and this got me thinking... I know that it takes the data ready signal around 12 ns to be synchronized to from clock A domain into clock E domain. Doesn't this mean that I have to tell TimeQuest that the data from clock A domain needs to be stable at clock E domain before 12 ns, which is the point where the data gets captured from clock A domain?  I'm thinking that I need to put the following commands in the SDC file:   - set_max_delay -from [get_clocks {clk_a}] -to [get_clocks {clk_b}] 11 ns  - set_max_delay -from [get_clocks {clk_b}] -to [get_clocks {clk_a}] 11 ns  Is this assumption correct?  Br, David

[Altera_Forum]

The only situation in which you can cross a clock domain and have signals synchronous, but delayed, would be if the clocks are synchronous. If that was the case, then you could create time constraints between the two clock domains. However, if you have added synchronizing logic between the domains, that implies you consider the two clock domains independent, in which case you may was well tell TimeQuest the same thing. 

 So what is your situation, are those clocks really synchronous?  Cheers, Dave

[Altera_Forum]

Hi David, 

 you can constrain the paths with the 'set_net_delay' command from sdc_ext package. I wrote a tcl wrapper for it:  proc set_q_fanout_net_delay {src delay} { set_net_delay -max $delay -from -to * } # and use it like this: set_q_fanout_net_delay *my_module_0|my_registered_signal "5 ns"   To see the if the constrints were met you can run the command 'report_net_delay' in timequest. Note that the default timing analysis script will not check these constraints so you have to run this command to see if they're met.  You can make quartus run the 'report_net_delay' command automatically with following recipe: 1. put this in a tcl file (eg. report_net_delay.tcl) : report_net_delay -panel {Net Delay Constraints}  2. add this to your .qsf file: set_global_assignment -name TIMEQUEST_REPORT_SCRIPT "../scripts/report_net_delay.tcl"  Next time you run Quartus compile you should see an entry under Timequest in the reports pane.  However, I think the most important thing is that you let quartus know that your clock domains are asynchronous and that you have the synchronizer chain detection on.  Regards Magne

[Altera_Forum]

David, 

I would suggest to use a (small) DC FIFO to handle that clock crossing.