always statemnt's order in same simulation time 
Author Message
 always statemnt's order in same simulation time

I have a question about sequence of "always" in same simulation time.

I made an experiment about "always" statement and I found out that
"always", which is connected to the same wire, events occur
continuously. Does this condition always hold?

For example,
Display the signal when all gate's inputs or outputs change.

module buf1( o1, i1 );
input i1;
output o1;

        buf     #10
                g1( o1, i1 );


                $display( "#%d %m.buf1 i1", $time );


                $display( "#%d %m.buf1 i1", $time );
endmodule

   a ______|\_______|\__
        |  |/g1 |   |/g2
        |       |
        |       |___|\___
        |           |/g3
        |
        |_|\________|\__
          |/g4  |   |/g5
                |
                |___|\___
                    |/g6

The experiment's result is like this...
(g1.o, g2.i, g3.i occur sequentially, but they occur out of order.
also g4.o, g5.i g6.i do the same. )

#        0 g1.i
#        0 g4.i
#       10 g2.i
#       10 g3.i
#       10 g1.o
#       10 g5.i
#       10 g6.i
#       10 g4.o

Does this sequence never occur?
#        0 g1.i
#        0 g4.i
#       10 g2.i
#       10 g3.i
#       10 g4.o
#       10 g1.o
#       10 g5.i
#       10 g6.i

By the way, is there any way to, after an output's transition, force
the state of inputs connected to that output to change?

-- takamura



Tue, 31 Dec 1996 16:25:11 GMT  
 always statemnt's order in same simulation time

| I have a question about sequence of "always" in same simulation time.
| I made an experiment about "always" statement and I found out that
| "always", which is connected to the same wire, events occur
| continuously. Does this condition always hold?

        There is no defined order between always blocks, other than
that they should each be called whenever their sensitivity expression
evaluates to a changed value.

        Two different always blocks that are keyed on the same
expression may be called in different orders.  This is what is called
a race.

--


