Tco Constraints

--- Quote Start ---

What I understand a Tco constraint does is that it specifies the maximum acceptable time for a signal at the input to a register on a clock edge to appear at the output pin. Is this what it actually specifies?

--- Quote End ---

Tco is the time from a clock edge to the output of the register actually changing. In your case the delay between a clock edge and your reset signal being activated. I would expect your clock signal to be in the "from" field.

--- Quote Start ---

I don´t understand why an error is not produced by quartus and why this causes the warning mentioned above

--- Quote End ---

Quartus sometimes just ignores invalid constraints and assignments. Is there a section in the report or console where it says something like "found x invalid timing requirements" - if you find this and expand it you may find this assignment in there.

According to the Quartus help on tco "This time always represents an external pin-to-pin delay" so I think you're probably safe to remove the assignment in question - Quartus should handle the internal timing requirements based on the clock requirement.

Is there a tpd requirement associated with your warning message - i.e. your man might have wanted the reset to propagate to the outputs in 14 ns.

--- Quote Start ---

Are there any guidelines for placing Tco constaints that i should be aware of, if I want to verify or change existing constraints.

--- Quote End ---

I thin kit's just a case of looking at your design and working out the relationship between the signals on the board.

You didn't mention what type of constraint it was(or I missed it, or it's implied to be a Tco). Anyway, one thing about how the assignment editor works. There are multi-point assignments, which have a node in the from and to columns, and single-point assignments, which always are listed in the to column, regardless of if it's from or to anything. Sometimes this doesn't make sense though. For example, if doing a Tsu constraint, you could do:

From -> pin_name

To -> internal_registers

So that all paths from the pin_name the internal_registers it feeds have this Tsu requirement. Or you could do a single point assignment of:

To -> pin_name

In this case it's a single point assignment, so the concept of from/to is ignored, and Quartus just knows your putting a Tsu constraint on the pin pin_name.

Just pointing out that you have a single point assignment.

(And to get more confusing, different timing constraints work differently for single points assignments. For example, Cuts propogate forward, i.e. you're cutting the timing on all paths that that node fans out to, while if it were a Multicycle single-point assignment, you're applying the multicycle to all paths leading into that node. This is all another reason why Classic Timing Analyzer was abandoned for TimeQuest...)

Thank you for both replies.

Forgive me but I´m still a little confused about the Tco constraint as I always thought that it was the time from a clock edge until the signal appears at an output pin, as this was the description given in the assignment editor in Quartus. It wouldn´t be the first time that i have misinterpretted it though. Also Quartus says that the time value specified in a Tco constraint "always represents an external pin to pin delay". What exactly does altera mean by this: a register input to output pin or an input pin to output pin?

Is it possible to place a Tco between 2 signals and then the Tco could mean the time from the clk edge until the output appears at the register output?

The constraint in question is a single point Tco costraint it seems. This constraint has an internal reset signal in the 'To' field, so Quartus, if I understand correctly, will attempt to meet the Tco time specified from this signal to each output pin that it can effect. Am I correct on this?

So now the warning that I see in the timing report makes sense (I initially thought it seemed unrelated, but the original constraint did not appear in the ignored constraints list), Quartus seems to be saying that from this signal to one of the outputs that the reset can affect does not meet the timing constraint.

I have had a look at the code and can see nothing abovious that I can do to improve the timing, so i suppose I will just relax this constraint and see how this work out in the simulation later.

Many thanks.

Tco should be from pin to pin. If it started at some point inside the chip, then in general it would not be very useful. On one compile the delay to that arbitrary point could be 1ns, on the next compile it could be 10ns, and the time your data comes out would be all over the place, yet Quartus would report the same Tco since it ignored the variance up to that point.

That being said, I'm not sure exactly what's being analyzed in your case. Right-click on it in the Tco report and do a List Path. You should see a message added to the window below, which can be opened to get more detail. This should tell you everything that it's analyzing and in much more detail. I can't tell you what the original designers intent was, which is the difficult problem you need to tackle.

Also, I think a Tco can be an asynchronous reset, i.e. if a reset comes in, goes through the register and to the output pin, much like a clock would.

--- Quote Start ---

Also Quartus says that the time value specified in a Tco constraint "always represents an external pin to pin delay". What exactly does altera mean by this: a register input to output pin or an input pin to output pin?

--- Quote End ---

As I understood this, you have a clock somewhere in your FPGA which ultimately comes from an input pin.

--- Quote Start ---

The constraint in question is a single point Tco costraint it seems. This constraint has an internal reset signal in the 'To' field, so Quartus, if I understand correctly, will attempt to meet the Tco time specified from this signal to each output pin that it can effect. Am I correct on this?

--- Quote End ---

I'm not quite sure what your particular "From * To reset" constraint would be doing to be honest - I would have thought that it would get ignored because reset is not an output pin. I would be surprised and worried if Quartus was transforming that constraint into "From reset To everything_else_that_depends_on_reset". I'm not saying that's not what's going on, but if it is what's going on then it's very weird and illogical.

from Rysc:

--- Quote Start ---

Also, I think a Tco can be an asynchronous reset, i.e. if a reset comes in, goes through the register and to the output pin, much like a clock would.

--- Quote End ---

