I had to partially disassemble the keypunch to clear a really bad jam, but once I did I could verify that the interface will correctly punch and read cards. The keypunch itself needs work so that it can register each card in the read station after it is released from the punch area, and to place the cards in the stacker at the end, and to autofeed blank cards from the hopper. That doesn't impact the interface testing and operation.
It is time to do a full and complete test of the code, validating its correct operation with all the features, functions, and conditions that will be encountered. I will spend some time tonight and tomorrow writing up a comprehensive test plan which I will execute.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
I worked out the method for using the ISE toolchain Impact program to set up and load the flash on the FMC Carrier S6 board, allowing me to have the interface box come up automatically. I set it up this very cold morning in the bay area (cold for us, just a few degrees above freezing when I awoke).
My Python code is working well to display the incoming signals, looping every five seconds to display the B register, clock levels and status information. This was debugged using my spare Nexys2 board, but targeted for use with the board in the SAC interface. I tested the ability of my code to open and access the registers of the FMC Carrier S6 board.
I was able to read for a couple of rounds then the python program began receiving address and data timeout errors, suggesting that my logic in the fpga was hung up somehow and not properly responding. Timeout recovery is missing from the fpga side logic, something I need to investigate and correct.
My initial testing showed me that I had improved the assignment of signals to lights but not totally correct. parts of the B register signals are offset or missing, and all the four interrupt level signals are the inverse of their expected state - when entering IL4, the light assigned to that state turns off, otherwise all four IL levels are lit when they should be extinguished. A simple matter to invert the IL signals, the rest takes some investigation and changes to the assignment spreadsheet.
I decided to pull the 1130 cables from my interface box and use a continuity checker to make sure I know what signals are handled by each circuit on each of the four interface boards. As well, I will check that the appropriate pin to the fpga stack is used for the circuits. With that done, I can create a fully accurate assignment spreadsheet, update the fpga logic and then be sure that I am looking at the appropriate LED when testing each signal.
Lack of a signal then indicates either a fault in my interface boards, in the cable, or in the 1131 itself. There should be very few such issues to manually trace, but I have to get the assignments correct before I have eliminated the most likely cause of any LED remaining dark.
I traced all the signals and came up with the definitive assignments of the cable signals to the interface board circuits. The sun had set so I went inside and began updating the spreadsheet and documentation. That took a couple of hours to carefully cross check everything. Once done with that, I turned to the VHDL and updated the logic to get the signals straight inside the fpga. It is now ready for the next round of testing tomorrow.
My initial testing showed me that I had improved the assignment of signals to lights but not totally correct. parts of the B register signals are offset or missing, and all the four interrupt level signals are the inverse of their expected state - when entering IL4, the light assigned to that state turns off, otherwise all four IL levels are lit when they should be extinguished. A simple matter to invert the IL signals, the rest takes some investigation and changes to the assignment spreadsheet.
I decided to pull the 1130 cables from my interface box and use a continuity checker to make sure I know what signals are handled by each circuit on each of the four interface boards. As well, I will check that the appropriate pin to the fpga stack is used for the circuits. With that done, I can create a fully accurate assignment spreadsheet, update the fpga logic and then be sure that I am looking at the appropriate LED when testing each signal.
Lack of a signal then indicates either a fault in my interface boards, in the cable, or in the 1131 itself. There should be very few such issues to manually trace, but I have to get the assignments correct before I have eliminated the most likely cause of any LED remaining dark.
I traced all the signals and came up with the definitive assignments of the cable signals to the interface board circuits. The sun had set so I went inside and began updating the spreadsheet and documentation. That took a couple of hours to carefully cross check everything. Once done with that, I turned to the VHDL and updated the logic to get the signals straight inside the fpga. It is now ready for the next round of testing tomorrow.
No comments:
Post a Comment