meaning of transport delay

--- 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