DFF Toggle Flop / PLL clock division impact on timing

[Altera_Forum]

Hello all again... :) 

 Alright..So finally, I managed to make my project compiled and synthesized at 40MHz without any setup/hold timing issues....My last problem comes as my clock input would be at 80MHz (twice as fast)...so..I was thinking...simple DFF Toggle Flop divide-by-2 or a PLL can solve my issue.....Well...not really...as soon as I change the input to a 80MHz, and then put either a divide-by-2 DFF or a PLL after to create my 40MHz...I ran into timing issue again (I have changed the .sdc file to reflect the changes)...  Any one can explaine to me how come when input clock is directly a 40MHz, I have no timing violations. Then changing to a 80MHz and using a DFF Toggle Flop (or a PLL) to divide it downto 40MHz, I ran into problem again?  I have attached the zipped project files to this post..so any other suggestion is more than welcomed (I've been learned alot through this project and from this forum)...Thx  The three zip files are EC_CRC_x1_40MHz.zip --- directly 40MHz input EC_CRC_x1_80MHz_PLL.zip --- 80MHz followed by a PLL EC_CRC_x1_80MHz_DFF.zip --- 80MHz followed by a DFF toggle flop

[Altera_Forum]

Always use a PLL when possible. I generally recommend using derive_clock_uncertainty, but it's up to you(you should get the same results, but if you change your PLL settings, derive_clock_uncertainty will update it.) 

 When things change, do a "report_timing -detail full_path ..." on the failing paths, then go to the working design and do the same analysis on the same path(use the endpoints), to see what changed. In this case, something like: report_timing -from {EC_Framer:inst2|EC_Frame[0][22]} -to {EC_Framer:inst2|Txmit_Frame[22]} -hold -npaths 10 -detail full_path -panel_name {Report Timing} The -detail full_path gives more detailed clock information. When your clocks are correct, it just clutters up the report, but it's useful when analyzing clock changes.  Your last two clocks have a frequency of 2.67Mhz, i.e. they're really slow. Seems strange since they have 667Mhz in the name, but could be right. Anyway, your failing path is between domains. I'm guessing there is no relationship between the 40mHz domain and these other clocks coming in. TimeQuest considers all clocks related, so to undo this you would add: set_clock_groups -asynchronous   -group {80MHz   40MHz}   -group {2p667MHz_CCTCLK}   -group {2p667MHz_CCRCLK}  Not positive that's what you want though.

[Altera_Forum]

You seem to be sending logic between clock domains without synchronizing them, going through a FIFO, etc. Are they really related? Even though the CC?CLK clocks are slow, you generally can't just send data to them asynchronously.

[Altera_Forum]

yeah...Thanks Rysc... 

 I was thinking the 2.66667 MHz (T=375ns) is alot slower than the 40MHz one...so maybe I can cut some corner by passing the signal directly... and yeah..I should set the clock group asynchronously...TimeQuest probably looking at the 40Mhz and the 2.66667Mhz and figured they are related (x15)...so no timing issues were reported at first..now..the PLL introduce phase difference and timing issues show up.... ...more debugging...more correcting....seems endless process :)   I'll try that and if further question, I'll post it here..     --- Quote Start ---  You seem to be sending logic between clock domains without synchronizing them, going through a FIFO, etc. Are they really related? Even though the CC?CLK clocks are slow, you generally can't just send data to them asynchronously.  --- Quote End ---  

[Altera_Forum]

When sending data between asynch clock domains, two things can happen: 

1) The data can be changing just as the receiving register clocks it, causing the register to go metastable. Doesn't happen too often, but the metastable output can trickly down and cause failures elsewhere. 2) When sending more than one bit that are analyzed together, they will all arrive at slightly different times. So if the receiving registers are at "0000" and you send "1111", that transition may occur around a clock edge, so some registers clock in the 1s and the others don't. Your data is no longer valid. Understnading clock domains and handling them is one of the major things FPGA/ASIC designers need to understand, and it takes a while.

[Altera_Forum]

two quick questions... 

1)...During compliation, Quartus II decided that some FSM state bit will be used as clock signals...How can I avoide these situations?  These errors generally look like this:  Warning: Node: EC_DeFramer:inst3|SC.state_bit_0 was determined to be a clock but was found without an associated clock assignment.   2)..I just added "set_clock_groups -asynchronous -group {80MHz 40MHz} -group {2p667MHz_CCTCLK} -group {2p667MHz_CCRCLK}" to the design with the PLL..and now the setup/hold timing isses are gone? Are they really gone or they are just masked out?     --- Quote Start ---  When sending data between asynch clock domains, two things can happen: 1) The data can be changing just as the receiving register clocks it, causing the register to go metastable. Doesn't happen too often, but the metastable output can trickly down and cause failures elsewhere. 2) When sending more than one bit that are analyzed together, they will all arrive at slightly different times. So if the receiving registers are at "0000" and you send "1111", that transition may occur around a clock edge, so some registers clock in the 1s and the others don't. Your data is no longer valid. Understnading clock domains and handling them is one of the major things FPGA/ASIC designers need to understand, and it takes a while.  --- Quote End ---  

[Altera_Forum]

Quartus II won't ever use something as a clock. It's going to be something in your code. You can trace it forward in the RTL viewer, or another trick is to run the following in TimeQuest: 

derive_clocks -period 10.0 This will constrain these clocks as 10ns clocks and they'll be related to everything. Basically at this point the timing analysis is useless, but you can do a report_timing to these two new clock domains and you'll see which registers are using these state-bits as clocks. You can then look through the code and figure it out from there.

[Altera_Forum]

Thanks Rysc... 

ok..fixed this mystery clock problem..It's because in a case statement, some signal assignment does not takes place in all cases..therefore, these signals were synthesized as latches as supposed to registers...therefore, these state bits were used as a clock/enable kind of signal for these DFFs to work as latches.  Now...next problem...I have the main FSM updating on the rising edge of clock and sending some data (with ctrl signals) from EC_Framer to the CRC module..why in TimeQuest, it is shown that the launch edge is inverted (therefore wasted half of the cycle...)..this is causing my setup time violations..(this is the same time domain, so no cross-clock domain issue for here)...suggestion??     --- Quote Start ---  Quartus II won't ever use something as a clock. It's going to be something in your code. You can trace it forward in the RTL viewer, or another trick is to run the following in TimeQuest: derive_clocks -period 10.0 This will constrain these clocks as 10ns clocks and they'll be related to everything. Basically at this point the timing analysis is useless, but you can do a report_timing to these two new clock domains and you'll see which registers are using these state-bits as clocks. You can then look through the code and figure it out from there.  --- Quote End ---