On Sun, 29 Oct 2006 16:11:54 +0100 Peter Lund <[EMAIL PROTECTED]> wrote:
> 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 Thanks for stuff to read in the train ;) > 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. Juup. Any signal that crosses clocking domains has to be first synchronized. > 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. Nope. That's about it. For us it would mean to first deasert reset for all peripherials, then PCI interface, then main FPGA. > Or to put it shorter: > > 1) make each local reset synchronous. > > 2) make a reset module to handle all the nasty cases. ACK. > 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. Actualy something more comes into play here: We are using an FPGA for development, which behaves a little different concerning reset than an ASIC. Have to have a look at the SpartanIII specs as soon i get some free time with a working brain. > 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. I don't really see the race condition here. Attila Kinali -- Lotus Notes ist eine verteilte Datenbankapplikation, als Sample ist eine miese Groupware dabei ;) -- Lukas Beeler _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
