Oh no! Resets Again? Yes, but it could be important.

Important if you need your designs to cleanly reset every time.

Apologies, but many folks are still posting code for asynchronous
resets... some are even advocating it:

On Nov 11, over in thread "Open Source FPGA...", Mike Treseler wrote:

"I use exactly this template of three top procedures in every new
design entity:

  begin -- process template
    if reset = '1' then
      init_all_regs; -- no port init required
    elsif rising_edge(clock) then
      update_process_regs;
    end if;
    update_output_ports; -- wires ok for reset or clk
  end process template;
"
This is only the most recent example, and seeing this asynchronous
reset code over and over again is starting to worry me, particulary
considering that some FPGA's may be in critical environments, where
cleanly coming out of reset is vital.

Xilinx[Ken Chapman] suggests this is not the most efficient strategy
for LUT utilization in http://tinyurl.com/66xby. Ken cheats a bit in
his article (he re-works an async reset to be sync to get a more
compact circuit, but the behavior of the smaller circuit is different
than the original!), but overall he has a good point. And there is a
stronger reason to write your code to reset synchronously. The
following is quoted verbatim from the Xilinx Constraints Guide
(cgd.pdf), in the Timing Constraints section:

"The tools do not automatically analyze asynchronous set/reset paths."
(I assume tools means Map/Place/Route)

This bears repeating.
"The tools do not automatically analyze asynchronous set/reset paths."

Following that scary statement is a reference to the "Enable" and
"Disable" constraints, which control timing checks over these two paths
(among others):

"Asynchronous Set/Reset to output propagation delay"
 and
"Synchronous Set/Reset to clock setup and hold checks"

But lo and behold! There is NO checking (according to cgd above) of the
path:

"Asynchronous Set/Reset to clock setup and hold checks"

(I like the convention of calling "async reset" clear, and calling
"async set" preset, leaving set/reset for the sync functions, and will
try to stick with that for the rest of this discussion)

The clear pin may be released at various registers in a process with
uncertain timing relative to clock, _even_ if the clear signal started
out synchronous. This has the same potential for trouble as any other
async input to a synchronous state machine, because clear is just
another input after all. A one-hot state machine can go no-hot or
many-hot; a binary coded (non-Gray) SM may enter an illegal state; or
see Ray's counter example (which is _not_ a counter-example) at
http://tinyurl.com/8gjxe. These are not good things.

I've modified my style to ALWAYS reset synchronously, using a sync
reset (with considered exceptions for certain unique circuits):

process(clock)
begin
    if RISING_EDGE(clock) then
      if reset = '1' then
        init_regs; -- the ones that need it.
      else
      [elsif enable = '1' then] -- I like this form, it's free
        update_process_regs;
    end if; end if;
end process;

Sure, it means that reset has to be synchronized somewhere, and (egad,
worse yet!) typing an extra "end if" and indenting a level deeper, but
this is a small price to pay for designs that start up first time,
every time.

To quote Ray:
" Generally speaking, asynchronous resets are a very bad idea in
FPGAs."
Because this might be mis-interpreted, I'd clarify that and say even
synchronous resets, if used as a clear function, are a bad idea. Write
code to reset synchronously. Keep clear of that clear pin.

Regards to all,
John

"JustJohn" <john.l.smith@titan.com> schrieb im Newsbeitrag 
news:1132397821.560864.109950@g49g2000cwa.googlegroups.com...
>
> On Nov 11, over in thread "Open Source FPGA...", Mike Treseler wrote:
>
> "I use exactly this template of three top procedures in every new
> design entity:
>
>  begin -- process template
>    if reset = '1' then
>      init_all_regs; -- no port init required
>    elsif rising_edge(clock) then
>      update_process_regs;
>    end if;
>    update_output_ports; -- wires ok for reset or clk
>  end process template;
> "

Do you want to take the fun out of the world of electronic design ?

