Delta Delays

Hi,

I am new to VHDL and really don't understand the need for delata delays
in concurrent statements. I, infact understand the need for delta
delays in "process" statements. Are delta delays applicable only in
"process" statements?

bhavanireddy@gmail.com

On 13 Nov 2006 01:38:52 -0800, wrote:

>Hi,
>
>I am new to VHDL and really don't understand the need for delata delays
>in concurrent statements. I, infact understand the need for delta
>delays in "process" statements. Are delta delays applicable only in
>"process" statements?

Delta delay affects every assignment to a signal.

A concurrent signal assignment is a process. Take,
for example:

architecture foo of bar is
signal a,b,c: bit;
begin
a <= b and c;
end;

The concurrent assignment "a <= b and c;" is EXACTLY
equivalent to the process

process(b,c) begin
a <= b and c;
end process;

which, in its turn, is exactly equivalent to

process begin
a <= b and c;
wait on b,c;
end process;

In all three cases, the signal assignment suffers a delta delay.

Delta delays allow a discrete-event simulator to be deterministic
without the need for (explicit) mutual exclusion mechanisms.

As Verilog shows, it is possible to define a simulator in which
some signal assignments do NOT suffer delta delays, and yet
retain deterministic behaviour if the user is careful enough.
The delta delay mechanism is available in Verilog, through
nonblocking assignment, and is effectively essential when
writing clock-synchronous descriptions. I say "effectively
essential" because there are other ways to write clock-
synchronous models, without using nonblocking
assignment; but they are extremely clumsy and
error-prone.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Thanks for really quick response..

Since the statements in "process" block execute sequentially, I
thought order of execution is important...like in traditional
programming languages (C, C++, Java). Look at the following piece of
code.

process begin

a <= NOT i; -- stmt1
b <= d nand a; -- stmt2
a <= b and a; -- stmt3

WAIT;

end process

Is order of statements important in the above code? Since they are in
"process" block they should execute sequentially and think order is
important. I am new to VHDl and getting confused here..Thanks in
advance four your help

Jonathan Bromley wrote:
> On 13 Nov 2006 01:38:52 -0800, wrote:
>
> >Hi,
> >
> >I am new to VHDL and really don't understand the need for delata delays
> >in concurrent statements. I, infact understand the need for delta
> >delays in "process" statements. Are delta delays applicable only in
> >"process" statements?
>
> Delta delay affects every assignment to a signal.
>
> A concurrent signal assignment is a process. Take,
> for example:
>
> architecture foo of bar is
> signal a,b,c: bit;
> begin
> a <= b and c;
> end;
>
> The concurrent assignment "a <= b and c;" is EXACTLY
> equivalent to the process
>
> process(b,c) begin
> a <= b and c;
> end process;
>
> which, in its turn, is exactly equivalent to
>
> process begin
> a <= b and c;
> wait on b,c;
> end process;
>
> In all three cases, the signal assignment suffers a delta delay.
>
> Delta delays allow a discrete-event simulator to be deterministic
> without the need for (explicit) mutual exclusion mechanisms.
>
> As Verilog shows, it is possible to define a simulator in which
> some signal assignments do NOT suffer delta delays, and yet
> retain deterministic behaviour if the user is careful enough.
> The delta delay mechanism is available in Verilog, through
> nonblocking assignment, and is effectively essential when
> writing clock-synchronous descriptions. I say "effectively
> essential" because there are other ways to write clock-
> synchronous models, without using nonblocking
> assignment; but they are extremely clumsy and
> error-prone.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
>
> http://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

wrote:

> process begin
> a <= NOT i; -- stmt1
> b <= d nand a; -- stmt2
> a <= b and a; -- stmt3
> WAIT;
> end process
>
> Is order of statements important in the above code?

Yes, but the values of a and b do not change until the WAIT.

> I am new to VHDl and getting confused here..

It is confusing.
You have discovered the reason that I use
variables instead of signals for everything
except port maps.

-- Mike Treseler

Thanks Mike...but if those three stmts are in concurrent signal
assignment area then the order is not important..right?


