Flip-flop delay in VHDL

[Marty]

Hi c.l.vhdl,

I've always coded my flip-flops in Verilog with a bit of delay for
simulation purposes. This is done when you infer your regs and is ignored
in synthesis. For example:

always @(posedge clk or negedge resetb)
if (!resetb)
flop_q <= 1'b0;
else
flop_q <= #1 1'b1;

I can achieve the same thing in VHDL as follows:

process (clk, resetb)
begin
if (resetb = '0') then
flop_q <= '0';
elsif clk'event and clk = '1' then
flop_q <= '1' after 1 ns;
end if;
end process;

Is that the correct way to achieve the same thing that I'm doing in Verilog
with the #1 delay?

Just curious...
--
Marty

 

[Mike Treseler]

Marty wrote:

process (clk, resetb)
begin
if (resetb = '0') then
flop_q <= '0';
elsif clk'event and clk = '1' then
flop_q <= '1' after 1 ns;
end if;
end process;

Is that the correct way to achieve the same thing that I'm doing in Verilog
with the #1 delay?

The AFTER clause is ignored for synthesis.
A "delta" delay is implied by the signal assignment alone.

-- Mike Treseler

 

[Marty]

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:xJydnYWKmZH6wQTcRVn-sA@comcast.com...

Marty wrote:

process (clk, resetb)
begin
if (resetb = '0') then
flop_q <= '0';
elsif clk'event and clk = '1' then
flop_q <= '1' after 1 ns;
end if;
end process;

Is that the correct way to achieve the same thing that I'm doing in
Verilog
with the #1 delay?

The AFTER clause is ignored for synthesis.
A "delta" delay is implied by the signal assignment alone.

Ah yes, the delta delay makes it all work in simulation. However, the thing
about delta delays is that you don't see those in the waveform during
simulation and I don't like when everything lines up because I'm not used to
seeing that way. Maybe I need to get used to that.

Thanks Mike.
--
Marty

 

[mike_treseler]

Yes. Clock and Q looked lined up
in the functional sim waveforms
while there is really a finite
clock to Q delay.

Yes. Consider getting used to it
rather than adding AFTER clauses
to the source code. A static
timing analysis after place and
route will check all these delays for
you at every node.

If you want to see the real delays,
(and have some time to kill)
run a post-route gate level sim.

-- Mike Treseler

 

[Jonathan Bromley]

"Marty" <whatever@alo.com> wrote in message news:<10pikkmkj3p4c33@corp.supernews.com>...

Hi c.l.vhdl,

I've always coded my flip-flops in Verilog with a bit of delay for
simulation purposes. This is done when you infer your regs and is ignored
in synthesis. For example:
[snip]
I can achieve the same thing in VHDL as follows:
[snip]
Is that the correct way to achieve the same thing that I'm doing in Verilog
with the #1 delay?

Be very, very afraid. Especially in Verilog.

Suppose you write this...

always @(posedge clk) begin
Y <= #1 1'b0; // default
if (some_complicated_condition)
Y <= 1'b1; // oops, forgot the delay
end

This is catastrophically wrong... simulation will
set Y to 1'b1 only for a #1 glitch, then lapse it
back to zero; synthesis will build the logic you
probably wanted, mis-matching simulation.
Can you *honestly* promise that you will *always*
put the *same* delay on every assignment? Every time?

In VHDL the situation is a little different...

process (clk) begin
if rising_edge(clk) then
Y <= '0' after 1 ns; -- default
if some_complicated_condition then
Y <= '1'; -- oops, forgot the delay
end if;
end if;
end process;

VHDL's inertial delay on assignment will give
you approximately the correct behaviour on
both simulation and synthesis, although of
course you won't see a delay in the Y<='1' case.

If you really must do this, whether in VHDL or in
Verilog, then please put the delay in a single
place - typically, the place where you copy an
internal register value to an output port.
Less clutter, much more robust. Or, in Verilog,
use a specify block to get the same effect.
--
Jonathan Bromley

 

[Thomas Stanka]

"mike_treseler" <tres@fl_ke_networks.com> wrote:

