delta delay..

Hello,
'delta delays'are described in all vhdl books.
Is it that one which the vhdl programmer has to worry about?
Is it of interest to simulator writers only?
Has the delta delay mechanism of a simulator , in any way affect the
programming methodology?
My concern is, should we take into account the delta delay of
simulator in programming?
Much confused.(As a programmer , transport and inertial delays are
enough. That is my view . i may be wrong.).
Can any one clear the doubts?
thanks a lot.
ram
22nd sep 2003

Ramakrishnan

(Ramakrishnan) wrote in message news:<. com>...
> Hello,
> 'delta delays'are described in all vhdl books.
> Is it that one which the vhdl programmer has to worry about?
> Is it of interest to simulator writers only?
> Has the delta delay mechanism of a simulator , in any way affect the
> programming methodology?
> My concern is, should we take into account the delta delay of
> simulator in programming?
> Much confused.(As a programmer , transport and inertial delays are
> enough. That is my view . i may be wrong.).
> Can any one clear the doubts?
> thanks a lot.
> ram
> 22nd sep 2003
Delta times are needed for simulation to emulate concurrency.
Care must be taken when using variable to avoid code that is
harder to read, and is confusing. In the example below, variable V
is used both as a FF and as a temporary variable. This is very poor
style.
If you use a variable as a temporary, assigning before reading it.
If you using as a FF, then avaoid reusing it as a temporary, implying
combinational logic.
Problem_proc: process (clk, reset_n) is
variable v : std_logic;
begin -- process Problem_proc
if reset_n = '0' then -- asynchronous reset (active
low)
s1 <= '0';
s2 <= '0';
elsif clk'event and clk = '1' then -- rising clock edge
s1 <= v; -- v is a FF since it holds old value
v := s3 and s4; -- v is a temp
s2 <= s1 and v; -- v is a temp here, equal to (s3 and s4)
v := s2; -- v is a FF since it must hold value till next clock
end if;
end process Problem_proc;

On another related topic, avoid using "wait for 0 ns; " ,unless
absolutely necessary (like my switch model. If you must resort to
"wait for 0 ns;" in your TB, then you are using a very poor style.
----------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/
Author of following textbooks:
* Using PSL/SUGAR with Verilog and VHDL
Guide to Property Specification Language for ABV, 2003 isbn
0-9705394-4-4
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn
0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn
0-7923-8115
------------------------------------------------------------------------------

ben cohen

ben cohen wrote:

> "wait for 0 ns;" in your TB, then you are using a very poor style.

Unless of course you are using two of them and doing
zero time handshaking between BFMs in a testbench.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Jim Lewis
Director of Training private.php?do=newpm&u=
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~

Jim Lewis

A delta cycle is a VHDL construct used to make
VHDL, a concurrent language, executable on a
sequential computer.

For RTL design, you can adopt some simple rules and
forget about delta cycles.

For testbenches, often you must have a good understanding
of what the simulator is doing.

The term "delta delay" refers to a signal being
scheduled a new value now, but the value does not get
applied until the next simulation cycle a delta cycle
later.

For RTL design, two simple rules:
1) All signal assignments in a clocked process (one that
describes a clock edge) create registers. Assignments in
a chain create a pipeline:

TwoRegProc : process
begin
wait until Clk = '1' ;
AReg1 <= A ;
AReg2 <= AReg1 ;
end process ;

2) In combinational logic, do not chain signal assignments
together in a process:
BadProc : process (A, B, C)
begin
Y <= A and B ;
X <= Y or C ;
end process ;

In this process, the value of Y seen by X is the
value form the previous execution. There are a number
of "ok" way to fix this, but the right way to do it is
to separate the logic into separate processes or concurrent
statements. In fact, in this case, two concurrent assignments
(ie: not in a process works best):

Y <= A and B ;
X <= Y or C ;

Remember those two points, and you can for the most part
forget about delta cycles for RTL design.

Cheers,
Jim Lewis

P.S. If you are still confused, a VHDL class might be
a good investment.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Jim Lewis
Director of Training private.php?do=newpm&u=
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~


Ramakrishnan wrote:

> Hello,
> 'delta delays'are described in all vhdl books.
> Is it that one which the vhdl programmer has to worry about?
> Is it of interest to simulator writers only?
> Has the delta delay mechanism of a simulator , in any way affect the
> programming methodology?
> My concern is, should we take into account the delta delay of
> simulator in programming?
> Much confused.(As a programmer , transport and inertial delays are
> enough. That is my view . i may be wrong.).
> Can any one clear the doubts?
> thanks a lot.
> ram
> 22nd sep 2003

Jim Lewis

Ramakrishnan wrote:

> 'delta delays'are described in all vhdl books.
> Is it that one which the vhdl programmer has to worry about?
> Is it of interest to simulator writers only?


For synchronous processes, delta delays may be ignored.

If your testbench uses wait statements, you will
discover delta delays. Sim signals will not change
value until a wait is encountered.

Consider writing your testbench in a synchronous
style, using waits only for the sim clock generator.

This not only eliminates the non-stylish "wait for 0 ns",
but it keeps your brain in synchronous mode at all times.

-- Mike Treseler

Mike Treseler