The division of labor between the Python code in the PC and the VHDL logic in the FPGA may leave me open to problems such as I am experiencing while debugging the virtual 2310 disk drive function. There is no way to 'hold off' the 1130 processor from executing instructions thus I need the PC to be fast enough to handle events.
The core of the partnership between PC and FPGA is that the PC is the master of the link, sending a series of transactions from PC down to the hardware box and receiving an immediate answer. These include both action transactions, such as turn on interrupt request, and polling transactions, such as return the last XIO function code issued for this device.
The vulnerability is that a program might issue a second XIO instruction before I have successfully retrieved the function code from the first, thus losing any recognition of the earlier XIO. At this point, nothing will stop the 1130 from chewing through instructions including XIO whether or not I have retrieved the prior instruction's values.
If all the logic for the device adapter were pulled into the FPGA, I could guarantee that I handle the XIO before a subsequent one can be issued. The current divide between Python and VHDL is a natural divide with more sequential and programmatic actions implemented in the programming language while more parallel and signal specific actions are handled in hardware (VHDL).
In the case of the 2310 disk drive, I am polling for the XIO Sense commands from the PC. These are used to provide the current sector rotating under the heads, the status of the device and operations that were begun on it, but also to set and reset conditions that trigger interrupts. Once the interrupt condition is set down in the FPGA, the 1130 will begin executing code that will very quickly get to an XIO Sense instruction or two. If that sense instruction is followed soon after by a different XIO, such as a read, write or seek, I might not see the Sense function code at all.
Not all of the task of the virtual drive can be handled in the FPGA - reading the PC file, translating its data from x86 format bytes to 1130 words, and similar activities still would be best handled up in the PC. However, I am reaching the conclusion that the balance of effort might need to be tilted much more towards the FPGA.
I will rethink the disk drive design such that everything to do with status, interrupts, and XIO Sense is handled locally. The PC will feed data to the FPGA or accept data on a write, otherwise it will not be involved in the processing.
My current implementation has a PC thread that mimics the rotation of the disk platter, so that XIO Sense DSW will pick up the current rotary position that simulates a real disk rotating at 1500 RPM. This is easy to move to FPGA, but was only done on the PC because control of the DSW - device status word - retrieved by XIO Sense DSW was accomplished on the PC. This is a poor choice. Similarly, the PC was simulating the time it takes an XIO seek command to move the disk arm and settle, but I can model that better in FPGA.
I will need interlocking between the PC and FPGA sides of the adapter, but it will be reduced to picking up the XIO read or write by polling, and then polling for the rest of the data it needs to do the IO including the current cylinder (arm position) and other information from the XIO. It will never see the Sense DSW or be involved in interrupts.
The read or write operation requested will not complete until the PC side sends a 'done' message. The 1130 can continue to issue XIO Sense commands but won't enter the interrupt routine until the PC has finished fetching or storing the disk data using the cycle steal hardware.
This reallocation of responsibilities will be even more important for timing-critical devices like the 1132 printer. Here, interrupts are generated based on the spinning of a timing wheel and the processor has to respond by issuing XIO read, then setting up a fixed set of memory words with a bit pattern to cause specific hammers to fire. The right division with interlocking will make this bulletproof, while the wrong allocation is sure to fail.
By noon I had my modeling or the platter rotation and of seek timing completed and had moved on to restructuring how XIO Sense and interrupts are handled. Following that, I coded up the process to turn operation complete on and off. The next logic handled a seek completely inside the FPGA.
I still needed to track the current cylinder number, as it will be requested by the PC program when a read or write is attempted. That plus the interlock for when a read or write was completed by the PC will be the last changes needed in the FPGA. All this subject to testing, debugging and correction, of course.
After lunch I tackled the Python program, stripping out all the seek and DSW logic, concentrating it on its task of doing cycle steal to read or write a sector that was requested by the 1130 via the FPGA. By mid-afternoon, everything was ready for the first round of tests. I expect to go through several iterations of failed test, new instrumentation, new tests, and repairs.
After the first test, reading cylinder 0, I did validate the memory contents of the disk buffer in core. When I then attempted to read sectors from other cylinders, the contents didn't match. Not sure if this is a flaw in my 'seek' logic inside the PC file or a problem internally. I need to instrument the system to see if it has moved the virtual arm to the proper cylinder.
I also saw an anomalous read of one word before the full sector read, which could be the diagnostic program trying to verify the seek was correct by reading the sector number that is word 1 of each sector. I will add some instrumentation but also look over the relevant logic.
My tests weren't conclusive - when I tried to force a seek to sector x123 I remained looping in interrupt level 2, which I think means I didn't reflect the operation complete properly back to the software. Resetting, I went back to a simple read of sector 0, no seeks required. I observed the one word read, then a 'read check' which attempts a read but doesn't transfer the data, followed by a read of the full 321 word sector.
Overnight, I will read over the DCIP utility code to see if it does in fact do a read of one word, a read check and then a read. if it is not doing this, then I am not properly latching, saving and returning the parts of the XIO that I need to.
Not all of the task of the virtual drive can be handled in the FPGA - reading the PC file, translating its data from x86 format bytes to 1130 words, and similar activities still would be best handled up in the PC. However, I am reaching the conclusion that the balance of effort might need to be tilted much more towards the FPGA.
I will rethink the disk drive design such that everything to do with status, interrupts, and XIO Sense is handled locally. The PC will feed data to the FPGA or accept data on a write, otherwise it will not be involved in the processing.
My current implementation has a PC thread that mimics the rotation of the disk platter, so that XIO Sense DSW will pick up the current rotary position that simulates a real disk rotating at 1500 RPM. This is easy to move to FPGA, but was only done on the PC because control of the DSW - device status word - retrieved by XIO Sense DSW was accomplished on the PC. This is a poor choice. Similarly, the PC was simulating the time it takes an XIO seek command to move the disk arm and settle, but I can model that better in FPGA.
I will need interlocking between the PC and FPGA sides of the adapter, but it will be reduced to picking up the XIO read or write by polling, and then polling for the rest of the data it needs to do the IO including the current cylinder (arm position) and other information from the XIO. It will never see the Sense DSW or be involved in interrupts.
The read or write operation requested will not complete until the PC side sends a 'done' message. The 1130 can continue to issue XIO Sense commands but won't enter the interrupt routine until the PC has finished fetching or storing the disk data using the cycle steal hardware.
This reallocation of responsibilities will be even more important for timing-critical devices like the 1132 printer. Here, interrupts are generated based on the spinning of a timing wheel and the processor has to respond by issuing XIO read, then setting up a fixed set of memory words with a bit pattern to cause specific hammers to fire. The right division with interlocking will make this bulletproof, while the wrong allocation is sure to fail.
By noon I had my modeling or the platter rotation and of seek timing completed and had moved on to restructuring how XIO Sense and interrupts are handled. Following that, I coded up the process to turn operation complete on and off. The next logic handled a seek completely inside the FPGA.
I still needed to track the current cylinder number, as it will be requested by the PC program when a read or write is attempted. That plus the interlock for when a read or write was completed by the PC will be the last changes needed in the FPGA. All this subject to testing, debugging and correction, of course.
After lunch I tackled the Python program, stripping out all the seek and DSW logic, concentrating it on its task of doing cycle steal to read or write a sector that was requested by the 1130 via the FPGA. By mid-afternoon, everything was ready for the first round of tests. I expect to go through several iterations of failed test, new instrumentation, new tests, and repairs.
After the first test, reading cylinder 0, I did validate the memory contents of the disk buffer in core. When I then attempted to read sectors from other cylinders, the contents didn't match. Not sure if this is a flaw in my 'seek' logic inside the PC file or a problem internally. I need to instrument the system to see if it has moved the virtual arm to the proper cylinder.
I also saw an anomalous read of one word before the full sector read, which could be the diagnostic program trying to verify the seek was correct by reading the sector number that is word 1 of each sector. I will add some instrumentation but also look over the relevant logic.
My tests weren't conclusive - when I tried to force a seek to sector x123 I remained looping in interrupt level 2, which I think means I didn't reflect the operation complete properly back to the software. Resetting, I went back to a simple read of sector 0, no seeks required. I observed the one word read, then a 'read check' which attempts a read but doesn't transfer the data, followed by a read of the full 321 word sector.
Overnight, I will read over the DCIP utility code to see if it does in fact do a read of one word, a read check and then a read. if it is not doing this, then I am not properly latching, saving and returning the parts of the XIO that I need to.
No comments:
Post a Comment