I had understood that Tco was strictly for a clock and to achieve this for a reset, one would have to use tpd - again I wouldn't swear blind to this and Rysc may well be right.

Basically I can see no reason why you would actually want to specify the tco for an internal signal - why would you want a particular register's output to change within x ns of the clock edge - you don't care how fast it changes as long as it's fast enough to meet the setup times of downstream logic and registers to meet the clock requirements. If it meets the clock requirements then why would you want to make it faster - you're just giving Quartus a harder job to do.

--- Quote Start ---

...so i suppose I will just relax this constraint and see how this work out in the simulation later.

--- Quote End ---

- I would say strip it out and check your simulation afterwards.

Frankly I think you're in a bloody difficult position - you've obviously had an undocumented design dumped on you which was done by somebody who may not have fully understood what all the constraints meant and so ended up over-constraining the design. You could chuck out all of the constraints and then look at the design yourself and work out from scratch what they should be - potentially risky and I'm not even sure that I'd want to attempt it myself but it depends on how confident you are of your abilities and how confident you are that the majority of the existing constraints aren't a load of guff.

Good luck - you really have my sympathy on this one.

Thanks for the sympathy Batfink. Yeah to be honest it´s an absolute nightmare, I´m still very much a beginner at this, but previous projects I have worked on were much more interesting and enjoyable. Needless to say I haven´t really been enjoying my work lately but thanks to yourself and Rysc, its becoming a little easier.

From looking at the code so far there are quite a few parts badly done, and its looks the same with the way the design has been constrained. Quartus is ignoring at least 1000 multicycle constraints (and I haven´t got to them yet!) and it seems in general that little thought was put into how the design was constrained.

Anyway I´ll keep plugging away bit by bit.

Thanks again for your help.

Hi,

I have seen a slow slew time contraint on each of the output pins in the design. I suppose its obvious what it does, and in the assignment editor it says that this value will affect any Tco constraint which apply to the pins. What I am wondering is, would applying a slow slew rate constraint to each pin be nessesery under normal circumstances? I have seen that by disabling this constraint, I can see huge improvements in the timings.

What is the danger in disabling them? Just that more noise may be generated and signals may be received incorrectly?

The design is used as a VME bus controller, so the interface with the local processor and the actual VME bus is asynchronous. Given that fact that the interface is asynchronous and precautions would be taken to ensure that all signals are read correctly to avoid metastability etc, would bit be ok to remove these constraints. Maybe this is difficult for anyone to answear given that they are not familiar with the board etc, but any adivice would be appreciated.

Just another query I have regarding the Tco constraints. Rysc said yesterday that really a Tco constraint should be from input pin to output pin, as if it is from a register to output pin, the delay could from an input pin to the register could change. But if the inputs enters the FPGA and is clocked through various components before finally being clocked out, what is the best way to constrain this. Is it by constraing every path between the clock cycles from the input pin to the output. in which case it would be aceptable to place Tco contraints from register inputs to FPGA outputs

One final thing on a slightly different topic:

When I look at the clock setup time warnings, Quartus reports the required longest P2P time and the actual longest P2P time. What is the difference in these? and why is the fmax calculated using a differnt value.

For example one warning appears as follows:

Required seup relationship: 20 ns (50 MHz)

Required longest P2P Time: 18.8 ns

Actual Longest P2P Time: 19.8 ns

Actual Fmax: 47.62 MHz ( period = 21.000 ns )

Why does fmax have a period of 21ns and what is the difference in the required and actual P2P times?

Again many thanks for your help.

Required is what you put in for the clock constraint. Required P2P is essentially the requirement between the registers. Essentially this is after clock skew. Actual is how long that was, and then the actual Fmax is how fast that path could run at according to the timing results. Right-click on a path, do a List Path, and analyze the detailed report, and most of this should come out. You won't fully understand timing analysis with relying heavily on that list path. The panels in the timing report are just summary level info on each path.

I believe a Tco can go through ripple clocks, i.e. where the incoming clock feeds a register, and that register's .Q pin feeds the .CLK port of the next register, and can ripple through multiple registers. It's not recommended, but it's doable. So if you have a Tco on the output pin, then you should see this full analysis. Again, analyze the List Path to see what is being analyzed and then determine if it's what you need, and if not, why?

I may have mis-understood the Quartus literature when it says tco applies from an input pin to an output pin; but I had thought that the input pin is your clock and the output pin is obviously your signal output - i.e. tco is the time between the clock edge and output changing. Ultimately the clock will come from an input pin - hence the Quartus literature saying it applies to input and output pins.

The slew rate limiting as far as I know is to limit the rise (and fall) times of outputs. Basically the edge slope is the critical parameter when you're considering signal integrity on the board - forget about the frequency of clocks etc - it's the slope of the transitions on those signals that contains the high frequency stuff which causes you problems. If you're not running signals at stupid MHz then you don't need them to transition that quickly - so if it's giving you grief you can limit the slew rate. Quite often this is done as standard to avoid signal integrity / EMC issues rather than finding you need it and then turning it one.

My advice would be to get a scope out and see if the signals are suffering with ringing, overshoot etc without the slew rate limit. If they're OK and they don't appear to be upsetting anything else then you're probably safe to leave the slew rate limit off.