Delta Tau Turbo PMAC2 VME Ultralight A24/A32 VME address space problem

[Ron Sluiter <sluiter@aps.anl.gov>]

FYI,

After several months of investigating various and intermittent problems here at the APS, I have finally determined that the root cause of these problems is the Delta Tau Turbo PMAC2 VME Ultralight's VMEbus interface.  A Turbo PMAC2 VME Ultralight, whose DPRAM is configured for A24, will respond to a A32 write cycle if it is preceded by a A24 write cycle to the PMAC's DPRAM and the A32 write cycle has the same lower 24 address bits as the A24 write (confusing, I know. See the five VMEbus transaction steps below).

I have a test program that I use to drive VMEbus data collection on a VMETRO VMEbus analyzer. The test program is NOT definitive; it is sensitive to both compiler optimization (only works without optimization) and out-of-order bus transactions; but the VMETRO data IS definitive.

The order of bus transactions to create a failure is;

1. A24@0x70 0674 write 0x1000 to PMAC DPRAM
2. A24@0x70 0674 read 0x1000 from PMAC DPRAM (this step is to confirm the previous write, not really a required bus transaction)
   
3. A24@0x70 0EA0 write 0x4000 to PMAC DPRAM
4. A32@0xA070 0674 write 0x8000 to Hytec DAC8402 DPRAM, or MAXv DPRAM, or no DPRAM (the problem occurs even if this bus transaction results in a VMEbus BERR)
   
5. A24@0x70 0674 read 0x8000 from PMAC DPRAM (this step confirms that step #4 resulted in a write to the PMAC's DPRAM)
   

Steps #3 and #4 are key.
The same problem occurs if the PMAC is configured for A32 and step #4 is a write to the A24 address space.

I was in contact with Delta Tau on this problem.  They informed me that "this is a product that will soon be placed on legacy status" and there is no plan for a fix.  The work-a-round is to make sure that the low order 24 bits of the PMAC-VME DPRAM and mailbox address spaces are unique in both the A32 and the A24 VMEbus address spaces.

Ron