understanding delay modes in Verilog (with NC/XL)...

[Lars Rzymianowicz]

Hi,

I came across a behavior of NC-Verilog/VerilogXL, and i don't know,
if it's a bug or a feature:

the problem:
- an assign models a tri-state driver
- the net driven has a transport/net delay
- a pullup is connected to the net
- if the toggle rate of the assign is faster than the net delay, the
values won't propagate onto the net; if it toggles slower, it does.

I thought, the net delay simply delays the signals, whether faster or not.

Here is a small testcase:

#######
module top;
parameter INPUT_DELAY = 6;
parameter NET_DELAY = 5;
wire #(NET_DELAY) pad;
reg do, en;

pullup (pad);
// a tri-state driver cell with enable
assign pad = (en == 1'b1) ? do : 1'bz;

initial begin
do = 0;
en = 0;
#10 en = 1;
end

always
#(INPUT_DELAY) do = ~do;

initial
begin
$monitor("%t: do:%b, en:%b, pad:%b.", $time, do, en, pad);
#100 $finish;
end

endmodule
#######

Simulating the above, you should see that the wire pad toggles, since the
NET_DELAY is less than the INPUT_DELAY. NOW set the INPUT_DELAY to 4,
and pad remains constant.

Would love to hear from Verilog experts:
- how do other simulators behave?
- is this specified in the LRM?

Any help appreciated.
Lars
--
Address: University of Mannheim; D7, 3-4; 68159 Mannheim, Germany
Tel: +(49) 621 181-2716, Fax: -2713
email: larsrzy@{ti.uni-mannheim.de, atoll-net.de, computer.org}
Homepage: http://mufasa.informatik.uni-mannheim.de/lsra/persons/lars/

[Parvathy Uma]

All delays in Verilog are inertial. Transport behavior is not
documented in the Verilog 2000 LRM and I think it is vendor specific.

The inertial delay model for wire delays is documented in section
6.1.3 of the 2000 LRM

It says that for a declaration of the type

wire #10 wireA;
//From the Verilog 2000 LRM

" In situations where a right-hand side operand changes before a
previous change has had time to propagate to the left-hand side, then
the following steps are taken:
a) The value of the right-hand side expression is evaluated

b) If this RHS value differs from the value currently scheduled to
propagate to the left-hand side, then the currently scheduled
propagation event is descheduled.

c) If the new RHS value equals the current left-hand side value, no
event is scheduled.

d) If the new RHS value differs from the current LHS value, a delay is
calculated in the standard way using the current value of the
left-hand side, the newly calculated value of the right-hand side, and
the delays indicated on the statement; a new propagation event is then
scheduled to occur delay time units in the future "

Hope this helps
-Uma

[Rick Filipkiewicz]

Parvathy Uma wrote:

In short inertial => pulses shorter than the wire/gate delay are
"swallowed".

[Lars Rzymianowicz]

Rick Filipkiewicz wrote:

>
> Parvathy Uma wrote:
> > b) If this RHS value differs from the value currently scheduled to
> > propagate to the left-hand side, then the currently scheduled
> > propagation event is descheduled.
>

> In short inertial => pulses shorter than the wire/gate delay are
> "swallowed".

Thanks for your answers. Now the question remains, how to model this?
A driver which toggles faster than the net delay is...

I browsed the NC docs, and there are a couple of command parameters
for ncelab like '-intermod_path', '-pulse', etc. They all modify the
delay modeling of the simulator, but are normally intended for SDF
backannotation, as i understand. But the docs are not very clear about
their purpose.
Any NC experts around here?

[Parvathy Uma]

The Verilog-XL reference (XL is the tool in which the transport
behavior was implemented first) has a good (I think) explanation for
all the transport modes that XL and NC support. Verilog-XL also supports
a mode called accu_path and this is not supported in NC. Other than that,
the
Verilog-XL reference documents are good for NC as well.

Spellings of the options may not be correct , so please check the
reference
The options are +transport_int_delays are +multisrc_int_delays .
They both translate to the same option on NC. These work only for the
interconnect delays which are back annotated by SDF. As far as I remember
they don't work on wire/net delays.

There is +transport_path_delays which models the paths in the specify
block
with transport behavior.

The pulse* options are to control how big a pulse has to be to pass
through. The default is 100% of the delay but you can specify less than
that. There are
two sets, pulse_e/pulse_r that affects specify path delays and
pulse_int_e and pulse_int_r that affect interconnect delays. AFAIK neither
of these work on wire delays.

If you had a specify block to model your delays you could use
+transport_path_delays . Or, you could use the +pulse_e and +pulse_r
options to specify how big a pulse is acceptable.

Finally there is a +showcancelled_e for debug purposes which tells you
what events got cancelled because of scheduling dilemmas.

Hope this helps
Uma

[Jonathan Bromley]

In article <3BB17D91...@ti.uni-mannheim.de>, Lars Rzymianowicz
<lar...@ti.uni-mannheim.de> writes

>Rick Filipkiewicz wrote:
>>
>> Parvathy Uma wrote:
>> > b) If this RHS value differs from the value currently scheduled to
>> > propagate to the left-hand side, then the currently scheduled
>> > propagation event is descheduled.
>>
>> In short inertial => pulses shorter than the wire/gate delay are
>> "swallowed".
>
>
>Thanks for your answers. Now the question remains, how to model this?
>A driver which toggles faster than the net delay is...
>

Not exactly an answer, but... Nonblocking assignments with intra-
assignment delays can give you a transport delay effect. So if you
wanted to get a transport delay on signal S:

(VHDL)
S_delayed <= transport S after T; -- it's so easy in VHDL :-)

(Verilog)

wire S_delayed; // NB no delay on this net
reg SD;
time T;

always @(S)
SD <= #T S; // gives the required transport delay

assign S_delayed = SD; // and this puts it on to a net for you

AFAIK there is nothing simulator-dependent about this. Module,
continuous-assignment and net delays are all inertial. Nonblocking
assignments go on to the event queue without affecting other
assignments already scheduled, and therefore give transport delay.
It certainly works OK in ModelSim; haven't tried others just yet.

Someone will no doubt find the line in the LRM that proves me wrong...

HTH
--
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223 Email: jonathan...@doulos.com
Fax: +44 1425 471573 Web: http://www.doulos.com

**********************************
** Developing design know-how **
**********************************

This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.