DFF Toggle Flop / PLL clock division impact on timing

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.