Since I had devoted some of the diagnostic pins from the fpga board to new functions - interrupt levels 0 and 1 request and state, plus the command to issue a program load sequence - my old connectors to the bank of LEDs won't fit. I had to make up a new set of connections to LEDs.
I also have a dim memory that certain of the diagnostic pins are dead - but not which ones. I set up a process to alternate through all the LEDs one by one at intervals of a tenth of a second. That will allow me to know which pins are really available before I assign them to diagnostic state for my transactional engine logic.
The first time it ran a bit too fast, but with it slowed to once per second I could easily check out all the pins. I then found LED 5 of the first block of 8 was not working. Since I only had seven signals to play with, I just set them up as 1, 2, 3, 4, 6, 7, 8 and was ready to begin debugging.
My first set of diagnostics were intended to display in binary the step in the PC link FSM where the machine had stalled. I can encode all of the 50 states in just six LEDs, thus I used the remaining one to show me that the main transaction FSM had moved off the idle position. The results were unexpected. I saw the lights flash through an entire transaction and go back to the idle state for both the PC link and the tranactional FSMs.
The fpga fired off the transaction, wrote out 12 words and returned to wait for the next transaction from the Python program in the PC. However, the Python code timed out trying to read the first inbound words. This is puzzling. I guess I need to put some diagnostic code in the Python program to figure out what is happening.
I wrote the 12 words out with pauses at strategic points, allowing me to see if the FSM for the link is at an appropriate place. Similarly, I pull the returned words in batches with pauses. I should have an idea where the failure is occurring when I run this code.
It occurred to me that this may not be a timeout, even though my error message reports it as that. I have the usb read in a 'try' block and assume it was a timeout. There may be a subtle error that is thrown which I am masking because of my assumption. I corrected the code to that it prints the exception itself, allowing me to understand what is occurring.
When I ran the test, I confirmed that this was not a timeout due to the fpga getting out of sync. I had an 'Overflow' error, which is because the fpga wrote 12 words but I was reading only the first 2. The PyUSB module throws an exception if the packet is shorter or longer than the quantity in the read statement. I restructured the code to read all 12 words at once and was back in business. The monitoring function was polling and receiving twelve words per transaction.
It is late at night and my testing will end for today. Once I verify that the returned data is correct, matching the 1130 machine status, my next two tests are loading core from a PC file and virtual 2310 disk IO. These both depend on my logic to buffer up words in groups of up to 12, flush a group when needed and pass those down to the FPGA for storing in core.
The fpga fired off the transaction, wrote out 12 words and returned to wait for the next transaction from the Python program in the PC. However, the Python code timed out trying to read the first inbound words. This is puzzling. I guess I need to put some diagnostic code in the Python program to figure out what is happening.
I wrote the 12 words out with pauses at strategic points, allowing me to see if the FSM for the link is at an appropriate place. Similarly, I pull the returned words in batches with pauses. I should have an idea where the failure is occurring when I run this code.
It occurred to me that this may not be a timeout, even though my error message reports it as that. I have the usb read in a 'try' block and assume it was a timeout. There may be a subtle error that is thrown which I am masking because of my assumption. I corrected the code to that it prints the exception itself, allowing me to understand what is occurring.
When I ran the test, I confirmed that this was not a timeout due to the fpga getting out of sync. I had an 'Overflow' error, which is because the fpga wrote 12 words but I was reading only the first 2. The PyUSB module throws an exception if the packet is shorter or longer than the quantity in the read statement. I restructured the code to read all 12 words at once and was back in business. The monitoring function was polling and receiving twelve words per transaction.
It is late at night and my testing will end for today. Once I verify that the returned data is correct, matching the 1130 machine status, my next two tests are loading core from a PC file and virtual 2310 disk IO. These both depend on my logic to buffer up words in groups of up to 12, flush a group when needed and pass those down to the FPGA for storing in core.
No comments:
Post a Comment