Clock Edge transitions..

Discussion in 'VHDL' started by VHDL User, Oct 12, 2004.

  1. VHDL User

    VHDL User Guest

    Hi All,
    I have a basic doubt. When a signal transitions on a clock edge, and I
    want to use the final value of this signal for computation on the same
    clock edge (and drive some other signal on the same edge) HOW do I do it ?
    Simulation takes the previous value of the signal as the transition is
    scheduled ater the simulation delta. I also fear a race condition like
    situation.
    This is my code :

    Ap : process(Clk)
    begin
    if (posedge(Clk))
    A<='1';
    end if;
    end process Ap;
    Bp : process(Clk)
    begin
    if (posedge(Clk) and A='1')
    B<='1';
    end if;
    end process Bp;

    A is global signal, so access by Bp is not a issue.When Ap and Bp get
    executed simultaneously, on the +ve edge, an event is scheduled on A after
    Simulation delta.This would mean the B signal would be asserted only on
    next edge,as A is "seen" as old value,which may not be 1. So,how do I make
    B also transit before the next edge ?
    One way could be to sample A after some time,say after 1/10 th of period
    or something like that. But that is arbitrary? A and B are output signals.
    Would using variables in the process and converting back later help to
    avoid the delta delay? Or adding a wait for 0ns statement ? Wouldnt
    synthesis of this code lead to a potential race condition ?
    Thanks a lot.Please let me know if more details are needed.
    Bye.
     
    VHDL User, Oct 12, 2004
    #1
    1. Advertising

  2. VHDL User

    Ken Smith Guest

    In article <>,
    VHDL User <> wrote:
    >Hi All,
    > I have a basic doubt. When a signal transitions on a clock edge, and I
    >want to use the final value of this signal for computation on the same
    >clock edge (and drive some other signal on the same edge) HOW do I do it ?
    >Simulation takes the previous value of the signal as the transition is
    >scheduled ater the simulation delta. I also fear a race condition like
    >situation.
    >This is my code :
    >
    >Ap : process(Clk)
    > begin
    > if (posedge(Clk))
    > A<='1';
    > end if;
    > end process Ap;
    >Bp : process(Clk)
    > begin
    > if (posedge(Clk) and A='1')
    > B<='1';
    > end if;
    > end process Bp;
    >

    [...]
    >avoid the delta delay? Or adding a wait for 0ns statement ? Wouldnt
    >synthesis of this code lead to a potential race condition ?


    I'll take on only what happens in a real part.

    Inside a real part, the "A" and "B" signals will only take on their new
    values some short time after the edge of "Clk". In most parts the new
    value is actually based on the value on the input to the flip-flop just
    before the edge. This means that "B" will become "1" one clock cycle
    after "A" does in almost all cases.

    In real parts there can be a problem with clock skew where one part of the
    chip see the edge before another. Chip designers go to great lengths to
    reduce clock skew but you should not ignore the question when working with
    large parts.


    --
    --
    forging knowledge
     
    Ken Smith, Oct 12, 2004
    #2
    1. Advertising

  3. VHDL User

    rickman Guest

    VHDL User wrote:
    >
    > Hi All,
    > I have a basic doubt. When a signal transitions on a clock edge, and I
    > want to use the final value of this signal for computation on the same
    > clock edge (and drive some other signal on the same edge) HOW do I do it ?
    > Simulation takes the previous value of the signal as the transition is
    > scheduled ater the simulation delta. I also fear a race condition like
    > situation.
    > This is my code :
    >
    > Ap : process(Clk)
    > begin
    > if (posedge(Clk))
    > A<='1';
    > end if;
    > end process Ap;
    > Bp : process(Clk)
    > begin
    > if (posedge(Clk) and A='1')
    > B<='1';
    > end if;
    > end process Bp;
    >
    > A is global signal, so access by Bp is not a issue.When Ap and Bp get
    > executed simultaneously, on the +ve edge, an event is scheduled on A after
    > Simulation delta.This would mean the B signal would be asserted only on
    > next edge,as A is "seen" as old value,which may not be 1. So,how do I make
    > B also transit before the next edge ?
    > One way could be to sample A after some time,say after 1/10 th of period
    > or something like that. But that is arbitrary? A and B are output signals.
    > Would using variables in the process and converting back later help to
    > avoid the delta delay? Or adding a wait for 0ns statement ? Wouldnt
    > synthesis of this code lead to a potential race condition ?


    I am a little fuzzy on things sometimes, but I am pretty sure that this
    is not a problem due to a thing called delta time. The clock edge
    transition triggers each of the two processes in an arbitrary order.
    But the output transitions (A and B) are queued to occur not immediately
    in the simulator, but after 1 delta time (which is not mapped to real
    time but occurs in zero real ns). So the Bp process will read the same
    value of A (the older one) regardless whether it runs before or after
    process Ap.

    Once all the events scheduled for zero delta time are run, then the
    processes that were scheduled for 1 delta time are run and so on until
    no more delta time events are queued and the simulator then looks at the
    next real time event.

    BTW, A does not need to be a global signal to be visible by process Bp
    (I'm not sure there *are* global signals vs. global variables). They
    just need to be in the same entity or you can pass A around in a port
    declaration.

    --

    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, Oct 13, 2004
    #3
  4. VHDL User

    VHDL User Guest

    On Wed, 13 Oct 2004, rickman wrote:

    > VHDL User wrote:
    >>
    >> Hi All,
    >> I have a basic doubt. When a signal transitions on a clock edge, and I
    >> want to use the final value of this signal for computation on the same
    >> clock edge (and drive some other signal on the same edge) HOW do I do it ?
    >> Simulation takes the previous value of the signal as the transition is
    >> scheduled ater the simulation delta. I also fear a race condition like
    >> situation.
    >> This is my code :
    >>
    >> Ap : process(Clk)
    >> begin
    >> if (posedge(Clk))
    >> A<='1';
    >> end if;
    >> end process Ap;
    >> Bp : process(Clk)
    >> begin
    >> if (posedge(Clk) and A='1')
    >> B<='1';
    >> end if;
    >> end process Bp;
    >>
    >> A is global signal, so access by Bp is not a issue.When Ap and Bp get
    >> executed simultaneously, on the +ve edge, an event is scheduled on A after
    >> Simulation delta.This would mean the B signal would be asserted only on
    >> next edge,as A is "seen" as old value,which may not be 1. So,how do I make
    >> B also transit before the next edge ?
    >> One way could be to sample A after some time,say after 1/10 th of period
    >> or something like that. But that is arbitrary? A and B are output signals.
    >> Would using variables in the process and converting back later help to
    >> avoid the delta delay? Or adding a wait for 0ns statement ? Wouldnt
    >> synthesis of this code lead to a potential race condition ?

    >
    > I am a little fuzzy on things sometimes, but I am pretty sure that this
    > is not a problem due to a thing called delta time. The clock edge
    > transition triggers each of the two processes in an arbitrary order.
    > But the output transitions (A and B) are queued to occur not immediately
    > in the simulator, but after 1 delta time (which is not mapped to real
    > time but occurs in zero real ns). So the Bp process will read the same
    > value of A (the older one) regardless whether it runs before or after
    > process Ap.
    >
    > Once all the events scheduled for zero delta time are run, then the
    > processes that were scheduled for 1 delta time are run and so on until
    > no more delta time events are queued and the simulator then looks at the
    > next real time event.


    Precisely. I have mentioned in my post that due to simulation
    delta cycle,A will be updated only 1 delta delay later,and hence B will
    always read the old value of A.My problem is how to change B based on new
    value of A before next positive edge.
    My fear of a race condition was only for the hardware.In
    simulation, delta delays ensure that no race conditions arise,but (as you
    yourself pointed out ) in real time, the two signals get updated in "zero"
    time.
    My problem still remains.How do I update B once A has been
    updated, before the next positive edge.

    >
    > BTW, A does not need to be a global signal to be visible by process Bp
    > (I'm not sure there *are* global signals vs. global variables). They
    > just need to be in the same entity or you can pass A around in a port
    > declaration.

    Sure.I agree completely.By "global" I meant signal in same
    entity. Sorry for the needless confusion.

    >
    > --
    >
    > 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
    >
     
    VHDL User, Oct 13, 2004
    #4
  5. VHDL User wrote:
    >
    >
    >>> Ap : process(Clk)
    >>> begin
    >>> if (posedge(Clk))
    >>> A<='1';
    >>> end if;
    >>> end process Ap;
    >>> Bp : process(Clk)
    >>> begin
    >>> if (posedge(Clk) and A='1')
    >>> B<='1';
    >>> end if;
    >>> end process Bp;
    >>>

    [snip]
    > My problem still remains.How do I update B once A has been updated,
    > before the next positive edge.


    Solution: put the stuff in one process, make A a variable.

    Think in hardware. What you wrote down originally are two flip-flops (Ap
    and Bp). You want to clock in the updated value of Ap into Bp. That does
    not make sense. If it does, Ap should not have been a flip-flop in the
    first place.

    Paul.
     
    Paul Uiterlinden, Oct 13, 2004
    #5
  6. On Wed, 13 Oct 2004 11:12:24 +0200, VHDL User <>
    wrote:

    >
    >
    >On Wed, 13 Oct 2004, rickman wrote:
    >
    >> VHDL User wrote:


    >> Once all the events scheduled for zero delta time are run, then the
    >> processes that were scheduled for 1 delta time are run and so on until
    >> no more delta time events are queued and the simulator then looks at the
    >> next real time event.

    >
    > Precisely. I have mentioned in my post that due to simulation
    >delta cycle,A will be updated only 1 delta delay later,and hence B will
    >always read the old value of A.My problem is how to change B based on new
    >value of A before next positive edge.


    If you want this to work in real hardware, I think the only way is to
    combine both A and B into the same process, so they react to the same
    event. (And then use a variable A_int inside the process for A, so that
    B sees the new value of that internal variable, not the "old" value of
    A. Assign A_int to A somewhere in the process)

    If you are simply doing simulation, you can add "clock skew" to B by
    clocking B off a separate clock signal, ClkB, and assigning ClkB <= Clk;
    This introduces a race condition and causes much head-scratching later.
    (I found this inside a memory simulation model recently. I changed a
    signal type, deleting an old assignment for type conversion purposes.
    So, having advanced my data by 1 delta cycle, the simulation results
    changed by an entire clock cycle!)

    - Brian
     
    Brian Drummond, Oct 13, 2004
    #6
  7. VHDL User

    rickman Guest

    VHDL User wrote:
    >
    > Precisely. I have mentioned in my post that due to simulation
    > delta cycle,A will be updated only 1 delta delay later,and hence B will
    > always read the old value of A.My problem is how to change B based on new
    > value of A before next positive edge.


    You can't since the Bp FF is edge triggered and won't sample the other
    inputs until the next clock edge. If you want B to be updated anytime A
    changes, you should remove the clock reference.


    > My fear of a race condition was only for the hardware.In
    > simulation, delta delays ensure that no race conditions arise,but (as you
    > yourself pointed out ) in real time, the two signals get updated in "zero"
    > time.


    There will be no race condition in the hardware. Hardware always has
    delays. The only problem would be if the clock routing delay is more
    than the signal delay. In FPGAs the manufacturer assures this will not
    happen. In ASICs it is up to you.


    > My problem still remains.How do I update B once A has been
    > updated, before the next positive edge.


    Now I don't understand what you are trying to do. Your code describes
    two FFs, one a simple clocked FF which starts in some unknown state and
    transitions to a '1' on the first clock edge remaining there forever.
    The second FF does nothing until the Ap FF becomes a '1' and then does
    the same on the next clock edge (not the same one).

    What are you trying to do?


    --

    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, Oct 13, 2004
    #7
  8. VHDL User

    Element Blue Guest

    On Wed, 13 Oct 2004, rickman wrote:

    > VHDL User wrote:
    >>
    >> Precisely. I have mentioned in my post that due to simulation
    >> delta cycle,A will be updated only 1 delta delay later,and hence B will
    >> always read the old value of A.My problem is how to change B based on new
    >> value of A before next positive edge.

    >
    > You can't since the Bp FF is edge triggered and won't sample the other
    > inputs until the next clock edge. If you want B to be updated anytime A
    > changes, you should remove the clock reference.
    >
    >
    >> My fear of a race condition was only for the hardware.In
    >> simulation, delta delays ensure that no race conditions arise,but (as you
    >> yourself pointed out ) in real time, the two signals get updated in "zero"
    >> time.

    >
    > There will be no race condition in the hardware. Hardware always has
    > delays. The only problem would be if the clock routing delay is more
    > than the signal delay. In FPGAs the manufacturer assures this will not
    > happen. In ASICs it is up to you.
    >
    >
    >> My problem still remains.How do I update B once A has been
    >> updated, before the next positive edge.

    >
    > Now I don't understand what you are trying to do. Your code describes
    > two FFs, one a simple clocked FF which starts in some unknown state and
    > transitions to a '1' on the first clock edge remaining there forever.
    > The second FF does nothing until the Ap FF becomes a '1' and then does
    > the same on the next clock edge (not the same one).
    >
    > What are you trying to do?


    Ok.What I had presented was "representative" code of my actual
    code, only to highlight the problem. Certainy the FFs dont stay there
    forever. My only concern was the clock edge where both signals are
    supposed to change. What I am trying to do is to ensure B changes before
    the next clock edge.


    >
    >
    > --
    >
    > 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
    >
     
    Element Blue, Oct 13, 2004
    #8
  9. VHDL User

    rickman Guest

    Element Blue wrote:
    >
    > Ok.What I had presented was "representative" code of my actual
    > code, only to highlight the problem. Certainy the FFs dont stay there
    > forever. My only concern was the clock edge where both signals are
    > supposed to change. What I am trying to do is to ensure B changes before
    > the next clock edge.


    Then Bp should not be a clocked process. By definition a clocked
    process only changes on the clock edge.

    My question is not about your sample code, but I don't understand what
    you are trying to do with these two signals. If you want B to change
    immediately on A changing, why do you put it in a clocked process? I
    think I am missing something.

    --

    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, Oct 13, 2004
    #9
  10. VHDL User

    Ken Smith Guest

    In article <>,
    Element Blue <> wrote:
    [...]
    >Ok.What I had presented was "representative" code of my actual
    >code, only to highlight the problem. Certainy the FFs dont stay there
    >forever. My only concern was the clock edge where both signals are
    >supposed to change. What I am trying to do is to ensure B changes before
    >the next clock edge.


    Can't you code "B" as combinatorial logic?

    --
    --
    forging knowledge
     
    Ken Smith, Oct 13, 2004
    #10
  11. VHDL User

    Element Blue Guest

    On Wed, 13 Oct 2004, rickman wrote:

    > My question is not about your sample code, but I don't understand what
    > you are trying to do with these two signals. If you want B to change
    > immediately on A changing, why do you put it in a clocked process? I
    > think I am missing something.

    Ok.I ll explain the context. There is a memory block which asserts
    signal A (Ready) on a clock edge. The reader block must assert the B
    (Upload) signal before the next clock edge,as that is when data appears on
    the data bus if Upload is high.Otherwise I incur a clock cycle delay.
    The read takes 2 cycles (2 words) and as soon as second word is read,
    Upload is to be deasserted irresepective of whether memory is ready for
    the next read or not ( irresp. of A),ie.,only 2 word accesses at a time.
    As you and Ken have pointed out, making Bp a non clocked process
    definitely helped. Thanks.

    >
    > --
    >
    > 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
    >
     
    Element Blue, Oct 14, 2004
    #11
  12. VHDL User

    rickman Guest

    Element Blue wrote:
    >
    > On Wed, 13 Oct 2004, rickman wrote:
    >
    > > My question is not about your sample code, but I don't understand what
    > > you are trying to do with these two signals. If you want B to change
    > > immediately on A changing, why do you put it in a clocked process? I
    > > think I am missing something.

    > Ok.I ll explain the context. There is a memory block which asserts
    > signal A (Ready) on a clock edge. The reader block must assert the B
    > (Upload) signal before the next clock edge,as that is when data appears on
    > the data bus if Upload is high.Otherwise I incur a clock cycle delay.
    > The read takes 2 cycles (2 words) and as soon as second word is read,
    > Upload is to be deasserted irresepective of whether memory is ready for
    > the next read or not ( irresp. of A),ie.,only 2 word accesses at a time.
    > As you and Ken have pointed out, making Bp a non clocked process
    > definitely helped. Thanks.


    This is an example where thinking not in the HDL, but in terms of
    hardware would have made your solution very obvious. What you are
    describing is a clocked signal, A, from the memory that must be gated
    (anded) with an enable, another clocked signal. You were trying to
    include the AND in the clocked signal while it should be a combinatorial
    function that combines the two clocked signals.

    I always think in terms of block level (sort of like RTL diagrams) logic
    and then write HDL to describe my digital blocks. I have seen some
    really bad code when people try to write HDL like it was software. :)

    --

    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, Oct 14, 2004
    #12
  13. Brian Drummond <> wrote in message news:<>...
    >
    > If you want this to work in real hardware, I think the only way is to
    > combine both A and B into the same process, so they react to the same
    > event. (And then use a variable A_int inside the process for A, so that
    > B sees the new value of that internal variable, not the "old" value of
    > A. Assign A_int to A somewhere in the process)
    >


    While I agree this is probably the best tactic I propose another
    alternative method which although not the best way, it is another way
    of looking at it. The way is to clock the process which calculates B
    on a negative edge. Therefore A process would be on the positive edge.
    Then on the negative edge B gets calculated which would fulfill your
    "B getting updated before the next positive clock edge".

    The problem with this idea is timing. You better have a small critical
    path from A to B. It has to have a delay of at most half the clock
    period. Also I'm not sure if you can constrain this later with the
    synthesis tool so it knows this half period constraint.

    - Paulo Valentim
     
    Paulo Valentim, Oct 14, 2004
    #13
  14. rickman wrote:

    > This is an example where thinking not in the HDL, but in terms of
    > hardware would have made your solution very obvious. What you are
    > describing is a clocked signal, A, from the memory that must be gated
    > (anded) with an enable, another clocked signal. You were trying to
    > include the AND in the clocked signal while it should be a combinatorial
    > function that combines the two clocked signals.
    >
    > I always think in terms of block level (sort of like RTL diagrams) logic
    > and then write HDL to describe my digital blocks. I have seen some
    > really bad code when people try to write HDL like it was software. :)


    Yes, sometimes it is better to start with schematic entry.
    On the other hand, I have seen some really good code
    where the designer understands hardware and the
    HDL and the synchronous templates and data structures
    and algorithmic design.

    -- Mike Treseler
     
    Mike Treseler, Oct 14, 2004
    #14
  15. VHDL User

    Element Blue Guest

    >
    > This is an example where thinking not in the HDL, but in terms of
    > hardware would have made your solution very obvious. What you are
    > describing is a clocked signal, A, from the memory that must be gated
    > (anded) with an enable, another clocked signal. You were trying to
    > include the AND in the clocked signal while it should be a combinatorial
    > function that combines the two clocked signals.


    Yeah.Things are a lot clearer now that you have put it like this.
    I never really did think of it this way. Infact this has simplified
    similar logic elsewhere in my system. I am still learning HDLs and this
    is an important lesson to me..thanks.

    >
    > I always think in terms of block level (sort of like RTL diagrams) logic
    > and then write HDL to describe my digital blocks. I have seen some
    > really bad code when people try to write HDL like it was software. :)
    >
    > --
    >
    > 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
    >
     
    Element Blue, Oct 15, 2004
    #15
  16. VHDL User

    ALuPin Guest

    Try to split the signals in an combinational part and one
    "registered" part.


    signal A, next_A : std_logic;
    signal B, next_B : std_logic;

    process(Clk)
    begin
    if rising_edge(Clk) then
    A <= next_A;
    end if;
    end process;

    process(Clk)
    begin
    if rising_edge(Clk) then
    B <= next_B;
    end if;
    end process;

    -- combinational process
    process(other_condition, A)
    begin
    next_A <= A;
    -- next_A <= '0';

    if other_condition='1' then
    next_A <= '1';
    end if;
    end process;

    -- combinational process
    process(next_A, B)
    begin
    next_B <= B;
    -- next_B <= '0';

    if next_A='1' then
    next_B <= '1';
    end if;
    end process;
     
    ALuPin, Oct 18, 2004
    #16
    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. Henning Bahr
    Replies:
    6
    Views:
    4,547
    S. Ramirez
    Jul 19, 2003
  2. Replies:
    4
    Views:
    741
    Peter Alfke
    Apr 27, 2006
  3. Ferdi Smit
    Replies:
    0
    Views:
    786
    Ferdi Smit
    Oct 10, 2005
  4. denish
    Replies:
    5
    Views:
    5,715
  5. KJ
    Replies:
    16
    Views:
    455
Loading...

Share This Page