Global Reset using Global Buffer

Mark,

Nice write-up! In the end, if you count up all the time (money) spent deter=
mining AND VERIFYING what does not NEED to be reset, you'd have been better=
 off resetting everything to start with, and only pulling out the reset whe=
re it kills your utilization (by kill, I don't mean raises util from 85% to=
 86%, I mean it doesn't fit!).=20

The pipe-lining/retiming trick for handling fanout on the synchronous reset=
 also works great for synchronously deasserted asynchronous resets!

When coding a process that has some registers reset and others not, if you =
use the familiar "reset ... elsif clock ..." structure, your fanout on rese=
t may not be reduced, because every register that saved a reset, added a cl=
ock enable (or another input to existing clock enable logic).=20

When I have both reset and non-reset signals/variables in the same process =
(e.g. ram arrays, etc.), I use the following structure to avoid clock disab=
le on non-reset signals/variables:

process (clk, rst) is
begin
   clocked: if rising_edge(clk) then
      -- logic assignments here
   end if clocked;
   reset: if rst then=20
      -- reset assignments here
   end if reset;
end process;

Although this style works fine for the general case (when everything is res=
et), I do not use this style unless I actuall need it. The reason is, in th=
e conventional reset elsif clock structure, you will get synthesis warnings=
 (from synplify at least) about feedback multiplexers on non-reset register=
s. You won't get those warnings for them if you use the method above. This =
also makes the above approach rarer, which stands out for the reviewer, whe=
re it gets extra attention to make sure that everything that should (can?) =
be reset is reset.

The same clock enable problem also happens when you use an "if reset else l=
ogic" structure for a synchronous reset. Nothing after that "else" executes=
 when reset is true, which results in extra clock enable logic on non-reset=
 registers. Use a similar approach to the above, by moving the (synchronous=
) reset assignments to their own if-statement just before the end of the cl=
ocked if-statement:

process (clk) is
begin
   if rising_edge(clk) then
      -- logic assignments here
      if rst then
         -- reset assignments here
         -- to avoid clock enables
         -- on non-reset registers
      end if;
   end if;
end process;

Strange how I didn't see any of this in that white paper written by the "ex=
perts"...

Andy

Awesome, thanks! Seems to me this makes it a lot easier to reason
about: you just give every variable or signal an initial value which is
loaded during bitstream load and let the configuration-clock-based GSR
handling deal with the rest. Make sure PLLs and DCMs start up after GSR
is deasserted and that everything uses a clock downstream of a PLL or
DCM (and perhaps introduce some BUFGCEs) and everything should be OK—at
least, for my application it’s easy enough to things that way. Clock
domain crossings might come up in either order, but that’s pretty easy
to deal with.

Chris

On Wed, 19 Sep 2012 16:06:58 +0000 (UTC)
Brian Drummond <brian@shapes.demon.co.uk> wrote:

> On Wed, 19 Sep 2012 09:50:35 -0500, jt_eaton wrote:
> 
> >>On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote:
> 
> >>> As far as issues of different FFs leaving reset on different clock
> >>> cycles are concerned, could one not solve these issues by
> >>> asserting GSR for long enough to reset all FFs, deassert it, then
> >>> activate the clocks afterwards?
> >>
> >>Yes. Perhaps better, activate clock enable(s) afterwards.
> >>
> >>Either way, you may need a hierarchy of clock activation; after
> >>reset, you don't want your main clock generator to wait for several
> >>cycles of a (stopped) clock...
> >>
> >>- Brian
> >>
> >>
> > Guys,
> > 
> > You don't need to stop the clock at all. The reset deassert to clock
> > edge spec only applies when you are trying to change state. 
> 
> I know. But I was being a little facetious, after one occasion when I 
> shot myself in the foot with a synchronous reset for a DLL...
> 
> - Brian