Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Is this trick with reset acceptable?

Reply
Thread Tools

Is this trick with reset acceptable?

 
 
valentin tihomirov
Guest
Posts: n/a
 
      04-11-2004
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.


 
Reply With Quote
 
 
 
 
VhdlCohen
Guest
Posts: n/a
 
      04-12-2004
>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/ http://www.velocityreviews.com/forums/(E-Mail Removed)
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
------------------------------------------------------------------------------
 
Reply With Quote
 
 
 
 
valentin tihomirov
Guest
Posts: n/a
 
      04-12-2004
> >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....


 
Reply With Quote
 
Jim Lewis
Guest
Posts: n/a
 
      04-12-2004
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 (E-Mail Removed)
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 ;

 
Reply With Quote
 
valentin tihomirov
Guest
Posts: n/a
 
      04-12-2004
>
> 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?



 
Reply With Quote
 
Nicolas Matringe
Guest
Posts: n/a
 
      04-13-2004
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 -
|_| |_|_|\__|\___/

 
Reply With Quote
 
Jim Lewis
Guest
Posts: n/a
 
      04-14-2004
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 (E-Mail Removed)
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
You will not be able to reset the access - can't reset. jc MCAD 0 12-09-2007 08:58 PM
CISCO 7XX / 761 password reset or reset to factory defaults Philipp Flesch Cisco 3 06-18-2006 07:47 PM
profile trick, really anoying Splibbilla Firefox 2 06-29-2005 08:39 PM
so... what's the trick in getting wireless working on Server 2003?! pif Wireless Networking 1 10-13-2004 04:21 PM
A .Net trick everyday! Nuri Yilmaz ASP .Net 0 07-28-2004 01:46 PM



Advertisments