|
CAMAC Universal Bridge System
(CUBS)
Epicure Design Note 135.3
26 April, 1996
Paul Kasley and Al Legan
I. Overview
This document outlines the design of an
Epicure-to-instrumentation bridge.
The Instrumentation Group has designed
several modules that need to be integrated into the Epicure control system.
These new NIM modules will include an Arcnet port through which parameters can
be passed to effect proper setup and operation
and by which data can be acquired.
Additionally, we may see increasing use
of commercially manufactured intelligent instrumentation in the beamlines and
experiment halls. Examples of such devices range from PID-loop controllers that
communicate using ASCII text strings on an RS232 connection to programmable
logic controllers (PLCs) that have an Ethernet port.
The purpose behind the development of
the bridge module is, in the short term, to have a solution to link
Instrumentation Group modules into Epicure. For the long term, it will provide
a gateway between Epicure and local slow data acquisition and housekeeping
networks. In situations where data acquisition requirements do not justify
installation of a local network, the module will be a flexible and cost
effective means to integrate one to several commercial devices into Epicure.
This proposal covers the flexible
bridge card and a proposed method for connecting CAMAC to the Instrumentation
Arcnet ("InNet"). The bridge will be configurable via a series of
add-on cards to handle protocols such as IEEE-488 (GPIB), Arcnet, Ethernet ,
ASCII serial, and HDLC serial protocols. The handling of devices other than the
NIM instrumentation modules is outside the scope of this document.
II. Bridge Module
A. General
The bridge is a standard CAMAC module
based on the C1010 design. The module will be physically split into a base
board carrying the i960CA processor and a common set of peripherals, and an I/O
board having the hardware and software needed to support a particular
communications scheme. The I/O board will connect to the processor board
through a right angle header such that the two boards mount flush to each other
(Figure 1). Inter-board connectors will be compatible with AMP AMPMODU System
50 (receptacle part number series 103911, header part number series 104118).
The height restrictions of the CAMAC specification prevent a mezzanine board
arrangement where the I/O board stacks on top of the main board. The I/O board
will include the 34 pin AUX card edge. The transition from the Viking connector
to a specific cable connector will be handled by a separate PCB mounted on the
rear of the CAMAC crate (Figure 2).
B. Main board hardware
The existing C1010 memory resources
will be enhanced. The 256 Kbyte SRAM, comprised of two banks of four each
0.300in 32Kbyte chips, will be replaced by a single bank of four 0.600in/.400in sockets. The sockets will be
configurable to accept either 128 Kbyte monolithic devices (512KB total), 512
Kbyte hybrid SRAM modules or 512 Kbyte monolithic SRAM (2MB total). The single
28F001 128K x 8 flash-ROM will be replaced with a pair of 32 pin PLCC sockets
that can accept either a 128 Kbyte 28F001 or a 256Kbyte 28F020. A set of
jumpers will be provided to control the flash PROM programming supply. The
flash chips will be independently programmable.
The common peripherals will remain on
the processor side of the module. These include the EADnet (Arcnet) port, an 8
Kbyte BBSRAM along with the Time & Date Clock built into the BBSRAM - (See
Fig. 5 for Timer Register Addressing), the TeV Clock decoder, the CAMAC Dataway
interface, and the DUART. The MADC parallel port will be deleted. The signal
lines for EADnet will be routed through the I/O card connector and from there
to the card edge. The EADnet port and the front panel and auxilliary serial port
DUART use standard components. The reader may refer to the manufacturer's
specifications for operation and programming details. The CAMAC port is
implemented in an Altera EPLD. The CAMAC register layout appears in Figure 3.
TeV Decoder registers appear in Figure 4.
The Processor-I/O connector defines a
16-bit data bus and a 20-bit address bus, plus timing, I/O, interrupt, status,
and control signals (Table 1). Power (+12V, +5V, -5V, GND) will be pinned to a
separate connector. Timing will be closely tied to the i960 local bus.
Table 1. I/O Card Connector
Signal |
Name |
Description |
Nr of lines |
D15:0 |
Data |
16-bit
data bus |
16 |
A19:0 |
Address |
Address
bus |
20 |
/BE0 |
Byte
Enable 0 |
Data
bus byte controls |
3 |
/BE1 |
Byte
Enable 1 |
|
|
/BE3 |
Byte
Enable 3 |
|
|
/IOSEL16 |
IO
Select |
I/O
card decode, word region |
1 |
/IOSEL8 |
IO
Select |
I/O
card decode, byte region |
1 |
/READ |
Read/Write
Select |
|
1 |
/ADS |
Address
Strobe |
|
1 |
/READY |
Ready
(input) |
|
1 |
/WAIT |
Wait
(output) |
|
1 |
/DEN |
Data
Enable |
|
1 |
/LOCK |
Lock |
atomic
memory cycle |
1 |
/RESET |
Reset |
|
1 |
PCLK |
Clock |
processor
clock |
1 |
/DREQ |
DMA
Request |
DMA
Ch.0 controls |
1 |
/DACK |
DMA
Acknowledge |
|
1 |
/WR |
Write
Strobe |
|
1 |
/RD |
Read
Strobe |
|
1 |
MHZ20 |
20
MHZ Clock |
Used
for (INNET) Arcnet Controller |
1 |
/EOP |
End
of operation |
|
1 |
/DMA |
DMA
cycle |
|
1 |
/INTI |
Interrupt
In |
i960
interrupt |
1 |
/INTO |
Interrupt
Out |
I/O
card interrupt |
1 |
EAD+ |
EAD
Arcnet + |
EAD
Arcnet differential I/O |
2 |
EAD- |
EAD
Arcnet - |
|
|
GND |
Ground |
Circuit
common |
5 |
HOLD |
Hold |
|
1 |
HOLDA |
Hold
Acknowledge |
|
1 |
|
|
Total
Pins |
67 |
Table 2. Main Card Memory Map
Address |
Access |
Description |
Device |
FFFC0000-FFFFFFFF |
Byte |
EPROM (128K x 8 parts) or |
28F020 |
FFF80000-FFFFFFFF |
Byte |
EPROM (256K x 8 parts) |
28F040 |
E0000000-E00FFFFF |
Longword |
SRAM (128K x 8 parts) 8 Pcs 1 Meg. Byte |
CY7C109 or equiv. |
D0000000-D0000008 |
See Fig.3 |
CAMAC Registers |
EPLD |
C0002000-C0003FFF |
See Fig.5 |
NVRAM With Timekeeper |
Dallas DS1643 |
C0000400-C00004FF |
Byte |
Front Panel LEDS |
PAL Decoded |
C0000300-C000030F |
Byte |
DUART |
Philips/Signetics 2692 |
C0000200 |
Byte |
TCLK FIFO |
CY7C408 |
C0000100-C00001FF |
Byte |
TCLK Mask RAM |
Cypress CY7C167 |
C0000000-C0000007 |
Byte |
EADnet Interface |
SMC COM20020 |
B0000000-B00FFFFF |
Word |
IO Card Word Address Space |
SEL16IO |
A0000000-A00FFFFF |
Byte |
IO Card Byte Address Space |
SEL8IO |
|
|
|
|
|
|
|
|
C. I/O Card
I/O cards will be required to have
on-board non-volatile memory (Flash (EPROM) to store device drivers and
protocol handlers that are specific to the card type. A block of I/O card
memory space is reserved for card specific identification, parameters, and
required CSRs that the processor card can access and use to configure and
communicate with the module. Configuration ROM reserved space must appear in
the I/O card byte-address space from A0000000-A003FFFF. CSRs will be mapped into the byte addressed
space. The remaining I/O card space is determined by the I/O card profile. Note
that the CSR space may be used for dual-ported RAM mailboxes between the main
card and the I/O card.
Unimplemented I/O card CSRs, flags,
and unused memory space will return all
ones when read by the main processor.
An I/O card processor and the main
processor will be able to interrupt each other through a pair of interrupt
lines. Registers in the I/O card CSR space contain a number that identifies the
interrupt source to each side of the interface. There is no interrupt vector
acquisition cycle across the I/O card connector.
All I/O Cards will have a Unique
address set by an 8 position DIP switch.
This will allow for the Main Processor to be able to discriminate
between all future I/O card types. The Address is A0040008H.
Table 3. I/O CSR Space and
Configuration Map
Address |
Bytes |
Name |
R/W |
Description |
A0000000 |
2 |
Flag |
R |
Fixed
pattern |
A0000002 |
2 |
Flag
Inverted |
R |
2s
complement of Flag |
A0000004 |
1 |
Hardware
Revision |
R |
|
A0000005 |
1 |
Firmware
Revision |
R |
|
A0000006 |
2 |
Card SN |
R |
I/O
card serial number |
A0000008 |
4 |
CSR
Base Adrs |
R |
|
A000000C |
4 |
CSR
Length |
R |
|
A0000010 |
4 |
RAM
Base Adrs |
R |
|
A0000014 |
4 |
RAM
Length |
R |
|
A0000018 |
4 |
NVRAM
Base Adrs |
R |
|
A000001C |
4 |
NVRAM
Length |
R |
|
A0000020-A000002F |
16 |
Cold
Boot Block Descriptor |
R |
|
A0000030-A000003F |
16 |
Warm
Boot Block Descriptor |
R |
|
A0000040-A000004F |
16 |
Programming
Code Block Descriptor |
R |
|
A0000050-A00000FF |
176 |
(Reserved) |
R |
|
A0000100-A00002FF |
512 |
Flash
ROM Descriptors |
R |
|
A0000300-A00004FF |
512 |
Code
Block Descriptors |
R |
|
A0000500-A003FFFF |
768 |
(Reserved) |
R |
|
A0040000 |
1 |
IO
Int ID |
R |
I/O
card to main interrupt ID |
A0040002 |
1 |
Main
Int ID |
W |
Main
to I/O card interrupt ID |
A0040004 |
1 |
IO
Card Status |
R |
I/O
card operational status |
A0040006 |
1 |
IO
Card Status |
R/W |
I/O
card programming and run ctrl |
A0040008 |
1 |
Card
ID |
R |
Identifies
I/O card type |
A004000A |
1 |
IO
Card Interrupt Enable |
W |
Re-enables
Hdw Interrupt |
A0040100- A004010F |
16 |
Duart
# 1 |
R/W |
I/O
Board Duart #1 |
A0040200- A004020F |
16 |
Duart
# 2 |
R/W |
I/O
Board Duart # 2 |
A0040300- A0040307 |
8 |
I/O
Arcnet (INNET) |
R/W |
I/O
Arcnet Address (INNET) |
D. InNet Card
The first I/O card produced will be a
non-intelligent module having an Arcnet port plus Three additional serial
ports. When combined with a main board, the resulting module will be an
Epicure-to-Instrumentation bridge. With additional firmware, it may also be
used as a bridge between Epicure and commercial instrumentation and control
devices. The InNet card will not be required to implement the interrupt ID
registers of Figure 8. Transition cards
will have a 2 Lemo connectors for each of the Arcnets and 3 - 8 Pin Modular
connectors for serial I/O. By designing break-away slots into the PCB layout
(Figure 1), the first fabrication pass will yield a complete set of four cards
per panel. Subsequent I/O card designs can be panelized with their respective
transition cards to achieve similar fabrication economies.
The Arcnet port will be a COM20020.
The serial ports will use
Philips/Signetics 2692 DUARTs. Single drop RS232 and multi-drop RS485 drivers
will be available simultaneously at the Viking connector. The line drivers and
receivers will not be electrically isolated from the module. General purpose
output pins on the DUARTS will be used to tri-state the RS485 drivers. The
outputs from the RS232 and RS485 receivers will be AND'ed before application to
a DUART receiver input. Each port will use a general purpose input pin as an
external RS485-level interrupt input. RTS, CTS, and a 1X TX/RX clock will also
be available on each port.
III. NIM Instrumentation Bridge Operation
The instrumentation bridge module is to
consolidate and forward data from the Instrumentation Arcnet
("InNet") to the front-end datapool via EADnet. The card will also
make InNet device registers accessible via CAMAC. Instrumentation cards use a
commercial protocol, ControLink, running on a Standard Microsystems Corporation
(SMC) COM20051 microcontroller. Refer to Epicure Design Note 136.x for InNet
protocol details and to SMC documentation for ControLink specifications.
The bridge will maintain a datapool of
the contents of all data registers and CSRs on all InNet modules for CAMAC
readback and it will package data from several NIM modules for re-transmission
on EADnet. The local datapool is updated by regular packets from the InNet
devices. The bridge will have CAMAC registers that specify when to return data
to the front end listener and when to invalidate the local pool. The times will
be specified as TeV Event plus delay.
A CAMAC maximum ID register will
determine the number of InNet modules that the bridge will service. The number
of modules is limited by the size of the pre-allocated listener common memory
block for the bridge module and by the content of the max-ID register on the
module. Modules not accessible to Epicure are permissible. An example is a
personal computer used as a local controller or data logger.
A NIM module may be composed of a
variable number of logical instruments. Each logical instrument, or device,
within a hardware module is to be assigned a unique module Service Access Point
(SAP).
On Arcnet reconfiguration, the bridge
scans the InNet and constructs a map of the module IDs that are present. It
then queries each ID to determine its type and configuration and sets up slots
for each logical instrument in the EAD datapool return packet. IDs are scanned
sequentially from $01 to [max-ID]. The scan continues until either all modules
are logged onto the bridge or until the maximum number of node IDs has been
scanned. Modules that do not get logged are simply not accessible to Epicure.
They can continue to operate within the local InNet.
The CAMAC procedure to write to an
InNet device is
1. Write the destination arcnet address
and device SAP to the InNet DID register F()A()
2. Write the InNet function register
F()A()
3. Read the "execute"
register F()A()
or repeated instances of
3. Write the destination device address
pointer register F()A()
4. Write succesive 16 bit words to
out-bound buffer register F()A()
followed by a single
5. Read the "execute"
register F()A()
Writing to the device address pointer
register causes the bridge to insert a delimiter into the out-bound buffer.
Upon receipt of the "execute" function, the bridge updates the error
status, builds a packet, passes it to the link layer services, and invalidates
the local datapool for that device. All data and CSRs for the device remain
invalid until the bridge receives an update packet.
The DID, function, and address pointer
registers are CAMAC readable. They do not autoincrement. They are not affected
by any other CAMAC functions except reset. The current error status appears in
bits 17 through 24 of every CAMAC read operation.
This method conserves F and A codes,
accomodates an arbitrary number of InNet module IDs, allows writing variable
length fields to an arbitrary address within a device, provides an implicit
mechanism for building packets of variable length, and allows code download in
addition to CSR access.
E. CAMAC Access of the Device CSR
Datapool
The data and CSRs for a device are read
over CAMAC by
1. Writing the device DID and SAP to
the device select register F()A(). The bridge processor locks the selected
datapool, copies it to a temporary buffer, unlocks the datapool, and clears the
address pointer.
2. Writing a 16 bit address to address
pointer F()A() if neccessary.
3. Reading successive data or CSRs at
data register F()A(). Data is read from the temporary copy made in step (1).
The data valid flag and error status is returned in the high byte of the CAMAC
data.
The device select register and the
address pointer are CAMAC readable. The address pointer autoincrements with
each read of the data register.
F. EADnet Return Data
The EADnet return from the bridge
consists of one or more packets formatted as:
1. EADnet header including NTI, packet
count and packet sequence number
Multiple instances of
2. Device InNet node ID and SAP
3. Device InNet status (not present,
not responding, stale, etc.)
4. Device data field length
5. Device data
A data block will be present in the
EADnet transmission for every logical device on every Arcnet module ID up to
and including the maximum set in the CAMAC max-ID register. The listener will
retrieve blocks based on Arcnet ID and SAP rather than an offset from the start
of the datapool block. This will allow the InNet to change dynamically without
having to advise Listener each time a reconfiguration occurs on any InNet.
Each datapool return from the bridge
will be for a fixed number of modules. The length and number of return packets
may vary as a function of the specific InNet module types in use, the number of
logical devices on the modules, and the length of the data field for each type
of logical device.
G. Bridge TeV Clock Service
TeV events may be decoded by the bridge
and broadcast to the InNet. A CSR in the bridge will provide on/off control of
TeV event broadcasts. This feature may eliminate the need for separate TCLK
distribution in areas where the latency of the TCLK re-transmission over the
Arcnet can be tolerated.
H.
DB25 to 8 Pin Modular Connector Wiring.
Color |
DB25- Pin# |
Mod- Pin# |
Discription |
Black |
2 |
3 |
RS232 X-Mit or RS422 X-Mit + |
Orange |
3 |
2 |
RS232 Receive or RS422 X-Mit - |
Blue |
7 |
1 |
Gnd |
Red |
12 |
4 |
RS422 RX+ |
Green |
13 |
5 |
RS422 RX- |
Yellow |
14 |
6 |
INT Input + |
Brown |
15 |
7 |
INT Input - |
White |
16 |
8 |
+5 Volt |
I.
DB9 to 8 Pin Modular Connector Wiring.
Color |
DB25- Pin# |
Mod- Pin# |
Discription |
Black |
3 |
3 |
RS232 X-Mit or RS422 X-Mit + |
Orange |
2 |
2 |
RS232 Receive or RS422 X-Mit - |
Blue |
5 |
1 |
Gnd |
Red |
6 |
4 |
RS422 RX+ |
Green |
7 |
5 |
RS422 RX- |
Yellow |
8 |
6 |
INT Input + |
Brown |
9 |
7 |
INT Input - |
White |
1 |
8 |
+5 Volt |
J.
Revision History
135.0 10
January 1995 Original issue
135.1 27 July 1995 By Al Legan
135.2 02 October 1995 By Al Legan
135.3
26 April 1996 by Al Legan