elektroda.net NewsGroups Forum Index - Verilog Language - Non-Blocking versus blocking
Cary R.
Guest
Guest
Thu May 27, 2010 2:33 am
Jonathan Bromley wrote:
Quote:
[*] Wait until Cary R. puts his head above the parapet to
explain all the other weird and wonderful timing machinery
you can use in Verilog thanks to primitives and specify blocks.
It's complicated and I almost never use it, so I won't even
try to explain - I'd get it badly wrong. Gate-level sim
people rely heavily on it.
explain all the other weird and wonderful timing machinery
you can use in Verilog thanks to primitives and specify blocks.
It's complicated and I almost never use it, so I won't even
try to explain - I'd get it badly wrong. Gate-level sim
people rely heavily on it.
I'm busy so I'll keep my head low! The quick answer is gate and UDP
primitives have inertial delays. Using a specify block (usually used to
model physical gate delays) you can control which pulse widths get
ignored (inertial delay), which get turned into an 'X' and which get
passed (transport delay). With this you can define that pulses less than
60% of the gates delay are ignore. Pulses less than 80% and greater than
or equal to 60% of the gates delay generate an 'X' and any pulse 80% of
the gates delay or greater will be passed. The default values for these
limits generate inertial delays equal to 100% of the gates delay.
Not quite as bad as Jonathan made it sound, but this is ignoring how
delays are actually defined in a specify block. Lets just say "Here be
Dragons" and I'm staying in the castle for now
.
If you are doing RTL design then you can safely ignore all this unless
you want to get fancy in your test code and even then my suggestion
would be ignore this unless you really need it. You can do many
wonderful things with the rest of Verilog if you are not constrained by
synthesis requirements.
Cary
Guest
Sat May 29, 2010 2:30 am
On May 24, 4:29 am, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:
Quote:
So far, so clear. Now things get a little more
difficult. As you say, there is a value change
on 'a'. Does that release the @*? I would argue
that it does not, because 'a' already has its new
value at the moment when execution reaches @*.
There is no further value change on 'a'.
Your argument would be correct.
Quote:
However, some simulators (I believe) compute
"value change" by looking at the value of a
variable before and after the execution of code
at a given point in time. Such a simulator might
now see that 'a' has changed since the beginning
of the time-slot, and therefore might choose to
release the @* for a second time. THIS DOES NOT
MATTER because your code describes proper
combinational logic and the second iteration,
if it occurs, will give exactly the same results
as before.
"value change" by looking at the value of a
variable before and after the execution of code
at a given point in time. Such a simulator might
now see that 'a' has changed since the beginning
of the time-slot, and therefore might choose to
release the @* for a second time. THIS DOES NOT
MATTER because your code describes proper
combinational logic and the second iteration,
if it occurs, will give exactly the same results
as before.
I am doubtful that there are any simulators that do this. If there
are, I would claim that they are not valid implementations of Verilog.
Depending on how I interpret your description, such a simulator might
be completely nonfunctional. Suppose that the simulator allowed an
event control to continue immediately, without blocking, if the event
expression had changed value earlier in the current time slice. Then
an always block with an event control would go into an infinite loop
and hang the simulation. It would wake up when the event it was
waiting for occurred. Then when it looped back to the event control
(assuming no other delaying statements in the block), it would find
that the event had occurred earlier in the current time slice, and
continue executing again. And again and again...
Perhaps you could find a way to adjust this mechanism so that it only
responded to a given event once. But it is much simpler to take the
LRM description at face value. It waits for the event. That means
the event must be one that occurs after it starts waiting.
So your earlier argument is correct. This speculation about
simulators that might do something else is probably just a red
herring.
Note that this is the distinction between the
wait(named_event.triggered) mechanism added in SystemVerilog and
@named_event. The "triggered" property (really more like a method)
does keep track of whether the named event was triggered earlier in
the current time slice. And if you wrote an always block whose only
delaying statement was that wait, it would go into an infinite loop as
soon as the event was triggered.
Jonathan Bromley
Guest
Guest
Sat May 29, 2010 1:36 pm
On Fri, 28 May 2010 17:00:30 -0700 (PDT), sharp_at_cadence.com wrote:
Quote:
However, some simulators (I believe) compute
"value change" by looking at the value of a
variable before and after the execution of code
at a given point in time.
[...]
I am doubtful that there are any simulators that do this. If there
are, I would claim that they are not valid implementations of Verilog.
"value change" by looking at the value of a
variable before and after the execution of code
at a given point in time.
[...]
I am doubtful that there are any simulators that do this. If there
are, I would claim that they are not valid implementations of Verilog.
Oh dear. Of course you're right. On re-reading that paragraph
it's clear I was mostly writing garbage and I'm not entirely
sure what I was thinking about.
I suspect that I was working hard to point out that any
propely-formed description of combinational logic must
work correctly even if it unnecessarily executes again
after computing the correct stable output values.
And I tried, unsuccessfully, to find some
justification for why that might happen in the
code the OP presented. Whoops.
Quote:
So your earlier argument is correct. This speculation about
simulators that might do something else is probably just a red
herring.
simulators that might do something else is probably just a red
herring.
Red and putrescent, yes.
Quote:
Note that this is the distinction between the
wait(named_event.triggered) mechanism added in SystemVerilog and
@named_event. The "triggered" property (really more like a method)
does keep track of whether the named event was triggered earlier in
the current time slice. And if you wrote an always block whose only
delaying statement was that wait, it would go into an infinite loop as
soon as the event was triggered.
wait(named_event.triggered) mechanism added in SystemVerilog and
@named_event. The "triggered" property (really more like a method)
does keep track of whether the named event was triggered earlier in
the current time slice. And if you wrote an always block whose only
delaying statement was that wait, it would go into an infinite loop as
soon as the event was triggered.
Indeed so. event.triggered is extremely useful for some
kinds of testbench synchronisation, but wouldn't make sense
in this context.
Thanks for putting the record straight (as usual!).
--
Jonathan Bromley
elektroda.net NewsGroups Forum Index - Verilog Language - Non-Blocking versus blocking
