🚀 go-pugleaf

smb@afterlife.ncsc.mil (Steve M. Burinsky) writes:

>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
>smb@afterlife.ncsc.mil

>-- 

>Steve M. Burinsky
>smb@afterlife.ncsc.mil

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
hughes@cs.uiuc.edu

------------------------------------------------
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;
    @(negedge q_empty);
    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 */
            @(negedge q_empty);    /* wait for insertion */
        end /* if */
    end /* while */
end /* initial */

always @(In) begin
    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

smb@afterlife.ncsc.mil (Steve M. Burinsky) writes:

>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.

smb@afterlife.ncsc.mil (Steve M. Burinsky) writes:

> 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
----------------------------------------------------------------------
Advanced Product Operations                 rajesh@chdasic.sps.mot.com
Motorola ASIC				     ----------------------------------------------------------------------

In article <1992Nov12.163116.17205@dsg.tandem.com> leung@DSG.Tandem.COM (Steven Leung) writes:
>
>	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
smb@afterlife.ncsc.mil

smb@afterlife.ncsc.mil (Steve M. Burinsky) writes:

|> In article <1992Nov12.163116.17205@dsg.tandem.com> leung@DSG.Tandem.COM (Steven Leung) 
>
|> >	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.

In article <1992Nov16.163807.15366@dsg.tandem.com>, leung@DSG.Tandem.COM (Steven Leung) writes:
> 
> 
> 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
    Zoran Microelectronics LTD,       E-mail: cindy@Zoran.HellNet.Org
    Advanced Technology Center
    Haifa 31204, Israel               Could be my employer doesn't agree.