meaning of transport delay

[Altera_Forum]

I wonder anybody can explain me the meaning of transport delay and how differ from just (after) statement. 

 thanks  Pete

[Altera_Forum]

In simulation delay modelling is one of at least 3 types: 

 1) delta delay: In effect a simulation bug. Simualtors can assign a target not immediately(zero delay) but on its  next simulation cycle, hence it is dependant on simulator resolution and is usually too small to be visible but  may mystify beginners in verification.  2) default delay i.e. after statement in VHDL implies what is called inertial delay.  Here model ignores any signal transients that are shorter than delay time (samples it at end of given delay). The wait for clk edge is in effect regular inertial delay(regular after).  3) transport delay: as 2 but transients are meant to pass through (samples continuously but makes the target assignment after given delay)

[Altera_Forum]

--- Quote Start ---  I wonder anybody can explain me the meaning of transport delay and how differ from just (after) statement.   thanks   Pete  --- Quote End ---     Inertial delays (the default) can basically be overriden by a subsequent assignment. Transport delays are not. Consider the following possible model for a 10 ns delay line. You might model it like this...    process(Inp_Pin) begin Out_Pin <= Inp_Pin after 10 ns; end process;    The problem is that if Inp_Pin is a pulse that is shorter than 10 ns (the length of the delay) then you won't see anything come out on Out_Pin. For example, Inp_Pin <= '0', '1' after 1 ns, '0' after 2 ns;   The first assignments of '0' (at t=0) will be overridden by the assignment of '1' (at t=1 ns) and that assignment will in turn be overridden by the assignment of '0' after 2 ns. By 'overridden' I simply mean that the result of the first assignment to 'Out_Pin' has not taken effect before there is a subsequent assignment so the result of that first assignment has basically been cancelled and forgotten.   However, the following code does accurately model a delay line. The response to the above mentioned 'Inp_Pin' will be the 'Inp_Pin' signal delayed by 10 ns;  process(Inp_Pin) begin Out_Pin <= transport Inp_Pin after 10 ns; end process;    Run a simulation so that you can see the differences. Since currently there are no products that synthesize a delay line from VHDL input 'transport' is ignored by synthesis tools. There aren't many other uses for 'transport' other than in delay lines (or similar constructs like a PCB trace model) so the main use for 'transport' you'll find is in a testbench...where it is quite handy, but even there not very frequently needed.   Kevin Jennings

[Altera_Forum]

--- Quote Start ---   1) delta delay: In effect a simulation bug. Simualtors can assign a target not immediately(zero delay) but on its  next simulation cycle, hence it is dependant on simulator resolution and is usually too small to be visible but  may mystify beginners in verification.   --- Quote End ---   Delta delay is not a 'simulation bug' is in no way dependant on 'simulator resolution' and is not 'too small to be visible' (open a list window and see for yourself).     --- Quote Start ---   2) default delay i.e. after statement in VHDL implies what is called inertial delay.  Here model ignores any signal transients that are shorter than delay time (samples it at end of given delay).   --- Quote End ---   the 'after' keyword does not imply inertial delay. Rather it is the lack of the word 'transport' that implies inertial delay.     --- Quote Start ---   The wait for clk edge is in effect regular inertial delay(regular after).   --- Quote End ---   Actually it would be 'wait until rising_edge(clk)'...but regardless, waiting on a signal is not an assignment statement therefore it is not an 'inertial' or a 'transport' delay.     --- Quote Start ---   3) transport delay: as 2 but transients are meant to pass through (samples continuously but makes the target assignment after given delay)   --- Quote End ---   There is no continuous sampling going on. A 'transport' delay simply means that a previously scheduled transition on a signal will not be erased from the signal's queue of scheduled transitions when a new assignment comes along.   Kevin Jennings

[Altera_Forum]

