set_{input,output}_delay for external bus - Page 1
Forum section: electronics / general

author: dolbeau
author_rank: Regular Contributor
timestamp: October 16, 2020, 05:32:29 pm
content: Hello,I have a question about set_input_delay & set_output_delay in a FPGA design, and their relationship with the specifications I have on hand for the bus I'm talking to. After googling them a lot I think I got them right, but I'm not certain.So the overall question for everything below - did I get it right or do I need to go back to the drawing board ?This in two parts; the first is important as it's a basic requirements for the FPGA tool. The second part is refinement of timing with regards to trace length, which may or may not be a good idea (side question: is it?).A) The important bit: from specs to delaysa) set_output_delayMy understanding is that the 'max' value is how long before the clock edge the signal should reach the pin. The min value is the negative value of how long after the cock edge the value should stay on the pin.So from this entry:QuoteI think I should use:Code:set_output_delay -clock SBUS_3V3_CLK -min -2.5 [get_ports {SBUS_3V3_D}]set_output_delay -clock SBUS_3V3_CLK -max 20 [get_ports {SBUS_3V3_D}]b) set_input_delayThis one I'm less confident, because I only find drawings with time *after* the clock edge, and my specification mentions before:QuoteI think the hold time is going to be the 'min' parameter to set_input_delay, while (clock_period - setup_time) is the 'max' parameter, and I should do:Code:set_input_delay -clock SBUS_3V3_CLK -min 1 [get_ports {SBUS_3V3_D}]set_input_delay -clock SBUS_3V3_CLK -max 25 [get_ports {SBUS_3V3_D}]B) The less important bit: refining the timing from wire delayThe timing should probably be accurate at the connector to the bus (says the book), so I might have to take propagation delay into account when computing the number above.a) set_output_delayI think I should take the length of the CLK trace (which delay arrival at the pin from the connector and so the FPGA reference), add the length of the signal trace (which delay arrival at the connector from the pin), compute a delay, and *add* the delay to both min and max - so that I get the signal sooner to the pin. So with 0.883ns of total wire delay I would actually use:Code:set_output_delay -clock SBUS_3V3_CLK -min -1.617 [get_ports {SBUS_3V3_D}]set_output_delay -clock SBUS_3V3_CLK -max 20.883 [get_ports {SBUS_3V3_D}]b) set_input_delayIn this case, what is important is the difference between the CLK trace length and the signal trace length. If the signal trace is longer than the CLK, then I get a timing difference that I need to add from both min and max - e.g. as the signal gets there a bit late, the hold time appears a bit longer.Code:set_input_delay -clock SBUS_3V3_CLK -min 1.060 [get_ports {SBUS_3V3_D}]set_input_delay -clock SBUS_3V3_CLK -max 25.060 [get_ports {SBUS_3V3_D}]Conversely, when the trace is shorter, the signal gets there early and the timing difference would be subtracted from both 'min' and 'max' (to less than 1 and less than 25 respectively).This is Vivado 2020.1 targeting an Artix-7, though I think the definition is independent of the manufacturer.Thanks in advance :-)

