Beginning design of an FPGA based 370 channel, needed to drive my Telex tape drives

THE NEED

Once I have the tape drives able to load tapes and move them forward and backward, I will run out of tests I can accomplish solely with the tape subsystem. To be able to send commands to the drive over the channel, as well as cause it to write and read back data from the tapes, it needs a 370 Input-Output Channel such as would be on an IBM mainframe of the era.

This means I can't really verify whether the read/write circuits work properly without a channel. Simple movement doesn't prove it can handle commands such as forward space past next tape mark. Also, the status and sense bytes that need to be returned can't be viewed without the channel to request them.

THE APPROACH

I chose to implement a 370 channel in an FPGA because this will be useful for a number of future projects in addition to testing my tape drives now.  This will require me to control 16 outputs and receive 15 inputs. In addition I will output a periodic Clock out and steady low Meter Out, terminating and ignoring Meter IN.

These are designed for SLT logic levels (+3 for high, 0 for low) with specific thresholds, currents and protections. This will be addressed by use of converter PCBs that build drivers with an LVCMOS (3.3) input and receivers that produce an LVCMOS output, but are SLT at 92 ohm impedance on the cable end.

This FPGA channel must be fast enough to handle the 781,250 bytes per second coming from a tape drive, thus a data rate of more than 6.25MB/s. I have to define a connection and protocol from the fpga to some computer where I can generate the software channel programs, source data for writing and receive data and sense information.

In my initial implementation my link to the computer does not need to support 6.25MB/s as each channel program and its data can be preloaded at slower rates, then results fetched at slower rates, as long as the actual transfer over the bus and tag occur at the full rate.

RESEARCH MATERIALS

I will use several references in building the specifications for my FPGA channel. The goal is to have definitions of state machines and logic equations for all output signals based on the states. When that is ready, coding it in VHDL will instantiate the machines.

IBM publishes a document that locks down the specifications over the Bus and Tag cables. It is A22-6843-x, IBM System/360 I/O Interface Channel to Control Unit Original Equipment Manufacturers' Information. This will be the first source. I need to understand updates that may have occurred by the time of the 370 version of the channels, which may be a different manual title or otherwise documented by IBM.

Telex schematics show me how they implemented the channel interface for the tape drive controller, which I can cross reference to be sure I understand the IBM documents. Some of this is implemented in firmware in the control unit ROM, thus may require quite a bit of effort to extract for understanding. One has to understand the architecture of the controller engine then must examine each instruction to see what it does.

We (will) have access to the full schematics of the IBM 360/50 mainframe. We already have all the microcode. The channel microcode and schematics show how IBM implemented the channels in the 360 model 50 which is another cross reference to validate what I learn from the documents.

The material from the 360/50 will not include any enhancements made for 370 channels and upon which the tape drive may rely. Hopefully I can back-fit the enhancements to my understanding of 360 channels.

The 360/370 channels come in three flavors, although one of them is not appropriate for use with high speed devices such as the tape drives. These are Byte Multiplexors, Selectors and Block Multiplexors. IBM spells their multiplexer channels with an 'o' - Multiplexor.

Selector channels are for high speed devices and will be busy during the entire channel program. Thus, if the tape has a 10,000 byte record and transfers at 781,250 bytes per second, it will tie up the channel for 12.8 ms until the transfer is done. Worse is when the channel program is searching for a specific record header on disk where up to an entire rotation of time can be required; the channel stays busy for this. Selection is for the transfer of an entire block at a time.

Multiplexor channels are for low speed devices. They select for the transfer of a byte of data then disconnect. This allows multiple slow devices to be overlapping their data transfer, as they multiplex their bytes over the channel.

The Block Multiplexor channel allows for concurrent command chained operations for each device, thus more than one device may be searching for a disk sector but they remain disconnected until the condition is satisfied. Data transfer overlap depends on the speed of the devices, the speed of the channel and the overhead of the control unit requesting the reconnection.