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

JustJohn wrote:

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

My code template assumes one global reset pulse
that occurs once, on a low-skew path,
after the fpga image has loaded.
I also assume that this pulse has a source
external to, but using the same clock as the fpga.
In my case, it comes from a cpu that loads
the binary fpga image.

I don't use vendor-specific resets
because they are vendor-specific.

The reason I use this "asynchronous" style template
is that it saves logic cells in every synthesis benchmark I have run
on both brands A and X.

In summary, I use one synchronized reset pulse,
on a low skew path to the asynch reset input
of every D-flop in the design.

I expect that this template will work for me
as long as fgpa vendors keep global routing
and asynch resets on D-flops.

I will update my code examples with these comments.

      -- Mike Treseler

>My code template assumes one global reset pulse
>that occurs once, on a low-skew path,
>after the fpga image has loaded.
>I also assume that this pulse has a source
>external to, but using the same clock as the fpga.
>In my case, it comes from a cpu that loads
>the binary fpga image.

Is that good enough?

Don't you also need the prop time on that low-skew path
to be short enough relative to your clock cycle time so
that you know when it gets to your FFs?

Last I checked, the global reset on most Xilinx parts
was too slow to be useful in that context.

I thought that consensus here was to use the global
reset hardware to (asynchronously) force your state
machines into a known state and then use a local
FF that has been synchronized to get out of that state.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray wrote:

> Is that good enough?

It has been in many cases.

> Don't you also need the prop time on that low-skew path
> to be short enough relative to your clock cycle time so
> that you know when it gets to your FFs?

For the trailing edge, yes.
On the board, a zero delay clock buffer
and careful distribution to all devices does
the trick. On the fpga I just have to make
sure the reset node gets one of the global nets.

> Last I checked, the global reset on most Xilinx parts
> was too slow to be useful in that context.

Yes. I don't use anyone's the built-in reset.

> I thought that consensus here was to use the global
> reset hardware to (asynchronously) force your state
> machines into a known state and then use a local
> FF that has been synchronized to get out of that state.

I don't think I'm contradicting that idea.
The asynch reset gives you a starting
point for simulation. After this, well-designed
control logic will use an idle state for
specific synchronous initialization.

           -- Mike Treseler

(Back from my walk...)

Hal wrote:

>I thought that consensus here was to use the global
>reset hardware to (asynchronously) force your state
>machines into a known state and then use a local
>FF that has been synchronized to get out of that state.

Aaahhh, thanks Hal, _very_ nicely put, succinct and clear. (It's been a
while since those discussions, I turned 50 last month, and have been
working in the wonderful world of M$ GUI design lately, so forgive me
for forgetting).

Integrating everyone's good words with Mike's generic process template
and my desire for an entity local reset into pseudo VHDL:

process (clock, gsrout) begin
  if gsrout = '1' then
    init_all_regs;   -- Every darn one of them
    init_state_regs; -- To a 'dormant' reset state
  elsif RISING_EDGE(clock) then
    if reset = '1' then
      init_some_regs;   -- Only ones really that need it,
                        -- both to reduce routing req's,
                        -- and because it may be useful
                        -- to keep some values across
                        -- a reset event
      init_state_regs2; -- To an 'awake' reset state
    else                -- No enable form
    [elsif enable = '1' then] -- Using enable form
      run_reg_logic;    -- And they're off to the races
      run_state_logic;  -- (oops, bad word, no races here!)
  end if; end if;
 end process;

Signal gsrout comes from the Xilinx 'STARTBUF_arch' primitive, so that
the async device clear does not take FF pins or routing. (Mike may not
like this vendor specific stuff, see my parting question)

