Flip-flop delay in VHDL

Discussion in 'VHDL' started by Marty, Nov 16, 2004.

  1. Marty

    Marty Guest

    Hi c.l.vhdl,

    I've always coded my flip-flops in Verilog with a bit of delay for
    simulation purposes. This is done when you infer your regs and is ignored
    in synthesis. For example:

    always @(posedge clk or negedge resetb)
    if (!resetb)
    flop_q <= 1'b0;
    else
    flop_q <= #1 1'b1;

    I can achieve the same thing in VHDL as follows:

    process (clk, resetb)
    begin
    if (resetb = '0') then
    flop_q <= '0';
    elsif clk'event and clk = '1' then
    flop_q <= '1' after 1 ns;
    end if;
    end process;

    Is that the correct way to achieve the same thing that I'm doing in Verilog
    with the #1 delay?

    Just curious...
    --
    Marty
     
    Marty, Nov 16, 2004
    #1
    1. Advertising

  2. Marty wrote:

    > process (clk, resetb)
    > begin
    > if (resetb = '0') then
    > flop_q <= '0';
    > elsif clk'event and clk = '1' then
    > flop_q <= '1' after 1 ns;
    > end if;
    > end process;
    >
    > Is that the correct way to achieve the same thing that I'm doing in Verilog
    > with the #1 delay?


    The AFTER clause is ignored for synthesis.
    A "delta" delay is implied by the signal assignment alone.

    -- Mike Treseler
     
    Mike Treseler, Nov 16, 2004
    #2
    1. Advertising

  3. Marty

    Marty Guest

    "Mike Treseler" <> wrote in message
    news:...
    > Marty wrote:
    >
    > > process (clk, resetb)
    > > begin
    > > if (resetb = '0') then
    > > flop_q <= '0';
    > > elsif clk'event and clk = '1' then
    > > flop_q <= '1' after 1 ns;
    > > end if;
    > > end process;
    > >
    > > Is that the correct way to achieve the same thing that I'm doing in

    Verilog
    > > with the #1 delay?

    >
    > The AFTER clause is ignored for synthesis.
    > A "delta" delay is implied by the signal assignment alone.


    Ah yes, the delta delay makes it all work in simulation. However, the thing
    about delta delays is that you don't see those in the waveform during
    simulation and I don't like when everything lines up because I'm not used to
    seeing that way. Maybe I need to get used to that.

    Thanks Mike.
    --
    Marty
     
    Marty, Nov 16, 2004
    #3
  4. Yes. Clock and Q looked lined up
    in the functional sim waveforms
    while there is really a finite
    clock to Q delay.

    Yes. Consider getting used to it
    rather than adding AFTER clauses
    to the source code. A static
    timing analysis after place and
    route will check all these delays for
    you at every node.

    If you want to see the real delays,
    (and have some time to kill)
    run a post-route gate level sim.

    -- Mike Treseler
     
    mike_treseler, Nov 16, 2004
    #4
  5. Marty

    rickman Guest

    Marty wrote:
    >
    > "Mike Treseler" <> wrote in message
    > news:...
    > > Marty wrote:
    > >
    > > > process (clk, resetb)
    > > > begin
    > > > if (resetb = '0') then
    > > > flop_q <= '0';
    > > > elsif clk'event and clk = '1' then
    > > > flop_q <= '1' after 1 ns;
    > > > end if;
    > > > end process;
    > > >
    > > > Is that the correct way to achieve the same thing that I'm doing in

    > Verilog
    > > > with the #1 delay?

    > >
    > > The AFTER clause is ignored for synthesis.
    > > A "delta" delay is implied by the signal assignment alone.

    >
    > Ah yes, the delta delay makes it all work in simulation. However, the thing
    > about delta delays is that you don't see those in the waveform during
    > simulation and I don't like when everything lines up because I'm not used to
    > seeing that way. Maybe I need to get used to that.


    That would help. Prelayout simulation is also called "unit delay"
    simulation because there is an assumption that your delays are always
    less than the clock cycle and so are all figured to be "one unit".

    If the confusion comes from seeing the outputs of FFs and logic change
    on the clock edge, just remember that these signals are actually
    changing after the clock edge and if you align a cursor with the clock
    edge, the signal values read out will be the prior values, not the
    latter.

    --

    Rick "rickman" Collins


    Ignore the reply address. To email me use the above address with the XY
    removed.

    Arius - A Signal Processing Solutions Company
    Specializing in DSP and FPGA design URL http://www.arius.com
    4 King Ave 301-682-7772 Voice
    Frederick, MD 21701-3110 301-682-7666 FAX
     
    rickman, Nov 18, 2004
    #5
  6. rickman wrote:
    > Marty wrote:
    >
    >>"Mike Treseler" <> wrote in message
    >>news:...
    >>
    >>>Marty wrote:
    >>>
    >>>
    >>>>process (clk, resetb)
    >>>>begin
    >>>> if (resetb = '0') then
    >>>> flop_q <= '0';
    >>>> elsif clk'event and clk = '1' then
    >>>> flop_q <= '1' after 1 ns;
    >>>> end if;
    >>>>end process;
    >>>>
    >>>>Is that the correct way to achieve the same thing that I'm doing in

    >>
    >>Verilog
    >>
    >>>>with the #1 delay?
    >>>
    >>>The AFTER clause is ignored for synthesis.
    >>>A "delta" delay is implied by the signal assignment alone.

    >>
    >>Ah yes, the delta delay makes it all work in simulation. However, the thing
    >>about delta delays is that you don't see those in the waveform during
    >>simulation and I don't like when everything lines up because I'm not used to
    >>seeing that way. Maybe I need to get used to that.

    >
    >
    > That would help. Prelayout simulation is also called "unit delay"
    > simulation because there is an assumption that your delays are always
    > less than the clock cycle and so are all figured to be "one unit".
    >
    > If the confusion comes from seeing the outputs of FFs and logic change
    > on the clock edge, just remember that these signals are actually
    > changing after the clock edge and if you align a cursor with the clock
    > edge, the signal values read out will be the prior values, not the
    > latter.
    >

    I have just found one reason to use the after clause. That was many,
    many, years ago when I used modelsim. It was claimed to be a VHDL
    complaint simulator, but in fact they didn't honor the delta delay. I
    spent a couple of days before I understood why my simulations didn't
    reflect my code. Adding the "after 1 ns" made it all work. When I asked
    a more senior designer he sad that he always had to add a lot of "wait"
    statements where he thought the simulator would do wrong things without
    them.

    (One funny thing though, I didn't have to add it to all my code, so it
    could just have been a faulty implementation.)

    Clearly two different ways to perform the same thing. I can't imagine
    that it could be a problem today. I have been without a working newsfeed
    for at least two years, before that job pressures kept me from reading
    any for a couple of years (the newsfeed worked at my place of work), but
    if it still would be problem I think I should have seen something about
    it, since my newsfeed has been working for about two months now.

    In the end I must agree with the rest of the posters here. It is best to
    get used to the behavior. A nice feature is usually to be able to put
    your vertical marker on a clock edge and see actually which signals are
    changed due to that clock.

    /NS
     
    Nils Strandberg, Nov 19, 2004
    #6
  7. "Marty" <> wrote in message news:<>...
    > Hi c.l.vhdl,
    >
    > I've always coded my flip-flops in Verilog with a bit of delay for
    > simulation purposes. This is done when you infer your regs and is ignored
    > in synthesis. For example:

    [snip]
    > I can achieve the same thing in VHDL as follows:

    [snip]
    > Is that the correct way to achieve the same thing that I'm doing in Verilog
    > with the #1 delay?


    Be very, very afraid. Especially in Verilog.

    Suppose you write this...

    always @(posedge clk) begin
    Y <= #1 1'b0; // default
    if (some_complicated_condition)
    Y <= 1'b1; // oops, forgot the delay
    end

    This is catastrophically wrong... simulation will
    set Y to 1'b1 only for a #1 glitch, then lapse it
    back to zero; synthesis will build the logic you
    probably wanted, mis-matching simulation.
    Can you *honestly* promise that you will *always*
    put the *same* delay on every assignment? Every time?

    In VHDL the situation is a little different...

    process (clk) begin
    if rising_edge(clk) then
    Y <= '0' after 1 ns; -- default
    if some_complicated_condition then
    Y <= '1'; -- oops, forgot the delay
    end if;
    end if;
    end process;

    VHDL's inertial delay on assignment will give
    you approximately the correct behaviour on
    both simulation and synthesis, although of
    course you won't see a delay in the Y<='1' case.

    If you really must do this, whether in VHDL or in
    Verilog, then please put the delay in a single
    place - typically, the place where you copy an
    internal register value to an output port.
    Less clutter, much more robust. Or, in Verilog,
    use a specify block to get the same effect.
    --
    Jonathan Bromley
     
    Jonathan Bromley, Nov 19, 2004
    #7
  8. "mike_treseler" <tres@fl_ke_networks.com> wrote:
    > Yes. Clock and Q looked lined up
    > in the functional sim waveforms
    > while there is really a finite
    > clock to Q delay.
    >
    > Yes. Consider getting used to it
    > rather than adding AFTER clauses
    > to the source code. A static
    > timing analysis after place and
    > route will check all these delays for
    > you at every node.


    I believe it's bad design practice to use _no_ after clauses.
    In VHDL its very clean and easy to use, so why not infering some gate
    delay?
    Of course you might get big trouble when mixing it up with statements
    without after clause in some cases, but normaly you have only benefits
    from adding after clauses.

    In concurrent statements you might prevent zero delay glitches by
    adding after clauses which will speed up your simulation.

    bye Thomas
     
    Thomas Stanka, Nov 22, 2004
    #8
  9. Thomas Stanka wrote:

    > I believe it's bad design practice to use _no_ after clauses.
    > In VHDL its very clean and easy to use, so why not infering some gate
    > delay?


    The AFTER clause infers *nothing* for synthesis.
    It cannot change the synthesis result in any way.

    > Of course you might get big trouble when mixing it up with statements
    > without after clause in some cases, but normaly you have only benefits
    > from adding after clauses.


    The only possible benefit is that your functional simulation
    waveforms might match reality better, if you happen to know
    in advance what all the delays ought to be.

    > In concurrent statements you might prevent zero delay glitches by
    > adding after clauses which will speed up your simulation.


    A synchronous design will prevent such glitches both
    in simulation and on the bench.

    -- Mike Treseler
     
    Mike Treseler, Nov 22, 2004
    #9
  10. Mike Treseler <> wrote:
    > Thomas Stanka wrote:
    >
    > > I believe it's bad design practice to use _no_ after clauses.
    > > In VHDL its very clean and easy to use, so why not infering some gate
    > > delay?

    >
    > The AFTER clause infers *nothing* for synthesis.
    > It cannot change the synthesis result in any way.


    Thats right, maybe I'm a bit easy with words :=). I mean infering in
    the simulation. Of course there's no way of infering gate delay in the
    synthesis result.

    > > In concurrent statements you might prevent zero delay glitches by
    > > adding after clauses which will speed up your simulation.

    >
    > A synchronous design will prevent such glitches both
    > in simulation and on the bench.


    Concurrent statements and zero-delay glitches are possible in
    synchronous designs.

    out0<=a or b
    out1<=out0 xor b

    will lead to a zero delay glitch on out1 if b changes (synchronous)
    from 0 to 1 while a=0.
    This will have no functional effect (in a synchronous design), but may
    slow down your simulation.

    bye Thomas
     
    Thomas Stanka, Nov 23, 2004
    #10
  11. Thomas Stanka wrote:

    > Concurrent statements and zero-delay glitches are possible in
    > synchronous designs.
    > out0<=a or b
    > out1<=out0 xor b
    > will lead to a zero delay glitch on out1 if b changes (synchronous)
    > from 0 to 1 while a=0.
    > This will have no functional effect (in a synchronous design), but may
    > slow down your simulation.


    OK. I see what you're saying.
    This is a matter of style.
    I prefer to use variables instead of
    signals for local calculations:

    out0_v := a or b;
    out0 <= out0_v;
    out1 <= out0_v xor b;

    Using signals for local calculations,
    with an AFTER clause for simulation,
    is also a valid way to do the same thing,
    if that is your preference.

    -- Mike Treseler
     
    Mike Treseler, Nov 23, 2004
    #11
  12. Marty

    rickman Guest

    Thomas Stanka wrote:
    >
    > "mike_treseler" <tres@fl_ke_networks.com> wrote:
    > > Yes. Clock and Q looked lined up
    > > in the functional sim waveforms
    > > while there is really a finite
    > > clock to Q delay.
    > >
    > > Yes. Consider getting used to it
    > > rather than adding AFTER clauses
    > > to the source code. A static
    > > timing analysis after place and
    > > route will check all these delays for
    > > you at every node.

    >
    > I believe it's bad design practice to use _no_ after clauses.
    > In VHDL its very clean and easy to use, so why not infering some gate
    > delay?
    > Of course you might get big trouble when mixing it up with statements
    > without after clause in some cases, but normaly you have only benefits
    > from adding after clauses.
    >
    > In concurrent statements you might prevent zero delay glitches by
    > adding after clauses which will speed up your simulation.


    I don't know why it would be *bad* to not use delays. I never use
    them. For one, if you use 1 ns on each expression and have a number of
    expressions, the delay can add up to more than a fast clock cycle. If
    you use *no* delays, you won't get glitches. All register outputs will
    change on the clock edge and all logic will settle before simulation
    time advances. Besides, adding a fixed delay to each of your signals
    does not prevent glitches, it just spreads them out over a longer time.

    --

    Rick "rickman" Collins


    Ignore the reply address. To email me use the above address with the XY
    removed.

    Arius - A Signal Processing Solutions Company
    Specializing in DSP and FPGA design URL http://www.arius.com
    4 King Ave 301-682-7772 Voice
    Frederick, MD 21701-3110 301-682-7666 FAX
     
    rickman, Nov 28, 2004
    #12
  13. Marty

    rickman Guest

    Thomas Stanka wrote:
    >
    > Concurrent statements and zero-delay glitches are possible in
    > synchronous designs.
    >
    > out0<=a or b
    > out1<=out0 xor b
    >
    > will lead to a zero delay glitch on out1 if b changes (synchronous)
    > from 0 to 1 while a=0.
    > This will have no functional effect (in a synchronous design), but may
    > slow down your simulation.


    Notice that adding delay to each of these assignments does not eliminate
    the glitch. It simply spreads it over a wider time (1 ns vs. 1 delta =
    0 ns). It also takes 2 ns for the out1 signal to settle. If you had
    more levels of assignments the delay could add up to a significant
    portion or even longer than a clock cycle if it is fast.

    No delay out1 _____|_______ (likely not displayed in most simulators)

    With delay out1 _______|--|__ Isn't this a glitch too?

    --

    Rick "rickman" Collins


    Ignore the reply address. To email me use the above address with the XY
    removed.

    Arius - A Signal Processing Solutions Company
    Specializing in DSP and FPGA design URL http://www.arius.com
    4 King Ave 301-682-7772 Voice
    Frederick, MD 21701-3110 301-682-7666 FAX
     
    rickman, Nov 28, 2004
    #13
  14. Marty

    ayza1505

    Joined:
    Aug 23, 2007
    Messages:
    1
    Location:
    malaysia
    i converted my vhdl file into verilog but it cant works!!pls help me.there's syntax error at input.....


    module d_ffdelay (clk,resetn,d_in,d_out)
    input clk, resetn, d_in;
    output d_out;

    reg s;

    always@(posedge clk)
    begin
    if (!resetn)
    d_out<=1'b0;
    else
    s<= #20 1'b1;
    d_out<=s;
    end
    endmodule
     
    ayza1505, Aug 23, 2007
    #14
    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. John

    Flip Flop Synchronization

    John, Jan 3, 2004, in forum: VHDL
    Replies:
    3
    Views:
    9,717
    valentin tihomirov
    Jan 5, 2004
  2. eric
    Replies:
    15
    Views:
    1,455
  3. Weng Tianxiang

    IC area of flip-flop and SRAM?

    Weng Tianxiang, May 19, 2004, in forum: VHDL
    Replies:
    1
    Views:
    1,188
    Samuel Fuhrer
    May 23, 2004
  4. Weng Tianxiang

    Best book on a flip flop circuit

    Weng Tianxiang, May 19, 2004, in forum: VHDL
    Replies:
    1
    Views:
    821
    Mike Treseler
    May 20, 2004
  5. Jim

    Tristate Flip Flop

    Jim, Oct 27, 2004, in forum: VHDL
    Replies:
    12
    Views:
    4,891
    Ho. Li
    Nov 18, 2004
Loading...

Share This Page