$monitor and IEEE Std 1364 
Author Message
 $monitor and IEEE Std 1364

Hi all,

        In section 5 of the IEEE document, near the end of 5.3, it says:

"The $monitor and $strobe system tasks create monitor events ... monitor
events are unique in that they cannot create any ofther events."

Further down, there is an algorithm given for the processing of all events.
After trying to implement this, it doesn't look right.  My understand
of $monitor and $strobe is that $monitor produces outputs for any change
in the arguments.  But $strobe only produces outputs once.  Thus, can
both $monitor and $strobe system tasks generate the same events?  The
algorithm seems to only work for $strobe.  It will not produce the type
of output that $monitor requires.  Am I reading the document wrong, or
is the description wrong?

In another issue, can $monitor events be queued?  If the purpose of $monitor
is to produce output for any changes in the arguments, then won't queuing
cause some events to be lost?

--jc
--



Wed, 14 Jun 2000 03:00:00 GMT  
 $monitor and IEEE Std 1364

Quote:

>         In section 5 of the IEEE document, near the end of 5.3, it says:

> "The $monitor and $strobe system tasks create monitor events ... monitor
> events are unique in that they cannot create any ofther events."

> Further down, there is an algorithm given for the processing of all events.
> After trying to implement this, it doesn't look right.  My understand
> of $monitor and $strobe is that $monitor produces outputs for any change
> in the arguments.  But $strobe only produces outputs once.  Thus, can
> both $monitor and $strobe system tasks generate the same events?  The
> algorithm seems to only work for $strobe.  It will not produce the type
> of output that $monitor requires.  Am I reading the document wrong, or
> is the description wrong?

> In another issue, can $monitor events be queued?  If the purpose of $monitor
> is to produce output for any changes in the arguments, then won't queuing
> cause some events to be lost?


My understanding is that the IEEE std 1364 is intended to be the
standard of
the Verilog HDL, its main purpose is to serve as the reference should
ambiguity
arises.  Since various techniques, heuristics and algorithms are being
used to improve the performance of digital simulators, it is very hard
for
the standard committee to dictate "standard algorithms" for the HDL.
Any
algortihms, if any, documented in the standard should be interpreted as
conceptual, and it is the resposiblity of the simulator designers to
work
out his/her own algorithms.

BTW, I revisit the algorithm and did not see anything wrong with it.  

For many of the details you are requesting information on, they are all
knowledge specific to Verilog simulators.  I am not sure if you can get
the answers you need for implementing a Verilog XL compatible simulator.
You may need to figure that out youselves.

tan
surefire verification



Fri, 16 Jun 2000 03:00:00 GMT  
 $monitor and IEEE Std 1364

Quote:

> Hi all,

>    In section 5 of the IEEE document, near the end of 5.3, it says:

> "The $monitor and $strobe system tasks create monitor events ... monitor
> events are unique in that they cannot create any ofther events."

> Further down, there is an algorithm given for the processing of all events.
> After trying to implement this, it doesn't look right.  My understand
> of $monitor and $strobe is that $monitor produces outputs for any change
> in the arguments.  But $strobe only produces outputs once.  Thus, can
> both $monitor and $strobe system tasks generate the same events?  The
> algorithm seems to only work for $strobe.  It will not produce the type
> of output that $monitor requires.  Am I reading the document wrong, or
> is the description wrong?

        $monitor & $strobe both are executed at the end of the time
step, just before advancing time to the next time step, as correctly
described in 1364.

        $strobe is really a version of $display, one which can be
scheduled at any time, but is executed at the end of the time step,
with the values of the arguments as they are at the end of the time
step, after everything has settled.  It is intended to eliminate the
race which would result below if $strobe was a $display:


                $strobe($time,"a is %b, b is %b",a,b);

                b = f(a);

        $strobe is also very useful for extracting vectors for a wafer
tester, or architectural or cycle based simulator:


                $strobe($time,,pin0,pin1,pin2,pin3,pin4,pin5,pin6);

        $monitor is automatically continuously enabled. Like $strobe,
$monitor is executed at the end of those time step, but only in those
which the value displayed of one or more of the arguments is different
than the previous execution of that $monitor statement.

        This "only print if there is a change" does not apply to
anything that is related to $time or $stime (which will always be
different). That is to say, $monitor($stime); will not trigger every
time step.

        The $monitor tracks changes in the displayed value; hence
$monitor("4 state value of net is %b",net);

will not be executed if net changes from St1 to Pu1, however will be
executed if the $monitor was:

$monitor("128 state value of net is %v",net);

        If there wasn't this last bit about strength, or the feature
that $monitor ignores "spikes", you could emulate
$monitor($time,"a %b b %v c %d",a,b,c)
with $strobe as follows:


                $strobe($time,"a %b b %v c %d",a,b,c);

References: IEEE 1364, section 14.1.2, page 179-180

Quote:
> In another issue, can $monitor events be queued?  If the purpose of $monitor
> is to produce output for any changes in the arguments, then won't queuing
> cause some events to be lost?

        It really isn't queued; basically, at the end of every time
step, check to see if the "resolved" value of the $monitor statement
is different than the last time you ran $monitor. If an argument
changes from 1 to 0, but gets back to 1 during the time step, $monitor
ignores it.

Quote:

> --jc
> --


--

   /\//    SureFire Verification Inc.
  /\///\   <http://www.surefirev.com>
 _\///\/        Formerly Silicon Sorcery
  \//\/    Get my verilog emacs mode from
    \/     <http://www.surefirev.com/verilog-mode.html>


Fri, 16 Jun 2000 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. IEEE 1364 Verilog PLI-TSC Request for Enhancements, Errata

2. Verilog 2001 (1364-2001 IEEE Standard) Question

3. Gate level primitives in IEEE 1364 Verilog standard...

4. Q: Coding style in violation of IEEE-1364?

5. IEEE-1364

6. delay_or_event_control construct in IEEE 1364 Verilog

7. IEEE 1364 parser test suite?

8. IEEE 1364 and Verilog-A Courses in Feb in Silicon Valley

9. Verilog is now IEEE 1364 standard

10. The differences of IEEE 1364-1995

11. Where can I find IEEE Par-1364?

12. IEEE 1364 Working Group Minutes

 

 
Powered by phpBB® Forum Software