Pulse stretching

Discussion in 'VHDL' started by Shannon, Feb 7, 2007.

  1. Shannon

    Shannon Guest

    Since everyone has been so helpful lately I thought I'd press my luck
    with a nagging problem I keep running into.

    Many times in a syncronous domain I end up with some "enable" pulse
    that is exactly one clock wide. Let's say I want to use that enable
    to start a counter for some reason. I want the counter to start
    counting when enable is true but keep counting until it's done. Let's
    say it's a down counter counting down to zero.

    I guess my question seems simple: How do I "latch" this enable
    pulse? It seems like anything I do is in danger of a race condition.
    If everything is syncronous, I can't "act" on anything until the next
    clock cycle after the front edge of "enable". But exactly at that
    moment, enable is going away! Seems scary.

    Mike Treseler once posted the following code to "stretch" a one-clock-
    wide pulse to two clocks wide:

    library ieee;
    use ieee.std_logic_1164.all;
    use ieee.numeric_std.all;

    entity stretch is
    port (
    clk : in std_logic;
    reset : in std_logic;
    trig : in std_logic;
    pulse : out std_logic
    );
    end stretch;


    architecture synth of stretch is
    begin
    process (reset, clk) is
    variable last_trig : std_logic;
    begin
    if reset = '0' then
    pulse <= '0';
    elsif clk'event and clk = '1' then
    pulse <= trig or last_trig; -- pulse for 10,11,or 01
    last_trig := trig; -- save trig
    end if;
    end process;
    end synth;


    Doesn't this suffer the same problem? "last_trig" is changing state
    right when "trig" is going away. Same for pulse: pulse wants to
    change state right as last_trig is going away.

    I'm sure the code works but it's the same problem I have. It just
    seems scary.

    Any ideas?

    Shannon
     
    Shannon, Feb 7, 2007
    #1
    1. Advertising

  2. Shannon

    Shannon Guest

    On Feb 7, 9:46 am, "Shannon" <> wrote:
    > Since everyone has been so helpful lately I thought I'd press my luck
    > with a nagging problem I keep running into.
    >
    > Many times in a syncronous domain I end up with some "enable" pulse
    > that is exactly one clock wide. Let's say I want to use that enable
    > to start a counter for some reason. I want the counter to start
    > counting when enable is true but keep counting until it's done. Let's
    > say it's a down counter counting down to zero.
    >
    > I guess my question seems simple: How do I "latch" this enable
    > pulse? It seems like anything I do is in danger of a race condition.
    > If everything is syncronous, I can't "act" on anything until the next
    > clock cycle after the front edge of "enable". But exactly at that
    > moment, enable is going away! Seems scary.
    >
    > Mike Treseler once posted the following code to "stretch" a one-clock-
    > wide pulse to two clocks wide:
    >
    > library ieee;
    > use ieee.std_logic_1164.all;
    > use ieee.numeric_std.all;
    >
    > entity stretch is
    > port (
    > clk : in std_logic;
    > reset : in std_logic;
    > trig : in std_logic;
    > pulse : out std_logic
    > );
    > end stretch;
    >
    > architecture synth of stretch is
    > begin
    > process (reset, clk) is
    > variable last_trig : std_logic;
    > begin
    > if reset = '0' then
    > pulse <= '0';
    > elsif clk'event and clk = '1' then
    > pulse <= trig or last_trig; -- pulse for 10,11,or 01
    > last_trig := trig; -- save trig
    > end if;
    > end process;
    > end synth;
    >
    > Doesn't this suffer the same problem? "last_trig" is changing state
    > right when "trig" is going away. Same for pulse: pulse wants to
    > change state right as last_trig is going away.
    >
    > I'm sure the code works but it's the same problem I have. It just
    > seems scary.
    >
    > Any ideas?
    >
    > Shannon


    I forgot to say - the reason I think it's scary is that it seems to be
    begging for a hold-time violation at the input to the flip-flops.

    Shannon
     
    Shannon, Feb 7, 2007
    #2
    1. Advertising

  3. Shannon

    Dave Pollum Guest

    On Feb 7, 12:46 pm, "Shannon" <> wrote:
    > Since everyone has been so helpful lately I thought I'd press my luck
    > with a nagging problem I keep running into.
    >
    > Many times in a syncronous domain I end up with some "enable" pulse
    > that is exactly one clock wide. Let's say I want to use that enable
    > to start a counter for some reason. I want the counter to start
    > counting when enable is true but keep counting until it's done. Let's
    > say it's a down counter counting down to zero.
    >
    > I guess my question seems simple: How do I "latch" this enable
    > pulse? It seems like anything I do is in danger of a race condition.
    > If everything is syncronous, I can't "act" on anything until the next
    > clock cycle after the front edge of "enable". But exactly at that
    > moment, enable is going away! Seems scary.
    >
    > Mike Treseler once posted the following code to "stretch" a one-clock-
    > wide pulse to two clocks wide:
    >
    > library ieee;
    > use ieee.std_logic_1164.all;
    > use ieee.numeric_std.all;
    >
    > entity stretch is
    > port (
    > clk : in std_logic;
    > reset : in std_logic;
    > trig : in std_logic;
    > pulse : out std_logic
    > );
    > end stretch;
    >
    > architecture synth of stretch is
    > begin
    > process (reset, clk) is
    > variable last_trig : std_logic;
    > begin
    > if reset = '0' then
    > pulse <= '0';
    > elsif clk'event and clk = '1' then
    > pulse <= trig or last_trig; -- pulse for 10,11,or 01
    > last_trig := trig; -- save trig
    > end if;
    > end process;
    > end synth;
    >
    > Doesn't this suffer the same problem? "last_trig" is changing state
    > right when "trig" is going away. Same for pulse: pulse wants to
    > change state right as last_trig is going away.
    >
    > I'm sure the code works but it's the same problem I have. It just
    > seems scary.
    >
    > Any ideas?
    >
    > Shannon


    Shannon said:
    Many times in a syncronous domain I end up with some "enable" pulse
    that is exactly one clock wide. Let's say I want to use that enable
    to start a counter for some reason. I want the counter to start
    counting when enable is true but keep counting until it's done. Let's
    say it's a down counter counting down to zero.

    So, create a "counter_enable" FF that is set to '1' by the enable
    signal and is cleared when the counter reaches 0. Naturally,
    "counter_enable" should be set to '0' by the reset signal.
    HTH
    -Dave Pollum
     
    Dave Pollum, Feb 7, 2007
    #3
  4. Shannon

    Shannon Guest

    On Feb 7, 10:01 am, "Dave Pollum" <> wrote:
    > On Feb 7, 12:46 pm, "Shannon" <> wrote:
    >
    >
    >
    >
    >
    > > Since everyone has been so helpful lately I thought I'd press my luck
    > > with a nagging problem I keep running into.

    >
    > > Many times in a syncronous domain I end up with some "enable" pulse
    > > that is exactly one clock wide. Let's say I want to use that enable
    > > to start a counter for some reason. I want the counter to start
    > > counting when enable is true but keep counting until it's done. Let's
    > > say it's a down counter counting down to zero.

    >
    > > I guess my question seems simple: How do I "latch" this enable
    > > pulse? It seems like anything I do is in danger of a race condition.
    > > If everything is syncronous, I can't "act" on anything until the next
    > > clock cycle after the front edge of "enable". But exactly at that
    > > moment, enable is going away! Seems scary.

    >
    > > Mike Treseler once posted the following code to "stretch" a one-clock-
    > > wide pulse to two clocks wide:

    >
    > > library ieee;
    > > use ieee.std_logic_1164.all;
    > > use ieee.numeric_std.all;

    >
    > > entity stretch is
    > > port (
    > > clk : in std_logic;
    > > reset : in std_logic;
    > > trig : in std_logic;
    > > pulse : out std_logic
    > > );
    > > end stretch;

    >
    > > architecture synth of stretch is
    > > begin
    > > process (reset, clk) is
    > > variable last_trig : std_logic;
    > > begin
    > > if reset = '0' then
    > > pulse <= '0';
    > > elsif clk'event and clk = '1' then
    > > pulse <= trig or last_trig; -- pulse for 10,11,or 01
    > > last_trig := trig; -- save trig
    > > end if;
    > > end process;
    > > end synth;

    >
    > > Doesn't this suffer the same problem? "last_trig" is changing state
    > > right when "trig" is going away. Same for pulse: pulse wants to
    > > change state right as last_trig is going away.

    >
    > > I'm sure the code works but it's the same problem I have. It just
    > > seems scary.

    >
    > > Any ideas?

    >
    > > Shannon

    >
    > Shannon said:
    > Many times in a syncronous domain I end up with some "enable" pulse
    > that is exactly one clock wide. Let's say I want to use that enable
    > to start a counter for some reason. I want the counter to start
    > counting when enable is true but keep counting until it's done. Let's
    > say it's a down counter counting down to zero.
    >
    > So, create a "counter_enable" FF that is set to '1' by the enable
    > signal and is cleared when the counter reaches 0. Naturally,
    > "counter_enable" should be set to '0' by the reset signal.
    > HTH
    > -Dave Pollum- Hide quoted text -
    >
    > - Show quoted text -


    Yes, of course that is what is done. But look closely at the timing
    with that solution.

    A clock edge occurs.
    A propagation delay later, enable goes true.
    The input to your "counter_enable" is now true and waiting for a clock
    edge.
    One clock later two things happen:
    1) "counter_enable" attempts to clock through it's input
    2) A propagation delay after the clock edge, enable goes away!
    All is fine as long as the propagation delay of enable is longer than
    the hold time of the "counter enable" FF.

    Doesn't that sound like dicey engineering?

    Have a look at what happens on the next clock edge when the counter
    counts for the first time. A lot happens on that next edge!

    Shannon
     
    Shannon, Feb 7, 2007
    #4
  5. Shannon wrote:

    > Doesn't that sound like dicey engineering?


    If a clock enable were in the clock path, that would be true.
    It is actually a mux control that sends either the input or Q
    to the D input.

    -- Mike Treseler
     
    Mike Treseler, Feb 8, 2007
    #5
  6. Shannon

    Ben Jones Guest

    Hi,

    "Shannon" <> wrote in message
    news:...
    > On Feb 7, 9:46 am, "Shannon" <> wrote:
    >> Since everyone has been so helpful lately I thought I'd press my luck
    >> with a nagging problem I keep running into.
    >>
    >> Many times in a syncronous domain I end up with some "enable" pulse
    >> that is exactly one clock wide. Let's say I want to use that enable
    >> to start a counter for some reason. I want the counter to start
    >> counting when enable is true but keep counting until it's done. Let's
    >> say it's a down counter counting down to zero.
    >>
    >> I guess my question seems simple: How do I "latch" this enable
    >> pulse? It seems like anything I do is in danger of a race condition.
    >> If everything is syncronous, I can't "act" on anything until the next
    >> clock cycle after the front edge of "enable". But exactly at that
    >> moment, enable is going away! Seems scary.


    >> .... <some code> ....


    >> Doesn't this suffer the same problem? "last_trig" is changing state
    >> right when "trig" is going away. Same for pulse: pulse wants to
    >> change state right as last_trig is going away.
    >>
    >> I'm sure the code works but it's the same problem I have. It just
    >> seems scary.

    >
    > I forgot to say - the reason I think it's scary is that it seems to be
    > begging for a hold-time violation at the input to the flip-flops.
    >
    > Shannon


    Just stop being scared of it and you'll be fine.

    Synchronous design is an abstraction - there is no need to think about
    physical issues such as clock skew, setup times, hold times, clock-to-out
    times and so on, except insomuch as they affect the amount of work you can
    reasonably expect to do in one clock cycle. The back-end implementation
    tools take care of all these things for you.

    Forget about edges and propagation delays. Your circuit consists of
    registered elements that hold the current state and get updated each clock
    cycle. You write some logic to decide what the new values held in these
    registered elements should be, based on their current values and the values
    of the inputs. That's all there is to it.

    -Ben-
     
    Ben Jones, Feb 8, 2007
    #6
  7. On 7 Feb 2007 11:56:17 -0800, "Shannon" <> wrote:

    >On Feb 7, 10:01 am, "Dave Pollum" <> wrote:
    >> On Feb 7, 12:46 pm, "Shannon" <> wrote:
    >>


    >Yes, of course that is what is done. But look closely at the timing
    >with that solution.


    >One clock later two things happen:
    > 1) "counter_enable" attempts to clock through it's input
    > 2) A propagation delay after the clock edge, enable goes away!
    >All is fine as long as the propagation delay of enable is longer than
    >the hold time of the "counter enable" FF.
    >
    >Doesn't that sound like dicey engineering?


    Sounds like, but isn't.

    It's VERY good that you are aware of the problem; because you will be on
    guard for situations where the conditions required for safety are
    missing or in doubt.

    For example, the enable is generated on one chip, and used on another.
    That can be made to work fine, but you must take care of various
    conditions yourself, when normally the tools take care of them for you.

    Consider your logic in an ideal FPGA, where the counter enable is
    generated *from* the clock. It cannot happen *before* the clock, and the
    generating logic has some finite propagation time; therefore (this being
    an ideal FPGA) the enable is guaranteed stable through the next clock.

    In a real FPGA, you design as if the above situation is true. Now
    typically there is a "clock skew" whereby the clock reaches different
    FFs at different times; and there is a propagation delay in the signal
    path (composed of both clock-to-output delay in one FF, and wire delays
    to another). Provided the propagation delay is *both* guaranteed longer
    than the clock skew, AND shorter than the clock period (!) the real
    world design is safe.

    That guarantee is the job of the FPGA supplier, (a) controlling the
    processes on his chip, (e.g. providing dedicated high speed routing for
    clock signals) and (b) ensuring his "static timing analysis" tools
    accurately predict the delays on the routed design, to give you
    confidence the above conditions are met.

    Now if you gate signals together to make a clock signal, the tools
    cannot route that clock through the dedicated fast clock lines, and you
    should expect interesting warnings from the tools about clock skew
    problems. Ignore those warnings at your peril...

    - Brian
     
    Brian Drummond, Feb 8, 2007
    #7
  8. Shannon

    Shannon Guest

    On Feb 8, 3:51 am, Brian Drummond <>
    wrote:
    > On 7 Feb 2007 11:56:17 -0800, "Shannon" <> wrote:
    >
    > >On Feb 7, 10:01 am, "Dave Pollum" <> wrote:
    > >> On Feb 7, 12:46 pm, "Shannon" <> wrote:

    >
    > >Yes, of course that is what is done. But look closely at the timing
    > >with that solution.
    > >One clock later two things happen:
    > > 1) "counter_enable" attempts to clock through it's input
    > > 2) A propagation delay after the clock edge, enable goes away!
    > >All is fine as long as the propagation delay of enable is longer than
    > >the hold time of the "counter enable" FF.

    >
    > >Doesn't that sound like dicey engineering?

    >
    > Sounds like, but isn't.
    >
    > It's VERY good that you are aware of the problem; because you will be on
    > guard for situations where the conditions required for safety are
    > missing or in doubt.
    >
    > For example, the enable is generated on one chip, and used on another.
    > That can be made to work fine, but you must take care of various
    > conditions yourself, when normally the tools take care of them for you.
    >
    > Consider your logic in an ideal FPGA, where the counter enable is
    > generated *from* the clock. It cannot happen *before* the clock, and the
    > generating logic has some finite propagation time; therefore (this being
    > an ideal FPGA) the enable is guaranteed stable through the next clock.
    >
    > In a real FPGA, you design as if the above situation is true. Now
    > typically there is a "clock skew" whereby the clock reaches different
    > FFs at different times; and there is a propagation delay in the signal
    > path (composed of both clock-to-output delay in one FF, and wire delays
    > to another). Provided the propagation delay is *both* guaranteed longer
    > than the clock skew, AND shorter than the clock period (!) the real
    > world design is safe.
    >
    > That guarantee is the job of the FPGA supplier, (a) controlling the
    > processes on his chip, (e.g. providing dedicated high speed routing for
    > clock signals) and (b) ensuring his "static timing analysis" tools
    > accurately predict the delays on the routed design, to give you
    > confidence the above conditions are met.
    >
    > Now if you gate signals together to make a clock signal, the tools
    > cannot route that clock through the dedicated fast clock lines, and you
    > should expect interesting warnings from the tools about clock skew
    > problems. Ignore those warnings at your peril...
    >
    > - Brian


    Ok, thanks for the replies. I'm going to keep an eye on things with
    the timing analyzer but like I've said before, I'm a hardware guy and
    all the time I'm thinking of the actual gates and FF and wires that
    are getting synthisized by the compiler.

    I don't know what planet you design on Ben, but you do have to worry
    about clock skew, propagation delays and setup and hold times. At the
    end of the day there are physical electrons and holes that have to get
    from a to b. It's just life. Ignoring it won't make it go away.
    Don't you ever wonder why the tool chain has all those tools for
    looking at it?

    Shannon
     
    Shannon, Feb 8, 2007
    #8
  9. Shannon

    Ben Jones Guest

    "Shannon" <> wrote in message
    news:...

    > I don't know what planet you design on Ben, but you do have to worry
    > about clock skew, propagation delays and setup and hold times. At the
    > end of the day there are physical electrons and holes that have to get
    > from a to b. It's just life. Ignoring it won't make it go away.


    Abstraction.
    Ab - strac - tion.

    "the act of considering something as a general quality or characteristic,
    apart from concrete realities, specific objects, or actual instances."

    Cornerstone of the real world.

    > Don't you ever wonder why the tool chain has all those tools for
    > looking at it?


    No, I don't "wonder", I use those tools every day. I know exactly what
    impact all these timing parameters of the real-life circuitry have on my
    higher-level design, and I worry about them as and when necessary. This is
    not sloppiness, this is the way engineering works. If you sat down to design
    a digital video processing system and the first thing you worry about is
    electrons and holes, you will not get very far.

    Cheers,

    -Ben-
     
    Ben Jones, Feb 8, 2007
    #9
  10. Shannon wrote:

    > I don't know what planet you design on Ben, but you do have to worry
    > about clock skew, propagation delays and setup and hold times.


    That was Brian, not Ben, and I also design on their planet.
    For FPGAs, all of the issues you raise can be covered
    by design rules, simulation and static timing.
    I see no advantage to going back to analog Spice
    simulations of individual MOS transistors and
    transmission lines.

    -- Mike Treseler

    ps: check out http://en.wikipedia.org/wiki/Synchronous_circuit
     
    Mike Treseler, Feb 8, 2007
    #10
  11. Shannon

    Shannon Guest

    On Feb 8, 9:21 am, Mike Treseler <> wrote:
    > Shannon wrote:
    > > I don't know what planet you design on Ben, but you do have to worry
    > > about clock skew, propagation delays and setup and hold times.

    >
    > That was Brian, not Ben, and I also design on their planet.
    > For FPGAs, all of the issues you raise can be covered
    > by design rules, simulation and static timing.
    > I see no advantage to going back to analog Spice
    > simulations of individual MOS transistors and
    > transmission lines.
    >
    > -- Mike Treseler
    >
    > ps: check outhttp://en.wikipedia.org/wiki/Synchronous_circuit


    I think you both take my comments to literally. What I was trying to
    say is that you cannot ignore the concerns I had in the original
    post. And both of you admit that you DO look at (and are concerned
    with): delays, skew, and hold times. Yet at the same time (if you
    want me to quote I will) you say "don't worry about it." Just let the
    tools "make it all work out." I just happen to think (read: my
    opinion is..) that relying on the tools blindly is asking for
    trouble. No, you don't have to do MOS simulations but I think that is
    a far cry from worrying about data disappearing from a FF just
    slightly after the flip flop clocks!!!!

    But this is a digretion that doesn't benifit anyone. Back to the
    problem at hand. Mike and Ben you can ignore this discussion since
    you don't pay attention to such things.

    Brian said:

    "Consider your logic in an ideal FPGA, where the counter enable is
    generated *from* the clock. It cannot happen *before* the clock, and
    the
    generating logic has some finite propagation time; therefore (this
    being
    an ideal FPGA) the enable is guaranteed stable through the next
    clock."

    This is true but my concern is not with the NEXT clock but with the
    CURRENT clock.
    To restate the problem: enable is generated from the clock as you say
    somewhere else in the code. In my example this means that enable will
    go FALSE on the SAME clock edge as the counter enable FF is trying to
    clock through the enable from the LAST clock edge. In ascii art:

    CLOCK _____^^^^^_____^^^^^_____^^^^^_____^^^^^_____
    ENABLE ______^^^^^^^^^^^_________________________
    CNT_ENA ______________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    _______________________|_________________________ edge of doom!

    If you open your basic TTL cook book from back in the day, this would
    be a huge NO-NO! The hold time of the "cnt_ena" FF would almost
    certainly be violated. What I'm hearing loud and clear from all of
    you is that I just shouldn't worry about it. "The tools will take
    care of it." Pardon me for being stuck in my ways but wouldn't it be
    keen if you had code that was GUARANTEED to not have a potential
    timing problem? That's all I was asking.

    I'll go back to closing my eyes and hoping for the best from the
    tools...

    Shannon
     
    Shannon, Feb 8, 2007
    #11
  12. Shannon

    Shannon Guest

    On Feb 8, 12:32 pm, "Shannon" <> wrote:
    > On Feb 8, 9:21 am, Mike Treseler <> wrote:
    >
    > > Shannon wrote:
    > > > I don't know what planet you design on Ben, but you do have to worry
    > > > about clock skew, propagation delays and setup and hold times.

    >
    > > That was Brian, not Ben, and I also design on their planet.
    > > For FPGAs, all of the issues you raise can be covered
    > > by design rules, simulation and static timing.
    > > I see no advantage to going back to analog Spice
    > > simulations of individual MOS transistors and
    > > transmission lines.

    >
    > > -- Mike Treseler

    >
    > > ps: check outhttp://en.wikipedia.org/wiki/Synchronous_circuit

    >
    > I think you both take my comments to literally. What I was trying to
    > say is that you cannot ignore the concerns I had in the original
    > post. And both of you admit that you DO look at (and are concerned
    > with): delays, skew, and hold times. Yet at the same time (if you
    > want me to quote I will) you say "don't worry about it." Just let the
    > tools "make it all work out." I just happen to think (read: my
    > opinion is..) that relying on the tools blindly is asking for
    > trouble. No, you don't have to do MOS simulations but I think that is
    > a far cry from worrying about data disappearing from a FF just
    > slightly after the flip flop clocks!!!!
    >
    > But this is a digretion that doesn't benifit anyone. Back to the
    > problem at hand. Mike and Ben you can ignore this discussion since
    > you don't pay attention to such things.
    >
    > Brian said:
    >
    > "Consider your logic in an ideal FPGA, where the counter enable is
    > generated *from* the clock. It cannot happen *before* the clock, and
    > the
    > generating logic has some finite propagation time; therefore (this
    > being
    > an ideal FPGA) the enable is guaranteed stable through the next
    > clock."
    >
    > This is true but my concern is not with the NEXT clock but with the
    > CURRENT clock.
    > To restate the problem: enable is generated from the clock as you say
    > somewhere else in the code. In my example this means that enable will
    > go FALSE on the SAME clock edge as the counter enable FF is trying to
    > clock through the enable from the LAST clock edge. In ascii art:
    >
    > CLOCK _____^^^^^_____^^^^^_____^^^^^_____^^^^^_____
    > ENABLE ______^^^^^^^^^^^_________________________
    > CNT_ENA ______________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >
    > _______________________|_________________________ edge of doom!
    >
    > If you open your basic TTL cook book from back in the day, this would
    > be a huge NO-NO! The hold time of the "cnt_ena" FF would almost
    > certainly be violated. What I'm hearing loud and clear from all of
    > you is that I just shouldn't worry about it. "The tools will take
    > care of it." Pardon me for being stuck in my ways but wouldn't it be
    > keen if you had code that was GUARANTEED to not have a potential
    > timing problem? That's all I was asking.
    >
    > I'll go back to closing my eyes and hoping for the best from the
    > tools...
    >
    > Shannon


    Ok, the ascii art didn't work out. CNT_ENA is supposed to be rising
    on the same clock edge as ENABLE is falling.
     
    Shannon, Feb 8, 2007
    #12
  13. Shannon

    Ben Jones Guest

    "Shannon" <> wrote in message
    news:...
    > On Feb 8, 12:32 pm, "Shannon" <> wrote:
    >> On Feb 8, 9:21 am, Mike Treseler <> wrote:
    >> > For FPGAs, all of the issues you raise can be covered
    >> > by design rules, simulation and static timing.
    >> > I see no advantage to going back to analog Spice
    >> > simulations of individual MOS transistors and
    >> > transmission lines.


    >> I just happen to think (read: my
    >> opinion is..) that relying on the tools blindly is asking for
    >> trouble. No, you don't have to do MOS simulations but I think that is
    >> a far cry from worrying about data disappearing from a FF just
    >> slightly after the flip flop clocks!!!!


    Then don't rely on the tools blindly - do it with your eyes open.

    There are basically just two ways these low-level properties of the FF
    circuits (which incidentally are a far cry from anything you'll find in a
    TTL databook) manifest themselves at the "synchronous design" abstraction
    level:

    (1) A delay at the start of the clock cycle before the contents of a
    register propagates out;

    (2) A delay at the end of the clock cycle before which the new value to go
    into a register must be ready.

    The problems of skew and race conditions between clock and data are
    mitigated down to negligible levels by the dedicated very-low-skew clock
    distribution hardware in an FPGA. Effectively all clock edges happen
    everywhere at the same time, to within a few ps (and the tools even know
    precisely about those few ps and take them into account). With a single
    clock in your circuit, all you have to concern yourself with is fitting all
    your logic into the time available in the clock cycle.

    So, say if you're designing a circuit to run at 200MHz, you have a 5ns clock
    period, of which say 300ps is taken up by the clock-to-out of the source
    register, 300ps by the setup time of the destination register, and the rest
    is available for logic delays and routing delays. That's it.

    > Pardon me for being stuck in my ways but wouldn't it be
    > keen if you had code that was GUARANTEED to not have a potential
    > timing problem?


    All circuits do! A circuit designed to run at 100MHz has a potential timing
    problem in that if someone decides to run it at 200MHz, it won't work
    because all the timing parameters of the synchronous elements it contains
    will be violated. The synthesis, mapping, placing and routing tools from
    FPGA/EDA vendors are all timing-aware, and the timing engines have margins
    built into them to account for process and temperature variations. And if
    you're really paranoid these can be de-rated further simply by speccing the
    static timing for 110MHz when you know you're only going to run at 100MHz.

    I don't think any of these assumptions are less reasonable than the
    assumption you are making that the value of every node inside your circuit
    is either a 0 or a 1. Do you worry that the signals in your circuit are
    really analogue, and they might have ringing if they toggle too fast or they
    might droop if the fanouts are too high and the driving transistors aren't
    strong enough? I don't. That level of abstraction is taken care of by the
    nice people who make the chips, so I don't have to worry about it.

    Cheers,

    -Ben-
     
    Ben Jones, Feb 9, 2007
    #13
  14. On 8 Feb 2007 12:32:08 -0800, "Shannon" <> wrote:

    >On Feb 8, 9:21 am, Mike Treseler <> wrote:
    >> Shannon wrote:


    >To restate the problem: enable is generated from the clock as you say
    >somewhere else in the code. In my example this means that enable will
    >go FALSE on the SAME clock edge as the counter enable FF is trying to
    >clock through the enable from the LAST clock edge.


    not ON; but AFTER the same clock edge. Some guaranteed time after, in
    the common case. Some guaranteed time _greater_ than the clock skew.

    >If you open your basic TTL cook book from back in the day, this would
    >be a huge NO-NO! The hold time of the "cnt_ena" FF would almost
    >certainly be violated.


    Depends on the MINIMUM clk-out time of the previous stage. Which
    typically wasn't specified or guaranteed; therfore you couldn't
    undertake the same analysis by hand, which the tools now do for you.

    >What I'm hearing loud and clear from all of
    >you is that I just shouldn't worry about it. "The tools will take
    >care of it."


    Or warn you if they can't (e.g. gated clocks).

    You DO have to pay attention at the I/O pins, which interface to other
    devices. IO blocks usually have provision (such as IOBDELAY) to allow
    meeting timings too.

    - Brian
     
    Brian Drummond, Feb 9, 2007
    #14
  15. Shannon

    Shannon Guest

    On Feb 9, 7:37 am, Brian Drummond <>
    wrote:
    > On 8 Feb 2007 12:32:08 -0800, "Shannon" <> wrote:
    >
    > >On Feb 8, 9:21 am, Mike Treseler <> wrote:
    > >> Shannon wrote:

    > >To restate the problem: enable is generated from the clock as you say
    > >somewhere else in the code. In my example this means that enable will
    > >go FALSE on the SAME clock edge as the counter enable FF is trying to
    > >clock through the enable from the LAST clock edge.

    >
    > not ON; but AFTER the same clock edge. Some guaranteed time after, in
    > the common case. Some guaranteed time _greater_ than the clock skew.
    >
    > >If you open your basic TTL cook book from back in the day, this would
    > >be a huge NO-NO! The hold time of the "cnt_ena" FF would almost
    > >certainly be violated.

    >
    > Depends on the MINIMUM clk-out time of the previous stage. Which
    > typically wasn't specified or guaranteed; therfore you couldn't
    > undertake the same analysis by hand, which the tools now do for you.
    >
    > >What I'm hearing loud and clear from all of
    > >you is that I just shouldn't worry about it. "The tools will take
    > >care of it."

    >
    > Or warn you if they can't (e.g. gated clocks).
    >
    > You DO have to pay attention at the I/O pins, which interface to other
    > devices. IO blocks usually have provision (such as IOBDELAY) to allow
    > meeting timings too.
    >
    > - Brian


    Ok, I think I'm getting it now. Thanks Brian. I guess the key
    sentence for me was "Some guaranteed time _greater_ than the clock
    skew."

    The key take-away for me is that the tool will do it's best to make it
    happen and report it when it can't. I can't help but feel let down by
    this however. When I solve engineering problems I like to find
    solutions that -- by their nature -- solve the problem by eliminating
    the source. It's nice when the tools I use can compensate for the
    design error but I always feel better when I have solved something in
    such a way as to not have to rely on the tools.

    Put another way, say you design an amplifier. You can trust that
    purchasing will buy 1% resistors for you so that your gain is what you
    designed it to be. OR... you can design an amplifier that can handle
    10% resistors and STILL provide the gain you wanted. I just hate to
    "trust" purchasing in the same way I hate to "trust" Quartus. If I
    had a way to make sure enable stuck around long enough to GUARANTEE it
    was there long enough for the next FF. For example, clocking the next
    FF with the falling edge of clock instead.

    Shannon
     
    Shannon, Feb 9, 2007
    #15
  16. Shannon

    KJ Guest


    >
    > Ok, I think I'm getting it now. Thanks Brian. I guess the key
    > sentence for me was "Some guaranteed time _greater_ than the clock
    > skew."
    >
    > The key take-away for me is that the tool will do it's best to make it
    > happen and report it when it can't. I can't help but feel let down by
    > this however. When I solve engineering problems I like to find
    > solutions that -- by their nature -- solve the problem by eliminating
    > the source. It's nice when the tools I use can compensate for the
    > design error but I always feel better when I have solved something in
    > such a way as to not have to rely on the tools.


    If you use a synchronous design method then it really has absolutely nothing
    to do with 'the tools'. The real engineering went into the design of the
    part itself....the flip flops, the clock distribution, etc. that is the
    reason it all works and one usually doesn't have to think about it too hard.
    It's not the tools, but the parts. The parts have things like global clock
    distribution and they know exactly where the flops and memories and anything
    else that 'could' be clocked are located and the engineering effort by the
    FPGA suppliers went into guaranteeing that no matter where you are on the
    device, any two clocked devices can reliably send a signal from any place to
    any other place without violating setup/hold requirements.

    What the tools really bring to the table is that they can quickly perform
    the full static timing analysis for you and let you know where timing breaks
    down because the logic path is too long for the given clock speed or I/O
    setup to Tco specifications that you require can or can not be met.

    Now when you start trying to implement things that deviate from the
    synchronous style (like generating gated clocks and such) you're starting to
    take on some design risk in many cases or making the design susceptible to
    working/not working when you make 'simple' design changes. Here the
    software tool is doing it's best and will still perform the timing analysis
    for you and dutifully report violations but you're making things harder than
    they generally need to be....either that or maybe an FPGA is not really the
    proper thing to be implementing that particular design in since it doesn't
    lend itself to synchronous methods for whatever reason.

    > Put another way, say you design an amplifier. You can trust that
    > purchasing will buy 1% resistors for you so that your gain is what you
    > designed it to be. OR... you can design an amplifier that can handle
    > 10% resistors and STILL provide the gain you wanted. I just hate to
    > "trust" purchasing in the same way I hate to "trust" Quartus.

    The only 'trust' is that they properly performed the timing analysis for
    you.....along with the complete blind faith that one must have that they
    translated your code into something that is functionally identical using
    LUTs, flops and memories.

    > If I
    > had a way to make sure enable stuck around long enough to GUARANTEE it
    > was there long enough for the next FF. For example, clocking the next
    > FF with the falling edge of clock instead.
    >

    Ask yourself then how would you go about performing static timing analysis
    inside the FPGA? You'd need to get all the info and assemble it and perform
    what should be the same calculations that the tool performs....how would you
    validate that you did it correctly?

    Again, for a synchronous method, you're trusting the tool to perform the
    analysis correctly more so than you are to implement it correctly. Correct
    implementation is something that came more from the IC guys that designed
    the gates, flops, etc. on the chip to begin with.

    Kevin Jennings
     
    KJ, Feb 10, 2007
    #16
  17. On Sat, 10 Feb 2007 02:21:30 GMT, "KJ" <> wrote:

    >
    >>
    >> Ok, I think I'm getting it now. Thanks Brian. I guess the key
    >> sentence for me was "Some guaranteed time _greater_ than the clock
    >> skew."
    >>
    >> The key take-away for me is that the tool will do it's best to make it
    >> happen and report it when it can't. I can't help but feel let down by
    >> this however.

    >
    >If you use a synchronous design method then it really has absolutely nothing
    >to do with 'the tools'. The real engineering went into the design of the
    >part itself....


    Agreed. The tools basically provide verification - including
    verification that you are using the part in a way that doesn't violate
    the constraints of that engineering (e.g. using pins that can't connect
    to clock routing, for clock signals)

    >Now when you start trying to implement things that deviate from the
    >synchronous style (like generating gated clocks and such) you're starting to
    >take on some design risk in many cases or making the design susceptible to
    >working/not working when you make 'simple' design changes.


    It's worth mentioning that the analysis is only as good as the
    constraints you supply - e.g. if you incorrectly specify I/O signal
    timings, the tool can only assure you those timings are met (or not!);
    not that the design will work.

    - Brian
     
    Brian Drummond, Feb 10, 2007
    #17
  18. On 9 Feb 2007 07:51:20 -0800, "Shannon" <> wrote:

    >On Feb 9, 7:37 am, Brian Drummond <>
    >wrote:
    >> On 8 Feb 2007 12:32:08 -0800, "Shannon" <> wrote:


    >The key take-away for me is that the tool will do it's best to make it
    >happen and report it when it can't. I can't help but feel let down by
    >this however. When I solve engineering problems I like to find
    >solutions that -- by their nature -- solve the problem by eliminating
    >the source.


    It never happens (if you are talking in absolute terms).

    >Put another way, say you design an amplifier. You can trust that
    >purchasing will buy 1% resistors for you so that your gain is what you
    >designed it to be. OR... you can design an amplifier that can handle
    >10% resistors and STILL provide the gain you wanted.


    Whether 1% or 10%, you still have to trust that the resistors are at
    least as accurate as that coloured stripe promises. (Unless you are in
    the medical or aerospace industries, when you may be obliged to test
    100%; this merely transfers the problem of trust to your test equipment,
    your calibration service, and ultimately the National Physical
    Laboratory)

    Of course you can establish a basis for that trust, by sampling a few
    resistors from each batch, by ISO 9000 paperwork, and/or by measuring
    the gain at test. If you find that trust misplaced, a good supplier will
    work to repair the situation.

    I don't think trusting the FPGA manufacturer's process and tools is any
    different. They stand by their process, and their tools agreement with
    it. This is an active process, especially with new devices - the tools
    rely on "speed files" which are - maybe not perfect - but guaranteed by
    the manufacturer. Often the first release of the speed files is
    conservative, and subsequent updates are relaxed as the manufacturer
    gains experience; or occasionally tightened if an unforeseen problem is
    encountered. The same is true of any printed datasheet...

    - Brian
     
    Brian Drummond, Feb 10, 2007
    #18
  19. Shannon

    asicbaba Guest

    On Feb 8, 2:46 am, "Shannon" <> wrote:
    > Since everyone has been so helpful lately I thought I'd press my luck
    > with a nagging problem I keep running into.
    >
    > Many times in a syncronous domain I end up with some "enable" pulse
    > that is exactly one clock wide. Let's say I want to use that enable
    > to start a counter for some reason. I want the counter to start
    > counting when enable is true but keep counting until it's done. Let's
    > say it's a down counter counting down to zero.
    >
    > I guess my question seems simple: How do I "latch" this enable
    > pulse? It seems like anything I do is in danger of a race condition.
    > If everything is syncronous, I can't "act" on anything until the next
    > clock cycle after the front edge of "enable". But exactly at that
    > moment, enable is going away! Seems scary.
    >
    > Mike Treseler once posted the following code to "stretch" a one-clock-
    > wide pulse to two clocks wide:
    >
    > library ieee;
    > use ieee.std_logic_1164.all;
    > use ieee.numeric_std.all;
    >
    > entity stretch is
    > port (
    > clk : in std_logic;
    > reset : in std_logic;
    > trig : in std_logic;
    > pulse : out std_logic
    > );
    > end stretch;
    >
    > architecture synth of stretch is
    > begin
    > process (reset, clk) is
    > variable last_trig : std_logic;
    > begin
    > if reset = '0' then
    > pulse <= '0';
    > elsif clk'event and clk = '1' then
    > pulse <= trig or last_trig; -- pulse for 10,11,or 01
    > last_trig := trig; -- save trig
    > end if;
    > end process;
    > end synth;
    >
    > Doesn't this suffer the same problem? "last_trig" is changing state
    > right when "trig" is going away. Same for pulse: pulse wants to
    > change state right as last_trig is going away.
    >
    > I'm sure the code works but it's the same problem I have. It just
    > seems scary.
    >
    > Any ideas?
    >
    > Shannon


    thsi is what you are looking at

    entity stretch is
    port (
    clk : in std_logic;
    > reset : in std_logic;
    > trig : in std_logic;
    > pulse : out std_logic
    > );
    > end stretch;
    >
    > architecture synth of stretch is

    signal count :std_logic_vector(3 downto 0);
    signal state :std_logic
    > begin
    > process (reset, clk) is
    > variable last_trig : std_logic;
    > begin
    > if reset = '0' then
    > pulse <= '0';

    state <= '0';
    count <= "1111";
    > elsif clk'event and clk = '1' then

    case state is
    when 0 =>
    if trig = '1'then
    count <= count - '1';
    state <= '1';
    else
    count <= "1111";
    end if
    pulse <= '0';
    when 1 =>
    if count = "0000" then
    state <= '0';
    pulse <= '1';
    else
    count <= count - '1';
    end if;
    end case

    > end if;
    > end process;
    > end synth;
     
    asicbaba, Feb 15, 2007
    #19
    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. Jamie
    Replies:
    4
    Views:
    1,062
    Thomas Stanka
    Oct 22, 2003
  2. The Weiss Family

    race conditions/pulse width

    The Weiss Family, Oct 16, 2004, in forum: VHDL
    Replies:
    6
    Views:
    746
    Jim Lewis
    Oct 19, 2004
  3. Replies:
    3
    Views:
    2,615
  4. Praveen

    pulse streatcher

    Praveen, May 6, 2005, in forum: VHDL
    Replies:
    2
    Views:
    821
    Ralf Hildebrandt
    May 7, 2005
  5. crazy_kuts

    VHDL PULSE COUNTER - PLS HELP

    crazy_kuts, Mar 30, 2006, in forum: VHDL
    Replies:
    1
    Views:
    3,355
    Dave Pollum
    Mar 30, 2006
Loading...

Share This Page