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





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

Navigate by Date:
Prev: Re: Multi-threading in BOY Python scripts Márcio Paduan Donadio
Next: Problem with CSS alarm notifier 龙巍
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 Michael Davidsaver
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 ·