Timequest & Output delay problem

[Altera_Forum]

Hey: 

 I'm using Timequest and am looking at output timing for an external interface.   I've specified a virtual clock for my set_output_delay command with a value of 14.22ns which is the setup time of the external device. The external device is sourcing the clock I'm using for internal logic and I've set this clock and the virtual clock to the same period (20.833ns). There are no multicycle paths defined for this clock domain.   When I do a report timing (my internal clock is the source and my virtual clock is the destination) I get the waveform attached and it reports a setup time slack of 27.433ns which of course is greater than the period.    Also notice that it starts the output delay at the rising edged of the latch clock.  Does anyone know how this can happen without any multicycle paths defined?   Thanks   alan

[Altera_Forum]

The output delay of 14.22ns is helping your setup, but should be hurting it. Maybe it's negative in your constraints? The arrow should be going in the other direction.

[Altera_Forum]

Rysc: 

 Yes the arrow should be going in the other direction and you are correct that the value I calculate is negative. I used the examples from the TimeQuest Timing Analyzer Cookbook document with setting the delay value using an expression including board delays i.e. expr [CLKBs_max - Tsub_max + BDb_max - CLKBd_min] with the Tsu number being much higher than any of the other values. In the example with the numbers defined I would also expect that the example number would be also be negative.   Interestingly enough I looked at another output pin on a different clock (similar conditions to my first example) and it seems to be calculatiing things correctly - but it shows a -10.00 output delay value with the arrow heading left from the latch edge. And this makes sense. But this output delay also uses the same expression calculation with a setup number much higher than any of the other values.   At this point I'm a little puzzled about why one works and the other does not but at least I understand what the timing analyzer is doing.   Seems like I need to force the results of the expression calculation to be positive or simplify the calculation such that it cannot be negative.   If you have any other thoughts please let me know.   Thanks,   Alan

[Altera_Forum]

Which example?  

Walking thru it, your clocks are edge aligned, so the default setup relationship is one clock period, or 20.833ns. This is the difference between your launch and latch edge. If your external delay was 0ns(and I often start them at 0ns for a placeholder), then the FPGA has 20.833ns to get it's data out. Now, whatever the external delay is will cut into that delay. So as the external delay gets larger, the FPGA has less time to get the data out. So the Tsu should be a positive number. The board delay is also a positive number. The clock delay to the FPGA is a positive number. All three of these things hurt setup and help hold. The only one that helps setup is the board delay to the external device, and hence that's a negative number.

[Altera_Forum]

Rysc: 

 The example is on page 1-11 (example 1-11) in the Analyzer Cookbook as follows:   set_output_delay - clock clkB_virt  -max [expr $CLKBs_max - $tSUb_max + $BDb_max - $CLKBd_min] ...   The variable values were defined above in the example and they would give the following expression:   [0.100 - 0.500 + 0.100 - 0.050]   So this would produce a negative number. I'm assuming TCL will evaluate this left to right but this is the first project I've used TCL. It seems to me that this expression as written is not correct but perhaps in this example it does make sense. By the way they describe the tSUb_xxx values as the clock to out of the external device which I think should be the setup of the external device. Probably a cut and paste error.   Now what you said actually makes sense and thats the way that I also think about the calculation (this is a case of me being stupid, blindly following an example and not thinking about what's really going on) so I think the expression should be:   [expr $tSUb_max + $BDb_max + $CLKBd_min - $CLKBs_max]   And yes my clocks are aligned and my simple calculation (in my head looking at the waveform) was:    slack = (period - (internal clock delay + output data path delay + output delay value (i.e external setup time required)).   But I had not consider the effect of a negative number for the output delay calculation. Which I think can be a valid result but not in my case. The setup numbers for the IC I'm interfacing to are in the 9.2 to 14.6ns range depending on the signal - obviously much larger than any board delays. I originally thought that negative values would just be treated as essentially positive numbers for the output or input delays but in thinking about it that obviously would not be correct.    Thanks for making me actually think about this stuff.   Alan

[Altera_Forum]

I've found it easy to totally get wrapped up into equations and lost in the details. THe funny thing is there is no complex math, it's just addition or subtraction. So I start with my requirement and I figure out that the -max output delay cuts into it as it gets larger. So anything that cuts into my setup is added, anything that helps is subtracted. 

Most importantly though, is analyzying the final report. I tend to look at the Data Path tab rather than the waveform because it gives more details, but in the end they show the same thing. For an output, the Data Arrival is the delay through the FPGA. This is everything you care about except a) manual PLL phase-shifts or b) negative edge clocking, both of which affect the launch and/or latch edge. So in your case which doesn't have a) or b), I would treat it as the Tco. Your requirement is 20.833. That requirement minus your output delay and minus your Tco should be your slack, and it should all add up.

[Altera_Forum]

The example in the cookbook seems to be wrong. 

 Your max output delay should specify everything that is not already known by TimeQuest, and that affects the setup relationship of the outputs. Anything that hurts should have a positive magnitude, and anything that helps, a negative one. In your case, all the parameters hurt (I think Rysc was thinking on system synchronous, but you are saying the clock is generated by the external device).  So your set_output_delay max should be: max_data_board_delay + max_clock_board_delay + external_device_tSU.  Note that the board delays "hurts" twice.

[Altera_Forum]

Rysc, vjAlter: 

 Guys thanks I got it all sorted out.   vjAlter - you are correct Rysc was thinking of a system synchronous (which is not my case) and yes the example in the cookbook is wrong.   I ended up with the equation you mentioned in your response.   Thanks again for your help.   Alan

[Altera_Forum]

A good example ,thanks all

[Altera_Forum]

shouldn't "So your set_output_delay max should be: max_data_board_delay + max_clock_board_delay + external_device_tSU." 

 be:  max trace delay for data + Tsu of external device - min trace delay for clock ? i.e. the setup plus skew. ? Please be gentle - every app note/white paper/forum thread confuses me more - Sorry for adding to the confusion.   Any chance of an altera definitive guide one day?

[Altera_Forum]

Calvyn: 

 The answer could be yes but it assumes that the model you use has an external clock that drives both the external device and the FPGA. This is shown in the Timing Analyzer Cookbook example (figure 1-9)   That is not the case in my design.   I have an external oscillator which drives the external device. The external device then drives the clock into the FPGA (this is usually referred to as source synchronous).   Because of this I have added the clock delay from the external device to the FPGA. Normally you would then subtract the min delay for the clock (if this is for the max output constraint) to the external device but in my case I have set this to zero because as I mentioned above the external device is sourcing the clock to the FPGA.   Hope this helps.   Alan