Building up the next level of logic in order to begin tests on the physical hardware

SCAFFOLDING TO INCLUDE LOOPCART AND THE BRIDGE MODULES

The getdata, getsdram, getcommands and loopcart modules will be instantiated in the high level module that contains the connections to the actual System on a Chip (SoC) hardware. This ties them to the signals coming from and going to the various bridges. Now that this block of logic appears correct from simulation, it must be connected to the SoC for proof on real hardware. 

After instantiation, when loopcart is activated it will drive the bridges to accomplish the movement of the nearly 1MB of virtual 2315 cartridge information between the running Linux image in the Hard Process System (HPS) side and the SDRAM whose last megabyte was reserved for access from the Field Programmable Gate Array (FPGA) side. 

ADD LOGIC TO RECEIVE COMMANDS AND SEND STATUS TO LINUX

The HPS to FPGA Lightweight Bridge (H2F LW) is controlled by the Linux side and communicates with logic in the FPGA. I will accept a command word written from Linux, latch it in, and make use of it to control my logic. Most importantly, it delivers words that trigger loopcart to run in load or unload modes to transfer the virtual cartridge data. 

I also provide a status word that is delivered then the H2F LW bridge does a read, giving Linux the current status of any commands it has issued to the FPGA side. The command word will also drive the switching of control for SDRAM access between two major functions, loopcart and diskmodel. 

When the disk drive is running, our diskmodel module will read and write words as they are streaming to/from the disk drive electronics. When the Linux user is selecting the appropriate virtual cartridge to load into a drive which is currently switched off, loopcart will be controlling SDRAM. 

ADD REDIRECTOR FOR SDRAM ACCESS BETWEEN DISKMODEL AND LOOPCART

The signals that drive the getsdram module must have only one source to avoid conflict. Thus, a redirector will be set to have these signals driven by either loopcart or diskmodel, based on the commands we received over the H2F LW bridge. This is a very simple bit of logic which should not change as we move forward to the production version of this virtual disk cartridge facility.

START ON LINUX APPLICATION TO RUN IN THE HPS

I will need to write some user code running under Linux to work with the FPGA side over the bridges. First, it must activate the three bridges H2F LW, FPGA to SDRAM (F2SDRAM) and HPS to FPGA (H2F) so that they can be used. These are memory mapped interfaces, thus I need only store or access particular locations in the Linux memory space to use the bridges.

Code is needed to send the commands over H2F LW to switch SDRAM access, to drive a load or unload, and to check status. It must handle the HPS side of a cartridge load or unload. This involves looping through a memory mapped disk file, the virtual 2315 cartridge image, and transferring blocks of four words iteratively over the H2F bridge to the FPGA. Each such operation involves 130, 326 blocks of words to transfer the nearly 1MB cartridge image. 

Eventually this code will be integrated into a full user interface which permits the user to select virtual cartridge files that are sitting on the SD Card. As the disk drive is switched on and off, this code will drive the load and unload to put the cartridge image in SDRAM, and switch SDRAM access based on the state of the physical disk drive. 

Initially, I will set up a dummy file and have skeleton code that simply fires off a load, loops to send the dummy file, then fires off an unload and compares what comes back to the dummy file. This will prove out the transfer mechanism without having to code and debug the rest of the user interface.