VHDL switching from a waveform to a constant

[shaiko]

Hello,

x is an entity input.
y is an entity output.

I want y to be driven by x for some time and by a constant '1' afterwards.

This works correctly:

signal aux : std_logic ;
aux <= '0', '1' after 100ns ;
y <= x when aux = '0' else '1' ;

This doesn't:

y <= x , '1' after 100 us ;

I've seen something similar before with Modelsim and assumed it to be a local bug...but now I see the same behavior with Active HDL.

Any idea why it happens?

 

[TrickyDicky]

Your one liner that doesnt work is the same as writing:

process
begin
  y <= x;
  wait for 100 us;
  
  y <= '1';
end process;

From this, you can see y will be updated at time 0, but not again. Putting time statements in 1 liners draws a waveform at the specified times - it isnt sensitive to the signals on the RHS (because having a process with a sensitivity list and wait statements is illegal).

 

[shaiko]

Your one liner that doesnt work is the same as...

So you're saying that one line statements are treated simply as a process without a sensitivity list with "after" serving the role of "wait for"?

Putting time statements in 1 liners draws a waveform at the specified times

By "specified time" you mean - after 100us?

 

[TrickyDicky]

single line assignments are always an implied process, with a sensitivity list made up from the signals on the RHS, unless there is a time statement in
This code is also valid, and may not produce expected behaviour.

process(x)
begin
  y <= x, '1' after 100 us;
end process;

Would also not do alot, as the new assignment to y would override the old assignment and reset the timer.
I dont have a simulator here to check which form actually gets implied. Either way, its not going to behave as you seem to expect.

 

[shaiko]

single line assignments are always an implied process, with a sensitivity list made up from the signals on the RHS

Trying to make sense out of it...

y <= x , '1' after 100 us ;

In the above example - 'x' is on the RHS and from what you're saying it implies a statement with x in the sensitivity list.
Yet you also said (in the previous post) that the above implies the following process (which doesn't have a sensitivity list at all):

process
begin
  y <= x;
  wait for 100 us;
  y <= '1';
end process;

So which one is it??
What type of process do "single liners" imply??

 

[shaiko]

Another thing,

The process equivalent of:

y <= x , '1' after 100 us ;

Is NOT

process
begin
  y <= x;
  wait for 100 us;
  y <= '1';
end process;

Both yield different results.
I really want to understand how it works...
So - what is the process equivalent of:

y <= x , '1' after 100 us ;

?

 

[K-J]

I really want to understand how it works...
So - what is the process equivalent of:

y <= x , '1' after 100 us ;

?

The process of equivalent of...

y <= x, '1' after 100 us;

is this...

process(x)
begin
    y <= x, '1' after 100 us;
end process;

The line of code 'y <= x, '1' after 100 us;' will be executed each time there is an event on x, whatever that event might be. At that time, the simulator will do three things:
- Remove any events that that might currently be scheduled for 'y'
- Schedule 'y' to be updated at the next simulation delta to the current value of 'x'
- Schedule 'y' to be updated 100 us in the future to the value of '1'

If there is a subsequent event on 'x' somewhere before the 100 us comes up, the code simply gets executed again.

The original code that TrickyDicky posted that contained the wait statement is not equivalent because it would miss any event on 'x' that occurs within 100 us of the previous event on x. The subsequent post that he had (same as mine) is equivalent. Both of those processes and the single concurrent statement complete in one simulation delta of time.

In post #4 in this thread from TrickyDicky the portion of the statement "unless there is a time statement" is not correct ("single line assignments are always an implied process, with a sensitivity list made up from the signals on the RHS, unless there is a time statement".

Kevin Jennings

 

[shaiko]

Kevin,
Thanks for the elaborate response!

- Remove any events that that might currently be scheduled for 'y'
- Schedule 'y' to be updated at the next simulation delta to the current value of 'x'
- Schedule 'y' to be updated 100 us in the future to the value of '1'

Assuming x is a simulated clock from t=0 to infinity with a time period of 5ns.
In this case the 100us scheduled event for y (green) will never be reached - because frequent changes in x will cause red to happen.

Correct?

 

[K-J]

Kevin,
Thanks for the elaborate response!



Assuming x is a simulated clock from t=0 to infinity with a time period of 5ns.
In this case the 100us scheduled event for y (green) will never be reached - because frequent changes in x will cause red to happen.

Correct?

Correct.

Kevin

- - - Updated - - -

In this case the 100us scheduled event for y (green) will never be reached - because frequent changes in x will cause red to happen.

By the way, there is another way of assigning that uses the 'transport' keyword which does not do the "Remove any events that that might currently be scheduled for 'y'". It doesn't really apply to this particular thread, but if you want to model a delay line 'transport' is useful.

y1 <= x after 10 ns; -- #1
y2 <= transport x after 10 ns; -- #2

x < '0', '1' after 20 ns, '0' after 25 ns;

Since 'x' is a 5 ns wide pulse which is less than the 10 ns delay time, the code in #1, essentially filters that pulse out and the pulse will not show up on 'y1'. In #2, the 5 ns pulse does propagate through the 10 ns delay line and will show up on y2.

Kevin

 

[shaiko]

Post #7 scores high in my: "most helpful & clarifying edaboard.com posts list"
Thanks a lot Kevin.

With simulation being serial - I often stumble upon these logical race conditions.
Can you give me a few tips/thumb rules of how to avoid these pitfalls?