Hi, I'm trying to apply a generated clock to a clock net burried in the hieracrchy, like so: create_generated_clock -name {oven_ctl_i2c_clk} -divide_by 1024 -source [get_ports {osc_clk0}] [get_pins oven_ctl:inst20|clk_div_50m_i2c_clk:inst2|i2c_clk] However, TimeQuest comes back and tells me that the SDC command get_pins returns an empty value. I can determine the where the signal is at in the Technology Map Viewer, but how do I determine the correct path (and syntax) to place in the SDC file? Also, since the SDC file is used for timing-driven pnr, as well as post-route timing analysis, wouldn't it make since to use two different types of SDC files, one for pnr and one for timing analysis? :confused: Thanks, Tony

Brad, Yes, I am used to doing this in an ASIC. With an ASIC, you can create as many generated clocks as you'd like, and then assign the output to a clock buffer, which then gets converted to a clock tree by the layout engineer. The clock tree is balanced across the chip for minimal clock skew. Typically, all clocks are created in a central clock and reset block, something that I highly recommend. The design I am working with was inherrited, so I have no control over the logic. The generated clocks are driving local area logic, and are not used as a global clock. All global clocks in the design are driven from the PLLs in the Nios II processor. Its true there will be some clock skew, but from what I've seen so far, this does not appear to be a problem. However, to do sure, I need to create the generated clocks correctly, inside TimeQuest, hence the start of this thread. As for using the Netlist Viewer inside TimeQuest, I don't remember if I used the compatibility mode checkbox as you recommended.....I will check on this again tomorrow morning. For what I am trying to accomplish, I should be able to create a generated clock on the output pin of the device that is driving the clock, which I would typically use the get_pins command. For now, I will use get_keepers, unless you can give me a good argument against it.

--- Quote Start --- TimeQuest comes back and tells me that the SDC command get_pins returns an empty value. I can determine the where the signal is at in the Technology Map Viewer, but how do I determine the correct path (and syntax) to place in the SDC file? --- Quote End --- I use the Name Finder to be sure the name is correct. You can get to the Name Finder from inside other TimeQuest dialog boxes or at "View --> Name Finder". Even if I want the exact node name in the SDC command, I usually start by typing a portion of the name I'm confident is correct and use wildcards for the rest. For wildcards with get_pins and get_cells, enable the "Compatibility mode" checkbox in the Name Finder dialog box or read the on-line help for get_pins or get_cells to learn the special wildcard rules for those collections. --- Quote Start --- Also, since the SDC file is used for timing-driven pnr, as well as post-route timing analysis, wouldn't it make since to use two different types of SDC files, one for pnr and one for timing analysis? --- Quote End --- You are free to use whatever .sdc file(s) you want to report timing after compilation completes, but usually you use the same timing constraints for the Fitter and for reporting.

Brad, Thanks for the reply.... The only way that I can return a non-empty list is by using get_keepers, which appears to return a list of nets (?), but I'm not sure what they are. I'm used to assigning a generated clock directly to the Q pin of a flop, but so far, I haven't been able to determine how that is done with the Altera toolset. Tony

Use the Name Finder to search on the get_pins function(rather than just adding it and doing a whole TimeQuest run to find it doesn't match anything). get_pins acts in a strange manner that I believe corresponds to other tools. The handbook describes it, but basically it has a -compatibility mode, or something like that(it's a checkbox in the Name Finder), that makes it work more like a name matching, wildcarding search that you probably want. As for different .sdc files for fit and timing analysis, this is definitely possible, but I don't think it's readily available in the GUI because 99.9% of designs do not need this. (Altera generally does not recommend over-constraining your design, which is a common practice when dealing with some other vendors). I think you can do it just running from command line(look at the .flow.rpt to get the commands from a given push-button compile), and then modifying the quartus_sta command so it has --sdc=newsdc.sdc on it.

Name Finder will only return a list of items if I use the get_keepers function; get_pins returns an empty list. I believe if I want to apply the generated clock to the Q pin of the divide flop, I would use this (I think...): [get_nodes inst20|inst2|i2c_clk|regout] This appears to place the generated clock on the Q output of the DFF in the cell i2c_clk, but it's not too clear based on that the Technology Map Viewer shows. However, based on what the TimeQuest documentation says, I believe using get_keepers will accomplish the same result. If anyone can correct me on this, please let me know! Thanks...

