> Some remarks on "cashing" w/ PPC boards and the universe-II chip.
> I had problems within interrupt service routines on MVME2100 CPUs.
> The ISR contained several VME reads and writes
> to determine the cause of the interrupt and then clear it.
> On the backplane analyzer, those "writes" sometimes showed up
> with huge time intervals between them.
> So the "clear interrupt" reached the board with a long delay.
> Dave Thompson (ORNL) helped with the following.
> The assumption was: The UniverseII chip keeps writes
> in a pipeline instead of flushing them to the VME bus.
> And yes: There is no obvious "disable pipelining" register
> on the Universe II.
> This looks paranoid, but now my ISR seems to function all the time:
> 1) #define SYNC __asm__ volatile ("sync")
> then "SYNC" after writes to assert that
> the commands actually leave the CPU.
> 2) At the end of the ISR, add a dummy "read" to the addres
> of the last "write". That seems to flush the Universe-II write pipeline.
The problem, apparently, is not with the "pipelining" but with the
instruction sequencing optimization that occurs in the PPC processor.
Instructions are NOT necessarily executed in the same sequence that
they appear in memory. In particular, a write to an external register
through the VME interface (the CPU is connected to an internal memory
bus and cannot sense that a memory location is actually mapped to an
external register) may be delayed if the CPU determines that it can
increase its effective speed by reordering the commands.
I experienced just this problem when I coded an interrupt service
routine to handle an interrupt from a slow VME device. Because the
PPC reordered the instructions (i.e. delayed the register write that
cleared the interrupt request from the VME device) the interrupt
service routine exited before the interrupt request signal was removed
from the VME bus. This resulted in an overflow of the kernel's
When I realized what was happening, I consulted our local PPC expert
who advised me to include a "useless" read of the same register
immediately after the write. This forced the optimizer to execute the
write so that the read would return the correct value. That
eliminated the problem. If you use this technique, I suggest that you
include a comment in the code which explains the purpose of the extra
read. Otherwise, one of your successors may remove this seemingly
redundant statement from the program.
- Re: ISEG VHQ204L Driver Burkhard W. Kolb
- RE: ISEG VHQ204L Driver Kay-Uwe Kasemir
- Navigate by Date:
Re: switch clock Maren Purves
side-effect of malloc() in startup file Peregrine M. McGehee
- Navigate by Thread:
RE: ISEG VHQ204L Driver Kay-Uwe Kasemir
Re: ISEG VHQ204L Driver Burkhard W. Kolb