Restructuring the GUI
-- virtual 1442 --
I made a change to the logic that simulates the emission of IL0 interrupts for each card column of the 1442. I had written the state machine to reflect the timing of a 1442 - 20+ ms wait from starting a read or punch until the first column is under the photocells and then a column arrives every 1.125 ms causing an interrupt. The remaining time, 40 ms as the card comes to a stop in the next station, is modeled before it signals completion and drops the busy status.
My prior logic waited for the program to issue the XIO Read to pick up the results of a card column before it moved on with the delay and emission of the next column interrupt. A real 1442 does not do this - it fires off column interrupts every 1.125ms whether the CPU is able to keep up with XIO Read or not. I now simulate this exact behavior, same for punch except the interrupts are once per 6.125ms in that case.
No difference in the behavior after this change. I am going to set up some logic to tell me if the buffer is loaded with the duplicated character or if it is a phenomenon of access during the XIO Read. When I tried to test, I had multiple failures that are hard to understand given the small changes I made. Some look to be hardware problems in the 1130 itself or the SAC interface.
For example, when I try to load core from a file, I get errors where bit 4 is not writing when it should be. It writes just fine when I toggle it in from the console, so it may be an issue with my SAC Interface driver for that bit. Why it would act up now is a mystery.
I attempted a test of the 1442 but encountered timeouts in the transactional engine. This sets me back as I now have to redo all the diagnostics to a very basic level until I find the cause of the stall, then go back to working on the 1442 device behavior.
Well, when I had it all set up with the new low level diagnostics, I powered up and the problems went away! Loading core works well, all 16 bits. The transactions don't time out at all. I attribute this to one of those Xilinx things, where the untrustworthy toolchain produces broken output and it all goes away with a re-synthesis even with trivial changes.
I can turn back to work on the off by one issues, in main core and as the data is copied over from pre-read to pre-punch buffers and then extracted to the stacker files.
My traps to record whether I had a 0 or 1 bit in row 12 of card column 2 failed - since I had a pair, one triggering for a value of 0 and one triggering for a value of 1, it means that the triggering conditions didn't occur. I looked at the case where the Remitter is running, putting out interrupts on IL0 and seeking XIO reads from the software, when the buffer address is 2.
I am not sure how this can fail, since I am loading the buffer even if it might be off by one. I did notice that the sensitivity list for the process had the wrong signals listed, so that might have given me a nonfunctional process for one of the traps. I changed things and tried again.
The traps are still not working, but my fixes have corrected the off-by-one problem for reading into core. I still have a problem with the data fetched from the pre-punch buffer, but that could be a failure in several places:
-- virtual 1442 --
I made a change to the logic that simulates the emission of IL0 interrupts for each card column of the 1442. I had written the state machine to reflect the timing of a 1442 - 20+ ms wait from starting a read or punch until the first column is under the photocells and then a column arrives every 1.125 ms causing an interrupt. The remaining time, 40 ms as the card comes to a stop in the next station, is modeled before it signals completion and drops the busy status.
My prior logic waited for the program to issue the XIO Read to pick up the results of a card column before it moved on with the delay and emission of the next column interrupt. A real 1442 does not do this - it fires off column interrupts every 1.125ms whether the CPU is able to keep up with XIO Read or not. I now simulate this exact behavior, same for punch except the interrupts are once per 6.125ms in that case.
No difference in the behavior after this change. I am going to set up some logic to tell me if the buffer is loaded with the duplicated character or if it is a phenomenon of access during the XIO Read. When I tried to test, I had multiple failures that are hard to understand given the small changes I made. Some look to be hardware problems in the 1130 itself or the SAC interface.
For example, when I try to load core from a file, I get errors where bit 4 is not writing when it should be. It writes just fine when I toggle it in from the console, so it may be an issue with my SAC Interface driver for that bit. Why it would act up now is a mystery.
I attempted a test of the 1442 but encountered timeouts in the transactional engine. This sets me back as I now have to redo all the diagnostics to a very basic level until I find the cause of the stall, then go back to working on the 1442 device behavior.
Well, when I had it all set up with the new low level diagnostics, I powered up and the problems went away! Loading core works well, all 16 bits. The transactions don't time out at all. I attribute this to one of those Xilinx things, where the untrustworthy toolchain produces broken output and it all goes away with a re-synthesis even with trivial changes.
I can turn back to work on the off by one issues, in main core and as the data is copied over from pre-read to pre-punch buffers and then extracted to the stacker files.
My traps to record whether I had a 0 or 1 bit in row 12 of card column 2 failed - since I had a pair, one triggering for a value of 0 and one triggering for a value of 1, it means that the triggering conditions didn't occur. I looked at the case where the Remitter is running, putting out interrupts on IL0 and seeking XIO reads from the software, when the buffer address is 2.
I am not sure how this can fail, since I am loading the buffer even if it might be off by one. I did notice that the sensitivity list for the process had the wrong signals listed, so that might have given me a nonfunctional process for one of the traps. I changed things and tried again.
The traps are still not working, but my fixes have corrected the off-by-one problem for reading into core. I still have a problem with the data fetched from the pre-punch buffer, but that could be a failure in several places:
- the copy function between pre-read and pre-punch buffers might be shifting the data
- the get special data transaction may be sending the data incorrectly
- the GUI program may be handling the returned data wrong before writing to the file
I will shoot the problem by instrumenting the GUI to show me exactly what is returned from the transaction. This will isolate the problem to either the GUI or the FPGA. I set up the diagnostic messages and ran the system again.
The data is coming up shifted over by one - the first word is always a space, then card column 1 shows up in word 2, etc. This puts the problem down in the fpga, but it could be in one of two places - the copyover process or the get special data transaction process. I will look over both bits of logic to see if I spot anything, plus look at what diagnostic LEDs will help me track this down.
I tried a few changes and ran the tests again, but had the same issue. It is hard to see how the copyover process can get this wrong, since it uses a single index to address both buffers simultaneously and does the write operation to pre-punch several cycles after the address has stabilized.
If it is the get special data transaction that is malfunctioning, I can't see where it is going wrong. The code that loads up the outgoing data words is a series of if statements driven by the counter which is stepped from 0 to 9 for each transaction and the address to read the buffer is stepped from its start value in concert with the counter. If the problem was here, I would expect to lose every tenth character, not to see the entire card image shifted over by 1.
I need some inspiration for how to track this one down. It is late so I will stop testing for the day, which has been generally successful. Now that the off-by-one error is gone, reading works solidly. Remaining known issues:
- data coming out of the stacker is shifted over, so that we have only cols 1-79 with an initial blankcolumn
- When we read the final card with last card selected, the status is not returned along with the operation complete. This needs a small change to both GUI and FPGA to make this happen
I also need to test:
- feed only cycles - should copy card contents from hopper to the stacker
- punch operations of a whole card
- punch of a short card
- punch to a non-blank card
- hopper emptying without last card selected
No comments:
Post a Comment