General time constraint questions

What would answer a lot of questions is to see a typical Nios project example with some misc user logic modules and a fully constrained timequest sdc file, but I don't see any sdc files in the installed nios examples.

As I understand it, the timequest GUI is supposed to help mine the info needed to properly create the sdc file, and that the sdc should specify timing commands/constraints so the fitter can do a better job, and also commands/constraints so it can analyze the final fitting correctly. Am I on track here?

Even after reading CH6 (lots of terminology, some confusing typos), it isn't clear which sdc entries are used by the fitter and which are used for analysis, or do they all do both? Am I supposed to have both a fitter and an analysis section for the sdc, two different sdcs, or? Once I have written an sdc, added it to my project files and selected timequest, is the sdc applied automatically for fitting and analysis or do I need to go into timequest every time? We are talking hundreds of registers/pins/cells/etc. How will I know when my design is fully constrained or constrained enough?

kwalts doc shows the generated clocks having names like ..|auto_generated|..., but my generated clocks dont have 'generated' in them. Is something wrong?

One of the first steps is to use create_clock, but the waveform info is discarded before adding to the sdc file. I assume this entry is used by the fitter. Is the waveform info ever used (for timing analysis perhaps?).

My top level is a bdf with a nios symbol and some user logic symbols userlogicA, userlogicB, etc. The nios runs at 90Mhz and the userlogicA block at 50mhz. All my user logic is mostly single-cycle synchronous with a couple of divided clocks thrown in. Under classic timing, the fast model meets timing and the standard model had two violations. Inconsistent behavior led me to use timequest.

I have defined a nios component interface for userlogicA which is an avalon MM slave with some typical signals clock,reset,wr,addr,dataout. Since I have specified in SOPC that userlogicA will use the 50mhz clock, I assume it has placed clock crossing logic between the 50mhz interface and the 90mhz avalon bus. Critical warnings in timequest led me to believe I needed to put synchronizers on those same signals between the interface and userlogicA. The clock domain is the same. This can't be correct.

userlogicA also has some inputs and outputs directly from the 90mhz domain via some nios component gpio interfaces. There are warnings for these too, and I can see that syncronizers on those signals make sense, although they are slow static control and status bits and the way they are used it probably would not matter. I just realized I could go into SOPC and also change the clock assignment for the gpio from 90mhz to 50mhz. Some of those async clock domain warnings should go away.

If I needed to tell timequest to stop nagging me about a signal, or to not do anything special for a chunk of logic, how would I?

Just another thing to look at:

http://www.alteraforum.com/forum/showthread.php?t=1845&highlight=timequest

If you see failures in your design, it is very important to understand what is being analyzed and how it is being analyzed. Once you get that, you then need to correlate it back to your design. Note that TimeQuest analyzes your design against your constraints. Crossing asynchronous clock domains is the classic example. If you have logic going through an asynchronous FIFO, that doesn't mean no physical paths exist between the clock domain, and TimeQuest doesn't decide whether to analyze those paths or not. By default, all clock crossings are analyzed, and only a set_clock_groups or set_false_path constraint can be used to tell TimeQuest not to analyze them. So your question of whether a clock-crossing block is inserted doesn't mean the paths don't exist in TimeQuest.

