Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: ISEG VHQ204L Driver
From: "J. Frederick Bartlett (bartlett@fnal.gov)" <bartlett@d0mino.fnal.gov>
To: ahed.aladwan@psi.ch
Cc: kasemir@lanl.gov, tech-talk@aps.anl.gov, bartlett@d0mino.fnal.gov
Date: Wed, 24 Jul 2002 14:05:35 CDT
> Hello:
> 
> 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.
> 
> Thanks,
> -Kay


  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
working stack.

  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.

							Fritz


Replies:
Re: ISEG VHQ204L Driver Burkhard W. Kolb
References:
RE: ISEG VHQ204L Driver Kay-Uwe Kasemir

Navigate by Date:
Prev: Re: switch clock Maren Purves
Next: side-effect of malloc() in startup file Peregrine M. McGehee
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: RE: ISEG VHQ204L Driver Kay-Uwe Kasemir
Next: Re: ISEG VHQ204L Driver Burkhard W. Kolb
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·