Delay in synthesizable VHDL.

Eric Venditti

unread,

Jun 17, 1998, 3:00:00 AM6/17/98

to

Hi Everybody,

I would like to have your advise on the use of after statement in RTL
description, to modelize for example output delay of Flip Flop, or
latency through a latch.

In my idea we never need to use this kind of thing for synchronous
design and I never had this need for the moment.

an example will be:

process (clk)

begin

if (clk'event AND clk = '1') THEN

A_q <= A_d after 1 ns ;

end if;

end process ;

Thanks in advance for your advice.

Best regards,
Eric.

Paul J. Menchini

unread,

Jun 17, 1998, 3:00:00 AM6/17/98

to

Eric Venditti (even...@tif.ti.com) wrote:
: Hi Everybody,

: I would like to have your advise on the use of after statement in RTL
: description, to modelize for example output delay of Flip Flop, or
: latency through a latch.

: In my idea we never need to use this kind of thing for synchronous
: design and I never had this need for the moment.

: an example will be:

: process (clk)
: begin
: if (clk'event AND clk = '1') THEN
: A_q <= A_d after 1 ns ;
: end if;
: end process ;

No synthesis tool of which I am aware will utilize any time
specification embedded in the model. It will either ignore them, or
perhaps issue a warning. (I consider it ill-behavior to reject the
model outright....)

Paul

Robert H. Klenke

unread,

Jun 17, 1998, 3:00:00 AM6/17/98

to

The current version of the IEEE Draft RTL Synthesis standard
(IEEEP1076.6/D1.12) says that AFTER clauses are ignored. Therefore, a
tool will be non-compliant if it issues an error when it encounters an
AFTER clause.

Most tools I have used (Autologic, Exemplar, Cascade, Actel)
simply issue warnings that the AFTER clauses are being ignored.

Bob
--
-------------------------------------------------------------------------
Bob Klenke, Ph.D., Principal Scientist Dept. of Electrical Engineering
University of Virginia
http://csis.ee.virginia.edu/~rhk2j Charlottesville, VA 22903-2442
-------------------------------------------------------------------------

Eric Venditti

unread,

Jun 17, 1998, 3:00:00 AM6/17/98

to

Paul,

Thanks for your quick answer. I agree with you but the purpose of adding
some delay in your RTL vhdl is (or seems to be) to have a behavior of
your RTL closer to the the one you will have with your gate level
netlist.

What do you think about this point.

Regards,
Eric.

Robert H. Klenke

unread,

Jun 17, 1998, 3:00:00 AM6/17/98

to

Eric,

Sorry, I know you asked Paul, but I though I'd give you my
answer too...

I usually do put delays into the synthesizable VHDL that I
write. The reason being that the VHDL simulator I use (QuickVHDL ne.
ModelTech) does not display VHDL delta cycles in the waveform display
window. Therefore, if you have an RTL level synthesizable VHDL
description, when a clock edge comes along, everything APPEARS to
happen at once in the waveform window. Of course VHDL orders the
events using delta cycles, so the simulation is correct, but the
waveform window doesn't show it. Therefore, if I put AFTER clauses into
every signal assignment statement (usually AFTER some "generic" value
that I can change easily through a package or an actual VHDL generic on the
top-level entity) it spaces the events out in time so I can easily see
the order in a waveform display.

In addition, when using the Mentor tool QhPro that allows you to
simulate VHDL with designs done in their generic logic simulator,
QuickSim II, I have had situations where a VHDL design without delays
did not simulate correctly with the logic design, but after adding
delays, it did simulate correctly. This was caused by the fact that
the QuickSIM II simulator does not use delta cycles and the events in
the VHDL simulation were handled in an incorrect order by the QuickSim
simulator.

The bottom line is, adding the delays to the behavioral VHDL
before synthesis doesn't hurt and can have some significant benefits -
go ahead and put them in.

Paul J. Menchini

unread,

Jun 17, 1998, 3:00:00 AM6/17/98

to

Eric Venditti (even...@tif.ti.com) wrote:
: Paul,

: Thanks for your quick answer. I agree with you but the purpose of adding
: some delay in your RTL vhdl is (or seems to be) to have a behavior of
: your RTL closer to the the one you will have with your gate level
: netlist.

Well, if your purpose is to make the RTL *simulation* match in timing
(as well as functionality) with the synthesized results, then of course
adding after clauses is the right approach.

I was under the impression that you were talking about a synthesis
model....

Regards,

Eric Venditti

unread,

Jun 18, 1998, 3:00:00 AM6/18/98

to

Hi,

It seems, when you look to the different answers that my question has
not been well understand.
The question is for simulation of synthesizable model purpose only (not
for synthesis), do you use and recommend some "after statement" ?
If NO why and what is your personnal experience with that ?

if Yes why, where and what is your personnal experience with that ?
If you put one do you need to put "after" statement everywere in your
design ?

Thanks for everybody's answer.

Regards,
Eric.

PS : This question follow a discussion I had with some others designers,
and I would like to have as many answer as I can get.

Subbu Meiyappan

unread,

Jun 18, 1998, 3:00:00 AM6/18/98

to

Paul J. Menchini wrote:

> Eric Venditti (even...@tif.ti.com) wrote:
> : Paul,
>
> : Thanks for your quick answer. I agree with you but the purpose of adding
> : some delay in your RTL vhdl is (or seems to be) to have a behavior of
> : your RTL closer to the the one you will have with your gate level
> : netlist.
>
> Well, if your purpose is to make the RTL *simulation* match in timing
> (as well as functionality) with the synthesized results, then of course
> adding after clauses is the right approach.
>

Yeah, but how accurate of a match are u going to get?For example the
Clock->Out delays can be modelled
accurately as u know fo sure that the synthesizer will
create flops. Au contraire, for the combinational logic paths
one cannot anticipate how many levels of logic the synthesizer
will create and hence won't be able to model very accurately.
For behavioral models, used only for test purposes, it is cool
to use those delays.

And avoiding delays in RTL will reinforce the use of synchronous
designs. I almost never had to use such delays and the sims run fine
even when I back-annotate.

Rich Hatcher

unread,

Jun 24, 1998, 3:00:00 AM6/24/98

to

Even in a pure VHDL simulator (not a cosimulation like QHPRO)
if you have multiple clocks going through zero-delay buffers,
it's possible to get flip-flops out of sync due to delta delays.
This can cause malfunctions in simulation that will not be present
in the synthesized logic. Inserting small delays in the flip-flop
outputs usually eliminates these simulation failures. I've
seen this phenomenon called "flash-through." It's a little
like a race condition in asynchronous logic.

This has shown up and caused confusion in a couple of cases
we have seen. Some of the coding guidelines include inserting
these small delays in flip-flop outputs.

Rich Hatcher

Wolfgang Ecker

unread,

Jun 25, 1998, 3:00:00 AM6/25/98

to

Paul J. Menchini wrote:

> Eric Venditti (even...@tif.ti.com) wrote:
> : Hi Everybody,
>
> : I would like to have your advise on the use of after statement in RTL
> : description, to modelize for example output delay of Flip Flop, or
> : latency through a latch.
>
> : In my idea we never need to use this kind of thing for synchronous
> : design and I never had this need for the moment.
>
> : an example will be:
>
> : process (clk)
> : begin
> : if (clk'event AND clk = '1') THEN
> : A_q <= A_d after 1 ns ;
> : end if;
> : end process ;
>
> No synthesis tool of which I am aware will utilize any time
> specification embedded in the model. It will either ignore them, or
> perhaps issue a warning. (I consider it ill-behavior to reject the
> model outright....)
>

I think your are talking about RT-synthesis tools. Some High-Levels
synthesis
tools use transport after for delay specification in pipelined loops. E.g.

in a simplified way:

loop
wait until clk = '1'; -- sample every 2 clock cycles
wait until clk = '1';

result <= transport f( ... ) after 3 * tclock ; -- computation time
= 3 cycles;

end loop;

This coding style is quite dangerous if the result signal is direcly used
by another clocked
process (it arrives at delta 0 of an simulaiton cycle). You must use then
"after 3 * tclock + 1 fs".

Have fun

Wolfgang