Mike Treseler wrote:
> wrote:
>
> > process begin
> > a <= NOT i; -- stmt1
> > b <= d nand a; -- stmt2
> > a <= b and a; -- stmt3
> > WAIT;
> > end process
> >
> > Is order of statements important in the above code?
>
> Yes, but the values of a and b do not change until the WAIT.
>
> > I am new to VHDl and getting confused here..
>
> It is confusing.
> You have discovered the reason that I use
> variables instead of signals for everything
> except port maps.
>
> -- Mike Treseler

wrote:
> Thanks Mike...but if those three stmts are in concurrent signal
> assignment area then the order is not important..right?

The order of processes in an architecture
has no effect on simulation or synthesis.

The *number* of processes in an architectures
is a matter of style, and debugging preferences.

-- Mike Treseler

And in most cases, a matter of simulation speed. Fewer processes =
faster simulation. Fewer process wake-ups, fewer signals, fewer events.
However, most modern simulators merge processes that have the same
sensitivity lists, so several clocked processes with same clock (and
reset if applicable) will simulate the same as one combined process,
except for the fact that they have to communicate with each other via
signals, which have more overhead than variables.

Andy


Mike Treseler wrote:
> The *number* of processes in an architectures
> is a matter of style, and debugging preferences.

Hi,
actually VHDL don't need delta delays at all.
BUT, simulators do.
Since VHDL Simulators ar in general event driven simulators, and they
run on sequential machines (e.g. your PC) it's hard to write an
algorithm that simulates simultaneous signal changes.

So the simulator evaluates one signal, and the chane becomes valid at
the next delta cycle which is an event for the simulator to evaluate the
next signal etc.

Delta cycles (Or Delta delays) consumes no time in simulation but time
for simulation.

Try to simulate a combinatorical feedback loop e.g. in Modelsim like
A<= not A;

Your simulation time will stay at 0 ns but your simulator runs forever,
or at least until he exeeds some memory limit and gives an error message
(Version dependent).

A concurrent statement in VHDL is just the short form of a process.


A <= B and C;

is the same as

Process (B,C)
begin
A <= B and C;
end process;

But...while

A <= B and C;
B <= C or D;

and

Process (B,C,D)
begin
A <= B and C;
B <= C or D;
end process;

give the same results in synthesis and simulation,
the simulator may internally handle them differently.
This may cause a different number of delta cycles, but as said before
there's no real delay involved.

Have a nice simulation
Eilert

schrieb:
> Hi,
>
> I am new to VHDL and really don't understand the need for delata delays
> in concurrent statements. I, infact understand the need for delta
> delays in "process" statements. Are delta delays applicable only in
> "process" statements?
>

On Wed, 15 Nov 2006 14:15:52 +0100, backhus
<> wrote:

>Hi,
>actually VHDL don't need delta delays at all.
>BUT, simulators do.

Since VHDL's reason for existence is no more nor less than
to define the behaviour of a simulator, I think maybe you need
to re-phrase that just a little more carefully...
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Not _exaclty_ correct on that last example. With the separate
concurrent assignment statements, an event on D does not cause a
transaction on A (A'transaction = true), whereas in the combined
process, it does. Not a big difference, but in behavioral modelling
(e.g. testbenches), it can make a difference in the way some code
reacting to A behaves.

They are identical WRT synthesis, and simulation of synthesizable code
(i.e. with no references to A'transaction).

Andy


backhus wrote:
> But...while
>
> A <= B and C;
> B <= C or D;
>
> and
>
> Process (B,C,D)
> begin
> A <= B and C;
> B <= C or D;
> end process;
>
> give the same results in synthesis and simulation,
> the simulator may internally handle them differently.
> This may cause a different number of delta cycles, but as said before
> there's no real delay involved.
>
> Have a nice simulation
> Eilert
>
> schrieb:
> > Hi,
> >
> > I am new to VHDL and really don't understand the need for delata delays
> > in concurrent statements. I, infact understand the need for delta
> > delays in "process" statements. Are delta delays applicable only in
> > "process" statements?
> >