On Thu, 22 Feb 2024 at 15:09, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Tue, 20 Feb 2024 at 18:41, Inès Varhol <ines.var...@telecom-paris.fr> > wrote: > > > > This commit adds a QTest that verifies each input line of a specific > > EXTI OR gate can influence the output line. > > > > Signed-off-by: Inès Varhol <ines.var...@telecom-paris.fr> > > Reviewed-by: Peter Maydell <peter.mayd...@linaro.org> > > --- > > > > Hello, > > > > I expected this test to fail after switching the two patch commits, > > but it didn't. > > I'm mentionning it in case it reveals a problem with the test I didn't > > notice. > > The specific thing that goes wrong if you don't have the OR > gate handling is that the NVIC input will see every up > and down transition from each input separately. (This happens > because a GPIO/irq 'input' in QEMU is basically a function, > and wiring up an 'output' to an 'input' is setting "this > is the function pointer you should call when the output > changes". Nothing syntactically stops you passing the > same function pointer to multiple outputs.) > > So if you have for instance > raise A; raise B; drop B; drop A > where A and B are ORed together into an NVIC input, > the NVIC input is supposed to see the line go high > at "raise A" and only drop at the last "drop B". Without
...at the last "drop *A*", I mean. > the OR gate, it will see it go high at "raise A", and then > drop at "drop B". (Well, it sees "level is 1", "level is 1", > "level is 0", "level is 0", but inputs expect to sometimes see > calls for "level happens to be the same thing it was > previously", so it doesn't cause the NVIC to change state.) -- PMM