--- Quote Start ---   Delta delay is not a 'simulation bug' is in no way dependant on 'simulator resolution' and is not 'too small to be visible' (open a list window and see for yourself).   --- Quote End ---    No certainly it is not a bug per se but I amplified the expression to convey that it got nothing to do with design. I know for sure it depends on update rate and hence I thought it will depend on resolution(step). As to visibility, I mean on the waveforms... are we talking about same thing? Good to see your comments here as it stimulates further research.      --- Quote Start ---   the 'after' keyword does not imply inertial delay. Rather it is the lack of the word 'transport' that implies inertial delay.  --- Quote End ---    Just different wording of same concept. Naturally I mean by after as after on its own.     --- Quote Start ---   Actually it would be 'wait until rising_edge(clk)'...but regardless, waiting on a signal is not an assignment statement therefore it is not an 'inertial' or a 'transport' delay.  --- Quote End ---    again I am referring to clk edge, not actual syntax and I say "in effect" which means it is my personal perspective and certainly not that of simulator designers who will have their own intricate terminology.     --- Quote Start ---   There is no continuous sampling going on. A 'transport' delay simply means that a previously scheduled transition on a signal will not be erased from the signal's queue of scheduled transitions when a new assignment comes along.    --- Quote End ---    Just different wording of same thing...the simulator tool is sampling(or not erasing) at start of every of its cycles, I don't mean sampling in the sense of a clk edge or ADC.  Thanks for the comments.

[Altera_Forum]

Here is wiki statement on delta delay and similar statements seen in many other resources: 

   --- Quote Start ---   In vhdl (http://en.wikipedia.org/wiki/vhdl) simulations, all signal assignments occur with some infinitesimal delay, known as delta delay. Technically, delta delay is of no measurable unit, but from a hardware design perspective one should think of delta delay as being the smallest time unit one could measure, such as a femtosecond(fs).    --- Quote End ---  this is an example of how it can cause problems:  a <= b; -- comb. statement  one may think that in functional simulation it means (a) is wired to (b) and hence if (b) changes from 0 to 1 so would (a) with zero delay(concurrent).  but try it and use a clock to sample both (a) & (b),keep changing clock phase and you will get at some point a strange result. clock samples (a) as 0 but (b) as 1  The solution is to generate all signals from a reference signal e.g. clock...etc.  if we make (b) the reference then: b1 <= b; a <= b;  thus (b1) & (a) will have no delta delay.

[Altera_Forum]

--- Quote Start ---    Here is wiki statement on delta delay and similar statements seen in many other resources:   this is an example of how it can cause problems:   a <= b; -- comb. statement   one may think that in functional simulation it means (a) is wired to (b) and hence if (b) changes from 0 to 1 so would (a) with zero delay(concurrent).   --- Quote End ---     If this is the problem, then I suggest you are hijacking the thread...you should open a new topic.     --- Quote Start ---  but try it and use a clock to sample both (a) & (b),keep changing clock phase and you will get at some point a strange result. clock samples (a) as 0 but (b) as 1  --- Quote End ---   This method would only work if the sample clock is changing on the same Delta cycle as 'b' which depends on how it is generated. It is far easier to see this delta delay simply by opening a list window and drag both signals into the list window. Then you will see that 'b' changes at one time, 'a' changes on the next delta cycle.   As an example, if 'b' changes at t=1 ns, Delta=34, then 'a' will change at t=1 ns, Delta=35.   An even simpler method is signal a: std_logic := '0'; ... a <= not(a);   Put signal 'a' into the list window and run the sim. The simulator will stop at t=0 ns with an error to the effect that an iteration limit has been reached. Look at the list window. If the iteration limit is set to 1000, then you'll see 1000 lines of changes to signal 'a' as it toggles and toggles but is unable to advance real time because advancing delta time never reaches stability. Stability is when the simulator reaches a point where there are no signal transitions scheduled for the next delta cycle.   Besides clearly showing how the signal is transitioning in delta time, this example has the added benefit of demonstrating to the new user just what is meant when the simulator complains about an iteration limit being exceeded.   --- Quote Start ---    The solution is to generate all signals from a reference signal e.g. clock...etc.   if we make (b) the reference then: b1 <= b; a <= b;   thus (b1) & (a) will have no delta delay.   --- Quote End ---     While your last statement about delay between 'b1' and 'a' is true you are incorrect with your sentence "The solution is to...". The reason is that 'b1' and 'a' will have no delta delay relative to each other...unfortunately, that is not the problem that you stated. The problem definition that you proposed was "one may think that in functional simulation it means (a) is wired to (b) and hence if (b) changes from 0 to 1 so would (a) with zero delay" (emphasis KJ) Your proposed 'solution' has exactly the same delay between 'a' and 'b' and would simulate identically from the perspective of 'a' and 'b'...therefore yours is not a solution to your own problem...it may be the solution to some other problem, but again that would be yet another thread hijack. I won't be participating in that hijack if it is to occur.   Kevin Jennings

[Altera_Forum]

Thanks for the replies, clear and helpful