Epicure to Instrumentation Bridge

Epicure Design Note 135.2

2 October, 1995

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

C0000201 Byte TCLK FIFO Cypress CY7C408

C0000200 Byte TCLK FIFO Status

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


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


Security, Privacy, Legal