TimeQuest Issue on CDC Synchronization on Control and Data Path

[Altera_Forum]

Hi everybody, 

I have an issue on appropriate TimeQuest Constrains on a Clock Cross Domain Design. My context is an external Synchronous bus with a control signal and a set of data signals: my design solution is  synchronize the control signal (CS) through a 2 flip-flop metastability filter to produce a related signal (CS_synch) synchronized on the destination domain. And then use the variation on CS_synch(a falling edge in my case) to determine when to sample stable the external data signals (referred as Data[*] ) on the destination domain as Data_synch[*] .  I don't think that set_false_path could be a comprehensive solution.  The problem is that I suppose that my design works as long as the phase relation between CS and Data[*] is preserved through the routing from the pins to the synchronization destination registers in the FPGA. In other words my design can afford a Data[*] routing path greater than CS path of a specific amount that depends on the internal clock frequecy.  Any suggestion?  I tried with set_max_skew or set_max_delay , but I'm not sure that any of these is the right way to match delays between multiples routes.  Thanks in Advance for any help! Claudia  PS: here an extract of my sdc  Solution 1 set_max_delay ----------------------------------  # EXT_BUS cycle time of core_clock, it is also the duration of each state of EXT_BUS EBI fsm (S0,S1 etc) set EXT_BUS_T_CYC_2_ns 6.7 # EXT_BUS CLKOUT high to chip-select CSn valid set EXT_BUS_T_CHCV_ns_MAX [expr $EXT_BUS_T_CYC_2_ns + 5] set EXT_BUS_T_CHCV_ns_MIN 0  # EXT_BUS CLKOUT high to data output (DATA[31:0]) valid (output in S2) set EXT_BUS_T_CHDOV_ns_MAX 9  # Max delay from EXT_BUS_CSn activation to data output (DATA[31:0]) valid # Taking as zero reference S0, the min delay for Csn activation and the max delay  # for Data Output valid set T_CSlow2DOV_MAX [expr $EXT_BUS_T_CYC_ns + 9]   set_max_delay -from [get_ports {DATA[*]}] -to [get_registers {*}] [expr $T_CLK_OSC_ns + $T_CLK_OSC_ns - $T_CSlow2DOV_MAX -$PCB_DELAY_MAX]   Solution 2 set_max_skew only data path ---------------------------------- # Create a max skew constraint that includes only data path arrival #  set_max_skew -from [get_ports { DATA[*] CS} ] 1 -include { from_clock to_clock clock_uncertainty }   Solution 3 set_max_skew data path + clock path ---------------------------------- # Create a max skew constraint that includes only data path arrival #  set_max_skew -from [get_ports { DATA[*] CS} ] 1 -include { from_clock to_clock clock_uncertainty }

[Altera_Forum]

Hi Claudia, 

Isn't better to use a FIFO to decouple the clock domains?You have only to add some control logic to check FIFO full or empty, but I think this solution could be safier. In this case you could use false path between clocks... Giuseppe

[Altera_Forum]

Thaks Giuseppe, 

but the example in my post is a reduction: in reality my data[*] are  data, address and control signal of an external bus.  Bye Claudia

[Altera_Forum]

Is Data[*] also going through two synchronization registers, or is it held for multiple clock periods of the resynch clock?  

There is a certain class of constraints/circuits that aren't possible in .sdc(and most constraints, as far as I know). The way I would describe them is more of an "algebraic" comparison. For example, let's say you know CS and Data come in at the same time, +/-500ps. Then let's say you sample CS in a 5ns clock domain that is unrelated, so it could latch it by as much as 5ns later if it "just missed". Then you re-sample again for metastability, so another 5ns later. Then you use that output to latch the DATA[*], and you know DATA[*] is held for 12ns. So the CS data delay to the first register + delay from 2nd synchronization register to DATA[*] - delay from DATA[*] to capture register + clock skew must be less than (12-10-0.5). Or something like that. I probably have something wrong, but I have on occasion seen circuits like this which, in theory, would probably work if arbitrary delays could be add/subtracted and compared. It really can't handle this, and I've seen users "get by" with set_max/min_delay constraints that they manually tweak to get rid of what they don't want, or that they subdivide into portions of the sum they can handle.   I'm not positive your circuit falls into this, as I'm not sure how the re-synched CS then determines the capture of DATA[*], but there's a chance that it does. (Sorry I'm not being more helpful)

[Altera_Forum]

Hi Claudia and Rysc. 

What about recreating a bus cycle with the external clock? i.e. to use a state machine, using the internal clock, that latches control signals and detect the begining of the cycle, triggering another machine, at the external clock frequency, that recreates the bus cycle. I don't know if I was clear.  bye all

[Altera_Forum]

Thanks a lot Rysc, 

from your response I suppose you suggest me that the best way is to use set_max/min_delay.  In my case a transition high low of Cs means a start of a bus transaction, Data[*] are valid after CS goes low and with a max delay of 22,3 ns, and remain valid until the FPGA closes the transaction with an aknowledge signal. Data[*] doesn't go through a synchronized couple of flip-flop, but it's sampled when CS_synch goes low. FPGA internal clock has a 20 ns period .  So I tried to constraint max_delay for Data[*] path,  (being an extra delay on CS path not an issue, instead ... and otherwise I'm not able to relate delay between two paths !) with :  set_max_delay -from [get_ports {M_DATA_A[*]}] -to [get_registers {*}]  [expr $T_CLK_OSC_ns + $T_CLK_OSC_ns - $T_CSlow2DOV_MAX -$PCB_DELAY_MAX] # # 20 + 20 - 22.3 - PCB_delay_for_data_lines  Could this be a correct way?  Bye  Claudia

[Altera_Forum]

Hi Soin, 

thanks for your post: being able to use the external clock as you suggest would be the best solution, but for a series of routing problems of my board I can't use that esternal clock. Bye Claudia

[Altera_Forum]

I think your original thinking is correct: it will work, as long as you control the skewing between CS and D[*]. 

 So, option A: just set a max skew. Note that this over constrains the design. D[*] late relative to CS is bad, but CS late relative to D[*]. But max_skew just constrains it both ways. set_max_skew -from ]] -rise_to_clock    Another option would be to constrain the maximum delay in CS (which works against you) and then constrain D[*] taking that into account.  set_max_delay -from -rise_to clk $SOME_VALUE set_max_delay -from ] -rise_to clk   In nay case, I think you should set the -to as the clock, so clock delays are taken into account.  That said, with >15 ns to spare, you shouldn't have any problem.

[Altera_Forum]

Thanks a lot for your reply; 

you made me clear how and what I can obtain from the two methods. I think I'll use the second one.  Again Thanks Bye   Claudia

[Altera_Forum]

A little note there is a point I can't get completely ... 

Why a maximum delay in CS would work against me? Doesn't a CS delay open my window? Give extra time to Data to be sampled? set_max_delay -from -rise_to clk $SOME_VALUE set_max_delay -from ] -rise_to clk   Perhaps $SOME_VALUE would be added(best case) or not taken into account at all (worst case is considering that delay ZERO) ?

[Altera_Forum]

You're right. Delaying CS in relation to D[*] works in your favor.