On Sun, 2006-10-29 at 11:18 +0100, Attila Kinali wrote: > Moin, > > Also a small comment from my side on a very common mistake: > > On Tue, 17 Oct 2006 13:14:44 -0400 > "Timothy Miller" <[EMAIL PROTECTED]> wrote: > > > always @(posedge clock or posedge reset) begin > > if (reset) begin > [reset code] > > end > > else begin > [functional code] > > end > > end > > > Please do not use asynchrone resets. Using asynchrone > resets will in nearly all cases violate the setup and > hold times. Even using a asynchron edge trigered reset > like here, does only solve the hold time problem. > The setup time violation is still there. > Violation of either setup or hold time will result > in a metastable behavior of the registers.
There is always more than one of doing it right and more than one way of doing it wrong. That holds for both asynchronous reset and synchronous reset. I think these are the definitive papers on the subject (that are also reasonably accessible, uses Verilog, and do not suffer from academia's disease of ignoring parts of a problem): http://www.sunburst-design.com/papers/CummingsSNUG2003Boston_Resets.pdf http://www.sunburst-design.com/papers/CummingsSNUG2002SJ_Resets.pdf (the former is newer and better but as far as I recall, it refers to the latter here and there) Clifford Cummings has more Verilog papers at: http://www.sunburst-design.com/papers/ > Ok, one can argue now that reset will be asserted > for more than one clock cycle anyways, so after > the next rising edge of the clock all metastable > register will settle into the reset state. Can be handled by stretching the reset pulse before it reaches each subblock ;) On the other hand, using a synchronous reset means sampling the reset signal on a clock edge. The reset signal is asynchronous to the clock unless other precautions have been taken... This is also bad. > But, > there will be a period of time (up to one clock period) > in which more or less random signals are produced. Yep. How the reset is deasserted is often far more important than how it is asserted! > Those signals can disturb anything that they are concted > to. Especialy devices that are connected to our chip, and > if bad comes to bad you could fry something. Yep. As far as I recall the solution recommended in the Cummings papers is to use a synchronous reset on each submodule with a reset module to handle accepting an asynchronous reset, passing it through a couple of flip-flops to eliminate metastability problems, perhaps filtering it to avoid triggering on too short reset pulses, stretching it to be long enough that all submodules will handle, no matter what their clock speed is, perhaps synchronizing it with the clock in each clock domain if they are not locked in nice manner, asserting the reset in a specific order if necessary, holding it for long enough, deasserting it in a specific order if necessary -- and perhaps a couple of other things I may have forgotten. Or to put it shorter: 1) make each local reset synchronous. 2) make a reset module to handle all the nasty cases. That module can very simple (metastability fixing + stretching + synchronization of the deassertion with the clock) or very complicated depending on the needs. It is also something that can be fixed later, in parallel with other things, and which doesn't have to be perfect right from the beginning. -Peter PS: If you are writing a test bench, please don't assert or deassert the reset signal on a rising or falling clock edge. It is racy (so you'd need the reset module to make up for that). Assert/deassert it a little bit into the high or low part of the clock cycle. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
