Is this trick with reset acceptable?

Discussion in 'VHDL' started by valentin tihomirov, Apr 11, 2004.

  1. REG: process (CLK)
    begin
    if ASYNC_RESET and RESET = '1' then
    REGs <= SEED;
    elsif Rising_Edge(Clk) then
    if ENABLE = '1' then
    if RESET = '1' then
    REGs <= SEED;
    else
    REGs <= REG_NEXT;
    end if;
    end if; -- enable
    end if; -- clk
    end process;

    ASYNC_RESET woulsd allow to configure sync/async reset by generic.
    valentin tihomirov, Apr 11, 2004
    #1
    1. Advertising

  2. valentin tihomirov

    VhdlCohen Guest

    >REG: process (CLK)
    > begin
    > if ASYNC_RESET and RESET = '1' then
    > REGs <= SEED;
    > elsif Rising_Edge(Clk) then
    > if ENABLE = '1' then
    > if RESET = '1' then
    > REGs <= SEED;
    > else
    > REGs <= REG_NEXT;
    > end if;
    > end if; -- enable
    > end if; -- clk
    > end process;
    >
    >ASYNC_RESET woulsd allow to configure sync/async reset by generic.
    >


    That would work, but it would also add a bit of extra logic. In addition you
    would get both asynchronous reset (if conditions are met) and synchronous reset
    when RESET is active.

    What about using the generate instead where the generic selects the concurrent
    process to pick (synchronous or asychronous model?

    ------------------------------------------------------------------------
    Ben Cohen Trainer, Consultant, Publisher (310) 721-4830
    http://www.vhdlcohen.com/
    Author of following textbooks:
    * Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition, 2004 isbn
    0-9705394-6-0
    * Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
    0-9705394-2-8
    * Component Design by Example ", 2001 isbn 0-9705394-0-1
    * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
    * VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
    ------------------------------------------------------------------------------
    VhdlCohen, Apr 12, 2004
    #2
    1. Advertising

  3. > >REG: process (CLK)
    > > begin
    > > if ASYNC_RESET and RESET = '1' then
    > > REGs <= SEED;
    > > elsif Rising_Edge(Clk) then
    > > if ENABLE = '1' then
    > > if RESET = '1' then
    > > REGs <= SEED;
    > > else
    > > REGs <= REG_NEXT;
    > > end if;
    > > end if; -- enable
    > > end if; -- clk
    > > end process;
    > >
    > >ASYNC_RESET woulsd allow to configure sync/async reset by generic.
    > >

    >
    > That would work, but it would also add a bit of extra logic. In addition

    you
    > would get both asynchronous reset (if conditions are met) and synchronous

    reset
    > when RESET is active.

    Indeed, if ASYNC_RESET is True then there is two resets in the circuit. This
    wouldn't add extra logic:

    if ASYNC_RESET and RESET = '1' then
    REGs <= SEED;
    elsif Rising_Edge(Clk) then
    if ENABLE = '1' then
    if not ASYNC_RESET and RESET = '1' then
    REGs <= SEED;
    elsif
    ...
    A never-called reset block will be optimized out.


    >
    > What about using the generate instead where the generic selects the

    concurrent
    > process to pick (synchronous or asychronous model?



    A_RST: if ASYNC_RESET generate
    process (CLK, RESET)
    if RESET = '1' then
    REGs <= SEED;
    elsif Rising_Edge(Clk) then
    if ENABLE = '1' then

    REGs <= REG_NEXT;
    end if;--en
    end if;--clk,rst
    end generate;

    S_RST: if not ASYNC_RESET generate
    process (CLK, RESET)
    elsif Rising_Edge(Clk) then
    if ENABLE = '1' then

    if RESET = '1' then
    REGs <= SEED;
    else
    REGs <= REG_NEXT;
    end if; -- rst
    end if; -- en
    end if; --clk
    end generate;

    Seems, it is more cumbersome (like copy&paste vs. polymorpism). But is
    anybody tells it is the only reliable solution....
    valentin tihomirov, Apr 12, 2004
    #3
  4. valentin tihomirov

    Jim Lewis Guest

    valentin tihomirov wrote:
    > Indeed, if ASYNC_RESET is True then there is two resets in the circuit. This
    > wouldn't add extra logic:
    >
    > if ASYNC_RESET and RESET = '1' then
    > REGs <= SEED;
    > elsif Rising_Edge(Clk) then
    > if ENABLE = '1' then
    > if not ASYNC_RESET and RESET = '1' then
    > REGs <= SEED;
    > elsif
    > ...
    > A never-called reset block will be optimized out.


    YMMV. I would not want to predict if this
    confused a synthesis tool or not and whether
    it would work on all synthesis tools.

    >>What about using the generate instead where the generic selects the

    >
    > concurrent
    >
    >>process to pick (synchronous or asychronous model?

    >
    > A_RST: if ASYNC_RESET generate
    > process (CLK, RESET)
    > if RESET = '1' then
    > REGs <= SEED;
    > elsif Rising_Edge(Clk) then
    > if ENABLE = '1' then
    >
    > REGs <= REG_NEXT;
    > end if;--en
    > end if;--clk,rst
    > end generate;
    >
    > S_RST: if not ASYNC_RESET generate
    > process (CLK, RESET)
    > elsif Rising_Edge(Clk) then
    > if ENABLE = '1' then
    >
    > if RESET = '1' then
    > REGs <= SEED;
    > else
    > REGs <= REG_NEXT;
    > end if; -- rst
    > end if; -- en
    > end if; --clk
    > end generate;
    >
    > Seems, it is more cumbersome (like copy&paste vs. polymorpism). But is
    > anybody tells it is the only reliable solution....


    This would work, but yikes, it is alot of typing.

    If you need the ability to switch between registers
    that are asynchronous reset and synchronous reset,
    how about a package with the registers implemented as
    procedures? Note this may not be synthesizable on all
    ASIC synthesis tools yet, but it is in the lastest
    version of 1076.6 (the IEEE VHDL RTL Synthesis standard).


    Packages shown below. Usage as follows:

    -- Asynchronous Reset
    use work.AsyncRegisterPkg.all ;
    ....
    DFFRLE(CLK, not RESET, ENABLE, REG_NEXT, REGs, SEED) ;


    -- Synchronous Reset
    use work.SyncRegisterPkg.all ;
    ....
    DFFRLE(CLK, not RESET, ENABLE, REG_NEXT, REGs, SEED) ;

    You can also call procedures by named association:

    DFFRLE(
    Clk => CLK,
    nReset => not RESET,
    enable => ENABLE,
    D => REG_NEXT,
    Q => REGs,
    ResetVal => SEED
    ) ;


    From a standards point of view, we could and probably
    should have things like this standardized and freely
    available. It would be nice if the register names were
    somewhat familiar to some group of people. Hence,
    have names similar to ASIC/FPGA library names or have
    names similar to older HDLs that had things like this
    (ie CUPL/ABLE/PALASM/...). To get these standardized
    it is a matter of getting users that are interested in
    working on them (I for one am interested, have some
    ideas, and have a reasonable understanding of how IEEE
    standards groups work - however - at least near term,
    I am tied up with VHDL-200X work).

    If you are following VHDL-200X, we do have a new feature
    that will help some with design wide package switching.
    Check out:
    http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/
    the proposal is FT16 - please note documentation on
    it is still a work in progress - so be kind in your
    constuctive comments.

    Package definitions follow for the above functionality.

    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
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



    package AsyncRegisterPkg is
    ....
    procedure DFFRLE(
    signal Clk : in Std_Logic ;
    nReset : in Std_Logic ;
    enable : in Std_Logic ;
    D : in Std_Logic ;
    signal Q : out Std_Logic ;
    ResetVal : in Std_logic := '0'
    ) ;

    procedure DFFRLE(
    signal Clk : in Std_Logic ;
    nReset : in Std_Logic ;
    enable : in Std_Logic ;
    D : in Std_Logic_Vector ;
    signal Q : out Std_Logic_vector ;
    ResetVal : in Std_Logic_Vector := (others => '0')
    ) ;


    end package ;

    package body AsyncRegisterPkg is
    ....

    procedure DFFRLE(
    signal Clk : in Std_Logic ;
    nReset : in Std_Logic ;
    enable : in Std_Logic ;
    D : in Std_Logic ;
    signal Q : out Std_Logic ;
    ResetVal : in Std_Logic := '0'
    ) is
    begin
    if nReset = '0' then
    Q <= ResetVal ;
    elsif rising_edge(Clk) then
    if enable = '1' then
    Q <= D;
    end if ;
    end if;
    end DFF;

    procedure DFFRLE(
    signal Clk : in Std_Logic ;
    nReset : in Std_Logic ;
    enable : in Std_Logic ;
    D : in Std_Logic_Vector ;
    signal Q : out Std_Logic_vector ;
    ResetVal : in Std_Logic_Vector := (others => '0')
    ) is
    begin
    if nReset = '0' then
    Q <= ResetVal ;
    elsif rising_edge(Clk) then
    if enable = '1' then
    Q <= D;
    end if ;
    end if;
    end DFF;
    end package ;


    package SyncRegisterPkg is
    ....
    procedure DFFRLE(
    signal Clk : in Std_Logic ;
    nReset : in Std_Logic ;
    enable : in Std_Logic ;
    D : in Std_Logic ;
    signal Q : out Std_Logic ;
    ResetVal : in Std_logic := '0'
    ) ;

    procedure DFFRLE(
    signal Clk : in Std_Logic ;
    nReset : in Std_Logic ;
    enable : in Std_Logic ;
    D : in Std_Logic_Vector ;
    signal Q : out Std_Logic_vector ;
    ResetVal : in Std_Logic_Vector := (others => '0')
    ) ;


    end package ;

    package body SyncRegisterPkg is
    ....

    procedure DFFRLE(
    signal Clk : in Std_Logic ;
    nReset : in Std_Logic ;
    enable : in Std_Logic ;
    D : in Std_Logic ;
    signal Q : out Std_Logic ;
    ResetVal : in Std_Logic := '0'
    ) is
    begin
    if rising_edge(Clk) then
    if nReset = '0' then
    Q <= ResetVal ;
    elsif enable = '1' then
    Q <= D;
    end if ;
    end if;
    end DFF;

    procedure DFFRLE(
    signal Clk : in Std_Logic ;
    nReset : in Std_Logic ;
    enable : in Std_Logic ;
    D : in Std_Logic_Vector ;
    signal Q : out Std_Logic_vector ;
    ResetVal : in Std_Logic_Vector := (others => '0')
    ) is
    begin
    if rising_edge(Clk) then
    if nReset = '0' then
    Q <= ResetVal ;
    elsif enable = '1' then
    Q <= D;
    end if ;
    end if;
    end DFF;
    end package ;
    Jim Lewis, Apr 12, 2004
    #4
  5. >
    > From a standards point of view, we could and probably
    > should have things like this standardized and freely
    > available. It would be nice if the register names were
    > somewhat familiar to some group of people. Hence,
    > have names similar to ASIC/FPGA library names or have
    > names similar to older HDLs that had things like this
    > (ie CUPL/ABLE/PALASM/...).

    How about Library of Parametrized Modules
    http://www.edif.org/lpmweb/index.html?
    valentin tihomirov, Apr 12, 2004
    #5
  6. Jim Lewis a écrit:
    > valentin tihomirov wrote:
    >

    [generate statements...]


    >> Seems, it is more cumbersome (like copy&paste vs. polymorpism). But is
    >> anybody tells it is the only reliable solution....

    >
    >
    > This would work, but yikes, it is alot of typing.


    This would work only with std_logic, not std_ulogic.

    --
    ____ _ __ ___
    | _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
    | | | | | (_| |_| | Invalid return address: remove the -
    |_| |_|_|\__|\___/
    Nicolas Matringe, Apr 13, 2004
    #6
  7. valentin tihomirov

    Jim Lewis Guest

    Nicolas Matringe wrote:

    > This would work only with std_logic, not std_ulogic.

    -- on the assumption you are referring to the subprogram
    -- approach I mentioned, ...
    With subprograms the functions can be overloaded so
    all appropriate types are handled.

    However, with std_logic and std_ulogic, separate functions
    are not required since they convert automatically - subtypes
    of the same type convert automatically. Std_logic is a
    subtype of std_ulogic. All types are subtypes of themselves.

    Your point is well made, however, as overloading would be
    needed for std_logic_vector and std_ulogic_vector.
    Overloading is one of the advantages of the subprogram
    approach.

    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, Apr 14, 2004
    #7
    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. .Net Sports
    Replies:
    2
    Views:
    838
    Craig Deelsnyder
    May 3, 2005
  2. steve

    acceptable way to program

    steve, Dec 31, 2004, in forum: Java
    Replies:
    34
    Views:
    1,019
    Haximus
    Feb 20, 2005
  3. (Pete Cresswell)
    Replies:
    8
    Views:
    447
    Duende
    Dec 23, 2004
  4. windandwaves
    Replies:
    7
    Views:
    9,308
    windandwaves
    Oct 25, 2005
  5. Lindon

    acceptable to mix C/C++?

    Lindon, Jul 2, 2003, in forum: C++
    Replies:
    16
    Views:
    530
    Alexander Terekhov
    Jul 7, 2003
Loading...

Share This Page