From: eric@skatter.usask.ca
Subject: Problems with MVME167 and CAMAC
Organization: University of Saskatchewan
Date: Mon, 5 Oct 1992 17:33:57 GMT

A few months ago I posted an article mentioning the problems we're having
with our MVME167 data acquisition system.  Since then I've received a number
of letters from other people having similar problems.  I've been asked to
repost the problem in the hopes that someone can explain what's wrong.

The VME portion of our data acquisition system is quite simple:
	Motorola MVME167 (25 MHz 68040) VME cpu card
	Creative Electronic Systems CBD8210 CAMAC parallel branch driver

We have 3 CAMAC crates on the parallel branch now, but the problem remains
the same even with just one CAMAC crate.  In any case, the CAMAC parallel
branch always ends in a visual branch terminator CAMAC module in the crate
farthest from the parallel branch driver.

An aside for those who've never heard of CAMAC:  CAMAC is an IEEE standard
for data acquisition/process control modules installed in `crates' which are
interconnected by a data `highway'.  The standard provides for both serial
and parallel data highways.  The CBD8210 is a controller for a parallel
data highway referred to as a parallel branch highway.
Modules are addressed by their branch(B), the crate(C) in which they are
located, and their position(N) within that crate.  As well, each module can
have up to 16 subaddress(A) codes and 32 function(F) codes.  The CBD8210
parallel branch driver encodes each BCNAF code to a single address in the
VME A24/D16 space.  For example, the following instruction will read a
16-bit word from subaddress 0, of the module in station 1 of crate 1 on
branch 0, using function code 0:
	movew	@#0xf0810802,d0

The problem we're having is that it seems that the CBD8210 VME/CAMAC
handshaking hardware is unabled to keep up with two closely-spaced operations.

When we attempt to rapidly perform several CAMAC operations the CBD8210
locks up and does not finish the CAMAC or VME bus cycles.  This results in an
ACCESS FAULT exception that is indistinguishable from a module NO-X response.

Here is a code fragment (produced by our 68030/68040 C compiler) that
illustrates the problem.  The code is supposed to read 8 16-bit words from
the same CAMAC location into a buffer.  The point at which the failure occurs
is noted.

	lea _buf.0,a0
	movel #-259680254,a1    <=== B(0) C(5) N(19) A(0) F(0)
	movew a1@,a0@
	lea _buf.0+2,a0
	movew a1@,a0@+
	movew a1@,a0@+          <=== 68040 ACCESS FAULT EXCEPTION (exception 2)
	movew a1@,a0@+               with program counter pointing to
	movew a1@,a0@+               this instruction.
	movew a1@,a0@+
	movew a1@,a0@+
	movew a1@,a0@

We have also tried to use the CBD8210 with a Motorola MVME147 (25 MHz 68030)
cpu board.  WIth this setup we have found that code like the example above
works `most of the time', but that consecutive non-data-transfer operations
(e.g. F8 through F15, F24 through F31) often give ACCESS FAULT exceptions.
The following three instructions almost always fails on the second or
third instruction:
	movew @#0xf08198ea,d0 ; B(0) C(1) N(19) A(1) F(26)
	movew @#0xf081a0ea,d0 ; B(0) C(1) N(20) A(1) F(26)
	movew @#0xf081a8ea,d0 ; B(0) C(1) N(21) A(1) F(26)

We're using the default 64 microsecond VMEbus global timeout and 32 millisecond
VMEbus access timeout that the Motorola ROM's set into the VMEchip2.

When we contacted CES about these problems we were told that no one else had
ever reported difficulties with the CBD8210.  Now that I've heard from several
other people that *do* have the same problems I'm not sure what to do.
Is there something funny about the VME timing on the MVME167?  With the A24/D16
space in particular? Any ideas?

Help gratefully accepted.

--
Eric Norum                     eric@skatter.usask.ca
Research Engineer              phone: (306) 966-6308
Accelerator Laboratory
University of Saskatchewan