Design work on interface to hook devices to 1130 through SAC

DESIGNING 1130 SAC INTERFACE BOX

One of my objectives in designing the interface to hook up peripherals to the 1130 was to allow more than one device to be hooked up at the same time. Outbound access from the 1131, via the XIO instructions, is inherently serialized but inbound access, both cycle stealing to move data and requests for interrupts, may occur from more than one of the devices in uncontrolled sequences.

Interrupt levels could be used by more than one device on my box, thus I have to keep track of requests and present them in appropriate priority order. Cycle steal requests share a single level with the SAC, but if more than one device asks for cycle stealing, I not only have to keep track and present requests in some order. I also have to block the devices which are not given the cycle stealing hardware from seeing the CS level occur.

The logic for each device would presume that when CS level 1 is active, its request for cycle stealing was granted. All devices which requested cycle stealing will attempt to control the hardware when they see CS Level 1 active.

I realized that on the 1130 system, the SAC is designed to support just one connected device.  In order to handle more than one, the 1133 Multiplexer cabinet is hooked to the SAC. The multiplexing logic in the 1133 is similar to what I want to do - it divides up the devices into a number of multiplex levels, prioritizing access, blocking visibility of control signals and holding requests until they can be presented.

Role of 1133 as a multiplexer for more than one device through SAC

I have a general outline for how I will implement the multiplexing, working from the control lines that are available on the SAC, the outbound sequences for XIO instructions and some thinking about the conditions and states that can exist for inbound requests from the devices.

Since each device adapter is responsible for almost all of the work of tracking the XIO instruction, latching data, signaling for writes to core, handling interrupts, cycle steals and sense status, the multiplexer logic is only involved in gating the interrupt and cycle steal signals between devices and the 1131. It only has to switch the gating based on priority as the active device drops its requests.

I also have a design for the FSM to track the stages of an XIO instruction and to recognize when to take certain actions such as latching data from the 1131, setting up and signaling channel write for data going out to the 1131, and setting other status information. This is the logic needed at the heart of a device adapter. It can be instantiated for each device interface being implemented for connection through the SAC.