Clock uncertainty warnings under 10.0

[Altera_Forum]

I have a project that works fine under 9.0 - no timing violations. I upgraded to 10.0 and rebuilt without any warnings. If I now go into TimeQuest and perform a derive_clock_uncertainty followed by an update_timing_netlist, and then write out the .sdc, the new .sdc appears to be incomplete. When I build with the new .sdc, Quartus issues critical warnings that no clock uncertainty assignments exist for several of the signals. A search of the .sdc shows the signals in question don't have set_clock_uncertainty for the path in question, although the .sdc does have uncertainties for many of the paths and has all of the expected sections. Is there an additional step that's now needed? I've tried using the -overwrite option on the derive_clock_uncertainty but (as expected) that doesn't change if an uncertainty assignment gets created.

[Altera_Forum]

Don't know the exact issue, but I strongly am against having Timequest write out your .sdc and using that. The .sdc should be like a source HDL file, i.e. something you edit and maintain and don't want a machine overwriting. If you want to use write sdc to get the syntax of something, I would write it to a dummy file and then cut and paste into yours. At the bare minimum, the .sdc file should have lots of comments to describe what the constraints are doing and how they were calculated.  

All the time I see people get timing constraints(specifically from the Classic TAN) that have no supporting documentation. It will just be a Tsu constraint of 3ns. They have no idea how that was calculated, and if they're changing the FPGA, the upstream device or just doing a board re-spin, they either try to meet that old requirement but not knowing why, or have to re-do everything from scratch.  Sorry if that doesn't help your specific problem, but I think if you just kept derive_clock_uncertainty in your .sdc and nothing else, it should work.

[Altera_Forum]

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.

[Altera_Forum]

I'm still not following. If you have derive_clock_uncertainty in your .sdc, everything should be taken care of for you. There's no problem that derive_clock_uncertainty isn't used until the next update_timing_netlist, as those steps should always happen one after another. I think derive_clock_uncertainty should just happen behind the scenes and there would be no reason to add it to your design, but once you know about adding it there shouldn't be any probelms.

[Altera_Forum]

When I write out the .sdc, I basically cut and paste the clock uncertainty settings into the .sdc from Timequest. I do this because when I run the corner analysis from Quartus there is a info/warning that the uncertainties won't be used until the next netlist update. Are you saying that I can delete all of the uncertainties and just have a single derive_clock_uncertainty? It would be wonderful if I didn't need to update the .sdc with Altera information.

[Altera_Forum]

Yes, just have derive_clock_uncertainty in your .sdc. (I still recommend NOT having TimeQuest write out the .sdc, but either way, you don't need to manually put them in and can just have derive_clock_uncertainty. The netlist update is always run before timing analysis...)