I began by debugging my new version of the cycle steal engines that slashes the number of USB transactions needed to load or fetch from a large block of core. Beginning with my function to load core with a PC file such as the DCIP utility, then on to see what speedup I have gained with the virtual 2310 disk capability.
I had technical challenges debugging the memory load function since the GUI update was synchronous with the load function, blocking me from viewing the SAR value until the entire load process was done. I did play around with moving the load into a separate thread, but various Python functions that are not thread safe would cause a problem and more importantly, the diagnostic print statements won't appear until the entire program stops.
I looked at what was in memory and suspect that I have a race hazard somewhere in my fpga logic that is affected by a rapid fire string of cycle steal writes, such that sometimes data is stored in the wrong location. I looked at the code that was loaded by my function and found that about every 10th word had the wrong value in it. It is not lost writes, because the remaining data is correct and in its place.
More time needed to think and to look over the various FSMs in my design. I could build a special diagnostic core load that consists of the word addresses as their contents - allowing me to look for patterns in what is written and where. However, I did spot a potential race condition and repaired it, so that was worth a new test without changing the instrumentation.
I loaded core with all zero values then ran a few lines from the core load file and found it was skipping every other word. This tells me my logic is double-incrementing the SAR when I do a read, something I should be able to find and fix rapidly.
There was a race hazard where my FSM to bump the SAR would go back to idle while the trigger signal was still active, thus cycling twice. This was fixed and I now load core and move data as a virtual 2310 disk drive. The core load process is quicker but the virtual disk activity wasn't dramatically faster. The big delay appears to be over in the Python program.
When I have time, I will go on the 1130 simulator and build core load files for the 2310 disk diagnostic (and others such as the 1132 diagnostics) which will be handy to run. I also will create a boot card image so that I can attempt to boot DMS 2 from my virtual 2310 drive.
I looked at what was in memory and suspect that I have a race hazard somewhere in my fpga logic that is affected by a rapid fire string of cycle steal writes, such that sometimes data is stored in the wrong location. I looked at the code that was loaded by my function and found that about every 10th word had the wrong value in it. It is not lost writes, because the remaining data is correct and in its place.
More time needed to think and to look over the various FSMs in my design. I could build a special diagnostic core load that consists of the word addresses as their contents - allowing me to look for patterns in what is written and where. However, I did spot a potential race condition and repaired it, so that was worth a new test without changing the instrumentation.
I loaded core with all zero values then ran a few lines from the core load file and found it was skipping every other word. This tells me my logic is double-incrementing the SAR when I do a read, something I should be able to find and fix rapidly.
There was a race hazard where my FSM to bump the SAR would go back to idle while the trigger signal was still active, thus cycling twice. This was fixed and I now load core and move data as a virtual 2310 disk drive. The core load process is quicker but the virtual disk activity wasn't dramatically faster. The big delay appears to be over in the Python program.
When I have time, I will go on the 1130 simulator and build core load files for the 2310 disk diagnostic (and others such as the 1132 diagnostics) which will be handy to run. I also will create a boot card image so that I can attempt to boot DMS 2 from my virtual 2310 drive.
No comments:
Post a Comment