Forum Discussion
Definitely agree that the .sdc should be about my timing constraints. Philosophically I take the same position as you. Unfortunately Quartus seems very keen on having "set_clock_uncertainty" for all of the little gate connections, and it would be ridiculous to try and specify the rise/fall times for all of those. At that point I've degraded to somewhere between schematic entry and ASCII line art when I need to specify 4 items per connection. Part of the problem seems to be that "derive_clock_uncertainty" in my .sdc doesn't take until the next update_timing_netlist, which leads to the need to write out the .sdc to get the info back to the fitter. Maybe I don't understand the process and am missing some magic sequence, but if I don't have the clock uncertainties then I get setup/hold violations in TimeQuest. That doesn't seem to be a function of the design speed - even at low clock rates like 20MHz this happens. The designs are straight forward - data is available 1/2 clock before the latching, no CDC. This seems more a function of having incomplete or out of date clock uncertainties in the .sdc. Maybe I should just delete all the uncertainties and suppress the Quartus warning but Altera seems to think having "set_clock_uncertainty" is a good thing for your design.