Googling back to June reveals a 'roller' (http://tinyurl.com/ajvtw) who
asked about _not_ using this format. Nobody answered then, but after
going through this exercise, I would say this is a fairly solid
template, don't use it at your own peril.

Ok, I'm done, except for one last question... does Altera have a
similar GSR function? (Please pardon my laziness)

Thanks all,

John

Mike Treseler wrote:
> Hal Murray wrote:
> > I thought that consensus here was to use the global
> > reset hardware to (asynchronously) force your state
> > machines into a known state and then use a local
> > FF that has been synchronized to get out of that state.
>
> I don't think I'm contradicting that idea.
> The asynch reset gives you a starting
> point for simulation. After this, well-designed
> control logic will use an idle state for
> specific synchronous initialization.

You're right, Mike; the async reset is helpful for simulation.  Looking
back at my recent designs, I see a pattern.  All of my state machines
have a safe reset state.  A slow reset (where some of the state flops
reset before others) on a one-hot machine decodes as an illegal state
so the machine automatically bounces to the reset state.  Once
everything is reset then the machine synchronously transitions to an
"idle" state where it stays until other logic tells it to do something
interesting.

For things like loadable registers, the power-on reset is helpful, and
the usual template of

    myreg : process (clk, reset) is
    begin
        if (reset = '1') then
            register <= INITVAL;
       ....

tells the synthesis tool to use INITVAL as the power-on default as well
as the async reset value.  Ususally the rest of the logic doesn't
depend on these values, and the registers are loaded before they're
used.

-a

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:3u9tgiFv35pmU1@individual.net...
> The asynch reset gives you a starting
> point for simulation. After this, well-designed
> control logic will use an idle state for
> specific synchronous initialization.
>
Mike, All,
Yep. I use the same template as you. Every process has the same async reset
and is used *only* in functional simulation. Startup in real life is taken
care of by the FF initialisation on configuration. Any extra resets needed
after startup are synchronous.
The exceptions are when I want to infer SRLUTs, distributed RAM etc. In this
case the template misses out the async reset, as it is not supported by the
hardware.
Cheers, Syms.

Heiner Litz wrote me personally:

>Hello John,
>Very interesting thanks! But i still do not get the point. I am using the following verilog statements:>

>Always @(posedge clk or negedge res_n)
>  If(!res_n)
>   DO RESETS
> Else
>  NORMAL OPERATION
>
>What bad things can happen using this style
>if res_n is zero for more than one clock cycle?
>The ansync reset may violate setup/hold of
>registers but then after a while where res_n
>stays low everything should be fine.
>I have really strange problems as my
>sdf anotated placed and routed design
>works fine but the FPGA does not.
>I will try it out but do not really know
>what the problem is.
>
>Regards, Heiner

Hello Heiner,

  I don't use Verilog on a regular basis (yet), and have not built up a
repertoire of the natural forms of expression to produce solid results
in that language. Since you wrote my personal address, I'm reposting
this to c.a.f. for comment by others.

  My original point is that the place/route tools do not analyse clock
setup and hold paths through an async reset. Here's what can happen in
the case of a state machine that gets synthesized and expressed in
one-hot format (I'm sure this has been described before):

  Assume the state machine starts changing states immediately after
reset is removed. In one-hot form, there will be a FF, call it FF_rst,
corresponding to the reset state, which is set to 1 by the reset. The
first state FF after reset, call it FF_st1, will be set to 0 by reset.
If working correctly, at the first clock edge after reset is removed,
FF_rst -> 0, and FF_st1 -> 1. Now it is 99.99% (really, 100%)
guaranteed that the delay of reset to FF_rst will be different than the
delay to FF_st1. Assuming the reset delay is shorter to FF_rst, there
is a timing window where the clock can transition such that FF_rst -> 0
because reset is not active there, but FF_st1 stays at 0 because reset
is still asserted there. Voila, you've entered no-hotville. At the next
clock edge, when reset has finally de-asserted at FF_st1, still nothing
happens, because FF_st1 needs to see FF_rst = 1 in order to set.
There's no road out from no-hotville. If that timing window is larger
than your clock period, the SM will never start up. If that timing
window is really small, you can get a design that works 99.9 % of the
time and fails (by Murphy's law) when you really need it.

 People often don't travel this road, because state machines sit in
reset waiting for some other synchronized signal to leave reset, as
described by Andy, and this is perfectly legitimate. So no _single_
template fits every situation. As Syms says, SRLs and RAM based
registers can't have any reset in code that infers them. It is
important to distinguish between a global async reset and distributed
sync resets.

  Ah-hah!, looks like there is a back door out of no-hotville. XST has
a couple of new constraints on FSM expression: 'safe_implementation'
and 'safe_recovery_state'. I haven't played with these yet, so don't
know how much netlist inflation they produce, but if you (Heiner) want
a quick and dirty way to imunize state machines from async startup
woes, without having to modify any existing code, you might try these.
I'm not advocating relying on these as a fix for final release, but
they might be a tool to help show that a SM might be getting off track,
and that you need to  look deeper into your code. I would suggest them
for final release if you have SEU concerns (provisionally, I haven't
looked at their output yet).

  Has anyone any experience with these constraints they'd like to
share? Do any other synthesis tools support them?

Regards all,
John

p.s. I rely on Google for my c.a.f. browsing/posting. I'm glad they've
sped up their posting, I was finally able to participate in real-time
with a discussion here (formerly, they had a half day wait from posting
to appearance). Google makes me put my real address in, but please try
to refrain from writing me directly on thread topics, I feel guilty if
I don't have time or inclination to respond.

Hal Murray wrote:
> >My code template assumes one global reset pulse
> >that occurs once, on a low-skew path,
> >after the fpga image has loaded.
> >I also assume that this pulse has a source
> >external to, but using the same clock as the fpga.
> >In my case, it comes from a cpu that loads
> >the binary fpga image.
>
> Is that good enough?
>
> Don't you also need the prop time on that low-skew path
> to be short enough relative to your clock cycle time so
> that you know when it gets to your FFs?
>
> Last I checked, the global reset on most Xilinx parts
> was too slow to be useful in that context.
>
> I thought that consensus here was to use the global
> reset hardware to (asynchronously) force your state
> machines into a known state and then use a local
> FF that has been synchronized to get out of that state.
>
> --

How about using a bufgce instead of a bufg and gate off the clock
during and sometime after async reset? 

-Lasse

Lasse wrote:
>How about using a bufgce instead of a bufg and gate off the clock
>during and sometime after async reset?

Can be done with care, but there's a chorus of "don't gate clocks in an
FPGA" as a general design practice.

See e.g. http://tinyurl.com/73st2 for an answer record containing the
caveat:

"CE must not change during a short setup window just prior to the
rising clock edge on the BUFGCE input I. Violating this setup time
requirement can result in an undefined runt pulse output."

The list of "ways to do it wrong" is far larger than "ways to do it do
it right", and even the do it right list can have some ways to do it
wrong as a subset.

On 21 Nov 2005 13:58:11 -0800, "JustJohn" <john.l.smith@titan.com>
wrote:

>  My original point is that the place/route tools do not analyse clock
>setup and hold paths through an async reset. 

Assuming that you're talking about Static Timing Analysis tools (as
opposed to P&R), this is not true in general. Definitely not true for
standard cell flows and even in case of FPGA case, if you set the
right parameters, it's not true. You maybe hiding it by not
constraining your external reset pin with the clocks of the flops it
arrives at. You can get around this by driving your async reset input
of flops with a synchronized version of your reset pin. This way your
internal reset signal is sourced by a clock and it is also helpful in
that it reminds you to do this for every clock domain where reset is
used.