Now, your SDC looks good on first glance except for your IO timing. You have your input delays with a max of 1.0 ns(so you're requiring it to be less than 1ns) and a min of 2.0ns(requiring the same path to be greater than 2.0ns). Naturally, that's not possible and one of those will always fail.

Generally you should have 1 SDC. All constraints should be used by the fitter. Some won't be used by synthesis but there's nothing you can do about that and it still works really well(i.e. don't worry about that). In TimeQuest you can do a report on Unconstrained Paths, which is important to see if you miss anything.

Bottom line is you're going through some growing pains from a) I want to do as little timing analysis as possible to b) I'm trying to do it right but it's more complicated than I thought. This is normal, and keep progressing. The big thing you're avoiding is "inconsistent behaviour", which really means a design that doesn't meet timing, and just happens to work all the time. A good design that meets all timing requirements should work all the time.

As for how much constraining to do, everything should be constrained. What that means is that you correctly constrain all your clocks and all of your I/O, which I believe you've done(although the generic way the I/O have been constrained is reason to pause). Now everything has clock relationships and all transfers have requirements. Technically you have everything constrained, and what you do from there is "loosen" constraints. So your set_clock_groups command is telling TimeQuest not to analyze paths betwen unrelated clocks. set_false_path commands do the same thing, as do multicycles(which make the constraints looser).

Anyway, hope that helps.

Thanks for the link. It will take some time to digest.

My question about the automatic clock crossing was to make sure quartus is actually going to put it in there since I am assuming it does.

The IO constraints were taken directly from the original altera 'basic sdc example'. If they mixed up max and min, it should be fixed. I'll give it a try the other way around.

I noticed along with my custom sdc, quartus has created a couple of other sdcs in the project folder. They have alot of 'false path' statements. Can I safely delete these since I do not specify them in my settings?

So far all the documentation on TQ only shows trivial examples in which all the entity names, paths + delays are very simple and already identified for you. In a real project the hard part seems to be understanding what (and where) TQ is complaining about so you can actually do something intelligent about it.

In my project, I've put in the base clocks and generated clocks statements, and now I have post-fit analysis showing many violations. Is there some preferred plan of attack?

Do I need to have all constraints in place before I worry about violations?

I don't understand most of what it is complaining about since the names are not part of my user logic. I see several setup violations which list a base clock name as the launch edge. Base clocks only go to plls. There shouldn't be any logic driven directly from base clocks. All the logic is driven from pll output clocks.

If I could fix even one problem I'd have some hope for this tool.

TimeQuest is a timing analysis tool, but it doesn't show you your own code. (The RTL Viewer might be a better case). But the bottom line is if it's code you haven't written, and you don't understand it, TimeQuest can't tell you what to do about it. It just tells you whether it meets timing based on the constraints you've entered.

In TimeQuest, go to Report all Summaries, you should get a Setup Summary, Hold Summary, and most likely a Recovery and Removal Summary. If you have Setup failures, right-click on one of the failing domains and do a Report Timing. Change the detail level to Full Path and make sure it outputs the report to a text file. Then .zip it up and attach it. I was about to write up a long email about what could go wrong and things to look at, but a real case is much easier to point to.

launch clock = clk_ff

latch clock = inst|the_pll_main|the_pll|altpll_component|pll|clk[0]

So they are different clock domains. This doesn't necessarily mean there's a problem, but often is. So looking at the first failing path:

The launch edge time is 41.666ns and the latch edge time is 44.440ns, which means you have less than 3ns to meet the setup timing.

But the strange numbers are probably the biggest clue that something is wrong. I don't know the frequencies of these two clocks, but assume they are not related. For example, if the clocks were both 10ns, you would generally see a launch at time 0ns and a latch at time 10ns, for a 10ns setup requirement. But if the latch clock had a period of 9ns, then TimeQuest would find the point in time where they have the most restrictive setup requirement, which would be a launch at time 80ns and a latch at time 81ns, for a 1ns setup requirement.

So my guess is these domains should not be in the same group in your set_clock_groups command.

Now, I don't have the design, but I believe your earlier statement said that the clk_ff is the input clock pin to this PLL. So why aren't they related? If the PLL is creating a timing requirement that is not easily related to the main clock, that can happen. For example, if you have a 10ns input clock, but the output clock is 3/2 of that frequency(66.66ns), then even though they originate from the same source, they can't be related in such a way for you to do synchronous transfers between them.

So the final part is, does the design work if you don't do timing analysis between these domains, as there is obviously a path that exists. From the looks of it, I believe this is going to be all right, but to be perfectly honest I don't know for sure(I don't have much experience with Nios). It looks like they are register to register paths with no combinatorial logic in between, and is probably doing some sort of handshaking mechanism(i.e. transfer the data over, then hand-shake to say it is okay, which is a slow interface and has many clock cycles to meet timing).

Anyway, hope that helps.

--- Quote Start ---

launch clock = clk_ff

latch clock = inst|the_pll_main|the_pll|altpll_component|pll|clk[0]

So they are different clock domains. This doesn't necessarily mean there's a problem, but often is. So looking at the first failing path:

The launch edge time is 41.666ns and the latch edge time is 44.440ns, which means you have less than 3ns to meet the setup timing.

But the strange numbers are probably the biggest clue that something is wrong. I don't know the frequencies of these two clocks, but assume they are not related. For example, if the clocks were both 10ns, you would generally see a launch at time 0ns and a latch at time 10ns, for a 10ns setup requirement. But if the latch clock had a period of 9ns, then TimeQuest would find the point in time where they have the most restrictive setup requirement, which would be a launch at time 80ns and a latch at time 81ns, for a 1ns setup requirement.

So my guess is these domains should not be in the same group in your set_clock_groups command.

Now, I don't have the design, but I believe your earlier statement said that the clk_ff is the input clock pin to this PLL. So why aren't they related? If the PLL is creating a timing requirement that is not easily related to the main clock, that can happen. For example, if you have a 10ns input clock, but the output clock is 3/2 of that frequency(66.66ns), then even though they originate from the same source, they can't be related in such a way for you to do synchronous transfers between them.

So the final part is, does the design work if you don't do timing analysis between these domains, as there is obviously a path that exists. From the looks of it, I believe this is going to be all right, but to be perfectly honest I don't know for sure(I don't have much experience with Nios). It looks like they are register to register paths with no combinatorial logic in between, and is probably doing some sort of handshaking mechanism(i.e. transfer the data over, then hand-shake to say it is okay, which is a slow interface and has many clock cycles to meet timing).

Anyway, hope that helps.

--- Quote End ---

Thanks for taking the time. Every bit helps. I really didn't expect it would take longer to specify timing that to design the project.

clk_ff is indeed an external 24mhz clock which ONLY goes to a pll to produce clk0 (15/4=90mhz nios core) and clk1 (90mhz sdram). There are no explicit paths to/from clk_ff other than the one pll input. In SOPC clk_ff is only assigned to the pll, everything else uses clk_core, clk_sdram or clk_event (a different pll domain). Who knows what Quartus is doing behind the scenes here. I don't have the full license so I probably can't easily find out. My 2nd external clk input (50mhz) is treated in an almost identical way (but simpler ratios 1/1 and 1/5) and it does not show violations in the summary.

In kwalt's example which I followed, he also shows the pll input being grouped with the pll outputs, but his pll ratios were simpler.

I'll try having 3 clk groups instead of 2.

For designers with simple clock constraints, they are often able to quickly make constraints without understanding them. But as designs get more complex, they often ignore timing problems(or expect things to not be complicated and refuse to take the time to understand it). I'm sure you're frustrated, but hopefully the pain you're going through now will help a lot in future designs, as static timing analysis is a very important skill.

That makes sense that paths from the non PLL clock to the PLL output would have the tight requirement, considering one is 15/4ths of the other. Note that Quartus isn't doing anything funny to make these paths, and that they exist in the RTL. I'm separating Quartus from SOPC builder when I say that, as it looks like something the SOPC builder is creating is clocked by the non-PLL clock. Can you double-check your system to see if anything is run on that domain? Another option is to do a report_timing -to_clock clk_ff and list a lot of paths(maybe a couple hundred). Right now we're only seeing the registers that transfer to another clock domain, but that will show a lot more paths within that clock domain. It might become quickly apparent that a particular component is being clocked by this clock.

By digging deeper into the base clock connections, I see some kind of slave registers on a 16bit bus with a rd and wr line . I suspect this might be the interface to the EPCS device, since it has to be able to read this device before any of the fpga is configured (ie base clock driven logic), but also have r/w access after configuration (via nios/avalon bus).

There isn't any explicit connection to the base clock in any of the design, but since it is an optional component it must use some configurable logic rather than just dedicated hard cells.