> This is only the most recent example, and seeing this asynchronous
> reset code over and over again is starting to worry me, particulary
> considering that some FPGA's may be in critical environments, where
> cleanly coming out of reset is vital.

Our evolution is try and error. Do you want to hinder our evolution ?
Do you want to take the exitement out of our lives ?

And Frankly, every modern (since the Wintel revolution) user of any 
electronic device will "reboot" it until it works without worrying. I've 
already adapted this behaviour subconsciously.
I also experience a much higher rate of failure during operation of 
electronic devices.

Raymund Hofmann 

JustJohn wrote:
> "The tools do not automatically analyze asynchronous set/reset paths."
> (I assume tools means Map/Place/Route)
>
> This bears repeating.
> "The tools do not automatically analyze asynchronous set/reset paths."


You can turn this on the UCF.  Every UCF I have ever written has
contained the lines:

# magic incantation to make the tools trace timing through reset paths
ENABLE= reg_sr_q;


Regards,
Allan

JustJohn wrote:
> Important if you need your designs to cleanly reset every time.
> 
> Apologies, but many folks are still posting code for asynchronous
> resets... some are even advocating it:
> 
> On Nov 11, over in thread "Open Source FPGA...", Mike Treseler wrote:
> 
> "I use exactly this template of three top procedures in every new
> design entity:
> 
>   begin -- process template
>     if reset = '1' then
>       init_all_regs; -- no port init required
>     elsif rising_edge(clock) then
>       update_process_regs;
>     end if;
>     update_output_ports; -- wires ok for reset or clk
>   end process template;
> "
> This is only the most recent example, and seeing this asynchronous
> reset code over and over again is starting to worry me, particulary
> considering that some FPGA's may be in critical environments, where
> cleanly coming out of reset is vital.
> 

Without seeing the rest of Mike's code, I would be willing to bet that 
"reset" is in fact the Xilinx power on reset. This reset is going to 
happen in the actual hardware asynchronously whether you like it or not. 
All Mike has done (I assume) is to explicitely code the actual behavior 
of the builtin Xilinx hardware. This is in fact a perfectly reasonable 
thing to do, and I also insist on all VHDL code I control explicitly 
show asynchronous POR behavior, in the same way.

If a particular part of the circuit needs a synchronous reset, then that 
is simply added to the synchronous part of the process. That is a 
completely separate issue from POR.

This is interesting Allan...

 I did read the docs, that's where I quoted from. Are you saying that
ENABLE= reg_sr_q; which provides timing coverage for paths including:

1) "Asynchronous Set/Reset to output propagation delay"

will eventually somehow undergo a transformation into a check for paths
including:

2) "Asynchronous Set/Reset to clock setup and hold checks"

Because I am not talking about a reset -> output issue, This is a
matter of set-up/hold. Another Enable/Disable constraint, reg_sr_clk,
as listed in Tables 7-1 and 7-2, gives path checking for

3) "Synchronous Set/Reset to clock setup and hold checks"

but 3) is clearly different from 2). Do you see the difference I'm
suggesting?

Either my reasoning is totally kaflooeey, or the Xilinx documentation
is fairly misleading and should be changed to something like:

Enable = reg_sr_clk; implies
4) Any (Synchronous or Asynchronous) Set/Reset to clock setup and hold

It might be nice to have someone from Xilinx weigh in on this.

Regards,
John

JustJohn wrote:
> This bears repeating.

   This bears   This bears  This bears   This bears   This bears


Anyway, two things:

1) Do you guarantee a power-on reset either by always asserting the 
reset pin or through constraints?

2) What if your system is in an environment where the clock is stopped 
during your reset event?


Power-on states are guaranteed by the asynchronous reset.  Those of us 
who try to keep away from async resets MUST make sure there isn't an 
erroneous power-up state that confuses our logic OR guarantee that 
everything has the synchronous reset applied before the circuit affect 
the rest of our system.

