Restructuring the GUI
-- virtual 1442 --
I began debugging the virtual 1442 reader/punch next, as it will be convenient to book up the diagnostics properly from this card reader. Suitable diagnostic LEDs and GUI messages were set up.
When I ran a hand loop to read, I saw my main 1442 state machine advanced to its first stage, However, my GUI side didn't push down the card image and I didn't see it detect the read attempt at all.
Instrumented the GUI to learn more about what it saw, plus looked at the FPGA code to check for the alert that should be occurring as it sees the start read command. When I went out to test, I had to sit and wait while the jackbooted thugs of Microsoft forced a software update on my tablet. Finally, I could load the bitstream and begin my test.
It appeared that my logic to set the device ready was not working properly, thus blocking the XIO from being accepted. New LED diagnostic assignments and a run through the toolchains and loading process, then I could look into this symptom. However, the source of the problem appears to be in my GUI code, where I restructured some code and had the following snippet setting the status of the device:
-- virtual 1442 --
I began debugging the virtual 1442 reader/punch next, as it will be convenient to book up the diagnostics properly from this card reader. Suitable diagnostic LEDs and GUI messages were set up.
When I ran a hand loop to read, I saw my main 1442 state machine advanced to its first stage, However, my GUI side didn't push down the card image and I didn't see it detect the read attempt at all.
Instrumented the GUI to learn more about what it saw, plus looked at the FPGA code to check for the alert that should be occurring as it sees the start read command. When I went out to test, I had to sit and wait while the jackbooted thugs of Microsoft forced a software update on my tablet. Finally, I could load the bitstream and begin my test.
It appeared that my logic to set the device ready was not working properly, thus blocking the XIO from being accepted. New LED diagnostic assignments and a run through the toolchains and loading process, then I could look into this symptom. However, the source of the problem appears to be in my GUI code, where I restructured some code and had the following snippet setting the status of the device:
DSW1442 = self.theapp.my1442.getCOpen() #open or not
I then pushed the word DSW1442 down to the FPGA. My model function getCOen() returns 0 if the file is closed, 1 if it is open. I then pushed that to the FPGA to load the DSW. However, the bottom bit of the DSW is the Not Ready bit, thus a value of 1 means the reader is not ready and a value of 0 means it is good to go. My code was making the device not ready when I had cards in the hopper.
I put in some code to reverse the value of DSW1442 before pushing it to the FPGA. My testing then triggered the read, which my GUI caught, but in the process of pushing down the card image to the FPGA, the transactional engine stalled and I began getting timeouts reading from the USB. This points me to an entirely new area of investigation and diagnostic messages.
The transaction that pushes ten columns of data into the read buffer has a state machine, wsastate, that was triggered but the read buffers state machine, rbstate, didn't budge. Time to look closer at the triggering logic and the rbstate state machine.
I definitely kicked off the write special data transaction since that fsm advanced, but I wasn't sure if I had any movement of the rbstate machine, so I set up a process to show me if the machine ever reached a non-idle state. It hadn't.
Time to look at the transaction itself, to see if it emitted the trigger to start the read buffer. As I looked at it, I could see clear errors and it was obvious that this file I was given from the disk recovery was a stale file from early coding. It could never have worked, yet I had successfully debugged it all before the PC crash. Sigh. I will have to desk check and then exhaustively test the code to get it back to a working state.
First I will instrument the transactional engine to see where it stalled. That will point me at the next issue to address. The result of that testing led to my getting the push transaction to work. Now, the 1442 completed several card cycles, but the data being stored in memory was the same value for all eighty columns.
This could be the result of the 'black box' errors from the Vivado toolchain, if it hasn't really set up the block ram. That would give me just one value, probably the last one entered. Next up I will march through the storing operation in the read buffer and the retrieval by the XIO Read processor, looking for the next new-old problem to resolve.
XEROX ALTO RESTORATION PROJECT
A replacement CRT tube was bought by one of the team members (Al) and will be installed in the monitor to return it to full brightness. The team won't meet again until some time in early August, due to vacations and other time commitments.
I did locate a good cable I can use for the fgpa based Diablo disk drive emulator/driver, which I will wire up to my expansion card for a Digilent Nexys2 fpga board. As soon as I get through the VCF West event, I can turn my attention to building and testing the Diablo emulator/driver.
I definitely kicked off the write special data transaction since that fsm advanced, but I wasn't sure if I had any movement of the rbstate machine, so I set up a process to show me if the machine ever reached a non-idle state. It hadn't.
Time to look at the transaction itself, to see if it emitted the trigger to start the read buffer. As I looked at it, I could see clear errors and it was obvious that this file I was given from the disk recovery was a stale file from early coding. It could never have worked, yet I had successfully debugged it all before the PC crash. Sigh. I will have to desk check and then exhaustively test the code to get it back to a working state.
First I will instrument the transactional engine to see where it stalled. That will point me at the next issue to address. The result of that testing led to my getting the push transaction to work. Now, the 1442 completed several card cycles, but the data being stored in memory was the same value for all eighty columns.
This could be the result of the 'black box' errors from the Vivado toolchain, if it hasn't really set up the block ram. That would give me just one value, probably the last one entered. Next up I will march through the storing operation in the read buffer and the retrieval by the XIO Read processor, looking for the next new-old problem to resolve.
XEROX ALTO RESTORATION PROJECT
A replacement CRT tube was bought by one of the team members (Al) and will be installed in the monitor to return it to full brightness. The team won't meet again until some time in early August, due to vacations and other time commitments.
I did locate a good cable I can use for the fgpa based Diablo disk drive emulator/driver, which I will wire up to my expansion card for a Digilent Nexys2 fpga board. As soon as I get through the VCF West event, I can turn my attention to building and testing the Diablo emulator/driver.
No comments:
Post a Comment