Delta Delays

Discussion in 'VHDL' started by bhavanireddy@gmail.com, Nov 13, 2006.

  1. Guest

    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?
     
    , Nov 13, 2006
    #1
    1. Advertising

  2. 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.
     
    Jonathan Bromley, Nov 13, 2006
    #2
    1. Advertising

  3. Guest

    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.
     
    , Nov 13, 2006
    #3
  4. 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, Nov 13, 2006
    #4
  5. Guest

    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
     
    , Nov 13, 2006
    #5
  6. 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
     
    Mike Treseler, Nov 13, 2006
    #6
  7. Andy Guest

    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.
     
    Andy, Nov 13, 2006
    #7
  8. backhus Guest

    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?
    >
     
    backhus, Nov 15, 2006
    #8
  9. 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.
     
    Jonathan Bromley, Nov 15, 2006
    #9
  10. Andy Guest

    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?
    > >
     
    Andy, Nov 15, 2006
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Thomas
    Replies:
    2
    Views:
    1,115
    Mario Trams
    Jul 6, 2003
  2. Neil Zanella
    Replies:
    2
    Views:
    10,344
  3. Viswan
    Replies:
    5
    Views:
    650
    Paulo Valentim
    Oct 7, 2004
  4. Replies:
    5
    Views:
    1,763
    Jim George
    Apr 13, 2005
  5. srikanth.padava

    delta cycle?? (delta delay)

    srikanth.padava, Feb 28, 2008, in forum: VHDL
    Replies:
    0
    Views:
    1,154
    srikanth.padava
    Feb 28, 2008
Loading...

Share This Page