Honored ContributorCheck this out...I have a design with DDR3. I call the altera design constraints from timequest. Design passes timing. I then call write_sdc, reset my design, and read the 'written' sdc. The idea is to save a whole heck of a lot of time searching the netlist. Well, when I re-read the 'written' sdc, I get timing violations on DDR3 controller nets.
Is there a bug in write_sdc? What is the deal?
Honored ContributorDon't use write_sdc for DDR3. (I don't like write_sdc for anything, and it really shouldn't save time, as it still needs to apply evey constraint to the .sdc. Heck, write_sdc usually creates more constriants).
The DDR3 is a dynamically calibrating core, which is generally not something that can be analyzed by "static timing analysis". A lot of special features are put into the .sdc and analysis .tcl scripts to handle this. For example, I know the .sdc creates some clocks and constrains them/analyzes them, but then removes the clock from analysis when TimeQuest is running. The reason is that paths in it will fail static timing analysis, yet work once calibration takes place. The report_ddr reports will have sections like "Before Calibration" which can have negative slack, but they don't show up in red unless they're still failing after calibration. Anyway, the DDR3 analysis is not meant to work with that flow.Honored ContributorDumping a static SDC rather than using the original saves hours of compilation time. The fitter runs SDC files around 14-16 times. In large designs where your SDC files search through the netlist for pins and clocks to apply constraints, it takes 10s of minutes in some projects and up to an hour in others...simply to search the netlist and find the proper fanin/out signals to apply constraints to. Now imagine the fitter calling these 15 times!? In our designs, we dump the SDC file using write_sdc at the end of the first run through the fitter, and the fitter reuses the static SDC so that our fit times are in some cases cut in half or more...depending on the project. However, with DDR3 in the design, we cannot use this same SDC file. It fails in time quest. In that case, we have to run the 'static' write_sdc constraints then call the altera core constraints to get it to pass. What I suspect is happening is that the altera core constraints are applied yet not dumped during write_sdc. Some sort of 'hidden' SDC constraints like the cuts they build into the tool for FIFOs...that you can't see...but are happening.
I want to know if write_sdc is not giving me a good dump and what is called from the altera DDR3 controller SDC files that makes the difference?Honored ContributorSo it's not write_sdc to get around your existing .sdc, but to explicitly get around the DDR3 from being run. What version of Quartus was your UniPHy generated in? There are some versions where it ran really slow. (And to be honest, there still are...)
The quick way to check is to look at the failing path and analyze it in the original design(although it may not exist since calibrated clocks are removed from back-end analysis, as they would show up as failing). It's not designed to be run this way, and just running the write_sdc is most likely going to show failures that aren't real(due to calibration) or worse yet not analyze paths correctly. The more fundamental problem is that the uniphy .sdc constraints are taking too long to run. You might want to file an SR case, and make sure you're running with a recent version of them(some old stuff has been fixed, but I have seen cases where new Stratix V cores with many DDR3 instances takes a long time).Honored ContributorWhat takes so long is not the DDR3 constraints...they traverse the netlist only once in the fitter...altera does a good job of dumping the nets required to a database that is simply accessed on future runs. I think our issue is that our SDC files are not yet so slick. So we traverse the netlist with each call. However, I did figure out the issue. In one of the SDC files for the core, the following lines are used.
643 __if {(($::quartus(nameofexecutable) ne "quartus_fit") && ($::quartus(nameofexecutable) ne "quartus_map"))} {$ 644 ____set dqs_clocks [DDR3Memory_SIV_Cfg_1_Oct_Master_mem_if_ddr3_emif_0_p0_get_all_instances_dqs_pins DDR3Memory_SIV_Cfg_1_Oct_Master_mem_if_ddr3_emif_0_p0_ddr_db]$ 645 ____# Leave clocks active when in debug mode$ 646 ____if {[llength $dqs_clocks] > 0 && !$debug} {$ 647 ______post_sdc_message info "Setting DQS clocks as inactive; use Report DDR to timing analyze DQS clocks"$ 648 ______set_active_clocks [remove_from_collection [get_active_clocks] [get_clocks $dqs_clocks]]$ 649 ____}$ 650 __}$ Basically, when reporting timing in time quest, they do not have the failing paths set as active clocks. At this point I have all I need to work around the issue. Thanks for the hint... 'remove clocks'Honored ContributorGood find. Both the sdc and .tcl files used by report_ddr use the active clocks. My concern is that if you just remove them, they won't be analyzed at all. In reality, timing is met by taking their static timing analysis and then adding in what can recovered through calibration. So it's not that they're not analyzed at all, just that it's not a vanilla analysis.
