DFF Toggle Flop / PLL clock division impact on timing

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 ---