On Sun, Oct 2, 2011 at 8:39 PM, Avi Kivity <a...@redhat.com> wrote: > > > ----- Original Message ----- >> On Sun, Oct 2, 2011 at 8:21 PM, Avi Kivity <a...@redhat.com> wrote: >> >> > >> >> > What I'm saying is that RESET order isn't defined on real >> >> > hardware >> >> > either, due to signal propagation effects. >> >> >> >> Yes, but there the millions of reset cycles help immensely to >> >> suppress >> >> the effects. >> >> >> > >> > That's modeled correctly. After the end of phase 1, everything is >> > settled. During phase 1, you can see some spikes, but you can see >> > them on real hardware as well. >> >> No. With two phase reset (like I understood it), at the beginning of >> phase, everything internal is settled (registers reset), no I/O. >> After >> the phase 1, starting the external I/O activities cause spikes but >> these are not suppressed. > > Phase 1 is qemu_irq_raise() on all RESET inputs. During this period, outputs > of devices that have seen the edge move to their RESET values, and they > ignore inputs. Because it doesn't happen simultaneously, some devices see > those outputs moving and may act on them. This corresponds to different > devices having different propagation delays. > At the end of phase 1, everything is settled. This corresponds to T = > max(reset latency of all devices). > > Phase 2 is qemu_irq_lower() on all RESET inputs. At this time, inputs begin > to be considered. > > Between phase 1 and phase 2 are those millions of cycles (minus T above). > > > So yes, you see spikes, but you also see them on real hardware.
With this definition of phases, at least the DEV/PIC1/PIC2 example I presented earlier isn't possible. PIC2 would ignore the new input, so it would retain reset state.
