On Tue, Jan 24, 2012 at 7:22 AM, R. Diez <[email protected]>wrote:
> Hi all: > > I have recently realised that Wishbone reset signals are handled > asynchronously in most OpenRISC-related cores. However, the Wishbone B4 > specification states the following about the reset signal: > > It's more than the wishbone reset signals, all or1200 blocks except the fpu uses asynchronous reset. Back in the 70's when a system was boards full of ttl parts then there were good reasons why you should connect all flipflops to an active low async reset. That was so universal that 40 years later some engineers still follow that rule. The problem is that a lot has changed and todays asic and fpga targets work better with synchronous resets on the flipflops. Getting designers to realize this has been like pulling teeth. I posted a test I did on minsoc where I converted all the flipflops from async to sync resets. The result used 42% fewer LUT's in a Xilinx part and ran at the same speed. It is easy to design a synchronous reset system that is the blackbox equivalent to an asynchronous one but still there were designers who were not comfortable with giving up the tried and true. The 99.99% number cited by Xilinx is due to the nature of embedded designs. Our components usually do not come out of reset and immediately start operating, they sit there and wait for the cpu to configure them and tell them to run. When a component is sitting in reset then the vast majority of its flipflops will be held in their reset state AND that same state will be present on the D input. When reset is deasserted then nothing changes. That is why you can screw up the reset deassert timing and it doesn't hurt anything. There will always be a few flops that will have the opposite of its reset state present on its D input during reset. Buried deep in the cpu will be a state machine that will kick off the reset vector fetch sequence to start the boot process. This is why you have to meet reset deassert timing or else the state machine could fly off to la-la land with the wrong timing. Another problem occurs when several different blocks start up and assume that they are in sync because they all started off the same reset edge. This requires extra care in the reset distribution tree and greater attention to timing. Resyncing reset to a local one is a good ideal. The other thing that the Xilinx paper was emphasizing was that while reset is a requirement it is very very slow signal and should be last on your priority list. When designing a reset system you first look for any mission mode logic that forces the flop into the same state as reset and if you find some then simply piggyback reset on top of that. Do not worry about resetting the flop in one cycle, if the logic can guarantee a reset within X number of clocks then put in a reset generator that gives a reset pulse longer than X. We should change openrisc to use active high synchronous reset. The only time you need to use async resets is when you directly drive an outside pin. John Eaton
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
