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?

 

[Jonathan Bromley]

On 13 Nov 2006 01:38:52 -0800, bhavanireddy@gmail.com 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
jonathan.bromley@MYCOMPANY.com
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, bhavanireddy@gmail.com 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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

 

[Mike Treseler]

bhavanireddy@gmail.com 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:

bhavanireddy@gmail.com 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

 

[Mike Treseler]

mahenreddy@gmail.com 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

 

[Andy]

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.