I worked on quite a few functions that weren't fully implemented, so that by the time I could work on the 1130 at lunchtime, these were presumably ready and just needed testing.
I believe I found the cause of the delayed fetch data from my testing yesterday and hope to see that confirmed today.
The PC side python code was also cleaned up and augmented. I generalized some of the code to handle virtual devices as well as the GUI triggered actions. I need to work through all of these functions as well, since the code is new or modified.
I discovered some flaws in handling my newly generalized code with functions that previously worked correctly. I set up some instrumentation through the temporary lights in order to find the cause. It was pretty easy to zero in on the flaw in my new generalized code; fixed rapidly and back on track.
Cycle steal fetch now works perfectly. I still have some timing flaw in Cycle Steal Store where I am always writing zeroes instead of the intended data value. Shouldn't take long to track this down and fix it.
I then tested by interrupt requesting logic, but found that regardless of the interrupt number I thought I was triggering, I always turned on IL4. This too should be a simple flaw to find and correct. I went in to eat lunch, work on the flaws and resume testing later today to see if I got it right.
The cause was two fold, both in the python code. Testing proved out well - I could turn on or off each of the four interrupt levels independently for any device. I realized I have a small design problem in how to properly handle the XIO Sense ILSW for virtual devices, since when this command is issued the fpga has no way of knowing which bits in the ILSW are assigned for that device when it requested an interrupt for each level. It may need to be coded in fpga logic for the virtual device,leaving all its other handling to the PC side program.
I did some instrumentation in the python program to test the functions that let me retrieve the last XIO function, modifier fields, WCA and data word for a virtual device, plus the function to set device status and to set up the data word for an XIO Read to retrieve. This took a while but I resumed testing in the late afternoon.
Initially, I executed an XIO to the virtual device and tried to retrieve the various fields, but all that was returned were 0 values. I took the time to re-instrument the lights so that I could divide up the problem. First, make sure the proper status was being saved in my "UCW" field in the fpga, then I could track down whether it was being returned properly.
I found some spots where I could change the handling of the UCWs in the fpga, made the changes and tested again. The results were very good. Not perfect, I have a couple of issues to chase down and I still need to work out the mechanism for Sense ILSW, but most functions are working properly.
Specifically:
Cycle steal fetch now works perfectly. I still have some timing flaw in Cycle Steal Store where I am always writing zeroes instead of the intended data value. Shouldn't take long to track this down and fix it.
I then tested by interrupt requesting logic, but found that regardless of the interrupt number I thought I was triggering, I always turned on IL4. This too should be a simple flaw to find and correct. I went in to eat lunch, work on the flaws and resume testing later today to see if I got it right.
The cause was two fold, both in the python code. Testing proved out well - I could turn on or off each of the four interrupt levels independently for any device. I realized I have a small design problem in how to properly handle the XIO Sense ILSW for virtual devices, since when this command is issued the fpga has no way of knowing which bits in the ILSW are assigned for that device when it requested an interrupt for each level. It may need to be coded in fpga logic for the virtual device,leaving all its other handling to the PC side program.
I did some instrumentation in the python program to test the functions that let me retrieve the last XIO function, modifier fields, WCA and data word for a virtual device, plus the function to set device status and to set up the data word for an XIO Read to retrieve. This took a while but I resumed testing in the late afternoon.
Initially, I executed an XIO to the virtual device and tried to retrieve the various fields, but all that was returned were 0 values. I took the time to re-instrument the lights so that I could divide up the problem. First, make sure the proper status was being saved in my "UCW" field in the fpga, then I could track down whether it was being returned properly.
I found some spots where I could change the handling of the UCWs in the fpga, made the changes and tested again. The results were very good. Not perfect, I have a couple of issues to chase down and I still need to work out the mechanism for Sense ILSW, but most functions are working properly.
Specifically:
- The function code (XIO type) is correctly stored and retrieved for all XIO types
- The modifier field (bottom eight bits of IOCC word 2 is correctly stored and retrieved
- The WCA is correctly saved and retrieved for XIO Init Write and XIO Init Read
- The value in core memory is correctly transferred after an XIO Write
When I attempted to load a new value in the UCW for use with an XIO Read, it did not store the new value. I will narrow the instrumentation down to determine where the failure occurs.
When I attempted to store a new device status and interrogated it with an XIO Sense DSW command, I only saw zeroes in the B register. Again, my instrumentation will help me figure out where the failure is occuring. In addition to setting up instrumentation, I will be looking over the relevant logic in the fpga to see if I can spot the cause or have a cleaner implementation. Daylight is fading so my 1130 testing is over for the day.
No comments:
Post a Comment