Avoiding inertial delay in delay lines 
Author Message
 Avoiding inertial delay in delay lines

I need to simulate delay lines in order to model a bus interface.  The
solution seems obvious --  use a net delay.  However, the signal I need
to delay has pulse widths (w) which are shorter than the delay time (d);
that is w < d.  The problem is that inertial delay causes the short pulse
to disappear within the delay.

So, how should this be implemented?  I have two options, neither of which
I like:
1.  Implement the delay line as a string of (for example) 10 buffers, each
with 10% of the total required delay.  This has drawbacks, as it requires
that the user know the number of internal sub-delay units in order to
guarantee acurate delay generation.  Also, (given that 10 buffers are used)
10w > d is required.
2.  Implement a PLI routine which calls (for example) tf_strdelputp, which
allows me to specify transport (versus inertial) delay.

Is there anyway I can choose transport delay using a standard language
construct?  Is there another (easy, portable, general) way of implementing
delay lines I'm missing?

Thanks,
Steve Burinsky

--

Steve M. Burinsky



Mon, 01 May 1995 13:33:06 GMT  
 Avoiding inertial delay in delay lines

Quote:
>I need to simulate delay lines in order to model a bus interface.  The
>solution seems obvious --  use a net delay.  However, the signal I need
>to delay has pulse widths (w) which are shorter than the delay time (d);
>that is w < d.  The problem is that inertial delay causes the short pulse
>to disappear within the delay.
>So, how should this be implemented?  I have two options, neither of which
>I like:
>1.  Implement the delay line as a string of (for example) 10 buffers, each
>with 10% of the total required delay.  This has drawbacks, as it requires
>that the user know the number of internal sub-delay units in order to
>guarantee acurate delay generation.  Also, (given that 10 buffers are used)
>10w > d is required.
>2.  Implement a PLI routine which calls (for example) tf_strdelputp, which
>allows me to specify transport (versus inertial) delay.
>Is there anyway I can choose transport delay using a standard language
>construct?  Is there another (easy, portable, general) way of implementing
>delay lines I'm missing?
>Thanks,
>Steve Burinsky

>--
>Steve M. Burinsky


I bumped into this problem a long time ago.  I found that the most flexible
way to solve the problem was to write a module for the delay line.  The model
is truly event-driven, which keeps it from slowing down the simulation too
much.  I've included it below.

Good luck,  Eric Hughes
451 Loomis Lab   1110 W. Green St.   Urbana, IL  61801  USA

------------------------------------------------
module trans_delay(In, Out);

parameter qlen = 60;               /* number of transitions to be queued */
parameter delay_time = 960;        /* delay time of pipe */

input   In;                        /* input signal */
output  Out;                       /* output signal */
reg     Out;

reg     [32:1] times [1:qlen];     /* queue of transition times */
reg     [1:qlen] values;           /* queue of transition values */
integer read_addr;                 /* addresses to read */
integer write_addr;                /*  and write */
reg     q_full;                    /* remember if queue is full */
reg     q_empty;                   /* remember if queue is empty */

initial begin
    read_addr = 1;
    write_addr = 1;
    q_full = 0;
    q_empty = 1;

    while (1) begin                /* drive the output */
        #(times[read_addr] - $stime);
        Out = values[read_addr];
        q_full = 0;
        read_addr = read_addr % qlen + 1;
        if (read_addr == write_addr) begin
            q_empty = 1;           /* queue is empty */

        end /* if */
    end /* while */
end /* initial */


    if(q_full) $display("Transport queue is full -- make it bigger");
    else begin
        times[write_addr] = $stime + delay_time;
        values[write_addr] = In;
        write_addr = write_addr % qlen + 1;
        if (read_addr == write_addr) q_full = 1;
        q_empty = 0;
    end /* else */
end /* always */

endmodule



Mon, 01 May 1995 22:26:15 GMT  
 Avoiding inertial delay in delay lines


Quote:
>I need to simulate delay lines in order to model a bus interface.  The
>solution seems obvious --  use a net delay.  However, the signal I need
>to delay has pulse widths (w) which are shorter than the delay time (d);
>that is w < d.  The problem is that inertial delay causes the short pulse
>to disappear within the delay. ...

I think Verilog's stated delay model is inertia, but I found out from my
experiments (with 1.6a) that the non_blocking assignment _plus_ delay
control after the assignment operator has the same effect of transport delay.
Since I don't know whether either Cadence or OVI has formally stated support
for transport delay model, so I don't know whether this is a (happy) coincident
or there may be some limitations I didn't know or they may change in the
future version or it may not work with another Verilog simulator or ... But
you can try this:

        a <= #10 b;  /* transport delay */

Steven
--
328. Seek opportunity, not security. ...
        - Life's Little Instruction Book by H. J. Brown, Jr.