Determining path for cell in netlist | Altera Community

15 Replies

Altera_Forum
Honored Contributor
18 years ago
--- Quote Start ---
... and would definitely need to use a Stratix II or Stratix III, if anything so I could do temperature and voltage variations in my timing analysis. It really is weird that I can't do that using the Stratix family.....just doesn't make sense to me why Altera left this out.
--- Quote End ---

My previous post mentioned on-chip variation (process variation across the device at any given temperature and voltage) being added to the models for Cyclone III and Stratix III. Timing models with the slow and fast extremes of process/voltage/temperature have long been in Quartus, I think going back at least to the earliest Cyclone and Stratix devices.
Altera_Forum
Honored Contributor
18 years ago
After all of this discussion, I've finally been able to add the clock constraints to the SDC file. However, I'm still having a problem. TimeQuest is now reporting this:

info: the source clock for this clock assignment cannot be reached. clock: health_status_i2c_clk might not have valid arrival time.

I'm using this command to create the generating clock:

create_generated_clock -name {health_status_i2c_clk} -divide_by 1024 -source [get_ports {osc_clk0}] [get_pins inst2|inst8|i2c_clk|regout]

The clock that feeds the i2c_clk register is called clk50_mhz, which is a propagated clock from the Nios processor. The command derive_pll_clocks -use_tan_name is currrently being used. A base block is created on the input to the Nios processor, so I'm at a lost as to why I'm getting this message.
Altera_Forum
Honored Contributor
18 years ago
The port osc_CLK0 drives a PLL, which has a generated clock/s coming out of it, and you're using one of those clocks to generate another clock. So your -source should not be the port, but the ouptut of the PLL. In TimeQuest, double-click on Report Clocks and find the PLL output that drives this one. Use that Target name as the -source of this generated clock. (I filed an SR that I thought this Info message should be a Warning, as it's more serious than just Info...)
Altera_Forum
Honored Contributor
18 years ago
I used -source [inst|the_pll|the_pll|altpll_component|pll|clk[0]] and this seems to work. I'm not getting the informative message for this generated clock. I had to open up SOPC builder to determine the proper name of the PLL output clock name, and then deduce from that which clock to use from the report_clock command in TimeQuest.

I was hoping the [get_ports osc_CLK0] command would be able to propagate the clock through the PLL and on to to FFs, but doesn't look like TimeQuest can do this. But I suppose you have to treat the PLL as a generated clock source, which in turn is feeding another generated clock source.
Altera_Forum
Honored Contributor
18 years ago
TimeQuest shouldn't do this, by the way of the way create_generated_clocks works. Note that the -source is a node and not a clock. Basically this takes the "ideal" clock that exists on that node in the design. As a good example, when you run derive_pll_clocks, look at the Info messages to see what the -source is for the PLL output clocks. It is not the incoming clock port, but the actual inclock pin of the PLL. Now, you could modify this to be the top-level clock port and you would get identical results. This is because you only take the waveform along that clock, and TimeQuest then calculates the delay to that point(in the documentation they refer to it as latency). This is always confusing, but it is a much more powerful way to do it, more flexible, and gives the correct results.
But in your case, you chose a node before the PLL. So for example, let's say osc_CLK0 was a 10ns clock, and the PLL divided it down to a 20ns clock, and then your ripple clock divided it again to a 40ns clock. If your generated_clock was -divide_by 2, but you had the -source by osc_CLK0, we would be taking the 10ns clock and dividing it by 2, when you really want to take the 20ns clock and dividing it by 2.
(I'm probably making this more confusing, but it's more information as to how this works, which may prove useful).

Forum Discussion

Determining path for cell in netlist

15 Replies

Recent Discussions

Duplicate_hierarchy_depth / duplicate_register

Timing analysis - long combinational path

Automatically added negative node for TDS output doesn't work with Agilex 5

Quartus 20.1std compilation fails for Quartus map - Device 10AS057K2F40I1SG

QuartusPro 25.3 Crashed after using the Signal Tap Logic Analyzer