ULTRA SIMPLE REDIRECTOR MODULE TESTED FIRST
My module getsdram is the interface to the F2SDRAM bridge that allows the FPGA, as the controlling party, to read or write SDRAM over on the Hard Processor System (HPS) side of the board. I have reserved the last 1MB of the 1GB of installed SDRAM, so that Linux does not touch it. The bridge makes use of that 1MB to hold the current virtual cartridge image since a 2315 disk cartridge is just under 1MB in capacity.
When the IBM 1130 disk drive is spinning the dummy physical cartridge and goes into ready state, my application running on the HPS side will send a command to switch the Field Programmable Gate Array (FPGA) side over to active mode, setting on the drive_ram signal. This signal activates the disk modeling logic in the FPGA which will send streams of bits to the disk head electronics in the drive that correspond to what would have been read if the heads had lowered onto the physical cartridge.
By monitoring the sector mark signals from the disk drive my logic knows exactly where the head would be riding atop the circular track on the disk cartridge. By monitoring the disk arm movement interactions from the disk controller, my logic knows which cylinder is under the head. Thus my logic knows the cylinder, head, sector, word and bit within a word that will be beneath the head.
My diskmodel logic emits the proper stream of clock and data bit pulses into the disk drive head electronics as they would occur at this moment if we were reading a physical cartridge with the heads down and loaded. Because my modification stops the heads from loading onto the surface, the only source of pulses seen by the head electronics is the injection from my FPGA logic.
The diskmodel logic will call on getsdram to fetch each word of data for the current sector and feed that through the head electronics to the disk controller. The logic also generates all the preamble, sync word and check bits that the disk controller expects in order to successfully read from a sector.
When the disk controller is writing to the disk, I capture the stream of clock and data pulses sent by the controller, assembling them into bits and words in that sector. I then update the SDRAM in the appropriate spot to save the word that was just written from the IBM 1130 CPU.
At a later point, when the physical disk drive is switched off, the contents of the SDRAM upper 1MB may contain some data written from the IBM 1130. That must be transferred back to the source of the virtual 2315 cartridge image. When we start up, before we turn on the physical drive, an image of a disk cartridge must be selected and loaded into the end of the SDRAM.
These operation, unload and load, are the responsibility of my loopcart module. The virtual disk cartridge images are files on an SD Card that is attached to the HPS side of the chip. This facility provides capacity for hundreds of virtual 2315 disk cartridges on the SD Card and allows any one to be selected to be virtually loaded into the IBM 1130 disk drive.
Through interaction with the user interface, the operator first selects which virtual cartridge is to be loaded for use. My application in Linux on the HPS side will read that file and memory map it inside the running Linux image. It then makes use of the H2F bridge, as the controlling side, to write the cartridge to the FPGA side.
Loopcart interacts with the getdata module that receives the reads and writes of the H2F bridge. It will loop through the entire virtual 2315 cartridge image, four words at a time since that is the width of the H2F bridge, and ask getsdram to write them to the last MB of SDRAM. In order for loopcart to control the F2SDRAM bridge via getsdram, it must have control of that bridge. When drive_ram is off, loopcart has that control and can access the SDRAM.
As the IBM 1130 disk drive goes ready, my application sees that and sends commands on the H2F LW bridge to switch over, first asking loopcart to load the SDRAM as described above and then turning on drive_ram. When the physical disk drive shuts off, it is observed by my Linux application on the HPS side, which turns off drive_ram and then unloads the SDRAM contents back to Linux.
The unload operation is the mirror of loading. Loopcart will read each block of four words from SDRAM and then wait until the H2F bridge via getdata does a read to grab that content. We hold the HPS side from completing its read by controlling a wait request signal on the H2F bridge, thus ensuring we have completed fetching the block of words before presenting them to the read command from the H2F bridge.
This very simple module routes the control signals to getsdram so that, depending on the state of drive_ram, either the loopcart or the diskmodel modules drive getsdram. It is not even clocked, just simple multiplexing of the signals.
Testing under simulation involves having various processes asynchronously toggling control signals, addresses and data while the master process has drive_ram off for a while and then turns it on. This was very simple logic for a testbench and I could immediately verify that the proper addresses, data, control signal and response signals were occurring based on the state of drive_ram.
This tested out perfectly and I then moved to the barely more complicated module below.
COMMAND AND STATUS HANDLING MODULE TESTED NEXT
The existing module getcommands will continually latch in and register the value of any word written to us over the H2F LW bridge from the HPS side. This will be a four bit command that drives actions such as switching the drive_ram signal, starting load of a virtual cartridge, triggering unload of a cartridge, and a null action value. In addition, whenever the master side on HPS does a read from any address of this bridge it will be sent a status value that it uses to verify successful recognition of a command, successful completion of the operation, whether an error was detected, and an idle good status.
My bit of new logic simply monitors the registered Command word and advances through states to implement the commands. Part of its operation is emitting the proper Status value to be interrogated by HPS. This will show the Linux program that its command is underway, in the case of a load or unload, then demonstrate successful completion or error condition after loopcart is through.
My testbench simulated various write and read transactions as they would have been driven from the HPS side over the H2F LW bridge, using getcommands, and ensuring that I properly emitted control signals based on the various commands. The status returned appeared correct as well.
LASHING IT TOGETHER FOR FIRST HARDWARE TESTING
I will pull these simulated and validated modules into the top level reference design file, which is in Verilog rather than my preferred VHDL, so that I can fire up the board and test the operation of the commands on real hardware.
Do I read that right that the only time you sync changes made to the virtual disk back to the image file is on unload?
ReplyDeleteDoes that create any concern about potentially having a virtual disk sitting with changes made over several hours and experiencing data loss from, say, an unexpected power loss?
Given the intent of using this in a museum/demo setting I suppose the likelihood is high that any data written back would be trivial or have minimal value, but I thought of it so I decided I'd ask.
Trying to overlap writebacks during operation to an SD Card which is too slow to keep up with the 1130 disk means more complex logic and still no guarantee that every update would be flushed to the card during an abrupt failure.
ReplyDeleteI would instead add a humongous capacitor for the power supply and a signal when input power failed, triggering a putaway of the contents.
Still it is possible to have disk corruption even with a physical cartridge, as a sector could be in the midst of a write and therefore be unreadable after a power failure. Only protection against that is a UPS for the 1130 system itself.