Reset Sync style

Discussion in 'VHDL' started by Rick North, Jan 18, 2006.

  1. Rick North

    Rick North Guest

    Hi all,

    For a FPGA design, I have been told that the way to stay away from harm
    is to implement the reset synchronously. In this way the reset signal
    will be taken in consideration for timing analysis.

    I have seen two ways of obtaining a synchron reset 1) and 2) below. The
    argument for 2) is that it will take less resource than 1). The only
    way I 'think' it will be true is for variables, which will result in
    combatorial nets. The nets would get a reset net as well but since it
    normally is placed between FF1-comb-FF2 the comb output is determined
    by FF1.

    Did some initial test Synth-P&R but did not see any big difference
    which was as I initially thought.

    What does your expertise say about 1) and 2) template? Is there a
    benefit of using 2) over 1)? This might be a "should I use Altera or
    Xilinx" question but I will stick my neck out anyway.

    Cheers,
    /Rick

    -----------------------------------------------------------------------
    1)
    P_Foo: process (clk) is
    begin -- process P_Foo
    if clk'event and clk = '1' then -- rising clock edge
    if reset = '1' then -- synchronous reset
    (active high)
    -- reset variable, signal
    else
    -- set signals and assign variables
    end if;
    end if;
    end process P_Foo;

    2)
    P_Foo: process (clk) is
    begin -- process P_Foo
    if clk'event and clk = '1' then -- rising clock edge
    -- set signals and assign variables
    if reset = '1' then -- synchronous reset
    (active high)
    -- reset variable, signal
    end if;
    end if;
    end process P_Foo;
     
    Rick North, Jan 18, 2006
    #1
    1. Advertising

  2. Rick North wrote:

    > For a FPGA design, I have been told that the way to stay away from harm
    > is to implement the reset synchronously. In this way the reset signal
    > will be taken in consideration for timing analysis.


    See my synthesis benchmarks of 3 templates in the reference design here:
    http://home.comcast.net/~mike_treseler/

    -- Mike Treseler
     
    Mike Treseler, Jan 18, 2006
    #2
    1. Advertising

  3. Rick North

    Rick North Guest

    Odd style, but refreshing to read. Haven't seen any similar piece of
    code to your UART example. I think I need to test this. Usually my main
    would be the largest part of my code with processed and instances. This
    way tips it all upside down. Real nice!

    But, you have two asynchron reset example and the synchron example is
    the same as template 1) in my post. Do you have any opinion on the two
    template 1) and 2) ?

    /rick
     
    Rick North, Jan 18, 2006
    #3
  4. Rick North

    Rick North Guest

    Odd style, but refreshing to read. Haven't seen any similar piece of
    code to your UART example. I think I need to test this. Usually my main
    would be the largest part of my code with processed and instances. This
    way tips it all upside down. Real nice!

    But, you have two asynchron reset example and the synchron example is
    the same as template 1) in my post. Do you have any opinion on the two
    template 1) and 2) ?

    /rick
     
    Rick North, Jan 18, 2006
    #4
  5. Rick North wrote:
    > Odd style, but refreshing to read. Haven't seen any similar piece of
    > code to your UART example. I think I need to test this.


    Please post the results.
    test_uart has been verified using
    modelsim and ncsim 05.10 or newer.

    uart has been synthesized without error
    for leonardo and quartus.
    If anyone has access to precision, synplicity or synopsis,
    please give it a quick spin.

    > Usually my main
    > would be the largest part of my code with processed and instances. This
    > way tips it all upside down. Real nice!


    Thanks.
    Tradition prefers a netlist of many processes and signals.
    I like a process of many variables and procedures,
    with the "think-hardware" part covered by the template.
    >
    > But, you have two asynchron reset example and the synchron example is
    > the same as template 1) in my post. Do you have any opinion on the two
    > template 1) and 2) ?


    You can read my comments at the end of the uart file.
    For brand X and A FPGAs the s_rst template is much slower than the
    other two. I now use the v_rst style for new designs.

    -- Mike Treseler
     
    Mike Treseler, Jan 18, 2006
    #5

  6. >> But, you have two asynchron reset example and the synchron example is
    >> the same as template 1) in my post. Do you have any opinion on the two
    >> template 1) and 2) ?


    Sorry. I missed the difference in your templates.
    On first reading it looks to me like
    your template 2 is logically equivalent to 1
    as long as the reset clause always happens last.
    Template 2 wastes some simulation cycles during
    reset since the non-reset code always executes.


    -- Mike Treseler
     
    Mike Treseler, Jan 18, 2006
    #6
  7. "Mike Treseler" <> writes:

    > Rick North wrote:
    > > Odd style, but refreshing to read. Haven't seen any similar piece of
    > > code to your UART example. I think I need to test this.

    >
    > Please post the results.
    > test_uart has been verified using
    > modelsim and ncsim 05.10 or newer.
    >
    > uart has been synthesized without error
    > for leonardo and quartus.
    > If anyone has access to precision, synplicity or synopsis,
    > please give it a quick spin.
    >


    OK, I did this, while waiting for something else to finish :) Seems
    to go through Synplify 8.0 (Pro if it matters) fine - haven't taken it
    on to PAR.

    template 0,2:
    94 LUTS, 216 MHz in a xc3s50tq144-4
    template 2:
    76 LUTS, 171MHz in a xc3s50tq144-4

    Cheers,
    Martin

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.trw.com/conekt
     
    Martin Thompson, Jan 18, 2006
    #7
  8. Rick North

    Guest

    Well, from my hardware implementation experience, using Xilinx ISE
    (always the updated version, now it is the 8.1i), at least Xilinx ISE
    would do the following with your code:

    1)

    P_Foo: process (clk) is
    begin -- process P_Foo
    if clk'event and clk = '1' then -- rising clock edge
    if reset = '1' then -- synchronous reset
    (active high)
    -- reset variable, signal
    else
    -- set signals and assign variables
    end if;
    end if;
    end process P_Foo;

    All the signals in " -- set signals and assign variables" would have
    in their clock enable logic the "reset" signal. Even those signals are
    not actually reseted would have the reset in their clock enable
    logic... I don´t really like that. I prefer what it does in 2)



    2)
    P_Foo: process (clk) is
    begin -- process P_Foo
    if clk'event and clk = '1' then -- rising clock edge
    -- set signals and assign variables
    if reset = '1' then -- synchronous reset
    (active high)
    -- reset variable, signal
    end if;
    end if;
    end process P_Foo;

    In this approach, Xilinx ISE would use the "reset" signal on clock
    enable or reset pins of only those signals that are reseted on " --
    reset variable, signal".
    Those signals that appears only on " -- set signals and assign
    variables" and not "-- reset variable, signal" won´t have the "reset"
    signal on their logic.
    For me, it makes much more sense...
     
    , Jan 18, 2006
    #8
  9. Rick North

    Rick North Guest

    Ok... here is the result.

    Synplify Pro 8.4
    Fanout guide 10000
    Pipelining
    Retiming
    Reasurce Sharing
    ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
    template_c : natural := 2; -- 0=a_rst, 1=s_rst, others=>v_rst

    Requested Estimated Requested Estimated
    Clock Clock
    Starting Clock Frequency Frequency Period Period
    Slack Type Group
    ------------------------------------------------------------------------------------------------------------------------
    uart|clock 479.8 MHz 407.8 MHz 2.084 2.452
    -0.368 inferred Autoconstr_clkgroup_0
    ========================================================================================================================




    Resource Usage Report for uart

    Mapping to part: xc4vlx15sf363-12
    Cell usage:
    FDC 33 uses
    FDCE 52 uses
    FDP 6 uses
    FDPE 2 uses
    MUXF5 3 uses
    MUXF6 1 use
    LUT2 20 uses
    LUT3 29 uses
    LUT4 77 uses

    I/O primitives: 22
    IBUF 13 uses
    OBUF 9 uses

    BUFGP 1 use

    I/O Register bits: 1
    Register bits not including I/Os: 92 (0%)

    Global Clock Buffers: 1 of 32 (3%)


    Mapping Summary:
    Total LUTs: 126 (1%)

    ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
    template_c : natural := 0; -- 0=a_rst, 1=s_rst, others=>v_rst

    Worst slack in design: -0.368

    Requested Estimated Requested Estimated
    Clock Clock
    Starting Clock Frequency Frequency Period Period
    Slack Type Group
    ------------------------------------------------------------------------------------------------------------------------
    uart|clock 479.8 MHz 407.8 MHz 2.084 2.452
    -0.368 inferred Autoconstr_clkgroup_0
    ========================================================================================================================

    Mapping to part: xc4vlx15sf363-12
    Cell usage:
    FDC 33 uses
    FDCE 52 uses
    FDP 6 uses
    FDPE 2 uses
    MUXF5 3 uses
    MUXF6 1 use
    LUT2 20 uses
    LUT3 29 uses
    LUT4 77 uses

    I/O primitives: 22
    IBUF 13 uses
    OBUF 9 uses

    BUFGP 1 use

    I/O Register bits: 1
    Register bits not including I/Os: 92 (0%)

    Global Clock Buffers: 1 of 32 (3%)


    Mapping Summary:
    Total LUTs: 126 (1%)

    ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
    ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
    template_c : natural := 1; -- 0=a_rst, 1=s_rst, others=>v_rst
    Worst slack in design: -0.420

    Requested Estimated Requested Estimated
    Clock Clock
    Starting Clock Frequency Frequency Period Period
    Slack Type Group
    ------------------------------------------------------------------------------------------------------------------------
    uart|clock 420.4 MHz 357.3 MHz 2.379 2.799
    -0.420 inferred Autoconstr_clkgroup_0
    ========================================================================================================================


    Mapping to part: xc4vlx15sf363-12
    Cell usage:
    FD 1 use
    FDR 63 uses
    FDRE 45 uses
    FDS 5 uses
    FDSE 2 uses
    MUXF5 2 uses
    MUXF6 1 use
    LUT1 1 use
    LUT2 14 uses
    LUT3 46 uses
    LUT4 42 uses

    I/O primitives: 22
    IBUF 13 uses
    OBUF 9 uses

    BUFGP 1 use

    I/O Register bits: 1
    Register bits not including I/Os: 115 (0%)

    Global Clock Buffers: 1 of 32 (3%)


    Mapping Summary:
    Total LUTs: 103 (0%)
     
    Rick North, Jan 18, 2006
    #9
  10. Thanks to Martin and Rick for the synthesis benchmarks.
    I'll update the comments with these results.

    -- Mike Treseler
     
    Mike Treseler, Jan 19, 2006
    #10
  11. Rick North

    Rick North Guest

    I like this reply. Is this ISE specific?

    If I would have a async reset and omitts a reset value for a signal or
    a variable Synplify will light up a warning which says "feedback mux
    created for s_Foo". Should I not expect to see the same in the sync
    reset case?

    P_Foo: process (clk, reset) is
    variable v_foo : std_logic;
    begin -- process P_Foo
    if reset = '1' then
    s_Foo <= '1'; -- if omitted s_Foo would create a feedback mux.
    v_Foo := '1';
    elsif clk'event and clk = '1' then -- rising clock edge
    v_Foo := s_a or s_b; -- s_a and s_b are port signals
    s_Foo <= v_Foo and s_c; -- s_c is a port signal
    end if;
    end process P_Foo;

    would it not create a feeback mux in this case`?
    P_Foo: process (clk) is
    variable v_foo : std_logic;
    begin -- process P_Foo
    if clk'event and clk = '1' then -- rising clock edge
    v_Foo := s_a or s_b; -- s_a and s_b are port signals
    s_Foo <= v_Foo and s_c; -- s_c is a port signal
    if reset = '1' then
    s_Foo <= '1'; -- s_Foo would it not create a feedback mux if
    omitted.
    v_Foo := '1';
    end if;
    end if;
    end process P_Foo;

    /Rick
     
    Rick North, Jan 19, 2006
    #11
  12. Mike Treseler wrote:
    > Thanks to Martin and Rick for the synthesis benchmarks.
    > I'll update the comments with these results.


    Done. See end of testbench here:
    http://home.comcast.net/~mike_treseler/

    -- Mike Treseler

    -------------------------------------------------------------------------------
    -- Synthesis Performance for default constraints Thu Jan 26 15:52:21 2006
    -------------------------------------------------------------------------------
    -- template_a_rst;
    -------------------------------------------------------------------------------
    -- Quartus 5.1 356 MHz 52 FF 72 ALUT eps15sf484c3
    -- Synplify Pro 8.4 408 MHz 93 FF 126 LUTS xc4vlx15sf363-12
    by Rick North
    -- Synplify Pro 8.0 216 MHz 94 LUTS xc3s50tq144-4
    by Martin Thompson
    -------------------------------------------------------------------------------
    -- template_s_rst;
    -------------------------------------------------------------------------------

    -- Quartus 5.1 317 MHz 50 FF 80 ALUT eps15sf484c3
    -- Synplify Pro 8.4 357 MHz 108 FF 126 LUTS xc4vlx15sf363-12
    retime R.North
    -- Synplify Pro 8.0 171 MHz 76 LUTS xc3s50tq144-4
    by Martin Thompson
    -------------------------------------------------------------------------------
    -- template_v_rst;
    -------------------------------------------------------------------------------

    -- Quartus 5.1 356 MHz 52 FF 72 ALUT eps15sf484c3
    -- Leo 2005b.24 est 194 MHz 48 FF 62 ALUT
    -- Synplify Pro 8.4 408 MHz 93 FF 126 LUTS xc4vlx15sf363-12
    retime R.North
    -- Synplify Pro 8.0 216 MHz 94 LUTS xc3s50tq144-4
    by Martin Thompson
    -------------------------------------------------------------------------------
     
    Mike Treseler, Jan 27, 2006
    #12
  13. Re: Reset Sync style: (source, not testbench)

    Mike Treseler wrote:

    >> Thanks to Martin and Rick for the synthesis benchmarks.
    >> I'll update the comments with these results.

    > Done. See end of testbench here:

    Sorry, that's end of reference design source here:

    > http://home.comcast.net/~mike_treseler/
    >
    > -- Mike Treseler
     
    Mike Treseler, Jan 27, 2006
    #13
  14. Rick North

    kameshwar_kaushik

    Joined:
    Jan 26, 2006
    Messages:
    6
    i think, in template 1, u synthesise 1 latch, where as in template 2, u synthesize 2 latches, this will add to delay's ..so, i think latch 1 will be better
     
    kameshwar_kaushik, Jan 29, 2006
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Niv
    Replies:
    9
    Views:
    836
    Mike Treseler
    Jan 5, 2006
  2. Ken Varn
    Replies:
    0
    Views:
    492
    Ken Varn
    Apr 26, 2004
  3. jim

    Reset on Style Property does not change Design View

    jim, Dec 2, 2004, in forum: ASP .Net Building Controls
    Replies:
    0
    Views:
    137
  4. jim
    Replies:
    0
    Views:
    160
  5. Trans
    Replies:
    2
    Views:
    495
    Trans
    Dec 12, 2005
Loading...

Share This Page