author: NorthGuy
author_rank: Super Contributor
timestamp: October 16, 2020, 07:46:26 pm
content: Your input is other device's output.I think you need to get the basics right, then everything is simple.First, let's not think about devices. Let's think about flops. There's a launching flop and receiving flop. Launching flop gets a clock edge. In response to the clock it changes its state and then new state propagates to the receiver. The new state should arrive to the receiver before the next clock edge. How much earlier depends on the receiver. The time the receiver need is called "setup" time. The new state should arrive to the receiver only after the receiver is done dealing with the previous state. How much time is needed to finish with the previous state depends on the receiver and is called "hold". As strange as it sounds, both setup and hold may be negative, but this doesn't change anything. Both setup and hold are characteristics of the receiver, not the launcher.How the timing analysis is done?To violate the setup, the delay from launcher to the receiver must be big enough. The system calculates the maximum possible delay and sees if this delay would violate the setup. If even the longest delays don't violate the setup, the system will work. The max delay is always associated with setup.Conversely, to violate the hold, the signal must travel as fast as possible. The system calculates the minimum possible delay and sees if this delay would violate the hold. Thus the min delay is always associated with hold.There are also clock adjustments. Clock emanates from some common place and travels to both launcher and receiver.When calculating max delay (for setup), we must take into account clock delays too. If the clock path to the launcher is too long, this may violate setup (so we need to add themaximumorigin-to-launcher clock delay). If the clock arrives to the receiver too early, this may violate setup (so we need to subtract theminimumorigin-to-receiver clock delay). If the clock period is a little bit shorter, this may violate setup (so we need toaddclock jitter).Similarly, when we calculate the min delay (for hold) we must account for the clock delays which can violate hold (addminimumorigin-to-launcher clock delay, subtractmaximumorigin-to-receiver clock delay,subtractclock jitter). These things will make the delay as short as possible - that's what we need to violate the hold.When you deal with the external world, the tools know everything about insides of FPGA, but nothing about the outside. What you need to do, is to aggregate the worst cases for outside wires and devices and pass the result to the tools. They will add this value to the delays calculated for inside and complete the timing analysis.For example set_output_delay is about sending a signal to an outside device. The outside device is a receiver and must have setup and hold characteristics. So, we pile up all the delays which can violate the device's setup. We try to make the delay longer -maximumboard delay for the data traceplusreceiver setup time minusminimumboard delay for the clock trace - this will give you -min you need to give to the tools.Similarly, for set_output_delay -min we pile up everything we can to make the delay smaller and violate the hold -minimumboard delay for the data traceminusreceiver hold time minusmaximumboard delay for the clock trace.For set_input_delay, FPGA is a receiver. It has a receiving flop which has setup and hold characteristics, but we are not concerned with them because they're inside FPGA. So, we gather the delays from the external device datasheet (which is a launcher this time) trying to violate FPGA's setup or hold as much as we can. If you understood the principle, it shouldn't be a problem to do that.

