VHDL switching from a waveform to a constant

Status
Not open for further replies.
S

shaiko

Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Visit site
Activity points
18,302
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:

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

This doesn't:
Code: 
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?
 

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

Code: 
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).
 
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Your one liner that doesnt work is the same as...
Click to expand...
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
Click to expand...
By "specified time" you mean - after 100us?
 

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.

Code: 
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.
 
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
single line assignments are always an implied process, with a sensitivity list made up from the signals on the RHS
Click to expand...
Trying to make sense out of it...
Code: 
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):
Code: 
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??
 

Another thing,

The process equivalent of:
Code: 
y <= x , '1' after 100 us ;
Is NOT
Code: 
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:
Code: 
y <= x , '1' after 100 us ;
?
 

shaiko said:
I really want to understand how it works...
So - what is the process equivalent of:
Code: 
y <= x , '1' after 100 us ;
?
Click to expand...

The process of equivalent of...
Code: 
y <= x, '1' after 100 us;

is this...
Code: 
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
 
Last edited:
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'
Click to expand...

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

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

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
 
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
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?
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…