Debugging the resilient high speed link between fpga boards
I will go over my hamming code VHDL with a fine tooth comb, as well as the processes that do the error checking on my high speed SPI links between master and slave fpga boards. I need to find the reason for sporadic conditions that cause high error rates, usually while operating the 1130, which might be triggered by some signal from the 1130 changing which is assigned to a link bit position susceptible to some design flaw. I don't think this is the cause, but it is a precautionary check.
Another potential cause is ground bounce due to the inadequate grounding between the 1130, SAC box fpga and slave fpga. Each signal is sent over a twisted pair in the SAC cable, which isolates the signals from common mode disturbances but the cumulative effect of the signals changing may be shifting ground between the three units. This is more likely.
It was indeed the grounding - a very solid ground connection to the SAC Interface unit and nothing to the slave fpga board worked wonders - zero errors. Onward to testing at least parts of the plotter and paper tape interface.
I should be able to do diagnostics that confirm the basic process from XIO Write issuance through completion interrupt and reset. That can happen with the plotter switched off, then when the plotter logic in the slave fpga is certain to be issuing the commands to the plotter interface hardware, and similarly to the paper tape units, I can be in position to start testing with real hardware in a few days.
Implementing physical plotter (1627 equivalent)
I will set aside the work on the Strobe 100 interface that appears as a 1627 plotter, since I will be getting and restoring a Calcomp 565 which is the exact plotter that IBM sold as the IBM 1627 model 1. I was at the point of tuning the timing to suit the slower speed of the Strobe, which will not be needed
As explained above, I did continue to test just to confirm that my basic logic and interactions between master and slave worked properly. That is, I would issue an XIO Write to the plotter, see the slave receive it, see the slave fire the command signal to the plotter interface, then see the master fpga trigger the interrupt. I should see appropriate sense in the DSW, and the interrupt trigger should only go away when the reset bit is set in the XIO Sense Device command.
I loaded up diagnostics to let me see what the master was doing. The slave has LEDs displaying the commands issued to the plotter interface. With those done, I went out to the system and fired up the test. I discovered that the master set up the command and thought it had fired off the transaction to the slave, but the slave sat inert. Further, a signal on the master that should have reflected the transaction request was not active.
Changing both sides for new diagnostics increases the agonizing period of inactivity to more than 50 minutes. A quick inspiration based on test results, changes developed in just a few minutes, then 50 minutes of delay to make it happen. Fortunately, this is a pretty simple transaction.
The master raises transaction and doesn't drop it until it gets the response. The slave sees the transaction, does its thing and then raises the response. When the master sees the response, it drops the transaction. The slave goes back to wait for new transactions once it sees the previous transaction signal drop. Nicely interlocked and not timing critical.
When all was finally set, I went out to debug the transaction flow. To my chagrin, the high speed link was back to huge error rates. Back to the link - that has to be rock solid before I can move on to the peripherals.
Implementing physical paper tape reader/punch (1134 and 1055 equivalents)
The paper tape reader needs one relay activated by the slave fpga to drive the motor and multiple sensing signals which are based on simple switches. Thus, I don't need any voltage shifters or other interface, simply a relay driver circuit.
The paper tape punch has to drive a relay for the motor but also eight output signals to drive the punches. Feedback comes from simple switches, those are easy. I will build 8 transistor driver circuits to feed the punch circuitry, plus two relay drivers for the reader and punch motors. When this is ready, I can wire up the reader and punch to the slave fpga and begin debugging tests.
I selected the components that will let me build this using off the shelf boards designed for hobbyists. A twin relay board will let me drive the two motors. An 8 channel power driver board can drive up to 100ma per channel at reasonable voltages, acting as a 8 bit shift register and gated output. Level shifters allow the TTL level boards to be interfaced to the LVCMOS 3.3V fpga pins. A small box, connectors, wiring between boards and I will be ready to go. The parts will arrive in a few days.