How to address CDC and what methods needs to implement in this design?

[hcu]

Hi,


Spec : three modules connected from left to right.
module 1 works at 125 Mhz.
module 2 works at 750 Mhz.
module 3 works again at 125 Mhz.

module 1 performs some operations and generates a "module1_valid" (high only for 2 clocks) and a "module1_data" on a data_bus at every (451 clock cycles at 125mhz clock). this data on the databus remains stable until next new data overrides it which comes after a another 451 clocks.

module 2 gets into the working state after receiving "module1_valid" and works on the input data and then outputs "module2_vld" and "module2_data" at every (450 clock cycles of 125 mhz) note: mentioned at 125mhz rate.
here "module2_vld" stays for 1 clocks high (125mhz) and goes low. but the "module2_data" held constant untill next new data comes and overrides.

module 3 starts working once it samples "module2_valid" and "module2_data". works on it and produces the output.

one can observe , a slow to fast clock and then fast to slow clock transition is involved.
will it cause any cdc issues like metastablity ? if yes, what should be done ? any reference design plz.

Apart from this, what are the sta constraints to set for these 2 clocks. is it asynchronous clock grouping or a false_path constraint ?


note: currently i dont have spyglass CDC to work on it.
please don't suggest me fifo or assertions.


Thanks,
hcu

 

[dpaul]

please don't suggest me fifo or assertions.

Can we know the reason for not using an async FIFO to separate the clock domains?
In my opinion STA and constraining the design will be easier with async FIFOs.

 

[ThisIsNotSam]

Hi,


Spec : three modules connected from left to right.
module 1 works at 125 Mhz.
module 2 works at 750 Mhz.
module 3 works again at 125 Mhz.

module 1 performs some operations and generates a "module1_valid" (high only for 2 clocks) and a "module1_data" on a data_bus at every (451 clock cycles at 125mhz clock). this data on the databus remains stable until next new data overrides it which comes after a another 451 clocks.

module 2 gets into the working state after receiving "module1_valid" and works on the input data and then outputs "module2_vld" and "module2_data" at every (450 clock cycles of 125 mhz) note: mentioned at 125mhz rate.
here "module2_vld" stays for 1 clocks high (125mhz) and goes low. but the "module2_data" held constant untill next new data comes and overrides.

module 3 starts working once it samples "module2_valid" and "module2_data". works on it and produces the output.

one can observe , a slow to fast clock and then fast to slow clock transition is involved.
will it cause any cdc issues like metastablity ? if yes, what should be done ? any reference design plz.

Apart from this, what are the sta constraints to set for these 2 clocks. is it asynchronous clock grouping or a false_path constraint ?


note: currently i dont have spyglass CDC to work on it.
please don't suggest me fifo or assertions.


Thanks,
hcu

you need a FIFO or a handshake. your design, as it is described, suffers from CDC.
ps: you don't need spyglass. engineers were handling CDC way before the tools started to become smarter about it.

 

[hcu]

you need a FIFO or a handshake. your design, as it is described, suffers from CDC.

you mean to say that, keeping the data held constant for a large number of cycles won't help me ?
Is handshaking even needed at slow-fast boundary?

 

[Ashish Agrawal]

Case 1 : Clocks 125 MHz and 750 MHz are from different sources (async clocks).
From module 1 to module 2, you just need a synchronizer (may be 2/3 flops) for module1_valid signal.
From module 2 to module 3, again you need a synchonizer for module2_vld. The module2_vld should be @750 MHz if your module 2
running at 750 MHz. Assuming it is at 750 MHz. Then this signal needs to be synchronized in module3 using close loop synchronizer or
streching this signal for 6/7 clock cycles of 750 MHz.

Case 2 : Clocks 125 MHz and 750 MHz are from the same source and has known phase relationship (synchronous clocks)
No need of any synchonizer. Just need to make sure that, module2_vld is high for at least 1 clock cycle of 125 MHz.

