1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Delta Tau Turbo PMAC2 VME Ultralight A24/A32 VME address space problem |
From: | Ron Sluiter <[email protected]> |
To: | EPICS <[email protected]> |
Date: | Thu, 6 Nov 2014 14:05:15 -0600 |
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;
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 |