SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
Debugged the 1627 plotter interface
I switched my diagnostic light signals around to spot what was happening with the pin used to drive Carriage Right on the plotter. I found that pin D28 of the fpga board was at ground but should have been high like all the others nearby.
Some more diagnostic changes were made and I tested again, this to looking to see what state the fpga logic 'believed' the pin should be. I am narrowing down the issue to see if it is a physical board problem, an fpga hardware issue, a synthesis tool failure, a subtle logic problem in my vhdl code, or something else.
All functions of the plotter were activated, but when I put the machine into a tight loop, issuing a plotter movement and redriving it as soon as I received the operations complete interrupt from my adapter, I didn't get smooth movement. It seemed to miss some steps, which implied to me that my timer of 3ms is not long enough for the plotter hardware adapter and the Strobe 100 mechanism to recover from one move and accept a next command.
I didn't have documentation for the Strobe 100 plotter but did some internet searches in order to find any speeds and feeds that might guide me. Those turned up nothing at all, so I had to experiment to see what delay would work. I increased the timer from 3ms to just over 5ms and retested. I also tried 2.6ms, but it was hard to spot a difference among them and in no case did the plotter seem to move smoothly and fast. I think I need to test over a wider range of driving signals.
I did find some timings that seemed to work okay, but I need to tune in two different timings. The first is the length of the logic pulse that triggers the plotter, which has to be long enough to ensure it triggers but not so long that it moves more than one step. The second timing is the total delay before the device goes not busy and signals an interrupt. If this is too fast, the mechanism is still moving which will interfere with smooth overall action but if it is too slow the performance of the plotter is sharply reduced.
Playing with timing pairs was a tedious business, but I did arrive at values that seemed to deliver a decent behavior and reasonable speed. Once that was set, I adjusted my driving program in the 1130 to draw a small rectangle using a sequence of commands.
The rectangle is a bit small, due to the small step size of the plotter. I will try to increase its size a bit, while I prepare to shoot a short video clip of the 1130 drawing the rectangle under program control.
Serial links to other fpga and microcontrollers
If I am going to operate the high speed SPI bus at speeds approaching the 48MHz of the fpga board and support realistic distances between the main fpga board and any secondary boards, I needed to find differential converters that could meet my needs for distance and signaling rates.
I found the LTC1518 and LTC1688 chips which can drive signals at 50Mbps over cat 5 cable for 100 feet. These take single ended signals from the fpga SPI pins and drive the twisted pair to the receiving end where they yield a single ended output for the secondary fpga board.
I should begin with an SPI link operating at a lower speed, use it to link to fpga and arduino boards. I can use the paper tape reader as the first device connected this way. OpenCores has an SPI master and slave pair that is proven to operate at 50MHz with Spartan 6 fpgas - thus perfect for my boards.
Richard Stofer reminded me of the mbed microcontrollers, another option with more power than the Arduino, which I can add to the design pool for handling devices. He developed a 1627 plotter emulation for his IBM 1130 emulator using an mbed and shared the source code with me several years ago. I still have that mbed somewhere - it takes the 1130 plotter operations and converts them to HPGL to plot on an HP printer or plotter over ethernet.
The high speed SPI link is intended to extend input/output signals beyond what can be hosted on the core fpga board. Each board I am likely to use is going to have capabilities of 50 to a bit over 100 pins. Thus, my protocol is going to be set up for worst case, that all are either outbound or inbound.
I choose a SECDEC version of a Hamming Code allow possible correction of single bit errors and detect double bits. This would place eight parity bits along with 120 data bits onto a 128bit wide SPI 'word'. It will start out simply as a detection mechanism - ensuring that I spot and ignore any frames that contain errors. Later I can add in the correction on the fly circuits.
I don't want sporadic glitches driving output actions on peripherals, so I am willing to lose a few frames to reduce the risk of glitching. Any signal change that is not extremely short will be picked up on the next frame which does not have parity errors. With the speed I intend to operate the link, I should be sending a frame in about 2.5 microseconds. Even skipping several in a row is unlikely to miss a mechanical device controlling signal which would be millisecond range or longer.
Of course, that analysis is true for a single secondary fpga board handling expansion of up to 120 signals, but even if I tripled the number of secondary boards, we are still under 8 microseconds to deliver a frame update to every board.
Data streaming in from a fast device like a disk drive would be passed by a parallel word and interlocking, so that lost frames don't lose any data. The width of the parallel word is a tradeoff between losing external signals and performance needs of the device. A disk controller might dedicate many more bits to an interlocked buffer than the board controlling paper tape, terminal or card devices.
I began developing the logic for the SPI master (and a mirrored SPI slave version). The sending side will generate parity and transmit the latest version of its outbound signals, while its receiving side will accept frames, parity check and update registered signals, A simple pump that mirrors the state of signals to the remote side, the direction depending on whether the signal is an output or input of the master fpga.
The slower SPI link is intended to communicate with slower devices, typically microcontrollers like Arduino, mbed etc. I set that up with 8 data bits used pairs of words to include parity and protocol along with the data.
The initial implementation will be slowed to just under 1MHz, sending a frame each 125 microseconds. this is still fast enough to operate paper tape and plotters during the first phase before I ratchet up the link to full speed.
If I am going to operate the high speed SPI bus at speeds approaching the 48MHz of the fpga board and support realistic distances between the main fpga board and any secondary boards, I needed to find differential converters that could meet my needs for distance and signaling rates.
I found the LTC1518 and LTC1688 chips which can drive signals at 50Mbps over cat 5 cable for 100 feet. These take single ended signals from the fpga SPI pins and drive the twisted pair to the receiving end where they yield a single ended output for the secondary fpga board.
I should begin with an SPI link operating at a lower speed, use it to link to fpga and arduino boards. I can use the paper tape reader as the first device connected this way. OpenCores has an SPI master and slave pair that is proven to operate at 50MHz with Spartan 6 fpgas - thus perfect for my boards.
Richard Stofer reminded me of the mbed microcontrollers, another option with more power than the Arduino, which I can add to the design pool for handling devices. He developed a 1627 plotter emulation for his IBM 1130 emulator using an mbed and shared the source code with me several years ago. I still have that mbed somewhere - it takes the 1130 plotter operations and converts them to HPGL to plot on an HP printer or plotter over ethernet.
The high speed SPI link is intended to extend input/output signals beyond what can be hosted on the core fpga board. Each board I am likely to use is going to have capabilities of 50 to a bit over 100 pins. Thus, my protocol is going to be set up for worst case, that all are either outbound or inbound.
I choose a SECDEC version of a Hamming Code allow possible correction of single bit errors and detect double bits. This would place eight parity bits along with 120 data bits onto a 128bit wide SPI 'word'. It will start out simply as a detection mechanism - ensuring that I spot and ignore any frames that contain errors. Later I can add in the correction on the fly circuits.
I don't want sporadic glitches driving output actions on peripherals, so I am willing to lose a few frames to reduce the risk of glitching. Any signal change that is not extremely short will be picked up on the next frame which does not have parity errors. With the speed I intend to operate the link, I should be sending a frame in about 2.5 microseconds. Even skipping several in a row is unlikely to miss a mechanical device controlling signal which would be millisecond range or longer.
Of course, that analysis is true for a single secondary fpga board handling expansion of up to 120 signals, but even if I tripled the number of secondary boards, we are still under 8 microseconds to deliver a frame update to every board.
Data streaming in from a fast device like a disk drive would be passed by a parallel word and interlocking, so that lost frames don't lose any data. The width of the parallel word is a tradeoff between losing external signals and performance needs of the device. A disk controller might dedicate many more bits to an interlocked buffer than the board controlling paper tape, terminal or card devices.
I began developing the logic for the SPI master (and a mirrored SPI slave version). The sending side will generate parity and transmit the latest version of its outbound signals, while its receiving side will accept frames, parity check and update registered signals, A simple pump that mirrors the state of signals to the remote side, the direction depending on whether the signal is an output or input of the master fpga.
The slower SPI link is intended to communicate with slower devices, typically microcontrollers like Arduino, mbed etc. I set that up with 8 data bits used pairs of words to include parity and protocol along with the data.
The initial implementation will be slowed to just under 1MHz, sending a frame each 125 microseconds. this is still fast enough to operate paper tape and plotters during the first phase before I ratchet up the link to full speed.
No comments:
Post a Comment