JustJohn wrote:
> This is interesting Allan...
>
>  I did read the docs, that's where I quoted from. Are you saying that
> ENABLE= reg_sr_q; which provides timing coverage for paths including:
>
> 1) "Asynchronous Set/Reset to output propagation delay"
>
> will eventually somehow undergo a transformation into a check for paths
> including:
>
> 2) "Asynchronous Set/Reset to clock setup and hold checks"

Quite possibly.  It wouldn't be the first time Xilinx software did
something completely contrary to the documentation.  At least reg_sr_q
is mentioned in the documentation now (it wasn't always).

I'm a bit confused as to why you would attempt to use async resets to
implement logic functions that are better handled by synchronous
resets.  At least with synchronous resets you can know that the results
will be reliable.  If I caught any of the designers here trying to use
async resets that way they would get a stern talking to.

Any reasonable FPGA coding guide should strongly advise against using
async resets or sets to implement logic functions.  (At least for
Xilinx) async resets should only be connected to one net, and that net
should be connected to the reset input of a startup block.  Any other
usage should be illegal.  You should use a well known name for that net
as well.  Here we use the name 'gsr'.

Such guidelines are based upon studies made of non-working designs and
failing projects over many years.  You can ignore them at your peril.

Allan

John_H wrote:

> This bears   This bears  This bears   This bears   This bears

HA HA HA, Thanks for the smile this morning, I was up late last night
when I made that post, maybe got too long winded.

> 1) Do you guarantee a power-on reset either by always asserting the
>reset pin or through constraints?

Hmm, to answer both John and Duane, I was talking about an individual
reset for an entity, that may be asserted individually to that entity,
separate from others in the same design and not "globally" across the
chip, as a power-on reset. Perhaps code examples here in c.a.f. can
make the distinction, and generally use 'por' for power-on resets, and
'rst' for not necessarily global resets.

Personally, I admit to being a little lazy, and writing code so that
power-on state is irrelevant for most of the the system, except in one
place where a rst event is guaranteed to be generated. That rst does
the real work, and does not depend on the whether the FPGA has a por or
not.

>2) What if your system is in an environment where the clock is stopped
>during your reset event?

I'll duck this for now and say that's one of the "considered exceptions
for certain unique circuits". Hey, it's Saturday morning, and a bright
and sunny day here in southern California. Time to get outside.

Allan wrote:
>I'm a bit confused as to why you would attempt to use async resets to
>implement logic functions that are better handled by synchronous
>resets.

Apologies to you Allan, I was not trying to confuse you, and I would
NOT attempt such a thing, this was exactly the point of my post! Xilinx
docs say they don't check clock set-up for asynchronous reset input,
and yet, time after time, people post examples of async resets, which
will lead the unwary into trouble.
As I said on the other thread, it's a nice day out, time for a walk...

JustJohn wrote:
> Allan wrote:
> >I'm a bit confused as to why you would attempt to use async resets to
> >implement logic functions that are better handled by synchronous
> >resets.
>
> Apologies to you Allan, I was not trying to confuse you, and I would
> NOT attempt such a thing, this was exactly the point of my post! Xilinx
> docs say they don't check clock set-up for asynchronous reset input,
> and yet, time after time, people post examples of async resets, which
> will lead the unwary into trouble.
> As I said on the other thread, it's a nice day out, time for a walk...

I started out using TTL parts.  They (usually) didn't specify setup
times of async inputs with respect to the clocks.  Propagation delay
(async reset -> Q) was the only timing parameter specified.
(I just checked the data sheet for a SN54AHC74, it seems these
parameters are specified in more contemporary devices.)

I feel this is more about educating newbies than blaming Xilinx for
faults in their tools.
Surely schools teach ... wait, I can remember my classes (a long time
ago) and they didn't even touch on this sort of thing.

(I'll follow your lead and take a walk outside now.)

Regards,
Allan