Determining path for cell in netlist

[Altera_Forum]

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

[Altera_Forum]

--- 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.

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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...

[Altera_Forum]

--- Quote Start ---  Name Finder will only return a list of items if I use the get_keepers function; get_pins returns an empty list.  --- Quote End ---    Did you use the "Compatibility mode" checkbox as I said before?

[Altera_Forum]

--- Quote Start ---  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.  --- Quote End ---     Keepers are registers and ports (device pins). They are the things you can use as source and destination with report_timing.

[Altera_Forum]

--- Quote Start ---  I'm used to assigning a generated clock directly to the Q pin of a flop...  --- Quote End ---     Are you used to doing this in an ASIC? Avoid doing it in an FPGA. It is better to drive the clock with a PLL or to use a clock enable.  If you do drive a clock with a register or any other logic, be aware of the caveats in my posts at http://www.alteraforum.com/forum/showthread.php?t=754.

[Altera_Forum]

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.

[Altera_Forum]

As you may already have figured out, the global routing in FPGAs provides a low-skew, balanced clock tree similar to what you have in an ASIC. In the FPGA, it's designed once by Altera and is the same in every device (not customized for each design), so its timing is well characterized. A difference from an ASIC is that the FPGA has only a limited number of separate global routing lines, but at least it's a fairly big number in newer devices. 

 I think get_keepers is fine for what you're doing now. Since get_keepers is an Altera extension to SDC, however, you'll probably prefer to use a more standard collection like get_pins.  I highly recommend using the Name Finder even for simple names to avoid typos. Since you can start with wildcards in the Name Finder, it's usually easy to find the exact name as long as you don't have trouble with the special wildcard rules for get_pins and get_cells (which you might already be familiar with from past experience). "Compatibility mode" for those two collections treats the wildcards similarly to how other collections treat them.  I see a problem now with your original attempted pin name. You included the entity names: entity1:instance1|entity2:instance2|endname That works for some collections, but get_pins uses instance1|instance2|endname. When guessing pieces of the name in combination with wildcards to find the entire name in the Name Finder, try using just instance names.  I still recommend that you see the thread I referred you to for logic-driven-clock considerations (any kind of logic resource in the clock path whether register or LUT). It is recommended not to create FPGA clocks that way at all. But as that post says, it is OK if every clock is on global routing with no synchronous data paths between clock domains. (You can use global routing even for logic-driven clocks.) The problem is more than the skew that actually gets reported. As the other post says, there is the consideration of on-chip variation, which is in the timing model only for Cyclone III and Stratix III. That variation means that in older families you should allow for some extra margin for cross-domain paths if a clock is driven by logic resources and even within a domain for a nonglobal clock if there could be much clock routing that is not common between the source and destination registers.  You are probably used to gating clocks in logic in ASICs. Synplify and I think Precision have some capability to convert gated clocks in the RTL to the clock enable equivalent that is preferred in FPGAs.

[Altera_Forum]

Yes, there are definite differences between working with ASICs and FPGAs. I need to educate myself on the proper use of clock drivers in an FPGA, but it is actually fairly similar to that of an ASIC. For the ASIC that I just worked on, there were many clock domains, and I would need quite a few global resources if this design was implemented in an FPGA, 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. 

 I just completed a new Name Finder run, and this time using get_pins with the compatibility mode box checked, this was returned:  inst20|inst2|i2c_clk|regout  Yes, you're right that I'm used to using get_pins, and that commnand seems to be more universal.

[Altera_Forum]

--- 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]

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]

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]

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]

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).