On 10/01/2011 10:31 AM, Blue Swirl wrote:
Therefore it is incorrect to perform any qemu_irq activities during reset (also VM restore like the original example), don't you agree?
It is not incorrect. Real hardware updates outputs on RESET assertion, and real hardware deals with devices entering reset at different times (due to signal propagation delay or slow devices).
If we continued to reset all the devices (call the reset handlers multiple times), eventually machine state should stabilize (equivalent of real HW with nice long reset pulses), but on QEMU the reset event is infinitely short so we have to be more careful.
calling qemu_irq_pulse(reset) simulates a reset signal of any length (since nothing happens between the two edges).
Actually I don't think that even a two-phase reset with qemu_irq or Pin activity on the second phase would produce correct results in every obscure case. Though this may be detectable since the start state would be known.
The output signals have to stabilize before the second edge of the reset signal.
-- error compiling committee.c: too many arguments to function
