HELP!
        I need to schedule an IF statement to take place at a fixed delay after a signal change.  The obvious solution seems to be:

        #max_prop_delay
        if ($time >= din_lastchange + max_prop_delay)
                dout = dina + dinb;

        This doesn't work.  It seems that the entire ALWAYS statement waits to complete until after the IF statement has executed.  Thus, if dina changes again before the delay has completed, no further IF statements can be executed.
        I tried to get around this using fork-join, conditional operators, and intra-assignment delays.  None could achieve the desired effect.
        How do I delay an IF statement while keeping the ALWAYS statement active?

:       HELP!
:       I need to schedule an IF statement to take place at a fixed delay
: after a signal change.  The obvious solution seems to be:

:       #max_prop_delay
:       if ($time >= din_lastchange + max_prop_delay)
:               dout = dina + dinb;

:       This doesn't work.  It seems that the entire ALWAYS statement waits
: to complete until after the IF statement has executed.  Thus, if dina
: changes again before the delay has completed, no further IF statements
: can be executed.
:       I tried to get around this using fork-join, conditional operators,
: and intra-assignment delays.  None could achieve the desired effect.
:       How do I delay an IF statement while keeping the ALWAYS statement active?

I am not exactly sure what you are trying to do here, since this code
fragment is not complete, but there are a couple of things that may do
what you want.

First, if you are only trying to model an adder with delay, then a delayed
assign statement would do it. OUTSIDE all initial and always blocks
use
assign #max_prop_delay dout= dina + dinb;

With this, if dina (or dinb) change multiple times within max_prop_delay,
dout will only change after the last change of dina and dinb.

If you really want to have a module that triggers after the last change
of a signal then it is a bit more complicated.

--
event dina_change;

begin
        disable dina_change_block;
        #0 -> dina_change;
end

begin: dina_change_block;
        #max_prop_delay
        if ...
end
--

Thus on every change of dina, the block named dina_change_block, which
may or may not be waiting in the # at the top is disabled, and the
event triggering it is sent right away, causing the block to start
again, and hence start the #max_prop_delay again.

Hope this helps.

--

Avrum Warshawsky

Hewlett-Packard (Canada) LTD.

Avrum's named-event and timer is the only way I've found to
model phenomena like memory access time.
(Memories hold for a time after address changes, then go
unknown for the rest of the access time, then go valid.
Another address change resets the access time timer.)
It seems overly complex for an otherwise consise language.
Isn't there a simpler way?

Cameron

   Path: cds8604!uunet!noc.near.net!MathWorks.Com!panix!zip.eecs.umich.edu!newsxfer.itd.umich.edu!gumby!yale!yale.edu!not-for-mail

   Newsgroups: comp.lang.verilog
   Date: 18 Apr 1994 14:25:54 -0400
   Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158
   Lines: 12
   Distribution: world
   NNTP-Posting-Host: lion.zoo.cs.yale.edu

I had a similar problem in trying to design a voltage controlled oscillator.
Here are some snippets from that model that explain how to solve the problem.

    event frequency_change;

        /* This block watches for changes on wire_vin.  If it finds one, it   *
         * stops any frequency change calculation going on now.  It then sets *
         * an event signifying a new frequency change is needed.  It then goes*
         * back to watch for more changes.  This block should not actually do *
         * the frequency change because if it took the time to do it, it      *
         * wouldn't be able to watch for more changes.                        */
        disable frequency_change_block;
        /* The #0 insures that the disable has taken affect before posting the*
         * frequency_change event                                             */
        #0 -> frequency_change;
    end

        /* This block can actually do the frequency change which might take as*
         * much as half a period to accomplish.  It doesn't have to worry     *
         * about a change on the voltage control while it is busy.  Its pal up*
         * above is watching for that kind of change and will tell this guy to*
         * cancel its activity if that happens.                               */
        handle_frequency_change;
    end

/Steve
--
------------------------------------------------------------------------------
Steve Greenberg                         Phone: (508) 446-6231
Cadence Design Systems, Inc.            FAX:   (508) 446-6636

Chelmsford, MA 01824
Disclaimer: The standard disclaimer applies

The short answer is:

No.

The long answer is:

This example scratches the surface of what I consider to be fundamental
limitation of Verilog. In Verilog, all processes are global and physical.
This means you can't start a process again ( in this case, dina_change_block )
until it has either finished or has been disabled ( There are some exceptions
to this, but in general, other approaches are unpredictable and are not very
robust ). Until Verilog supports local and virtual processes, you're stuck.

While I allude to something greater, for this particular instance I believe
that disabling the block is an efficient way of accomplishing what you want.

I do have an idea for an alternative way:

always
fork
  begin

    disable dina_block;
  end
  begin: dina_block
    // This block is allowed to complete execution after the last transition
    // of dina.
    #max_prop_delay;
    if ...
  end
join

This is untested, but makes sense to me. If it works, it will save you
an event and an always block, -plus- the initial block not shown to initialize
the output.

                                        John Williams

|> >event dina_change;
|> >

|> >begin
|> >      disable dina_change_block;
|> >      #0 -> dina_change;
|> >end
|> >

|> >begin: dina_change_block;
|> >      #max_prop_delay
|> >      if ...
|> >end
|>
|>
|> Avrum's named-event and timer is the only way I've found to
|> model phenomena like memory access time.
|> (Memories hold for a time after address changes, then go
|> unknown for the rest of the access time, then go valid.
|> Another address change resets the access time timer.)
|> It seems overly complex for an otherwise consise language.
|> Isn't there a simpler way?

How about use the transport delay:

Similary, in the memory access case:

        m_out <= #data_invalid 'bx;
        m_out <= #data_valid mem[adr];
   end

Steven
--
"Life is a series of problems. ... Yet it is in this whole process of
meeting and solving problems that life has its meaning."
                       From "The Road Less Traveled" by M. Scott Peck

This might work with specific models and / or specific implementations
of Verilog. I believe you have to be careful about what you use to drive
this model. If you have more than one event during a time slot, the resultant
ordering, I believe, is not defined. Depending on the queue discipline being
used in the event list, you could have events pass each other in zero time.

I've heard lots of stories about non blocking assigns being broken, and I
think this is the mechanism by which they break. Personally, I avoid non
blocking assigns anyways. To me, its a kluge.

                                                John Williams

They actually seem to be buggy in the latest version of Cadence Verilog,
but I've been using them for three years in Chronologic and have never
had a problem with them.

--
Michael Lodman  Department of Electrical and Computer Engineering
               University of California, San Diego

        "It is better to be infamous than unknown" - Kerstin