Question about Ben Cohen's switch model

[Nicolas Matringe]

Hello all (and especially Mr Cohen)
I have looked at the switch model and I don't understand why the wait
statement includes "until ThenTime_v /= now"
It seems to me that this would trigger the process as soon as the time
counter advances. A colleague even tells me that this condition will
never be met since the function "now" won't generate an event.
In either cases, I don't understand what this is for.

Thanks in advance
Nicolas

 

[Jonathan Bromley]

On 11 Apr 2007 02:09:35 -0700,
"Nicolas Matringe" <nic_o_mat@msn.com> wrote:

I have looked at the switch model and I don't understand why the wait
statement includes "until ThenTime_v /= now"
It seems to me that this would trigger the process as soon as the time
counter advances. A colleague even tells me that this condition will
never be met since the function "now" won't generate an event.

Nicolas,

The *complete* wait statement in the switch model is

wait
on A(I)'transaction, B(I)'transaction, Cab(I)'transaction
until ThenTime_v /= now;

This wait statement has an explicit sensitivity list ("wait on").
So there is no need for the "until" condition to generate an
event; indeed, as you say, it cannot because ThenTime_v is a
variable and NOW is a function; neither can generate an event.

In effect it says:
Every time there is a transaction on one or more of
the signals {A(I), B(I), Cab(I)}, evaluate the expression
ThenTime_v/=now; if it's false, go back to waiting; but
if it's true, proceed.

So the wait will be released on the first transaction (driver
update) on any of those signals that occurs after the current
moment of simulation time.

Your colleague's point about "condition will never be met"
is based on a small misunderstanding. If you write
wait until <<condition>>;
then the wait statement has an implicit sensitivity list
built from every signal that appears in the <<condition>>.
But if the wait statement has an explicit sensitivity
list, then no implicit sensitivity list is required.

So:
wait until now >= 2 us;
is wrong - it will block forever.

But
wait on sig until now >= 2 us;
is OK; it will release at the first event on "sig"
that happens at or after time 2us.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Nicolas Matringe]

Jonathan Bromley a écrit :

On 11 Apr 2007 02:09:35 -0700,
"Nicolas Matringe" <nic_o_mat@msn.com> wrote:

I have looked at the switch model and I don't understand why the wait
statement includes "until ThenTime_v /= now"
It seems to me that this would trigger the process as soon as the time
counter advances. A colleague even tells me that this condition will
never be met since the function "now" won't generate an event.

Nicolas,

The *complete* wait statement in the switch model is

wait
on A(I)'transaction, B(I)'transaction, Cab(I)'transaction
until ThenTime_v /= now;

Yes, I know. I was only wondering about the last part (the reason for
the conditions on the signal transactions is pretty obvious)

This wait statement has an explicit sensitivity list ("wait on").
So there is no need for the "until" condition to generate an
event; indeed, as you say, it cannot because ThenTime_v is a
variable and NOW is a function; neither can generate an event.

I always thought that "wait until <condition>" implied an event on the
condition.
10 years and still learning )

So the wait will be released on the first transaction (driver
update) on any of those signals that occurs after the current
moment of simulation time.

OK I see.

Your colleague's point about "condition will never be met"
is based on a small misunderstanding. If you write
wait until <<condition>>;
then the wait statement has an implicit sensitivity list
built from every signal that appears in the <<condition>>.
But if the wait statement has an explicit sensitivity
list, then no implicit sensitivity list is required.

Why didn't anyone ever teach me this ? Why is it the first time I hear
about this implicit/explicit sensitivity list ?

So:
wait until now >= 2 us;
is wrong - it will block forever.

But
wait on sig until now >= 2 us;
is OK; it will release at the first event on "sig"
that happens at or after time 2us.

Well, thanks a lot Jonathan.
Nicolas

 

[canadianJaouk]

I actually experimented a lot with this code, and came to wonder why
transaction were necessary at all in it. The following code

process
begin
wait on a, b;

a <= 'Z';
b <= 'Z';
wait for 0 ns;

while a /= b loop
a <= b;
b <= a;
wait for 0 ns;
end loop;
end process;

works just fine. I've had more succes with this when using complex
networks of shorts connected together. With the transaction model I
would always end up running into infinite loops.

I assume there was a good reason for the transactions... Any ideas on
what could go wrong with thisimplementation?

 

[KJ]

"canadianJaouk" <jaouque@yahoo.ca> wrote in message
news:1176933364.176005.257800@l77g2000hsb.googlegroups.com...

I actually experimented a lot with this code, and came to wonder why
transaction were necessary at all in it. The following code

process
begin
wait on a, b;

a <= 'Z';
b <= 'Z';
wait for 0 ns;

while a /= b loop
a <= b;
b <= a;
wait for 0 ns;
end loop;
end process;

works just fine. I've had more succes with this when using complex
networks of shorts connected together. With the transaction model I
would always end up running into infinite loops.

I assume there was a good reason for the transactions... Any ideas on
what could go wrong with thisimplementation?

One thing that is not good about it is that the 'output side' will always

pause for a moment (i.e. a simulation delta or so) with a value of 'Z' when
the 'input side' switches. So if 'a' switches from '0' to '1', then 'b'
will go from '0' to 'Z' and then from 'Z' to '1'. One place where this gets
to be a problem is if you're using this to model a series termination
resistor for a clock signal. In that situation, when you then attempt to
use "if rising_edge(clock) then...." it will never trigger because the
transition on the clock is from '0' to 'Z' and then 'Z' to '1' neither of
which causes the rising_edge function to return a true value.

If I recall correctly, I think this is a problem with Ben Cohen's model as
well, it's not specific to your version.

Kevin Jennings

 

[canadianJaouk]

On Apr 19, 5:34 am, "KJ" <kkjenni...@sbcglobal.net> wrote:

"canadianJaouk" <jaou...@yahoo.ca> wrote in message

news:1176933364.176005.257800@l77g2000hsb.googlegroups.com...

I actually experimented a lot with this code, and came to wonder why
transaction were necessary at all in it. The following code

process
begin
wait on a, b;

a <= 'Z';
b <= 'Z';
wait for 0 ns;

while a /= b loop
a <= b;
b <= a;
wait for 0 ns;
end loop;
end process;

works just fine. I've had more succes with this when using complex
networks of shorts connected together. With the transaction model I
would always end up running into infinite loops.

I assume there was a good reason for the transactions... Any ideas on
what could go wrong with thisimplementation?

One thing that is not good about it is that the 'output side' will always
pause for a moment (i.e. a simulation delta or so) with a value of 'Z' when
the 'input side' switches. So if 'a' switches from '0' to '1', then 'b'
will go from '0' to 'Z' and then from 'Z' to '1'. One place where this gets
to be a problem is if you're using this to model a series termination
resistor for a clock signal. In that situation, when you then attempt to
use "if rising_edge(clock) then...." it will never trigger because the
transition on the clock is from '0' to 'Z' and then 'Z' to '1' neither of
which causes the rising_edge function to return a true value.

If I recall correctly, I think this is a problem with Ben Cohen's model as
well, it's not specific to your version.

Kevin Jennings

True, I have noticed that as well. Need to use if clk'event and
event=1 instead or rising_edge function. That temporarty Z drive
needs to be there so that the net value can be resolved without the
short itself influencing the outcome.

What I am a bit confused about is that why an event can be detected
when the model is driving an X on its ports. If i have a X driver on
a net, and add a '1' driver for instance, will that generate an
event? I would have thought it would not, but apparently it does.