Source Latency Definition

--- Quote Start ---

But jump now to the first case of confusion for me, namely the description of the set_input_delay command option -reference_pin <target>. Here the text reads:

specifies a pin or port in the design from which to determine source and network

latencies. this is useful to specify input delays relative to an output port fed by a

clock.

Can someone help me to translate that excerpt? How can one even conceive of input delays relative to an output port? What does that mean?

--- Quote End ---

It is confusing as such but could it be context related i.e. applies to the case when clock is output from fpga to get data from a device(clk opposite data direction).

Your thoughts about external delay/internal delay are correct. I don't see why altera technical editor has changed names to source/network delay.

--- Quote Start ---

Another source of confusion on this subject is found just below the description of the create_generated_clock command. The text reads:

source latencies are based on clock network delays from the master clock (not

necessarily the master pin). you can use the set_clock_latency -source

command to override source latency.

Based on clock network delays? That is confusing because "source" and "network" delays are seemingly independent based on the definition I cited earlier in this post. I thought source delays were external to the device. I have been groping with this for too long. Any hints?

Many thanks!

--- Quote End ---

Possibly, now the technical editor is confused and defines source as "source" literally not as external delay as he first defined it.

The best think to stick to your thoughts of external Vs internal delays.

Having said that, I normally don't use delay to get control of input/output data timing issues.

Instead I use Tsu/Th for input data, Tco for output data. Then let quartus do the work of delays. This approach is less confusing. The only drawback is when the delay graininess doesn't achieve my figures. In this case I rotate the clk internally using the lovely PLL.

For example:

If a device sends data and clk with Tco of 2ns. board delay of 1 ns estimated for clk and 1.5ns for data(I am not recommending this) then the data relation to clk becomes 2.5ns at pins. From this I will optimise timing window by entering Tsu/TH for a given frequency and quartus will insert delays.

As you can see any board delay can be passed as such to pins.

This method also covers cases when clk is opposite data and whether data is input as above or output(then you enter Tco instead taking into account any board delays and external device Tsu and TH).

So in short I configure my fpga for Tsu,TH,Tco as required to deal with external devices having fixed timing window and various board delays.

I use the classic analyser but it gives both options i.e. delays or Tsu/Th/Tco.

I presume TimeQuest will have similar features

TimeQuest does not have Tsu/Th/Tco, and you should always do external delays. From the original post, your concept of source and network latency are exactly the way I think of them. (Basically source is something TimeQuest can't know, while network is what it does know since it's all in the FPGA).

For the -reference_pin, I never use that(and if I did, it makes more sense on set_output_delay to something source synchronous). The reason I never use it is that it's short-hand for putting a create_generated_clock on an output port and then referencing that clock. I personally think this longer method makes more sense, and it gives the user more control, such as being able to name the clock going off chip.

Where it would be used with a set_input_delay is if you send a clock off chip and have a roundtrip delay(think of a read from external flash) back to your main clock delay. But again, put a generated clock on that and use that for your external clock. For the create_generated_clock part you quoted, I think it's talking about the fact that if you put a master clock in the middle of your design, then the latency starts there. For example, if you put a create_clock assignment to the output of a clock mux, then your latency will be calculated from that point, as if the clock magically appeared at that mux output, rather than tracing back to the source input ports. Of course, I don't think you should be putting a create_clock on the output of a mux, and instead should be doing a create_generated_clock assignment. (General rule of thumb is to use create_clock for input clock ports and external clocks, and create_generated_clock for anything internal to the FPGA or clocks going off chip).

Be careful about reading too much into the documentation. Not that it shouldn't be all correct, but you can get yourself caught up into mental knots. If you want to use the constraint, add it into your .sdc, do a report_timing, and then see how TimeQuest uses it. The weird corner cases usually don't matter, and the way it's used is pretty straightforward. (For as complicated as TQ can seem, at a basic level it takes the numbers you give it and either adds it or subtracts it in its slack calculations. I find looking at real examples are so much easier than talking about theoreticals.)

And speaking of corner cases, the one gotcha I've seen with set_clock_latency is if you do two constraints, an -early and a -fall, on the same clock into the FPGA. For example, if you're trying to mimic some variance and do a set_clock_latency -early 3.0 to fpga_clk, and also do a set_clock_latency -late 3.3 to fpga_clk. The problem is that internal paths will use both of these numbers, i.e. for a setup analysis, it will use 3.3ns as the source latency to your launching registers(I'm not saying source register to avoid confusion), and it will use 3.0ns as the source latency to your destination register. So if your clock period is 10ns, you've essentially cut your setup requirement by 300ps. Hold requirements will also get 300ps more strict. Bottom line is that you only want to use one number for source latency into the FPGA. (For external clocks, it's not a problem.)

Finally, I think set_clock_latency is pretty cool, but I don't see anyone using it. The more common practice is to just roll the number up into the set_input/output_delay constraints.

--- Quote Start ---

(For as complicated as TQ can seem, at a basic level it takes the numbers you give it and either adds it or subtracts it in its slack calculations. I find looking at real examples are so much easier than talking about theoreticals.)

--- Quote End ---

Indeed! I agree wholeheartedly. I'm not comfortable at this point however creating my own examples and "learning" from them. It may not be immediately clear to me if I'm doing something properly or interpreting TQ's response appropriately. Moreover, I may not be sufficiently challenging myself with a given example to fully grasp the implications of what I'm doing. I think I need a mentor to offer a few incrementally more challenging scenarios and then evaluate my effort to constrain appropriately.

With that in mind, a couple of ideas arise: where/how can I find such a mentor? Perhaps I could find a contractor. Or, what is the best approach here to communicate example problems and their solutions? Should I just post something in a Word document? "Here is a problem I started with. Is this the correct approach to TQ SDC constraining?" Or someone could post a problem to challenge me. To show me that I don't need constraint type X to solve it; I can use constraint type Y to handle it.

Many thanks again! I'm eager to learn and willing to do my homework.