Yes. Clock and Q looked lined up
in the functional sim waveforms
while there is really a finite
clock to Q delay.

Yes. Consider getting used to it
rather than adding AFTER clauses
to the source code. A static
timing analysis after place and
route will check all these delays for
you at every node.

I believe it's bad design practice to use _no_ after clauses.
In VHDL its very clean and easy to use, so why not infering some gate
delay?
Of course you might get big trouble when mixing it up with statements
without after clause in some cases, but normaly you have only benefits
from adding after clauses.

In concurrent statements you might prevent zero delay glitches by
adding after clauses which will speed up your simulation.

bye Thomas

 

[Thomas Stanka]

Mike Treseler <mike_treseler@comcast.net> wrote:

Thomas Stanka wrote:

I believe it's bad design practice to use _no_ after clauses.
In VHDL its very clean and easy to use, so why not infering some gate
delay?

The AFTER clause infers *nothing* for synthesis.
It cannot change the synthesis result in any way.

Thats right, maybe I'm a bit easy with words :=). I mean infering in
the simulation. Of course there's no way of infering gate delay in the
synthesis result.

In concurrent statements you might prevent zero delay glitches by
adding after clauses which will speed up your simulation.

A synchronous design will prevent such glitches both
in simulation and on the bench.

Concurrent statements and zero-delay glitches are possible in
synchronous designs.

out0<=a or b
out1<=out0 xor b

will lead to a zero delay glitch on out1 if b changes (synchronous)
from 0 to 1 while a=0.
This will have no functional effect (in a synchronous design), but may
slow down your simulation.

bye Thomas

 

[rickman]

Thomas Stanka wrote:

"mike_treseler" <tres@fl_ke_networks.com> wrote:
Yes. Clock and Q looked lined up
in the functional sim waveforms
while there is really a finite
clock to Q delay.

Yes. Consider getting used to it
rather than adding AFTER clauses
to the source code. A static
timing analysis after place and
route will check all these delays for
you at every node.

I believe it's bad design practice to use _no_ after clauses.
In VHDL its very clean and easy to use, so why not infering some gate
delay?
Of course you might get big trouble when mixing it up with statements
without after clause in some cases, but normaly you have only benefits
from adding after clauses.

In concurrent statements you might prevent zero delay glitches by
adding after clauses which will speed up your simulation.

I don't know why it would be *bad* to not use delays. I never use
them. For one, if you use 1 ns on each expression and have a number of
expressions, the delay can add up to more than a fast clock cycle. If
you use *no* delays, you won't get glitches. All register outputs will
change on the clock edge and all logic will settle before simulation
time advances. Besides, adding a fixed delay to each of your signals
does not prevent glitches, it just spreads them out over a longer time.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[rickman]

Marty wrote:

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:xJydnYWKmZH6wQTcRVn-sA@comcast.com...
Marty wrote:

process (clk, resetb)
begin
if (resetb = '0') then
flop_q <= '0';
elsif clk'event and clk = '1' then
flop_q <= '1' after 1 ns;
end if;
end process;

Is that the correct way to achieve the same thing that I'm doing in
Verilog
with the #1 delay?

The AFTER clause is ignored for synthesis.
A "delta" delay is implied by the signal assignment alone.

Ah yes, the delta delay makes it all work in simulation. However, the thing
about delta delays is that you don't see those in the waveform during
simulation and I don't like when everything lines up because I'm not used to
seeing that way. Maybe I need to get used to that.

That would help. Prelayout simulation is also called "unit delay"
simulation because there is an assumption that your delays are always
less than the clock cycle and so are all figured to be "one unit".

If the confusion comes from seeing the outputs of FFs and logic change
on the clock edge, just remember that these signals are actually
changing after the clock edge and if you align a cursor with the clock
edge, the signal values read out will be the prior values, not the
latter.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Nils Strandberg]

rickman wrote:

Marty wrote:

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:xJydnYWKmZH6wQTcRVn-sA@comcast.com...

Marty wrote:


process (clk, resetb)
begin
if (resetb = '0') then
flop_q <= '0';
elsif clk'event and clk = '1' then
flop_q <= '1' after 1 ns;
end if;
end process;

