problem with a shift register

Discussion in 'VHDL' started by dauzat.lilian@gmail.com, Oct 16, 2006.

  1. Guest

    Hello,

    I want to describe in VHDL a 8 bits shift register with synchronous
    load but I want it to shift every two rising edge of the master clock
    'clk' so I defined the signal clk05 which is supposed to be clk divided
    by 2.
    Here is my vhdl :

    entity man_encoder is
    port(
    din : in std_logic_vector(7 downto 0); -- parallel 8 bits input
    clk, wr, rst : in std_logic; -- wr:load din in input buffer,
    rst:asynchronous reset
    mdo, ready : out std_logic -- mdo:encoder output
    );
    end man_encoder;

    architecture Behavioral of man_encoder is
    signal clk05 : std_logic;
    signal wr1 : std_logic;
    signal dserial : std_logic;
    signal din_sig : std_logic_vector(7 downto 0);
    signal buff : std_logic_vector(7 downto 0);

    begin
    din_sig <= din;
    mdo <= buff(7);

    -- wr positive edge detector
    process(clk, rst, wr)
    begin
    if (rst='1') then
    wr1 <= '1';
    elsif (clk'event and clk='1') then
    wr1 <= wr;
    end if;
    end process;

    -- clock divider (/2)
    process(clk, rst)
    begin
    if (rst='1') then
    clk05 <= '0';
    elsif (clk'event and clk='1') then
    clk05 <= not(clk05);
    end if;
    end process;

    -- shift register
    process(din_sig, wr, wr1, clk)
    begin
    if (rst='1') then
    buff <= (others=>'0');
    elsif (clk'event and clk='1') then
    if (clk05='1') then
    if (wr='1' and wr1='0') then
    buff <= din_sig;
    else
    buff <= buff(6 downto 0) & '0';
    end if;
    end if;
    end if;
    end process;
    dserial <= buff(7);

    end Behavioral;

    My problem is the following : the register "buff" is shift on falling
    edge of clk05 and I want it on the rising edge of clk05.

    Could anyone help me ?

    Thanks a lot
    Lilian
    , Oct 16, 2006
    #1
    1. Advertising

  2. Guest

    Try this :
    process(clk,rst)
    begin
    if (rst='1') then
    buff <= (others=>'0');
    clk05_1 <= '0';
    elsif (clk'event and clk='1') then
    clk_05_1 <= clk_05;
    if (clk05='1' and clk05_1='0') then
    if (wr='1' and wr1='0') then
    buff <= din_sig;
    else
    buff <= buff(6 downto 0) & '0';
    end if;
    end if;
    end if;
    end process;
    , Oct 16, 2006
    #2
    1. Advertising

  3. TigerJade Guest

    What happens if you simply change
    if (clk05='1') then
    to
    if (clk05='0') then ?

    wrote:
    > Hello,
    >
    > I want to describe in VHDL a 8 bits shift register with synchronous
    > load but I want it to shift every two rising edge of the master clock
    > 'clk' so I defined the signal clk05 which is supposed to be clk divided
    > by 2.
    > Here is my vhdl :
    >
    > entity man_encoder is
    > port(
    > din : in std_logic_vector(7 downto 0); -- parallel 8 bits input
    > clk, wr, rst : in std_logic; -- wr:load din in input buffer,
    > rst:asynchronous reset
    > mdo, ready : out std_logic -- mdo:encoder output
    > );
    > end man_encoder;
    >
    > architecture Behavioral of man_encoder is
    > signal clk05 : std_logic;
    > signal wr1 : std_logic;
    > signal dserial : std_logic;
    > signal din_sig : std_logic_vector(7 downto 0);
    > signal buff : std_logic_vector(7 downto 0);
    >
    > begin
    > din_sig <= din;
    > mdo <= buff(7);
    >
    > -- wr positive edge detector
    > process(clk, rst, wr)
    > begin
    > if (rst='1') then
    > wr1 <= '1';
    > elsif (clk'event and clk='1') then
    > wr1 <= wr;
    > end if;
    > end process;
    >
    > -- clock divider (/2)
    > process(clk, rst)
    > begin
    > if (rst='1') then
    > clk05 <= '0';
    > elsif (clk'event and clk='1') then
    > clk05 <= not(clk05);
    > end if;
    > end process;
    >
    > -- shift register
    > process(din_sig, wr, wr1, clk)
    > begin
    > if (rst='1') then
    > buff <= (others=>'0');
    > elsif (clk'event and clk='1') then
    > if (clk05='1') then
    > if (wr='1' and wr1='0') then
    > buff <= din_sig;
    > else
    > buff <= buff(6 downto 0) & '0';
    > end if;
    > end if;
    > end if;
    > end process;
    > dserial <= buff(7);
    >
    > end Behavioral;
    >
    > My problem is the following : the register "buff" is shift on falling
    > edge of clk05 and I want it on the rising edge of clk05.
    >
    > Could anyone help me ?
    >
    > Thanks a lot
    > Lilian
    TigerJade, Oct 16, 2006
    #3
  4. Guest

    Thanks for your answer but I still have the same problem.... :-(

    wrote:
    > Try this :
    > process(clk,rst)
    > begin
    > if (rst='1') then
    > buff <= (others=>'0');
    > clk05_1 <= '0';
    > elsif (clk'event and clk='1') then
    > clk_05_1 <= clk_05;
    > if (clk05='1' and clk05_1='0') then
    > if (wr='1' and wr1='0') then
    > buff <= din_sig;
    > else
    > buff <= buff(6 downto 0) & '0';
    > end if;
    > end if;
    > end if;
    > end process;
    , Oct 16, 2006
    #4
  5. Guest

    In this case my the register is completly out of order :-(

    Thanks

    TigerJade wrote:
    > What happens if you simply change
    > if (clk05='1') then
    > to
    > if (clk05='0') then ?
    >
    > wrote:
    > > Hello,
    > >
    > > I want to describe in VHDL a 8 bits shift register with synchronous
    > > load but I want it to shift every two rising edge of the master clock
    > > 'clk' so I defined the signal clk05 which is supposed to be clk divided
    > > by 2.
    > > Here is my vhdl :
    > >
    > > entity man_encoder is
    > > port(
    > > din : in std_logic_vector(7 downto 0); -- parallel 8 bits input
    > > clk, wr, rst : in std_logic; -- wr:load din in input buffer,
    > > rst:asynchronous reset
    > > mdo, ready : out std_logic -- mdo:encoder output
    > > );
    > > end man_encoder;
    > >
    > > architecture Behavioral of man_encoder is
    > > signal clk05 : std_logic;
    > > signal wr1 : std_logic;
    > > signal dserial : std_logic;
    > > signal din_sig : std_logic_vector(7 downto 0);
    > > signal buff : std_logic_vector(7 downto 0);
    > >
    > > begin
    > > din_sig <= din;
    > > mdo <= buff(7);
    > >
    > > -- wr positive edge detector
    > > process(clk, rst, wr)
    > > begin
    > > if (rst='1') then
    > > wr1 <= '1';
    > > elsif (clk'event and clk='1') then
    > > wr1 <= wr;
    > > end if;
    > > end process;
    > >
    > > -- clock divider (/2)
    > > process(clk, rst)
    > > begin
    > > if (rst='1') then
    > > clk05 <= '0';
    > > elsif (clk'event and clk='1') then
    > > clk05 <= not(clk05);
    > > end if;
    > > end process;
    > >
    > > -- shift register
    > > process(din_sig, wr, wr1, clk)
    > > begin
    > > if (rst='1') then
    > > buff <= (others=>'0');
    > > elsif (clk'event and clk='1') then
    > > if (clk05='1') then
    > > if (wr='1' and wr1='0') then
    > > buff <= din_sig;
    > > else
    > > buff <= buff(6 downto 0) & '0';
    > > end if;
    > > end if;
    > > end if;
    > > end process;
    > > dserial <= buff(7);
    > >
    > > end Behavioral;
    > >
    > > My problem is the following : the register "buff" is shift on falling
    > > edge of clk05 and I want it on the rising edge of clk05.
    > >
    > > Could anyone help me ?
    > >
    > > Thanks a lot
    > > Lilian
    , Oct 16, 2006
    #5
  6. Al Guest

    wrote:

    > -- shift register
    > process(din_sig, wr, wr1, clk)
    > begin
    > if (rst='1') then
    > buff <= (others=>'0');
    > elsif (clk'event and clk='1') then
    > if (clk05='1') then
    > if (wr='1' and wr1='0') then
    > buff <= din_sig;
    > else
    > buff <= buff(6 downto 0) & '0';
    > end if;
    > end if;
    > end if;
    > end process;
    > dserial <= buff(7);
    >
    > end Behavioral;
    >
    > My problem is the following : the register "buff" is shift on falling
    > edge of clk05 and I want it on the rising edge of clk05.
    >
    > Could anyone help me ?
    >
    > Thanks a lot
    > Lilian
    >


    I would do it in this way, so that you load it with one clock-cycle of
    wr and you will shift it out when clk05 is 0, that means that the value
    will be updated on the next rising_edge (clk) when the clk05 will be 1
    again.
    Try and let us know.

    process(din_sig, wr, wr1, clk)
    begin
    if (rst = '1') then
    buff <= (others => '0');
    elsif (clk'event and clk = '1') then
    if (wr = '1' and wr1 = '0') then
    buff <= din_sig;
    elsif clk05 = '0' then
    buff <= buff(6 downto 0) & '0';
    end if;
    end if;
    end process;
    dserial <= buff(7);


    --
    Alessandro Basili
    CERN, PH/UGC
    Hardware Designer
    Al, Oct 18, 2006
    #6
  7. Jim Lewis Guest

    Lilian,
    I think your design is correct. Let me explain.
    In RTL sim, Clk05 does not have any propagation delay.
    As a result, it looks like it rises at the same time as
    Clk. In a real design, Clk05 has a propagation delay
    relative to Clk. Since Clk05 is only half the frequency
    of Clk, it looks like you are shifting on the falling
    edge of Clk05, however, this is the earliest time at
    which you will see Clk rising and Clk05 a 1.

    For simulation visualization purposes, you might change:
    clk05 <= not(clk05);

    to:
    clk05 <= not(clk05) after tperiod_Clk/2 ; -- where tperiod_Clk = period of Clk.

    However, in general I recommend against using after.

    Cheers,
    Jim

    > Hello,
    >
    > I want to describe in VHDL a 8 bits shift register with synchronous
    > load but I want it to shift every two rising edge of the master clock
    > 'clk' so I defined the signal clk05 which is supposed to be clk divided
    > by 2.
    > Here is my vhdl :
    >
    > entity man_encoder is
    > port(
    > din : in std_logic_vector(7 downto 0); -- parallel 8 bits input
    > clk, wr, rst : in std_logic; -- wr:load din in input buffer,
    > rst:asynchronous reset
    > mdo, ready : out std_logic -- mdo:encoder output
    > );
    > end man_encoder;
    >
    > architecture Behavioral of man_encoder is
    > signal clk05 : std_logic;
    > signal wr1 : std_logic;
    > signal dserial : std_logic;
    > signal din_sig : std_logic_vector(7 downto 0);
    > signal buff : std_logic_vector(7 downto 0);
    >
    > begin
    > din_sig <= din;
    > mdo <= buff(7);
    >
    > -- wr positive edge detector
    > process(clk, rst, wr)
    > begin
    > if (rst='1') then
    > wr1 <= '1';
    > elsif (clk'event and clk='1') then
    > wr1 <= wr;
    > end if;
    > end process;
    >
    > -- clock divider (/2)
    > process(clk, rst)
    > begin
    > if (rst='1') then
    > clk05 <= '0';
    > elsif (clk'event and clk='1') then
    > clk05 <= not(clk05);
    > end if;
    > end process;
    >
    > -- shift register
    > process(din_sig, wr, wr1, clk)
    > begin
    > if (rst='1') then
    > buff <= (others=>'0');
    > elsif (clk'event and clk='1') then
    > if (clk05='1') then
    > if (wr='1' and wr1='0') then
    > buff <= din_sig;
    > else
    > buff <= buff(6 downto 0) & '0';
    > end if;
    > end if;
    > end if;
    > end process;
    > dserial <= buff(7);
    >
    > end Behavioral;
    >
    > My problem is the following : the register "buff" is shift on falling
    > edge of clk05 and I want it on the rising edge of clk05.
    >
    > Could anyone help me ?
    >
    > Thanks a lot
    > Lilian
    >



    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Oct 18, 2006
    #7
  8. Al Guest

    Jim Lewis wrote:
    > Lilian,
    > I think your design is correct. Let me explain.
    > In RTL sim, Clk05 does not have any propagation delay.
    > As a result, it looks like it rises at the same time as
    > Clk. In a real design, Clk05 has a propagation delay
    > relative to Clk. Since Clk05 is only half the frequency
    > of Clk, it looks like you are shifting on the falling
    > edge of Clk05, however, this is the earliest time at
    > which you will see Clk rising and Clk05 a 1.
    >

    I'm sorry but the design is not correct. It should be taken into account
    even at the functional level (even if this cannot be verified with a
    simulation) that a signal which changes on the event of a clock will
    have a delay.
    So what's the point of functional verification if it will not check your
    functionalities but some other's stuff functionalities?

    > For simulation visualization purposes, you might change:
    > clk05 <= not(clk05);
    >
    > to:
    > clk05 <= not(clk05) after tperiod_Clk/2 ; -- where tperiod_Clk = period
    > of Clk.


    I think this assumption is really misleading and would get you to the
    point that your functional code would be rather different from the
    synthesized code. And as you said:

    > in general I recommend against using after.


    I would raccomand to use post-synthesis and post-fitting simulation to
    really have an idea of what's going on.
    Functional verification might be useful to check some combinatorial
    logic, but do you think is needed when you need to check sequential
    logic if it doesn't take into account the way sequential logic works?
    I might be (as almost always...) wrong, but still (even if I already
    discussed this in another thread -see Libero 7.2 on comp.arch.fpga) I
    doubt that functional simulation can help that much.

    Al

    --
    Alessandro Basili
    CERN, PH/UGC
    Hardware Designer
    Al, Oct 19, 2006
    #8
  9. Jim Lewis Guest

    Al
    >> I think your design is correct. Let me explain.
    >> In RTL sim, Clk05 does not have any propagation delay.
    >> As a result, it looks like it rises at the same time as
    >> Clk. In a real design, Clk05 has a propagation delay
    >> relative to Clk. Since Clk05 is only half the frequency
    >> of Clk, it looks like you are shifting on the falling
    >> edge of Clk05, however, this is the earliest time at
    >> which you will see Clk rising and Clk05 a 1.
    >>

    > I'm sorry but the design is not correct. It should be taken into account
    > even at the functional level (even if this cannot be verified with a
    > simulation) that a signal which changes on the event of a clock will
    > have a delay.


    The signal has a delta cycle delay with respect to clock.
    This in some ways represents a unit propagation delay.
    Unfortunately you can't see it in the wave window of most
    simulators. You can see it in the list window.

    As a designer you have to understand that all outputs that are
    clocked are going to show up exactly this way. As a result,
    if you create a single clock wide enable signal, it is as if it
    has a very long setup and a very short hold and it is going to
    look like you are seeing it when it falls. This is the nature
    of an enable signal that comes out of a register. It is not
    a clock. You are not looking for a rising edge. Instead you
    are looking for a level when clock rises.

    When drawing them by hand, some people used to draw them
    this way on paper too - however then they would confuse
    themselves and others as to which cycle they were designing
    the signal to occur on. As a result, I would always draw
    them with a propagation delay. This is always clear about
    the cycle at which they are intended to be sampled.

    This is why I suggested injecting the delay - solely
    for visualization. It is safe to put a single delay
    like this on any register output. I would probably be more
    likely to use tperiod_Clk/10 as long as it does not round to 0.
    Note that I don't do this in my design practice as once you
    understand the nature of enable signals, it is easy to follow
    what is happening in simulation and I am too lazy to do
    all that typing.


    >> For simulation visualization purposes, you might change:
    >> clk05 <= not(clk05);
    >>
    >> to:
    >> clk05 <= not(clk05) after tperiod_Clk/2 ; -- where tperiod_Clk =
    >> period of Clk.

    >
    > I think this assumption is really misleading and would get you to the
    > point that your functional code would be rather different from the
    > synthesized code.


    As long as you only do one delay per register output you are safe.

    >
    >> in general I recommend against using after.

    >
    > I would raccomand to use post-synthesis and post-fitting simulation to
    > really have an idea of what's going on.

    Only the timing that comes out after place and route is done is
    relevant. Any timing from a separate synthesis tool is just an
    estimate.

    > Functional verification might be useful to check some combinatorial
    > logic, but do you think is needed when you need to check sequential
    > logic if it doesn't take into account the way sequential logic works?
    > I might be (as almost always...) wrong, but still (even if I already
    > discussed this in another thread -see Libero 7.2 on comp.arch.fpga) I
    > doubt that functional simulation can help that much.


    Functional simulation + safe coding styles + static timing analysis =
    design done

    Gate and timing simulations are insurance that you did not mess up in one
    of the above. I always do gate with at least nominal timing. I don't
    put alot of faith in full timing simulations as it is difficult to
    exercise a critical path in a critical way.

    I read your referenced article. Mike stated,
    "A post-layout sim is not always needed for a synchronous design."
    I would bet that he is doing functional sim and not post-synthesis sim.

    Cheers,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Oct 19, 2006
    #9
  10. Al Guest

    Jim Lewis wrote:
    >
    > When drawing them by hand, some people used to draw them
    > this way on paper too - however then they would confuse
    > themselves and others as to which cycle they were designing
    > the signal to occur on. As a result, I would always draw
    > them with a propagation delay. This is always clear about
    > the cycle at which they are intended to be sampled.


    Indeed that's how you should think about a registered signal and that is
    the point that Lilian missed in the very first place.

    >> I would raccomand to use post-synthesis and post-fitting simulation to
    >> really have an idea of what's going on.

    >
    > Only the timing that comes out after place and route is done is
    > relevant. Any timing from a separate synthesis tool is just an
    > estimate.


    is an estimation which takes into account clock-to-output delay, as the
    functional sim doesn't. Am I wrong?
    >
    > Functional simulation + safe coding styles + static timing analysis =
    > design done
    >


    Are you saying that the static timing analysis is easier to handle than
    running a post-layout sim? If you already have a testbench, which you do
    because you have already done a functional sim, isn't just easier to run
    the post-layout sim, instead of checking all the critical paths?
    I'm sorry but I don't see clearly the point.

    > I read your referenced article. Mike stated,
    > "A post-layout sim is not always needed for a synchronous design."
    > I would bet that he is doing functional sim and not post-synthesis sim.


    I really hope to gain that ability one day, now I'm too far behind! :)
    And surely this ng will help a lot.


    --
    Alessandro Basili
    CERN, PH/UGC
    Hardware Designer
    Al, Oct 20, 2006
    #10
  11. KJ Guest

    "Al" <> wrote in message
    news:eh9ss8$et5$...
    > Jim Lewis wrote:
    >>
    >> Functional simulation + safe coding styles + static timing analysis =
    >> design done
    >>

    >
    > Are you saying that the static timing analysis is easier to handle than
    > running a post-layout sim? If you already have a testbench, which you do
    > because you have already done a functional sim, isn't just easier to run
    > the post-layout sim, instead of checking all the critical paths?
    > I'm sorry but I don't see clearly the point.


    'Easier' or 'harder' is not point. A post route simulation does not in any
    way replace the need to perform static timing analysis. All a post-route
    simulation lets you do is run with all max, or all min or all typical times
    for all modelled delays. It doesn't let you do any combination of min/max
    times let alone all possible combinations of these times. That's what
    static timing analysis addresses.

    If you do not perform static timing analysis then you're just rolling the
    dice hoping that the timing actually works out. You're not performing the
    analysis that would tell you whether your timing will work out under all
    conditions (so you can fix it now if there is a problem).

    Assuming that you do perform static timing analysis then there is generally
    no value to performing post-route simulation. The reason is simply that if
    you performed the timing analysis correctly then you know that your design
    will work correctly for any combination of delays; the post-route simulation
    is simply selecting one particular combination of delays.

    If you run a post-route simulation and it runs across an error it either
    means
    - You didn't perform the timing analysis and there is a timing problem.
    - You did not perform timing analysis correctly and there is a timing
    problem.
    - Your simulation model that surrounds the design being tested is not
    accurately modelling input delays in to the design.
    - Your simulation model that surrounds the design being tested is not
    waiting for the appropriate delays before sampling the outputs.
    - You have multiple clocks in your design and you're simply seeing the
    result of clock domain crossing...which by itself is not necessarily an
    error....depends on whether you've properly done the timing analysis.

    The other reason for running post-route simulation is to give management the
    warm fuzzies that you performed timing analysis correctly. As should be
    clear by now, successful post-route sim does not imply that the timing will
    work, but failing a post-route sim in many cases says that you haven't done
    the timing analysis correctly and there may be a design problem.

    For the experienced designer, the post-route sim is mainly a check off item
    that gets done in the background at the end of the design cycle. For the
    less experienced it can give some valuable feedback on why performing static
    timing analysis is an important step.

    KJ
    KJ, Oct 20, 2006
    #11
  12. Al Guest

    KJ wrote:
    > "Al" <> wrote in message
    > news:eh9ss8$et5$...
    >
    >>Jim Lewis wrote:
    >>
    >>>Functional simulation + safe coding styles + static timing analysis =
    >>>design done
    >>>

    >>
    >>Are you saying that the static timing analysis is easier to handle than
    >>running a post-layout sim? If you already have a testbench, which you do
    >>because you have already done a functional sim, isn't just easier to run
    >>the post-layout sim, instead of checking all the critical paths?
    >>I'm sorry but I don't see clearly the point.

    >
    >
    > 'Easier' or 'harder' is not point. A post route simulation does not in any
    > way replace the need to perform static timing analysis. All a post-route
    > simulation lets you do is run with all max, or all min or all typical times
    > for all modelled delays. It doesn't let you do any combination of min/max
    > times let alone all possible combinations of these times. That's what
    > static timing analysis addresses.
    >
    > If you do not perform static timing analysis then you're just rolling the
    > dice hoping that the timing actually works out. You're not performing the
    > analysis that would tell you whether your timing will work out under all
    > conditions (so you can fix it now if there is a problem).
    >
    > Assuming that you do perform static timing analysis then there is generally
    > no value to performing post-route simulation. The reason is simply that if
    > you performed the timing analysis correctly then you know that your design
    > will work correctly for any combination of delays; the post-route simulation
    > is simply selecting one particular combination of delays.
    >
    > If you run a post-route simulation and it runs across an error it either
    > means
    > - You didn't perform the timing analysis and there is a timing problem.
    > - You did not perform timing analysis correctly and there is a timing
    > problem.
    > - Your simulation model that surrounds the design being tested is not
    > accurately modelling input delays in to the design.
    > - Your simulation model that surrounds the design being tested is not
    > waiting for the appropriate delays before sampling the outputs.
    > - You have multiple clocks in your design and you're simply seeing the
    > result of clock domain crossing...which by itself is not necessarily an
    > error....depends on whether you've properly done the timing analysis.
    >
    > The other reason for running post-route simulation is to give management the
    > warm fuzzies that you performed timing analysis correctly. As should be
    > clear by now, successful post-route sim does not imply that the timing will
    > work, but failing a post-route sim in many cases says that you haven't done
    > the timing analysis correctly and there may be a design problem.
    >
    > For the experienced designer, the post-route sim is mainly a check off item
    > that gets done in the background at the end of the design cycle. For the
    > less experienced it can give some valuable feedback on why performing static
    > timing analysis is an important step.
    >
    > KJ
    >
    >


    Unfortunately all I know about logic is what I learned on the
    applications and never had the time to go that much into details, mainly
    because I'm developing a non time-critical application in which is not a
    matter of timing, as it is of reliability.
    Maybe I lack too much and I'd better study how to do static timing
    analysis. Anyway I appreciated the explanation and thanks to this ng I'm
    learning quicker.

    I'd like to excuse me with Jim because of that post, I simply didn't get
    your point because of my limited knowledge.

    Cheers

    Al

    --
    Alessandro Basili
    CERN, PH/UGC
    Hardware Designer
    Al, Oct 20, 2006
    #12
  13. Jim Lewis Guest


    >> Only the timing that comes out after place and route is done is
    >> relevant. Any timing from a separate synthesis tool is just an
    >> estimate.


    Al wrote:
    > is an estimation which takes into account clock-to-output delay, as the
    > functional sim doesn't. Am I wrong?


    As long as your static timing analysis shows that each
    register has less than one clock period delay, then
    your functional simulation is accurate.

    Gate sims tend to be much slower than RTL sims, so
    I try to limit myself to after place and route sim.
    However, if your design is small and its after synthesis
    sims run fast, there is no reason not to run them if
    they help you or your teammates understand what is
    going on better.

    Cheers,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Oct 20, 2006
    #13
  14. Al wrote:

    > ... I'm developing a non time-critical application in which is not a
    > matter of timing, as it is of reliability.
    > Maybe I lack too much and I'd better study how to do static timing
    > analysis.


    I expect that you are already running static timing
    with every place and route. Check the timing report.
    For quartus and ise, even if I don't set a single
    constraint, the tools will still find my clock,
    calculate Fmax, and show me my slowest nodes.

    Failing static timing is a design problem.
    Maybe I have to reduce the clock frequency
    or pipeline an offending path to use
    two ticks instead of one. Somehow I have
    to change the *design* and the problem
    is clearly defined.

    Failing a post-route netlist sim after
    passing the functional sim is a
    *process* problem, so it is an emergency.
    It should be a rare event, but if it ever happens,
    the reason must be found as a top priority.

    Such an error means that I either
    messed up a timing constraint *or*
    or i need to improve my design rule
    checking, *or* I need to add or delete
    a design rule.

    Design rules include my code and script templates
    (Jim's "safe coding styles") and the
    make, model and revision level of
    all tools involved in the production
    of the fpga download image.

    -- Mike Treseler
    Mike Treseler, Oct 20, 2006
    #14
  15. Jim Lewis Guest

    Al wrote:
    > Unfortunately all I know about logic is what I learned on the
    > applications and never had the time to go that much into details, mainly
    > because I'm developing a non time-critical application in which is not a
    > matter of timing, as it is of reliability.
    > Maybe I lack too much and I'd better study how to do static timing
    > analysis. Anyway I appreciated the explanation and thanks to this ng I'm
    > learning quicker.
    >
    > I'd like to excuse me with Jim because of that post, I simply didn't get
    > your point because of my limited knowledge.


    It is an easy and common thing to miss.

    This is how I learned about the value of verification
    vectors in a timing simulation.
    I did an ASIC for space. We were required to test
    on the ASIC test platform (fabrication test) the 6 slowest
    and one fastest path to/from each IO pin and internal to
    the design. We identified the paths with static timing analysis.
    _None_ of our normal verification vectors exercised
    the worst case paths. We had to tediously research the
    paths to figure out how to exercise them as we had to show
    pass and failure when they moved the timing checker on the
    test platform. After writing a couple we realized that this
    was a very timing consuming effort.

    Unfortunately we did not understand the impact of the
    requirement at the beginning of the program. Due to the
    time it was taking to write vectors, for some interfaces,
    we decided it would be faster to go back and redesign to
    register as much IO as possible at the chip interface.
    While this cost some time, it cost less time that writing
    the test vectors.

    Cheers,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Oct 20, 2006
    #15
  16. Al Guest

    Mike Treseler wrote:
    >
    > I expect that you are already running static timing
    > with every place and route. Check the timing report.
    > For quartus and ise, even if I don't set a single
    > constraint, the tools will still find my clock,
    > calculate Fmax, and show me my slowest nodes.


    Actually I use Designer, but it had never showed me problem about any
    timing. I've run through it sometimes, more because of curiosity than
    just a need.

    > Such an error means that I either
    > messed up a timing constraint *or*
    > or i need to improve my design rule
    > checking, *or* I need to add or delete
    > a design rule.


    So it is not just a "time constraint" issue, but most probably even a
    logic issue (as you said "reduce the clock frequency or pipeline an
    offending path to use two ticks instead of one").

    And most probably, as Jim said:

    > would be faster to go back and redesign


    instead of adding timing constraints which may turn out in some others
    critical paths. Is that correct?
    I think could be worthwhile to add some time constraints, but how do you
    get to the point when you realize that something must be changed in the
    logic? Is it experience?

    Anyway I learnt a lot from this chat and I thank you all guys (Jim, KJ
    and Mike). But it'll take time, so I would bother you again! ;-)
    Cheers

    Al
    Al, Oct 20, 2006
    #16
  17. Al wrote:

    > Actually I use Designer, but it had never showed me problem about any
    > timing. I've run through it sometimes, more because of curiosity than
    > just a need.


    Designer is a entry tool.
    Some other application is doing place and route.

    > So it is not just a "time constraint" issue, but most probably even a
    > logic issue (as you said "reduce the clock frequency or pipeline an
    > offending path to use two ticks instead of one").


    The two cases I discussed and should have numbered are:

    1. Failing static timing
    2. Failing a post-route netlist sim after
    passing passing static timing and a functional sim

    These don't overlap and neither do the causes.

    > Anyway I learnt a lot from this chat


    Me too. Good luck.


    -- Mike Treseler
    Mike Treseler, Oct 20, 2006
    #17
    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. Roberto Gallo

    Shift - byte[] buf shift

    Roberto Gallo, Jan 27, 2004, in forum: Java
    Replies:
    3
    Views:
    2,045
    Thomas Schodt
    Jan 27, 2004
  2. Indroneel Ganguly

    Shift Register Problem

    Indroneel Ganguly, May 5, 2006, in forum: VHDL
    Replies:
    9
    Views:
    2,195
    Indroneel Ganguly
    May 11, 2006
  3. Wenjie
    Replies:
    3
    Views:
    1,031
    Ron Samuel Klatchko
    Jul 11, 2003
  4. Replies:
    6
    Views:
    2,202
    Dave Higton
    Jun 30, 2006
  5. Santosh Nayak

    Left Shift / Right Shift Operators

    Santosh Nayak, Nov 30, 2006, in forum: C Programming
    Replies:
    16
    Views:
    1,446
    CBFalconer
    Nov 30, 2006
Loading...

Share This Page