Honored Contributor
Honored ContributorYou see it on the Data Arrival Path too? If so, it should be fine. Feel free to write the report_timing of one path to a .txt file and attach it.
The only major trick with ripple clocks is to note that clocks do not propogate through registers, and so if the output of a register ever feeds the .clk pin of another register, the user must put a generated clock assignment on that original register. If you don't do this, you won't get any analysis on the downstream logic and the ripple clock should show up as an unconstrained clock(Report Unconstrained Paths). Since you're seeing the analysis, it should be correct. The major points if you really want a full analysis: - Is the setup relationship correct? - Is the hold relationship correct? - With -detail full_path, do the launch and latch clocks track back to the FPGA input ports? That's really the only things Quartus is figuring out from your .sdc, and what to look at to determine if the analysis is correct. Everything else is just delays from the place-and-route and not your .sdc. Thanks on the wiki user guide. I keep mean to go back to it, although other stuff keeps getting in the way. (There's a source-synchronous timinig user guide, a fitter and seed sweep guide, and am currently working on logiclock and design partition guide. Also trying to learn QSYS better...) Most likely when I do go back I'll trim down what I plan to add, although a few things could be done pretty quickly.
