Electronics > FPGA
set_{input,output}_delay for external bus
(1/1)
dolbeau:
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 delays
a) set_output_delay
My 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:
--- Quote ---For tri-state circuits: (all signals except INT[7:1]*)
ParameterConditionSymbolMin.Max.UnitRising edge of CLK to next cycle output valid @ 25 MHz20 MHz <= FCLK <= 25 MHz CL = 100 pFTOD252.520ns
--- End quote ---
I think I should use:
--- Code: ---set_output_delay -clock SBUS_3V3_CLK -min -2.5 [get_ports {SBUS_3V3_D[1]}]
set_output_delay -clock SBUS_3V3_CLK -max 20 [get_ports {SBUS_3V3_D[1]}]
--- End code ---
b) set_input_delay
This one I'm less confident, because I only find drawings with time *after* the clock edge, and my specification mentions before:
--- Quote ---For tri-state circuits: (all signals except INT[7:1]*)
ParameterConditionSymbolMin.Max.UnitInput setup time required before rising edge of CLKTIS15nsInput hold time required after rising edge of CLKTIH1ns
--- End quote ---
I 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[1]}]
set_input_delay -clock SBUS_3V3_CLK -max 25 [get_ports {SBUS_3V3_D[1]}]
--- End code ---
B) The less important bit: refining the timing from wire delay
The 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_delay
I 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[1]}]
set_output_delay -clock SBUS_3V3_CLK -max 20.883 [get_ports {SBUS_3V3_D[1]}]
--- End code ---
b) set_input_delay
In 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[1]}]
set_input_delay -clock SBUS_3V3_CLK -max 25.060 [get_ports {SBUS_3V3_D[1]}]
--- End code ---
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 :-)
NorthGuy:
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 the maximum origin-to-launcher clock delay). If the clock arrives to the receiver too early, this may violate setup (so we need to subtract the minimum origin-to-receiver clock delay). If the clock period is a little bit shorter, this may violate setup (so we need to add clock jitter).
Similarly, when we calculate the min delay (for hold) we must account for the clock delays which can violate hold (add minimum origin-to-launcher clock delay, subtract maximum origin-to-receiver clock delay, subtract clock 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 - maximum board delay for the data trace plus receiver setup time minus minimum board 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 - minimum board delay for the data trace minus receiver hold time minus maximum board 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.
dolbeau:
--- Quote from: NorthGuy on October 16, 2020, 07:46:26 pm ---Your input is other device's output.
--- End quote ---
First, 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 stuff :)
My 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).
--- Quote ---ParameterConditionSymbolMin.Max.UnitOutput hold time after rising edge of CLKCL = 50 pFTOH2.5ns
--- End quote ---
I'll be thinking out loud below to track my understanding ... or perhaps lack thereof.
--- Quote ---I think you need to get the basics right, then everything is simple.
--- End quote ---
Thanks 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 VHDL :) I'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.
--- Quote ---(...) The time the receiver need is called "setup" time.
(...) How much time is needed to finish with the previous state depends on the receiver and is called "hold".
--- End quote ---
In 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).
--- Quote ---There are also clock adjustments. Clock emanates from some common place and travels to both launcher and receiver.
--- End quote ---
In 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).
--- Quote ---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 - maximum board delay for the data trace plus receiver setup time minus minimum board delay for the clock trace - this will give you -min you need to give to the tools.
--- End quote ---
From 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
--- End code ---
* + 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.
--- Quote ---Similarly, for set_output_delay -min we pile up everything we can to make the delay smaller and violate the hold - minimum board delay for the data trace minus receiver hold time minus maximum board delay for the clock trace.
--- End quote ---
That one seems OK as well.
From the FPGA (launcher) to the bus (receiver) hold,
--- Code: ---set_output_delay -min
--- End code ---
* + 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!
--- Quote ---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.
--- End quote ---
For 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
--- End code ---
* + 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 ns
From the bus (launcher) to the FPGA (receiver) hold,
--- Code: ---set_input_delay -min
--- End code ---
* + 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 [missing] 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?
NorthGuy:
--- Quote from: dolbeau on October 17, 2020, 10:29:35 am ---From what you wrote before, I think that last '-min' is a typo and this is the '-max' for setup?
--- End quote ---
Sure.
--- Quote from: dolbeau on October 17, 2020, 10:29:35 am ---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?
--- End quote ---
You 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.
dolbeau:
--- Quote from: NorthGuy on October 17, 2020, 05:07:14 pm ---(...)So, this number (clock_period - 15 ns) plus whatever is in the wires is your -max delay which may violate the setup
(...)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
--- End quote ---
Thanks again; so I had gotten it essentially right the first time, and thanks to your explanations I understand *why* significantly better :)
Navigation
[0] Message Index
Go to full version