`------' A VIEWlogic Company      For information, call 1-800-VERILOG



Wed, 01 Jan 1997 05:00:12 GMT  
 always statemnt's order in same simulation time

Quote:
>I have a question about sequence of "always" in same simulation time.

>I made an experiment about "always" statement and I found out that
>"always", which is connected to the same wire, events occur
>continuously. Does this condition always hold?

>For example,
>Display the signal when all gate's inputs or outputs change.

>module buf1( o1, i1 );
>input i1;
>output o1;
>        buf     #10
>                g1( o1, i1 );

>                $display( "#%d %m.buf1 i1", $time );

>                $display( "#%d %m.buf1 i1", $time );
>endmodule

>   a ______|\_______|\__
>    |  |/g1 |   |/g2
>    |       |
>    |       |___|\___
>    |           |/g3
>    |
>    |_|\________|\__
>      |/g4  |   |/g5
>            |
>            |___|\___
>                |/g6

>The experiment's result is like this...
>(g1.o, g2.i, g3.i occur sequentially, but they occur out of order.
>also g4.o, g5.i g6.i do the same. )

>#    0 g1.i
>#    0 g4.i
>#   10 g2.i
>#   10 g3.i
>#   10 g1.o
>#   10 g5.i
>#   10 g6.i
>#   10 g4.o

The Verilog Language does not formally specify the order in which events
should be evaluated in a given time step.  More importantly, no two
Verilog simulators will always evaluate events in the same order.  Buried
somewhere in the Cadence Verilog-XL reference manuals is a note that
Verilog-XL is also not even guarenteed to evaluate "simultaneous" events in
the same order every time a simulation is run.  It has been my experience,
however, that Verilog-XL is very consistent, and does the same thing
each time, *****as long as the design, stimulus, invocation options, etc.
do not change*****

The Cadence Verilog-XL product has a pecuiliar quirk that your model will
produce.  Verilog-XL uses two algorithms during simulation, the "XL"
algorithm for gates, and the "non-XL" for behavi{*filter*}statements.  During
simulation, one algorithm will process all simultaneous events in its
realm first, and then switch to the other algorithm (and then switch
back again if new events in the same time step are generated).  The
gate level XL algorithm can be turned on or off (using the -a option),
which in your model will quite likely change the event ordering.

The user is given very little control over the order of events in a
simulation time step.  This may not help in your example, but there are two
Verilog behavi{*filter*}constructs that do impact event ordering:

1. The non-blocking "RTL" assignment (i.e.:  a <= b; ) will cause the right
hand side expression to be evaluated when the statement is encountered,
but postpone changing the left hand side until the end of the time step.
Of course, if there are multiple non-blocking assignments, the order at
the end of the time step is beyond user control.

2. The #0 procedural delay (i.e.:  #0 a = b; ) will cause the evaluation
of the entire statement to be postponed until the end of the time step.
Again, multiple #0 delays put multiple statements at the end of a time
step without user control.

One final note:  The $monitor statement is specified to only print a
message at the end of a time step, when all events are completed,
so $monitor will not show the order of evaluation.  Using the

behavi{*filter*}event to be evaluated somewhere in the event queue.  (Try
changing one of your display statements to "#0 $display..." and note how
it changes the output order).  The only way to see the actual event order
that I'm aware of is to use the $settrace command, which is a non-OVI
standard command in Verilog-XL that may not exist in other simulators.

--
-- Stuart Sutherland                      Sutherland HDL Consulting  --

-- phone/fax: (303) 682-8864              Longmont, CO  80503        --
--                                                                   --
-- Publisher of Verilog HDL reference guides and training materials  --
-----------------------------------------------------------------------



Fri, 03 Jan 1997 17:39:39 GMT  
 always statemnt's order in same simulation time
Thank you for answering my questions by posting and E-mail.

Quote:

>  The Cadence Verilog-XL product has a pecuiliar quirk that your model will
>  produce.  Verilog-XL uses two algorithms during simulation, the "XL"
>  algorithm for gates, and the "non-XL" for behavi{*filter*}statements.  During
>  simulation, one algorithm will process all simultaneous events in its
>  realm first, and then switch to the other algorithm (and then switch
>  back again if new events in the same time step are generated).  The
>  gate level XL algorithm can be turned on or off (using the -a option),
>  which in your model will quite likely change the event ordering.

  I tried to run verilog both using -a option and not using it, but
there was no difference. We have also XL license, so we can use the
option -a.  Perhaps, since we have the license, this is a default
option, i.e., it is implicitly set to -a.
  How can I disable this option ?

Quote:
>  The user is given very little control over the order of events in a
>  simulation time step.  This may not help in your example, but there
>  are two Verilog behavi{*filter*}constructs that do impact event ordering:
>  :
>  :

  I understand that it is very difficult to control sequence of events
in a simulation time step. After all, we can change the order, but all
we can do is to postpone it until the end of the time step, right?

  To tell the truth, now I'm making a tool for asynchronous circuit
that shows the transitions which cause the next transition directly.
If orders were specified like what I thought, I don't have to add a
function to read a verilog-format file and get net-list of it...
  More work to do... :-(

Akihiro Takamura
Department of Computer Science, Tokyo Institute of Technology



Sat, 04 Jan 1997 20:53:28 GMT  
 always statemnt's order in same simulation time

Something I use alot ( and I am fairly sure it's not synthesizable ) is:

always
  begin

    do_something_here_first;
    second_order = first_order;
  end

always
  begin

    do_something_here_second;
  end

I use this alot in zero delay behavi{*filter*}models where I need to guarantee
an order but I don't want to put everything in one block ( usually because
I want to use implicit states ).

                                                John Williams



Sun, 05 Jan 1997 15:32:31 GMT  
 always statemnt's order in same simulation time

Quote:


>>I have a question about sequence of "always" in same simulation time.

You should NEVER write a model whose correctness depends on the order
of execution of always/initial blocks. In ANY HDL. You should merge these
blocks into a single block (since you know their order of execution, they can
be described as sequential statements).

Quote:
>2. The #0 procedural delay (i.e.:  #0 a = b; ) will cause the evaluation
>of the entire statement to be postponed until the end of the time step.
>Again, multiple #0 delays put multiple statements at the end of a time
>step without user control.

It's been a long time since I read the Verilog LRM, but does the
language actually *garantees* that a zero-delay will actually suspend
the execution of the block and schedule it in the next time cycle ? I
thought that Verilog could optimize away the '#0' statements... Unless
the simulation cycle description explicitely forbis such an
optimization (like VHDL's), optimizing zero-delays by removing them
should not change the behavior of the model (unless one relies on the
"delta cycles" introduced by these statements... again, bad style).

--
Janick Bergeron                  AnalySYS Inc.                  (613) 443-0428

Consultant                Embrun, ON, Canada, K0A 1W1
                        Synthesis  -  Verilog  -  VHDL



Sun, 05 Jan 1997 20:10:13 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Time scale precision Vs Simulation time

2. Static Timing Analysis vs Timing Simulation

3. Static Timing Analysis vs Timing Simulation

4. Always Blocks - Execution order

5. UDPs and simulation event ordering

6. 'Always On Top' for toplevel window

7. syntax in exec statemnt, please help

8. Is always really ALWAYS?

9. Searching an 'embedded' ordered collection

10. non-ordered 'switch' statement

11. CosmoPlayer download page 'out of order'?

12. Using 'or' to affect evaluation order

 

 
Powered by phpBB® Forum Software