In both the cases, FIFOs are not required, as data is held stable for a longer time.
You just need to synchronize the valid signals if clocks are asynchronous.

Hi,


Spec : three modules connected from left to right.
module 1 works at 125 Mhz.
module 2 works at 750 Mhz.
module 3 works again at 125 Mhz.

module 1 performs some operations and generates a "module1_valid" (high only for 2 clocks) and a "module1_data" on a data_bus at every (451 clock cycles at 125mhz clock). this data on the databus remains stable until next new data overrides it which comes after a another 451 clocks.

module 2 gets into the working state after receiving "module1_valid" and works on the input data and then outputs "module2_vld" and "module2_data" at every (450 clock cycles of 125 mhz) note: mentioned at 125mhz rate.
here "module2_vld" stays for 1 clocks high (125mhz) and goes low. but the "module2_data" held constant untill next new data comes and overrides.

module 3 starts working once it samples "module2_valid" and "module2_data". works on it and produces the output.

one can observe , a slow to fast clock and then fast to slow clock transition is involved.
will it cause any cdc issues like metastablity ? if yes, what should be done ? any reference design plz.

Apart from this, what are the sta constraints to set for these 2 clocks. is it asynchronous clock grouping or a false_path constraint ?


note: currently i dont have spyglass CDC to work on it.
please don't suggest me fifo or assertions.


Thanks,
hcu

- - - Updated - - -

If both the clocks are asynchronous, then you can define the asynchronous clock grouping in sta constraints. STA Tool will not try to meet timing in these crossing paths.
You can define the false path as well for STA by mentioning all the paths. But I would prefer defining asynchronous clock groups.


In case, if you plan to run CDC using any tool, then don't define the false_path constraint. For CDC tool, false_path means, it will never check for the crossings. CDC tools are intended to check for crossings.

 

[hcu]

Case 1 : Clocks 125 MHz and 750 MHz are from different sources (async clocks).
From module 1 to module 2, you just need a synchronizer (may be 2/3 flops) for module1_valid signal.
From module 2 to module 3, again you need a synchonizer for module2_vld. The module2_vld should be @750 MHz if your module 2
running at 750 MHz. Assuming it is at 750 MHz. Then this signal needs to be synchronized in module3 using close loop synchronizer or
streching this signal for 6/7 clock cycles of 750 MHz.

Case 2 : Clocks 125 MHz and 750 MHz are from the same source and has known phase relationship (synchronous clocks)
No need of any synchonizer. Just need to make sure that, module2_vld is high for at least 1 clock cycle of 125 MHz.

In both the cases, FIFOs are not required, as data is held stable for a longer time.
You just need to synchronize the valid signals if clocks are asynchronous.



- - - Updated - - -

If both the clocks are asynchronous, then you can define the asynchronous clock grouping in sta constraints. STA Tool will not try to meet timing in these crossing paths.
You can define the false path as well for STA by mentioning all the paths. But I would prefer defining asynchronous clock groups.


In case, if you plan to run CDC using any tool, then don't define the false_path constraint. For CDC tool, false_path means, it will never check for the crossings. CDC tools are intended to check for crossings.

case 2 is the one which I am with. I stretched the module2_vld signal as you said.
Is this enough ? what about the multi_bit data buses.

 

[ThisIsNotSam]

you mean to say that, keeping the data held constant for a large number of cycles won't help me ?
Is handshaking even needed at slow-fast boundary?

keeping the data stable doesn't fix the problem, read the post above about synchronizers.

 

[Ashish Agrawal]

case 2 is the one which I am with. I stretched the module2_vld signal as you said.
Is this enough ? what about the multi_bit data buses.

If it case 2 (clocks are synchronous) then this should be okay.
For multibit data, you should always capture it only when you detect the rising edge of _vld signal.
so actually _vld signal works as a qualifier for data.
The time you detect the rising edge of _vld signal, data is already stable.