EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  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  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: MVME-5500 Universe II
From: Michael Davidsaver <[email protected]>
To: [email protected]
Date: Wed, 29 Jul 2015 15:04:43 -0400
On 07/29/2015 09:30 AM, Amit Chauhan wrote:
> ...
> That is what one aspect of the problem is and in some slaves the 
> modification is not easy to make at present.

I've been involved in fixing several cards, both in-house designs, and
commercial.  It's possible, but never easy :(

> 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).

Any such configuration would be in one of the control registers for the
universeII.  The two I can see which might relate to your situation are
the Coupled Window Timer in the LMISC register.  Also the U2SPEC
register.  It might be worth seeing if these are different in your two
cases.


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


Replies:
Re: MVME-5500 Universe II Johnson, Andrew N.
References:
MVME-5500 Universe II Amit Chauhan
Re: MVME-5500 Universe II Michael Davidsaver
Re: MVME-5500 Universe II Amit Chauhan

Navigate by Date:
Prev: RE: Multi-threading in BOY Python scripts Williams Jr., Ernest L.
Next: Re: MVME-5500 Universe II Johnson, Andrew N.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: MVME-5500 Universe II Johnson, Andrew N.
Next: Re: MVME-5500 Universe II Johnson, Andrew N.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·