Forum Discussion
Altera_Forum
Honored Contributor
14 years agoThanks.
- I would suggest using generated clocks. Note that clocks do not propagate through registers(ripple clocks), so without them the delays of the clock going off chip will be ignored, making the analysis incorrect. At 12.5ns delays, there's definitely some risk in ignoring them. - Put a generated clock on the register(use get_keepers) that drives the clock out of the state-machine. The -source should be the output of the PLL that drives it and can be found by running report_clocks and looking at the Target column of clocks created by derive_pll_clocks. If there is no PLL, then it's just the input clock pin. - Put a second generated clock on the output port sending out data, it's source being the register that the clock is generated from. This shows TQ how the clock gets out, and this clock will be used by your set_output_delay constraints. - Use multicycles to create the correct setup and hold relationships. - Finally add the external -max/-min valuse to the set_output_delay based on the external delays. When you run: report_timing -setup -detail full_path -npaths 50 -to_clock output_clock_name -panel_name "Interface_name||setup" Make sure your data arrival path has the entire path from the clock coming in all the way to going out of the device. This means your generated clocks are correct. If they're not, you get a warning about not being able to determine clock latency from the source, but I find looking at the timing report easier. A complement goes a long way... : )