Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Delta Delays

Reply
Thread Tools

Delta Delays

 
 
bhavanireddy@gmail.com
Guest
Posts: n/a
 
      11-13-2006
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?

 
Reply With Quote
 
 
 
 
Jonathan Bromley
Guest
Posts: n/a
 
      11-13-2006
On 13 Nov 2006 01:38:52 -0800, http://www.velocityreviews.com/forums/(E-Mail Removed) 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
(E-Mail Removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
Reply With Quote
 
 
 
 
bhavanireddy@gmail.com
Guest
Posts: n/a
 
      11-13-2006
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, (E-Mail Removed) 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
> (E-Mail Removed)
> http://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.


 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      11-13-2006
(E-Mail Removed) 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
 
Reply With Quote
 
mahenreddy@gmail.com
Guest
Posts: n/a
 
      11-13-2006
Thanks Mike...but if those three stmts are in concurrent signal
assignment area then the order is not important..right?


Mike Treseler wrote:
> (E-Mail Removed) 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


 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      11-13-2006
(E-Mail Removed) 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

 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      11-13-2006
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.


 
Reply With Quote
 
backhus
Guest
Posts: n/a
 
      11-15-2006
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

(E-Mail Removed) 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?
>

 
Reply With Quote
 
Jonathan Bromley
Guest
Posts: n/a
 
      11-15-2006
On Wed, 15 Nov 2006 14:15:52 +0100, backhus
<(E-Mail Removed)> 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
(E-Mail Removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      11-15-2006
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
>
> (E-Mail Removed) 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?
> >


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
delta cycle?? (delta delay) srikanth.padava VHDL 0 02-28-2008 09:01 AM
Delays-delays-delays Colin Palmer Computer Support 5 02-26-2008 04:41 AM
delays: inertial delays vs. transport delays Neil Zanella VHDL 2 10-20-2003 07:27 AM
delta delay.. Ramakrishnan VHDL 4 09-23-2003 06:09 PM
Delta Count Overflow in Simulation Isaac VHDL 2 08-18-2003 09:57 AM



Advertisments