author: dolbeau
author_rank: Regular Contributor
timestamp: October 17, 2020, 10:29:35 am
content: Quote from: NorthGuy on October 16, 2020, 07:46:26 pmFirst, thank you very much for the kind detailed explanations :-)That bit I understand, but it makes me realize I was remiss in my explanations - my 'external' (other) device is a mainboard bus, not a single piece of silicon. The numbers I quoted are the timing characteristics as defined by the bus specifications. They were originally implemented in 1989 and have been obsolete for 20 years but that's what I want to interface with... (weird?) hobby stuffMy understanding is that the specifications as quoted are requirements for the peripheral on the bus, which is what I'm trying to implement. So at the connector that plugs into the bus, the signal is valid from 15ns before the edge to 1ns after the edge. To ensure this timing is met when talking to other peripheral on the shared bus, my peripheral must put a valid signal from 25ns before the edge to 2.5ns after the edge (which I forgot to quote, so here it comes).QuoteI'll be thinking out loud below to track my understanding ... or perhaps lack thereof.QuoteThanks for the vote of confidence. I'm purely a software guy and hardware - in particular timings - does not come naturally. I'm not finding *anything* simple, from PCB to VHDLI've managed to get some VHDL simulating to waves similar to what I have in the specifications & books, but that's the 'easy' cycle-per-cycle/purely digital part.QuoteIn my case, when my connector is the receiver it needs [setup,hold] from [-20,2.5] ns relative to the clock edge ("to next cycle output valid", "Output hold time" in the specs).QuoteIn my case, the bus supplies the clock. So when I measure clock delay to itself, I believe I can assume it's zero (with perhaps some jitter).QuoteFrom what you wrote before, I think that last '-min' is a typo and this is the '-max' for setup? So I think I got that one right - except I didn't really do min/max for the track delay yet; I know the length from the board design I will need to estimate max/min signal propagation speeds.From the FPGA (launcher) to the bus (receiver) setup,Code:set_output_delay -max* + maximum board delay for the data trace: 0.47 ns* + receiver setup time: (40-20)=20 ns* + maximum origin-to-launcher clock delay: 0.41 ns* - minimum origin-to-receiver clock delay: 0 ns* (+ clock jitter)-> the 20.883 from my original post (modulo some rounding in the copy/paste).I will have to re-read my specifications for the jitter value.QuoteThat one seems OK as well.From the FPGA (launcher) to the bus (receiver) hold,Code:set_output_delay -min* + minimum board delay for the data trace: 0.47ns* - receiver hold time: 2.5 ns* + minimum origin-to-launcher clock delay: 0.41 ns* - maximum origin-to-receiver clock delay: 0 ns* (- clock jitter)-> the -1.617 from my original post.BTW, that was a clearer explanation than what I had found via google!QuoteFor me it's not so obvious how to move from one to the other, mostly because I don't understand how to fit the parameters from my bus.From the bus (launcher) to the FPGA (receiver) setup,Code:set_input_delay -max* + maximum board delay for the data trace: 0.47 ns* + receiver setup time: (fpga, built-in the tool)* + maximum origin-to-launcher clock delay: 0 ns* - minimum origin-to-receiver clock delay: 0.41 ns* (+ clock jitter)-> which would be 0.06 nsFrom the bus (launcher) to the FPGA (receiver) hold,Code:set_input_delay -min* + minimum board delay for the data trace: 0.47ns* - receiver hold time: (fpga, built-in the tool)* + minimum origin-to-launcher clock delay: 0 ns* - maximum origin-to-receiver clock delay: 0.41 ns* (- clock jitter)-> which would also be 0.06 ns'set_input_delay' is commonly described as 'Sets input delay on pins or input ports relative to a clock signal', which those number would be - the only thing in the value is the difference in track length (which a competent PCB designer probably (c|w)ould tune to 0), and twice the  jitter. Also, using multiple propagation speeds would expand the gap. And for data signals with a track length shorter than the CLK's, this could go negative. I think I understand that part.However, this means in this version I never tell the FPGA tool about the 15ns before/1 ns after guarantee from the bus. Is there some way I can tell the FPGA that there is some additional margin to acquire the signal from the bus? Or is it something of no concern? They are not 'delays' as such, but it feels like they are important nonetheless...As far as I understand, in the specifications they are setup/hold requirements specified for the input side of the peripheral I'm implementing, from which are derived the setup/hold requirements seen by the output side of the peripheral I'm implementing (i.e. I need to output the signal 20ns before the next clock so that the other peripheral on the bus see the signal at least 15ns before the clock). So maybe they are only here so that whichever silicon is implementing the peripheral (in my case, the Artix-7) has receiver setup/hold requirements that fall into the limit of that [-15,1] ns bus specifications?

author: NorthGuy
author_rank: Super Contributor
timestamp: October 17, 2020, 05:07:14 pm
content: Quote from: dolbeau on October 17, 2020, 10:29:35 amSure.Quote from: dolbeau on October 17, 2020, 10:29:35 amYou should, when FPGA is a receiver. The ideal situation is when the signal arrives to FPGA immediately. This is not the case. The launcher will have a delay, but the bus guarantees that the signal will arrive at least 15 ns before the next clock edge. This is (clock_period - 15 ns) delay. So, this number (clock_period - 15 ns) plus whatever is in the wires is your -max delay which may violate the setup, but you don't worry about the setup value because it's inside FPGA. You can see that if the bus guaranteed wide window (say 20 ns instead of 15 ns), the max delay would be shorter, which would make it easier for you to meet the setup requirements of the flop.Similarly, from the hold viewpoint, the bus does not remove the signal at the clock edge, but it guarantees that the signal will linger for at least 1 ns. This is your asset. You add this to your -min calculation. This will help to meet the hold requirements of a flop somewhere inside your FPGA.Note that the situation may be different if the communication is not source-synchronous, that is one side drives the clock and the other side drives the data.

author: dolbeau
author_rank: Regular Contributor
timestamp: October 18, 2020, 06:32:59 am
content: Quote from: NorthGuy on October 17, 2020, 05:07:14 pmThanks again; so I had gotten it essentially right the first time, and thanks to your explanations I understand *why* significantly better