Is that the correct way to achieve the same thing that I'm doing in

Verilog

with the #1 delay?

The AFTER clause is ignored for synthesis.
A "delta" delay is implied by the signal assignment alone.

Ah yes, the delta delay makes it all work in simulation. However, the thing
about delta delays is that you don't see those in the waveform during
simulation and I don't like when everything lines up because I'm not used to
seeing that way. Maybe I need to get used to that.


That would help. Prelayout simulation is also called "unit delay"
simulation because there is an assumption that your delays are always
less than the clock cycle and so are all figured to be "one unit".

If the confusion comes from seeing the outputs of FFs and logic change
on the clock edge, just remember that these signals are actually
changing after the clock edge and if you align a cursor with the clock
edge, the signal values read out will be the prior values, not the
latter.

I have just found one reason to use the after clause. That was many,

many, years ago when I used modelsim. It was claimed to be a VHDL
complaint simulator, but in fact they didn't honor the delta delay. I
spent a couple of days before I understood why my simulations didn't
reflect my code. Adding the "after 1 ns" made it all work. When I asked
a more senior designer he sad that he always had to add a lot of "wait"
statements where he thought the simulator would do wrong things without
them.

(One funny thing though, I didn't have to add it to all my code, so it
could just have been a faulty implementation.)

Clearly two different ways to perform the same thing. I can't imagine
that it could be a problem today. I have been without a working newsfeed
for at least two years, before that job pressures kept me from reading
any for a couple of years (the newsfeed worked at my place of work), but
if it still would be problem I think I should have seen something about
it, since my newsfeed has been working for about two months now.

In the end I must agree with the rest of the posters here. It is best to
get used to the behavior. A nice feature is usually to be able to put
your vertical marker on a clock edge and see actually which signals are
changed due to that clock.

/NS

 

[Mike Treseler]

Thomas Stanka wrote:

I believe it's bad design practice to use _no_ after clauses.
In VHDL its very clean and easy to use, so why not infering some gate
delay?

The AFTER clause infers *nothing* for synthesis.
It cannot change the synthesis result in any way.

Of course you might get big trouble when mixing it up with statements
without after clause in some cases, but normaly you have only benefits
from adding after clauses.

The only possible benefit is that your functional simulation
waveforms might match reality better, if you happen to know
in advance what all the delays ought to be.

In concurrent statements you might prevent zero delay glitches by
adding after clauses which will speed up your simulation.

A synchronous design will prevent such glitches both
in simulation and on the bench.

-- Mike Treseler

 

[Mike Treseler]

Thomas Stanka wrote:

Concurrent statements and zero-delay glitches are possible in
synchronous designs.
out0<=a or b
out1<=out0 xor b
will lead to a zero delay glitch on out1 if b changes (synchronous)
from 0 to 1 while a=0.
This will have no functional effect (in a synchronous design), but may
slow down your simulation.

OK. I see what you're saying.
This is a matter of style.
I prefer to use variables instead of
signals for local calculations:

out0_v := a or b;
out0 <= out0_v;
out1 <= out0_v xor b;

Using signals for local calculations,
with an AFTER clause for simulation,
is also a valid way to do the same thing,
if that is your preference.

-- Mike Treseler

 

[rickman]

Thomas Stanka wrote:

Concurrent statements and zero-delay glitches are possible in
synchronous designs.

out0<=a or b
out1<=out0 xor b

will lead to a zero delay glitch on out1 if b changes (synchronous)
from 0 to 1 while a=0.
This will have no functional effect (in a synchronous design), but may
slow down your simulation.

Notice that adding delay to each of these assignments does not eliminate
the glitch. It simply spreads it over a wider time (1 ns vs. 1 delta =
0 ns). It also takes 2 ns for the out1 signal to settle. If you had
more levels of assignments the delay could add up to a significant
portion or even longer than a clock cycle if it is fast.

No delay out1 _____|_______ (likely not displayed in most simulators)

With delay out1 _______|--|__ Isn't this a glitch too?

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX