Generic controlling sync/async reset

Is it possible to use a generic to control how a piece of code is
reset?

i.e.
ENTITY...........................
GENERIC(
deglitch_depth : IN NATURAL := 3;
sync_reset : IN BOOLEAN := FALSE

);
PORT (
clk : IN std_logic;
reset_n : IN std_logic;
async_in : IN std_logic;
deglitched_out : OUT std_logic
);

ARCHITECTURE................
BEGIN ..................etc

PROCESS..................

IF sync_reset = TRUE THEN

IF reset_n = '0' THEN
signals <= '0';
ELSIF rising_edge(clk) THEN
signal assignments;
END IF;

ELSE -- sync_reset is FALSE

IF rising_edge(clk) THEN
IF reset_n = '0' THEN
signals <= '0';
ELSE
signal assignments;
END IF;
END IF;
END IF; -- (Generic).

The idea is to create a small block of code that is acceptable to many
users, but sometimes the reset has to be async & sometimes sync,
depending on where/how it's used.
Would this need a generate statement, or something else to get it to
work, if at all possible?

TIA, Niv.

Niv

>Is it possible to use a generic to control how a piece >of code is
>reset?

Sure

>The idea is to create a small block of code that is acceptable to many
>users, but sometimes the reset has to be async & sometimes sync,
>depending on where/how it's used.

Good

>Would this need a generate statement, or something >else to get it to
>work, if at all possible?

VHDL simulators should always accept this. However, synthesis tools can
have difficulties.

Another possibility is to use different architectures and VHDL
configurations (configuration sync/async).

Hubble.

Reiner Huober

Niv wrote:
> Is it possible to use a generic to control how a piece of code is
> reset?

Yes.
Here is an example that I used to compare three
synthesis templates using a generic switch:

http://home.comcast.net/~mike_treseler/uart.vhd

-- Mike Treseler

Mike Treseler

Aha, quite simple now I've been shown (as usual),
Thanks Mike, just what I was after.

Niv

Mike
Do you know which tools this works on?
Historically register synthesis in procedures
was a touchy point.

As an alternative to what you did,
if you are going to change between async and
sync reset on a project basis, you can create
two packages: one with async style resets and
one with sync style resets. Both packages create
procedures with the same names. This way, instead
of using generics and writing code to select
the register style, you simply compile the package
with the register style you are using for a project.

It would be cool to standardize something like this.
Just don't have time to work on it myself. I also
have been waiting for good support of registers in
subprograms.

Cheers,
Jim
> Niv wrote:
>
>> Is it possible to use a generic to control how a piece of code is
>> reset?
>
>
> Yes.
> Here is an example that I used to compare three
> synthesis templates using a generic switch:
>
> http://home.comcast.net/~mike_treseler/uart.vhd
>
> -- Mike Treseler


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Jim Lewis
Director of Training private.php?do=newpm&u=
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

Jim Lewis

Jim Lewis wrote:
> Mike
> Do you know which tools this works on?

Modelsim, Leonardo, Quartus for sure.

> Historically register synthesis in procedures
> was a touchy point.

This has not been the case for at least
two years with the tools above.

> As an alternative to what you did,
> if you are going to change between async and
> sync reset on a project basis,

I don't plan to.
This was a benchmark to pick the best
compromise for my own use.


> It would be cool to standardize something like this.
> Just don't have time to work on it myself.

I don't think anything needs to be done.
This is all standard VHDL '93.

-- Mike Treseler

Mike Treseler

>> Do you know which tools this works on?
>
> Modelsim, Leonardo, Quartus for sure.

Anyone know about other synthesis tools
such as Synopsys, XST or Synplicity?

>> Historically register synthesis in procedures
>> was a touchy point.
>
>
> This has not been the case for at least
> two years with the tools above.
>
>> As an alternative to what you did,
>> if you are going to change between async and
>> sync reset on a project basis,
>
>
> I don't plan to.
> This was a benchmark to pick the best
> compromise for my own use.
>
>
>> It would be cool to standardize something like this.
>> Just don't have time to work on it myself.
>
>
> I don't think anything needs to be done.
> This is all standard VHDL '93.

And VHDL-87. My thought is to create a set of
standard packages that provide register functions.
This way if you build a piece of IP on one project
that uses one reset style, you can use it on another
project that uses a different reset style and only
have to switch which package you use. Hence, it is
not a language change, it is just a set of packages.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Jim Lewis
Director of Training private.php?do=newpm&u=
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

Jim Lewis

Jim Lewis wrote:

>>> It would be cool to standardize something like this.
>>> Just don't have time to work on it myself.
>>
>>
>> I don't think anything needs to be done.
>> This is all standard VHDL '93.
>
> And VHDL-87. My thought is to create a set of
> standard packages that provide register functions.
> This way if you build a piece of IP on one project
> that uses one reset style, you can use it on another
> project that uses a different reset style and only
> have to switch which package you use. Hence, it is
> not a language change, it is just a set of packages.

I see.
Sure.
I'll package it and push it onto my site.

-- Mike Treseler

Mike Treseler

I'm curious as to how this would work, since the procedures that
determine the reset type must call custom procedures for the functional
behavior. If you put the former in a package, they don't have
visibility of the latter.

You could create ordinary register procedures in a package for a
variety of data types (automatically overriden based on signature), but
using them would look a lot like netlisting, and you'd have to create
packages for your enumerated types that were visible by both the
register package and your architecture (or wherever you define your
functional procedures).

I wonder instead if you had a sync_reset generic bit/flag that you
gated the async and sync resets with, if you could code both resets
together, and let the optimizer yank out the one that is gated off by
the generic. The sync_reset flag could be a package constant instead
of a generic. In the latter case you have to include the package
reference everywhere, and in the former you have to include the generic
plumbing everywhere. Generics can be overriden by synthesis or sim
command options.


constant sync_resets : boolean := true; -- make false for async_resets
-- could be generic or package constant

process (rst, clk)
....
begin
if reset and not sync_resets then
init_regs_and_outputs;
elsif rising_edge(clk) then
if reset and sync_resets then
init_regs_and_outputs;
else
update_regs_and outputs;
end if;
end if;
end process;

Granted, Mike's third option is a little different, but I've had good
results with making the outputs registered also (duplicates of
variables), and having synthesis optimize the duplicate register away.

Andy Jones

Andy

Andy wrote:
> I'm curious as to how this would work, since the procedures that
> determine the reset type must call custom procedures for the functional
> behavior. If you put the former in a package, they don't have
> visibility of the latter.

Yes, I'm not sure if I can hide much of the cruft
in a package. I'll look at it on the weekend.

> constant sync_resets : boolean := true; -- make false for async_resets
> -- could be generic or package constant
>
> process (rst, clk)
> ...
> begin
> if reset and not sync_resets then
> init_regs_and_outputs;
> elsif rising_edge(clk) then
> if reset and sync_resets then
> init_regs_and_outputs;
> else
> update_regs_and outputs;
> end if;
> end if;
> end process;

That would handle 2 of 3 templates...

> Granted, Mike's third option is a little different, but I've had good
> results with making the outputs registered also (duplicates of
> variables), and having synthesis optimize the duplicate register away.

Yes. I had expected that the v_rst and a_rst would
perform the same, but v_rst always won my
benchmarks. There is something about the
single port assignment that gives synthesis
an extra hint.

-- Mike Treseler

Mike Treseler