Wednesdays are the day I visit the CHM to meet with the rest of the team and repair anything that is not working on the two 1401 systems. We had two problems related to one of the 1403 printers - a driver card had a blown fuse, and one of the print solenoid coils that fires a hammer partially shorted and burned.
I repaired the driver card, using new-old-stock fuses we have to solder it in place after removing the blown component. Other members cut off the burned coil, soldered in a new-old-stock replacement and put the printer back together.
In addition, we received a 1403 type chain, manufactured by one of the team at the museum in Binghamton, NY. We will install this in a train case and try it out on one of our printers, as a test of the process he used. If it works, it will allow us to make multiple print chains for use on our two 1403 printers and the 1403 printer at the Binghamton facility.
We have been worrying about the fragility of the chains given the complexity of making replacement parts, so this is an exciting potential source to allow us to keep these systems running indefinitely. Once the chain passes tests, we will send a couple of people from the CHM restoration team out to NY to learn how to make more.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
Restructuring the GUI
-- virtual 1442 card reader and punch --
I tested the feed operation - will advance a card without emitting IL0 interrupts or causing reads to take place. My logic worked properly for this as well, so that both card reading and card feeding are solid.
I still have a problem with the copyover. The data I see coming out of the pre-punch memory for card column 2 is the value that was in column 1 in the pre-read memory. They use the exact same address and I see the correct value on the input lines to the memory when it is written a cycle or two before I sample it. Inexplicable.
At times like this, when I can't find any logical reason for the flaw, I try rewriting the section of logic, often with a slightly different approach, hoping to eliminate whatever obscure cause was generating my problems. I decided to change way I locked in the buffer memory addresses, even though the exact same string is used for both memories.
I was setting up the address with a mux, selecting one leg when the copyover process has moved away from idle state. The leg has std_logic_vector(to_unsigned((copyidx+1),7)) as the source of the address. This takes the integer counter copyidx, adds 1 to it, then converts it from an integer to a SLV with one signal per binary digit comprising the integer value. This was implemented at a time when I had a special use for buffer address 0, but it is no longer relevant.
It should take the value of copyidx, which is stable for several clocks around the time it matters, run it through an adder with a constant of one as the other operand, then route it as the memory address. I don't know how it could be getting this wrong, but I will change all my logic so that I use the index copyidx as it is, ranging from 0 to 79, eliminating the need for an adder in the address mux.
I also put in some diagnostic LEDs to compare the value in the data in lines and the data out lines for the pre-punch buffer, at the time we are looking at card column 2 in the copyover and have completed the write. I am finding that I am unable to update the pre-punch buffer memory even though I trigger the write and set the write enable flag.
I did see a type mismatch - the replacement VHDL I wrote to infer block ram used a simple signal as write enable, but the block box IP I had been using had a std_logic_vector of length 1 instead. I cleaned up all the code to be consistent and retested.
I still see a mismatch between the pre-punch memory input and output - indicating that it is not storing the right value. It agrees if the input is 0, but if the input is a 1 then we see a 0 on output. Oddly, some conditions give me a 1 on the output, but not the cases where I expect it to happen.
For the time being, I moved to the get special data routine which is failing to pick up the data from the pre-punch buffer (or that data is always blanks). I continue to hit a brick wall on this.
With some lingering suspicion that the block ram may not be working for some obscure reason, I set up the block memory module to force it to use distributed RAM rather that block RAM. This means the memory will be implemented using lookup tables throughout the FPGA rather than the dedicated block ram units on the chip.
Sadly, the results were exactly the same. I have cleared the reputation of the block RAM and toolchain, Back to allowing it to be implemented as block RAM and back again to the struggle to figure this out. I keep trying to change things in the hope that it resolves the problem but no luck so far.
No comments:
Post a Comment