I took what precious time I had free during the last couple of days and carefully drew out my FSMs and other logic in the FPGA that I recently updated with new functions for the virtual disk drive adapter. I had to remove some from the PC side Python program because they needed tighter synchronization that I could provide over the USB link with a PC program.
It is essential that every XIO and completion of the disk read or write data transfer be properly implemented in my logic. Further, I checked that no FSMs would stall in inappropriate states.
When XIO Control (seek), XIO Sense Device, XIO Sense Device with Reset, and XIO Sense ILSW occur, my logic must handle them wholly inside the FPGA. When XIO Initiate Read or XIO Initiate Write are issued by the 1130, I must set those in the "last function" field of the UCW and wait until the PC program has picked up that function via a poll transaction. I wait until I see Op Complete.
The PC has to accomplish the read or write from the PC file that is the virtual disk cartridge, use the 1130 cycle steal functions to do the actual transfer to/from core memory, and push a "DSW" down to the fpga that indicates the operation is complete, setting the Op Complete status. Any time Op Complete is on in the fpga, the interrupt level 2 is triggered. When a Sense Device with Reset is issued, it turns off Op Complete and the interrupt request.
This should interlock the operation of the PC and FPGA sides - while a read or write disk operation is underway, it is waiting for the disk hardware to make it happen. In our case, the disk hardware is the PC side, which does something and then lets us know via a push of the DSW bit assigned to Op Complete.
I saw a race hazard in the way that the op complete is set and reset in the fpga. Since the PC pushes a pseudo DSW with a certain bit turned on to signal op complete, that bit stays on until the PC pushes a second DSW with the bit off. During that uncertain interval, if the code on the 1130 gets the interrupt and resets the condition with XIO Sense Device, the fpga will go right back into the interrupt because the op complete condition is still turned on.
My solution is to have a flipflop for setting operation complete, which is triggered when the PC pushes the pseudo DSW and the flipflop gets immediately reset during the XIO Sense DSW. I ignore the DSW sent by the PC other than to flip on the operation complete flipflop, thus the PC does not have to push a second DSW. This resolves the timing hazard.
When XIO Control (seek), XIO Sense Device, XIO Sense Device with Reset, and XIO Sense ILSW occur, my logic must handle them wholly inside the FPGA. When XIO Initiate Read or XIO Initiate Write are issued by the 1130, I must set those in the "last function" field of the UCW and wait until the PC program has picked up that function via a poll transaction. I wait until I see Op Complete.
The PC has to accomplish the read or write from the PC file that is the virtual disk cartridge, use the 1130 cycle steal functions to do the actual transfer to/from core memory, and push a "DSW" down to the fpga that indicates the operation is complete, setting the Op Complete status. Any time Op Complete is on in the fpga, the interrupt level 2 is triggered. When a Sense Device with Reset is issued, it turns off Op Complete and the interrupt request.
This should interlock the operation of the PC and FPGA sides - while a read or write disk operation is underway, it is waiting for the disk hardware to make it happen. In our case, the disk hardware is the PC side, which does something and then lets us know via a push of the DSW bit assigned to Op Complete.
I saw a race hazard in the way that the op complete is set and reset in the fpga. Since the PC pushes a pseudo DSW with a certain bit turned on to signal op complete, that bit stays on until the PC pushes a second DSW with the bit off. During that uncertain interval, if the code on the 1130 gets the interrupt and resets the condition with XIO Sense Device, the fpga will go right back into the interrupt because the op complete condition is still turned on.
My solution is to have a flipflop for setting operation complete, which is triggered when the PC pushes the pseudo DSW and the flipflop gets immediately reset during the XIO Sense DSW. I ignore the DSW sent by the PC other than to flip on the operation complete flipflop, thus the PC does not have to push a second DSW. This resolves the timing hazard.
No comments:
Post a Comment