VHDL signal activity and attributes ?

[whygee]

Hello,

I search a way to safely detect that all the signals
of my entities have settled before my testbench
fires another clock cycle. I find no way in the
langage to indicate that there is no delta cycle
left, so the time can advance to the next step.
And even in the next step, I can't know if activity
has been scheduled to happen :-/

I could XOR_reduce all the signals I want to observe
and then apply a simple attribute, but the closest
I come is the 'active attribute, that won't even
tell me if the signal is scheduled to change in the future.

All I could do is assume things about the tested design,
and these assumptions are dangerous and not future-proof
or fool-proof. Or else I could remove all the timing
information from the model, but this would remove
all value or interest in the model :-/

If anyone has a trick or idea, i'll gladly read it !

yg

 

[whygee]

Hi !

A postponed process is guaranteed to run after all deltas have passed -
would that help? I'm not sure I quite understand what you're looking for,

oh yes, that's one idea.
It does not solve all my issues but it's an interesting method.
I don't have my reference books and must rely on the 'net
to find the informations.

Another side of the problem is :
how are the processes executed ?
I mean, if I write a process without sensitivity list,
which loops continuously, is the process executed
at every delta time ? Or does it loops continuously
inside the delta ? I imagine that the order in which
the processes are executed inside the delta is not
easily controlled but that can be circumvented.

regards
Alan

thank you,
yg

 

[whygee]

hi !

All postponed processes are guaranteed to run after all non-postponed
processes.
If you have more than one postponed process they will run in an
unspecified order.
A postponed process may not cause another delta.

OK, this confirms what I just read in other places.

"A postponed process can't cause another delta"
_at the same clock time_, but what if it causes
a delay and then causes another delta ?
I believe that it is ok because it avoids
the time paradox.

My current idea is to drop all the timing specification
of the model (I'll see later) and use something like :


signal clk : std_logic;

postponed process
begin
-- delay
wait for 1ms;
-- cause delta
if (clk='0')
then
clk<='1';
else
clk<='0';
end if;
end process;

Of course, this is not the end of the story,
since something as simple as this does
not require "postponed". Some side-effect-prone
stuff will be added later.

The fact that this postponed process is the only
timing controller helps things, but the tested
model might contain delayed signals which could
cause the whole thing to fall apart. I could
wait for more than 1ms, like 1 day or something "long"
but who knows what nasty side effect this could cause...

thanks for the hints, I knew I missed something

regards
Alan

yg

 

[Paul Uiterlinden]

Hi !


oh yes, that's one idea.
It does not solve all my issues but it's an interesting method.
I don't have my reference books and must rely on the 'net
to find the informations.

Another side of the problem is :
how are the processes executed ?

They are all executed at simulation start (time=0, delta=0) and run until
they encounter a wait statement, which will suspend the process. A
sensitivity list is an implicit wait statement at the end of the process.
The process resumes after the wait statement is fulfilled.

Reaching the end of a process causes execution to continue at the top again.

I mean, if I write a process without sensitivity list,

and without a wait statement...

which loops continuously, is the process executed
at every delta time ?
No.

Or does it loops continuously inside the delta ?

Yes. And because the process never suspends, no delta cycle occurs anymore.
In other words: the simulator hangs, until you kill it.

Always a nice situation to debug, as you cannot break the simulator to
continue with single stepping, to find exactly where the error is. At
least, that's my experience with ModelSim.

I imagine that the order in which
the processes are executed inside the delta is not
easily controlled but that can be circumvented.

The order of execution of processes that resume at exact the same delta is
undetermined. The delayed update of signals (one delta, or some real time,
like 1 ns) makes sure that this undeterministism is not a problem and does
not create a race condition. Unless of course you are mucking around with
shared variables, but that's another story.

 

[whygee]

Reaching the end of a process causes execution to continue at the top again.

without waiting for another delta time,
if i understand correctly (and your post is clear about it)

and without a wait statement...

yes (it's not mentioned, it's not implied)

Yes. And because the process never suspends, no delta cycle occurs anymore.
In other words: the simulator hangs, until you kill it. ouch...

The order of execution of processes that resume at exact the same delta is
undetermined. The delayed update of signals (one delta, or some real time,
like 1 ns) makes sure that this undeterministism is not a problem and does
not create a race condition. Unless of course you are mucking around with
shared variables, but that's another story.

oh, it's probably worse than that ;-)

i've see "wait for 0ns" somewhere, i'll have to try too.

thanks,
yg

 

[Tricky]

Yes. And because the process never suspends, no delta cycle occurs anymore.
In other words: the simulator hangs, until you kill it.

Always a nice situation to debug, as you cannot break the simulator to
continue with single stepping, to find exactly where the error is. At
least, that's my experience with ModelSim.

I was always under the impression that one loop of a process is 1
delta. If a process never waits, it will go for infinite delta's,
which is why you set an iteration limit inside modeslsim to prevent
loops like this occuring.

 

[Paul Uiterlinden]

A delta consists of

1. All runnable processes run until they suspend (e.g. hit a wait, or in
the case of a sensitivity list reach the bottom - which is of course an
implicit "wait on")

2. Once all processes suspend, signals update (possibly creating events,
which trigger processes to be runnable again - a new delta).

This code

process
begin
end process;

gets stuck at time 0 ns delta 0 and can never escape.

And that's why ModelSim (don't know for other simulators) generates a nice
warning for such a situation:

** Warning: [2] stuck.vhd(8): (vcom-1090) Possible infinite loop: Process
contains no WAIT statement.

And to get more explanation, run "verrror 1090":

vcom Message # 1090:
A process that has no sensitivity list, contains no wait statements,
and contains no calls to procedures that contain wait statements will
execute forever without advancing time.

IEEE Std 1076-2002, 9.2 Process statement:
The execution of a process statement consists of the repetitive
execution of its sequence of statements. After the last statement in
the sequence of statements of a process statement is executed,
execution will immediately continue with the first statement in the
sequence of statements.

This message can be suppressed with the vcom option -nowarn 2.

 

[whygee]

wait for 0 ns;
will wait for 1 delta.

thanks for the confirmation,

regards
Alan

yg