Tue, 02 May 1995 00:31:16 GMT  
 Avoiding inertial delay in delay lines

Quote:
> I need to simulate delay lines in order to model a bus interface.  The
> solution seems obvious --  use a net delay.  However, the signal I need
> to delay has pulse widths (w) which are shorter than the delay time (d);
> that is w < d.  The problem is that inertial delay causes the short pulse
> to disappear within the delay.

If you do not expect to have more than a single pulse (2 edges) every delay time
d units, then you could use the pulse rejection ratio command line switches
to Verilog. I do not have a manual in front of me now to give you the details,
but it is something like +pulse_r. This will however, change the pulse swallowing
ratio for all delays in the design. If you want control on one specific delay,
then look into using the specparam based control on pin-to-pin delays. The section
on specify blocks in the manual talks about this.
But the problem we ran into was we needed to run multiple pulses into the
delay line such that n*w < d, where n was the number of pulses. So we should
have seen all the n pulses come out of the delay line after a delay of d.
The switches mentioned above will let you control the width of a pulse that
will get thru but not the number of pulses. Verilog-Xl will only let you
schedule at the most 2 events (I believe) on any node. Each new event after the
second one will cause an earlier scheduled event to get overwritten/dropped.
As a result Verilog will show you only the last pulse in the pulse train
come out of the delay line. For this problem, I believe there is no solution
other than using a string of elements to build the delay line.

---
Rajesh Patil
----------------------------------------------------------------------

Motorola ASIC                                ----------------------------------------------------------------------



Wed, 03 May 1995 02:28:38 GMT  
 Avoiding inertial delay in delay lines

Quote:

>    a <= #10 b;  /* transport delay */

I cannot see why a non-blocking assignment should operate any differently
than a blocking assignment in terms of how events are scheduled.  Thus,
I expected that the above would not work.  However, it does, as does

        #10 a <= b;

I cannot see why this should work.  Anyone have an explanation?
--

Steve M. Burinsky



Fri, 05 May 1995 12:52:05 GMT  
 Avoiding inertial delay in delay lines



|> >      a <= #10 b;  /* transport delay */
|> >
|>
|> I cannot see why a non-blocking assignment should operate any differently
|> than a blocking assignment in terms of how events are scheduled.  Thus,
|> I expected that the above would not work.  However, it does, as does
|>
|>   #10 a <= b;

Are you sure? I check my experiments again and pretty sure that putting
the delay in front of the assignment statement will not make the delay
become transport. It behaves exactly the same as #10 a = b;.

BTW, putting the delay after the assignment operator appears to have
some effects on scheduling. Even "a = #10 b;" has some difference from
"#10 a = b;". (Don't know whether this is considered as a bug though.)

Steven
--
328. Seek opportunity, not security. ...
        - Life's Little Instruction Book by H. J. Brown, Jr.



Sat, 06 May 1995 00:38:07 GMT  
 Avoiding inertial delay in delay lines

Quote:

> BTW, putting the delay after the assignment operator appears to have
> some effects on scheduling. Even "a = #10 b;" has some difference from
> "#10 a = b;". (Don't know whether this is considered as a bug though.)

look in the manual.  "a = #10 b;" means sample b NOW, and assign its value to
a in 10 time units.  on the other hand, "#10 a = b;" means wait 10 time units
starting from now, and then sample b and immediately assign the sampled value
to a.  

parts of this discussion seem to have passed my news feed by, but from what
i gather, using "a <= #10 b;" (non-blocking) should work for the original
poster, since it will schedule the current value of b to be assigned in another
10 time units.  in the meantime, if b changes, before the 10 time units is up,
say at time 3, verilog will be free the execute the assignment again, and
schedule another assignment at time 3+10=13.  

notice:  1.  you must use a non-blocking assignment, with the delay after
             the equals

         2.  you must make sure that the current always statement does not
             contain (other) blocking assignments which will mess up the
             scheduling of this assignment.  

hope this helps.

cindy.

--

    Cindy Eisner,                     Tel: 972-4-551551
    CAD group,                        Fax: 972-4-551550

    Advanced Technology Center
    Haifa 31204, Israel               Could be my employer doesn't agree.



Sun, 07 May 1995 14:16:17 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Transport Delay and Inertial Delay

2. Transport Delay Vs Inertial Delay

3. Inertial and transport delay in Verilog

4. This week's Coding tip: modeling combinational logic with inertial delays

5. The inertial delay model

6. Inertial Delay in Aldec 4.2?

7. Inertial and transport delay in Verilog

8. This week's Coding tip: modeling combinational logic with inertial delays

9. Transport vs. Inertial....ooops (DELAY item)

10. Transport/Inertial DElay's

11. inertial vs. transport delay

12. Delays, verilog ignores my delays?

 

 
Powered by phpBB® Forum Software