Immunizing Design/Simulation From Unknowns

Discussion in 'VHDL' started by M. Norton, Mar 1, 2013.

  1. M. Norton

    M. Norton Guest

    Alright, well in the interests of bettering my design process etc, I've been trying to do a lot more low level simulations, full chip simulations, fiddling with post-fit models, etc. I've got a little CPLD whose main purposein life is to condition the reset signals a microprocessor gets and runs the configuration signals that are active while the processor is held in reset. Nothing particularly magic, nothing exotic.

    My trouble is that even with good design, the simulation of this falls apart because unknowns are propagated when they really shouldn't be. I may be missing a trick with the simulator but thus far I haven't found how to control this.

    So for example, my RTL code for this little reset pulse stretch runs like this:

    -- All the resets that enter the CPLD are asynchronous with the clock. To
    -- alleviate metastability concerns and make setup times for the counter
    -- used to pulse stretch, the resets here are synchronized into the clock
    -- domain.
    RESET_SYNC : process (i_clk_66mhz)
    begin
    if rising_edge(i_clk_66mhz) then
    board_por_n_meta <= i_board_por_n;
    board_por_n <= board_por_n_meta;

    cop_hreset_n_meta <= i_cop_hreset_n;
    cop_hreset_n <= cop_hreset_n_meta;

    cop_sreset_n_meta <= i_cop_sreset_n;
    cop_sreset_n <= cop_sreset_n_meta;

    fpga_sreset_n_meta <= i_fpga_sreset_out_n;
    fpga_sreset_n <= fpga_sreset_n_meta;
    end if;
    end process RESET_SYNC;

    -- proc_hreset_n is used throughout for the configuration and here is
    -- assigned to an output port.
    o_proc_hreset_n <= proc_hreset_n;
    o_proc_sreset_n <= proc_sreset_n;

    -- Reset control needs to conform to the reset initialization timing listed
    -- in the hardware specification (Section 2.4). In short, HRESET must be
    -- asserted a minimum of 25 us. SRESET must be asserted a minimum of 3
    -- SYSCLK cycles (30 ns). Additionally, the input setup time for POR
    -- configuration with respect to HRESET deassertion is 4 SYSCLK cycles.
    -- Thus any time HRESET is asserted, it must stay in that state for at least
    -- 4 clocks before it may be deasserted.
    HRESET_CTRL : process (i_clk_66mhz)
    begin
    if rising_edge(i_clk_66mhz) then
    if (board_por_n = '0' or cop_hreset_n = '0') then
    -- Assertion may happen immediately, start a count to control
    -- assertion minimum time. 25 us is 1667 15 ns counts.
    proc_hreset_n <= '0';
    else
    -- Deassertion must only happen after the minimum delay was reached.
    if (proc_hreset_n = '0' and hreset_count = 0) then
    proc_hreset_n <= '1';
    end if;
    end if;
    end if;
    end process HRESET_CTRL;

    HRESET_STRETCH_COUNTER : process (i_clk_66mhz)
    begin
    if rising_edge(i_clk_66mhz) then
    if (proc_hreset_n = '0') then
    if (hreset_count /= 0) then
    hreset_count <= hreset_count - 1;
    end if;
    else
    hreset_count <= to_unsigned(1750,12);
    end if;
    end if;
    end process HRESET_STRETCH_COUNTER;

    Of course what I'm actually simulating is the post-fit primitives, but thisis the essential behavior. So, if the initial reset meets the setup conditions for its first register, the whole thing works beautifully. However Icannot be guaranteed that, so I run a simulation where the reset does NOT meet the setup conditions for the first register. Now, this is exactly whyI have metastability registers emplaced on the input. The leading edge through the register will resolve high/low but be unknown, but the second clock cycle will resolve low and we're off to the races.

    The problem is that this unknown propagates through the rest of the design and basically fouls up figuring anything out. So Modelsim naturally says "I don't know what this input is during this clock cycle. The counter mightstart counting down -- or the counter might stay put and start counting down the next cycle. The result is a big mess of red.

    From one point of view, this is exactly what it ought to show, but I don't know what that means from a verification standpoint. I can demonstrate that if the input signal meets the setup time and the design works properly post-fit with backannotated timing. If the input signal does not meet the setup time, I can demonstrate from the device final schematic that there are two registers with enough delay to account for the metastability settling time and no interior registers are exposed to this unknown state. That is more of an analytical proof and it'd be nice to show a more direct proof that the design will indeed perform correctly.

    So am I resigned to just having to prove the design through metastability analysis and leave simulation to the "well-behaved" cases? Or is there sometrick of design or Modelsim wizardry where I can put in a badly behaved case in Modelsim and see that my design works properly regardless?

    Thanks for any insight.

    Best regards,
    Mark Norton
    M. Norton, Mar 1, 2013
    #1
    1. Advertising

  2. M. Norton

    HT-Lab Guest

    On 01/03/2013 21:59, M. Norton wrote:
    ...snip

    > The problem is that this unknown propagates through the rest of the design and basically fouls up figuring anything out. So Modelsim naturally says "I don't know what this input is during this clock cycle. The counter might start counting down -- or the counter might stay put and start counting down the next cycle. The result is a big mess of red.
    >
    > From one point of view, this is exactly what it ought to show, but I don't know what that means from a verification standpoint. I can demonstrate that if the input signal meets the setup time and the design works properly post-fit with backannotated timing. If the input signal does not meet the setup time, I can demonstrate from the device final schematic that there are two registers with enough delay to account for the metastability settling time and no interior registers are exposed to this unknown state. That is more of an analytical proof and it'd be nice to show a more direct proof that the design will indeed perform correctly.
    >
    > So am I resigned to just having to prove the design through metastability analysis and leave simulation to the "well-behaved" cases? Or is there some trick of design or Modelsim wizardry where I can put in a badly behaved case in Modelsim and see that my design works properly regardless?


    If you are running Modelsim SE or Questa search the reference manual for
    tcheck_set and tcheck_status, these commands can be used to
    control/modify X generation per instance.

    Hans
    www.ht-lab.com

    >
    > Thanks for any insight.
    >
    > Best regards,
    > Mark Norton
    >
    HT-Lab, Mar 4, 2013
    #2
    1. Advertising

  3. M. Norton

    M. Norton Guest

    On Monday, March 4, 2013 3:16:50 AM UTC-6, HT-Lab wrote:
    > On 01/03/2013 21:59, M. Norton wrote:
    >
    > ..snip
    >
    >
    >
    > > The problem is that this unknown propagates through the rest of the design and basically fouls up figuring anything out. So Modelsim naturally says "I don't know what this input is during this clock cycle. The counter might start counting down -- or the counter might stay put and start counting down the next cycle. The result is a big mess of red.

    >
    > >

    >
    > > From one point of view, this is exactly what it ought to show, but I don't know what that means from a verification standpoint. I can demonstrate that if the input signal meets the setup time and the design works properly post-fit with backannotated timing. If the input signal does not meet the setup time, I can demonstrate from the device final schematic that thereare two registers with enough delay to account for the metastability settling time and no interior registers are exposed to this unknown state. Thatis more of an analytical proof and it'd be nice to show a more direct proof that the design will indeed perform correctly.

    >
    > >

    >
    > > So am I resigned to just having to prove the design through metastability analysis and leave simulation to the "well-behaved" cases? Or is there some trick of design or Modelsim wizardry where I can put in a badly behaved case in Modelsim and see that my design works properly regardless?

    >
    >
    >
    > If you are running Modelsim SE or Questa search the reference manual for
    >
    > tcheck_set and tcheck_status, these commands can be used to
    >
    > control/modify X generation per instance.


    Thanks to you and Brian for these tips. It occurred to me that really whatI needed to do was have two additional simulations where the metastabilityresolves high, and another where the metastability resolves low and then simulation can prove that the design is well behaved at these cases. I'll look into the tcheck items and the asynchronous register attribute and see if I can't create these verification cases. And agreed, the goal would be to only place it on a single point of entry and verify the rest of the design reacts appropriately.

    Best regards,
    Mark Norton
    M. Norton, Mar 4, 2013
    #3
  4. M. Norton

    GaborSzakacs Guest

    M. Norton wrote:
    > On Monday, March 4, 2013 3:16:50 AM UTC-6, HT-Lab wrote:
    >> On 01/03/2013 21:59, M. Norton wrote:
    >>
    >> ..snip
    >>
    >>
    >>
    >>> The problem is that this unknown propagates through the rest of the design and basically fouls up figuring anything out. So Modelsim naturally says "I don't know what this input is during this clock cycle. The counter might start counting down -- or the counter might stay put and start counting down the next cycle. The result is a big mess of red.
    >>> From one point of view, this is exactly what it ought to show, but I don't know what that means from a verification standpoint. I can demonstrate that if the input signal meets the setup time and the design works properly post-fit with backannotated timing. If the input signal does not meet the setup time, I can demonstrate from the device final schematic that there are two registers with enough delay to account for the metastability settling time and no interior registers are exposed to this unknown state. That is more of an analytical proof and it'd be nice to show a more direct proof that the design will indeed perform correctly.
    >>> So am I resigned to just having to prove the design through metastability analysis and leave simulation to the "well-behaved" cases? Or is there some trick of design or Modelsim wizardry where I can put in a badly behaved case in Modelsim and see that my design works properly regardless?

    >>
    >>
    >> If you are running Modelsim SE or Questa search the reference manual for
    >>
    >> tcheck_set and tcheck_status, these commands can be used to
    >>
    >> control/modify X generation per instance.

    >
    > Thanks to you and Brian for these tips. It occurred to me that really what I needed to do was have two additional simulations where the metastability resolves high, and another where the metastability resolves low and then simulation can prove that the design is well behaved at these cases. I'll look into the tcheck items and the asynchronous register attribute and see if I can't create these verification cases. And agreed, the goal would be to only place it on a single point of entry and verify the rest of the design reacts appropriately.
    >
    > Best regards,
    > Mark Norton


    Probably a better method is a simulation where "metastability," which in
    your case really means failure to meet setup/hold, resolves to a random
    1 or 0. This covers more cases than the all 1's or all 0's method.

    -- Gabor
    GaborSzakacs, Mar 4, 2013
    #4
    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. Kelvin
    Replies:
    0
    Views:
    926
    Kelvin
    Sep 14, 2003
  2. anupam
    Replies:
    4
    Views:
    848
    Allan Herriman
    Sep 3, 2004
  3. Preben Holm
    Replies:
    6
    Views:
    558
    Mike Treseler
    Apr 25, 2005
  4. Mirza
    Replies:
    11
    Views:
    2,013
    Paul Uiterlinden
    Jul 21, 2007
  5. jasperng
    Replies:
    0
    Views:
    1,286
    jasperng
    Nov 27, 2008
Loading...

Share This Page