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: | Re: MVME-5500 Universe II |
From: | Amit Chauhan <[email protected]> |
To: | [email protected] |
Date: | Wed, 29 Jul 2015 19:00:26 +0530 |
Hello Michael, Thanks for the reply. Ya, the address modifier used is 0x39 (A24 non-privilege Access). You are right that when you say that VME master can't be expected to accommodate a non-compliant slave. That is what one aspect of the problem is and in some slaves the modification is not easy to make at present. The another aspect is that the same master is behaving differently under the control of different firmware (ie. MOTLoad vs. vxWorks) thereby accommodating even a non-compliant slave under one condition( MOTLoad). I am looking if the same master behavior can be 'programmed' under vxWorks also. Regards, Amit. On 29-07-2015 17:23, Michael Davidsaver
wrote:
Hello Amit, Many VME bus control lines (AS, DS*, and DTACK) are used for asynchronous handshaking. Sometimes the edge is important, and sometimes the level. The rules are complex. Simply saying "A24" or "A16" isn't necessarily sufficient. Giving the exact address modifier in a good idea. In this case I'm guessing its 0x39, 0x3A, 0x3D, or 0x3E. I think you have a non-compliant slave card. In my experience an unfortunate, but not unusual, occurrence. VME is more difficult to get right than other parallel buses (ie PCI). A VME master can't be expected to accommodate a non-complaint slave card. You should find a copy of the VME standard document. If you can find ANSI/VITA 1-1994 look for figure 2-8 "Non-multiplexed Address, Single-Byte Read Cycle". In particular, the following statement describes a clear violation of the VME standard when applied to a single cycle read.Some slave boards do not use DS* to derive DTACK*. They derive DTACK* using AS* only.The following is a less clear violation. My reading of the standard is that the slave should not react to the AS* line going high. In figure 2-8 the slave side flow includes "Receive AS* low", but never "Receive AS* high". The read is complete when the DS* lines are driven high.1. CPU asserts AS* and DS* signals. 2. Slave board responds with DTACK*, 3. CPU removes only DS* and *not* AS*. It expects the slave to remove DTACK*. 4. Only on finding the DTACK* removed by slave, the master removes AS* ending the cycle.In practice, after the slave asserts DTACK, I've seen VME masters release AS and setup the address for the next operation. I don't think this is a question of master configuration, but rather of the time between accesses. Isn't VME fun :) Michael On 07/29/2015 02:32 AM, Amit Chauhan wrote:Hi All, This is regarding the working of Tundra Universe II on VME based MVME-5500 CPU Board. Three of the important signals on VMEbus are Address Strobe (AS*), Data Strobes (DS0* & DS1*) and Data Acknowledgement (DTACK*). In a normal VMEbus data transfer cycle, the master asserts AS* and DS* signals. When a slave board responds with DTACK*, the master removes AS* and DS* and in turn slave also removes DTACK* thereby ending the cycle. Two common types of addressing (for slave boards)are : *A16* (16-bit addressing) and *A24* (24-bit addressing). On a MVME-5500 CPU,we have observed following three cases: _*Case-1:*_ CPU runs under *MOTload* (native bootloader) and performs *A24* cycle. 1. CPU asserts AS* and DS* signals. 2. Slave board responds with DTACK* 3. CPU removes AS* and DS* 4. In turn slave also removes DTACK* thereby ending the cycle. _*Case-2:*_ CPU runs under *vxWorks* and performs *A16 *cycle. 1. CPU asserts AS* and DS* signals. 2. Slave board responds with DTACK*. 3. CPU then removes AS* and DS* 4. In turn slave also removes DTACK* thereby ending the cycle. _*Case-3: *_ CPU runs under *vxWorks* and performs *A24 *cycle. 1. CPU asserts AS* and DS* signals. 2. Slave board responds with DTACK*, 3. CPU removes only DS* and *not* AS*. It expects the slave to remove DTACK*. 4. Only on finding the DTACK* removed by slave, the master removes AS* ending the cycle. Case-3 (A24, vxWorks) is the most used cycle type. It is causing the problem as not every slave follows the sequence expected. Some slave boards do not use DS* to derive DTACK*. They derive DTACK* using AS* only. In such cases CPU's AS* and Slave's DTACK* remain asserted causing a deadlock. It seems the vxWorks BSP programs the Tundra Universe II chip for Case-3 in such a way that it behaves differently from Case-1 (MOTLoad) for A24 cycles. Can we make any changes somewhere in vxWorks BSP or initialization-codes for Universe II so that CPU removes AS* when it finds DTACK* asserted by slave for A24 cycles also, which it is doing for A16 cycles . Regards, Amit. |