alternate synchronous process template

[Andy]

KJ wrote:

In the OP, the author has simply shown a way to provide the behavior of
two separate processes (one with async reset, one without), in one
process, a valuable technique if one wants to minimize processes and
maximize use of variables.

I'm not sure that 'maximize use of variables' is any sort of useful
metric (function/performance/power/code maintainability are more
useful), but I agree with you and the original post author that what
was posted is an improvement over using two processes and belongs in
the bag of tricks.

Maximizing use of variables also maximizes RTL simulation performance,
since there is far less overhead for variable update and access than
for that of signals. More simulation performance relates to more corner
cases hit, and more bugs found.

But the original post also mentioned this in the context of this being
a good way to avoid unwanted gated clocks. And in my original post I
simply mentioned that an asynchronously resetable shift register used
to generate the reset signal to everything else in the design and then
using synchronous resets throughout the design avoids the entire
situation entirely and in most cases costs darn near nothing and
performs virtually the same.

Agreed, but the devil's in the details of "most" and "virtually".

The only functional difference between the two is that PRIOR to that
first rising edge of the clock the outputs are in a different state.
AFTER the first rising edge everything is the same. The reset signal
itself can come when the clock is shut off, it's just the result of
that reset that doesn't show up until the clock does start.

Maybe I'm being picky, but that can be a big difference! They are NOT
the same, particularly when meeting requirements in the absence of a
clock!

As a practical matter, that functional difference is generally of no
importance....for the simple reason that the reason that the clock
isn't running is usually because something has knowingly shut it off
(i.e. maybe to conserve power). In any case, that thing that controls
the clock certainly knows to ignore the outputs of a function that it
is not actively using so the fact that the outputs aren't the way you
think they should be really doesn't matter darn near all the time.

Maybe "generally" and "usually" in your work, but not in mine!

If you think the slight functional difference is important because this
signal is a 'really important' signal that absolutely must come up
correctly (i.e. launch the missles) than think again. Before any
properly designed system would turn over control of that 'really
important' signal in the first place it would first test it to make
sure that it is working correctly (i.e. no false launches...no missed
launch commands). Only then would it allow that signal to control that
'really important' signal....and it would only do so after starting the
clock because the designer realizes that the outputs become valid after
the clock, not before.

This is not about proper initialization at startup, though those
problems are often the result of improperly handling (synchronizing)
reset inputs, no matter whether the end circuit is designed with an
async or a sync reset.

If the clock isn't running because it is just busted than maybe the
slight functional difference does become important but only if it
prevents the system from properly diagnosing what field replacable unit
needs replacing or being able to route around the failing component.

This is the most common root cause for the requirement for
predictable/safe behavior in the absense of a clock: a failed clock
input. If the system is designed to shut off the clock, then not
handling that would be a design defect. When system outputs are used
to directly control other things that can destroy themselves (or
destroy something else) if not actively controlled (motor servo loops
are just one minor example), then performance w/o a clock becomes
vitally important, particularly in medical, automotive, and military
applications where human lives are at stake.

<snip...>

There are many things that can be inferred from RTL that do not have
the option of an async reset,

Think you meant "the option of a sync reset"

Either one: ram and shift register primitives are a good example.

and mixing them with asynchronously reset
logic using the OP example is beneficial.

Agreed....keeping in mind that using async resets requires more 'skill'
(for lack of a better word) than sync resets.

Once the deasserted edge is handled, there is no more or less skill
invovled in using async vs sync resets. Handling the deasserting edge
is no more or less difficult than properly synchronizing a reset input
in the first place. Both have to be done for each clock domain. If
there is no more skill involved, why not use the "safest" approach,
which guarantees performance even in the absence of a clock. Now, if it
were for an ASIC, where flop primitives with async resets come at a
real-estate, if not performance, disadvantage, then by all means use
the sync reset (which usually gets munged in with the gates anyway) if
there are no requirements for safing the outputs in the absence of the
clock.

Even if it were more difficult, that's why they pay us the big bucks!


Andy

 

[Jonathan Bromley]

On 15 Jun 2006 10:04:14 -0700, "jens" <roden@rochester.rr.com> wrote:

[...]

Here's an alternate synchronous process template...

alternate_synchronous_process_template: process(clock, reset)
begin
if rising_edge(clock) then
-- assign all registers here
end if;
if reset = '1' then
-- initialize some or all registers here
end if;
end process alternate_synchronous_process_template;

In all the discussion about the pros and cons of synchronous and
asynchronous resets I haven't seen anyone acknowledging that
this is a straightforward and elegant solution to a common
issue.

I'm off to do a quick survey about which synth tools support it.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[KJ]

In all the discussion about the pros and cons of synchronous and
asynchronous resets I haven't seen anyone acknowledging that
this is a straightforward and elegant solution to a common
issue.

Last sentence, set off in a paragraph all by itself to stand out more in the

very first post that I made.

Must've dozed off before getting that far.

KJ

 

[Jonathan Bromley]

On Tue, 20 Jun 2006 09:52:41 GMT, "KJ"
<kkjennings@sbcglobal.net> wrote:

In all the discussion about the pros and cons of synchronous and
asynchronous resets I haven't seen anyone acknowledging that
this is a straightforward and elegant solution to a common
issue.

Last sentence, set off in a paragraph all by itself to stand out more in the
very first post that I made.

Must've dozed off before getting that far.

urrm, wouldn't be the first time... but not this time, I think; I was
badly thrown off the scent because you had wrongly rewritten
Jens's original code, at the comment "Oops, missed this one".

Whilst I completely agree with you that asynch resets on
clocked processes need a lot of care in real applications,
there's no doubt that they are important and useful - and
they DO raise the tiresome issue that the standard
synthesis template absolutely requires that every flop
must appear as an assignment target in BOTH the reset
AND the clocked branch. Jens's scheme obviates that
irksome coding-style requirement. It doesn't in any
way affect the *design* requirement to know what
is happening around the time when asynchronous
reset deasserts, as you and others wisely emphasised.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

jens wrote:

Here's an alternate synchronous process template...

For example...
if rising_edge(clock) then
s1 <= <whatever>;
s2 <= <whatever>;
end if;
if reset = '1' then
s1 <= (others => '0');
end if;
This template makes it possible to reset signal s1 but not s2. Running
it through Xilinx tools yielded the desired RTL results (and identical
to a two-process model).

I haven't tried your idea, but I think it would work if
I didn't mind keeping track of inter-process signal drivers.

I prefer to reset and update only variables
and to output values only to ports.

See the v_rst template in the reference design here:
http://home.comcast.net/~mike_treseler/

-- Mike Treseler