Narrowing down design after a bit of exploration of the DE10-Nano

COMPLICATIONS TO BE ADDRESSED

This board is divided into two sides - HPS and FPGA. The HPS (Hard Processor System) side has a twin core ARM system which we use to boot and run Linux. The FPGA (Field Programmable Gate Array) side has hardware logic that I create to manage the 1130 disk drive. 

Communications between the sides makes use of bridges built into the board. There are three bridges which differ based on which side of the board is the controlling entity (master in the widespread master-slave concept for computing systems). One is controlled by the FPGA, one is controlled by the HPS and one is a lighter weight, simpler bridge controlled by the HPS. 

Peripherals to the board are hooked to one side or the other, depending on the peripheral, thus they must be directly controlled by that side. The DDR3 RAM is hooked to the HPS side, as are some other peripherals such as ethernet and USB , while the General Input-Output pins, HDMI video, and analog to digital converter (ADC), among others, are wired to the FPGA side. 

My user interface will need either HDMI plus USB keyboard/mouse or the LCD touch screen panel. The LCD is completely attached to the FPGA side, while the other approach divides HDMI on the FPGA side and KB/mouse on the HPS side. 

In either case, it will be much easier to control the user interface with c code instead of hardware logic, but there are several design choices for where that code should run. Most of them require the use of the bridges between HPS and FPGA sides, although one of them does not. 

I can implement the c code on the HPS side and drive the HDMI or the touchscreen over the bridge. I can instantiate a soft process (NIOS II) in the FPGA, which consumes many logic elements on that side, which can directly access the touchpad and indirect control KB/mouse on the HPS side. There is also a set of Arduino Uno compatible pins on the FPGA, which I can use to connect an Arduino that drives its own user interface in c code and perhaps its own LCD screen shield, or the Arduino can directly drive the touchpad/HDMI and indirectly access the KB/mouse over the bridge.

All the bridge accesses map devices or signals to memory spans and then use master-slave memory access. Since I will be learning this for the essential access to the cartridge images between HPS and FPGA side, extending it to the various cross side accesses for the above user interface purposes is not much additional work. 

USING MEMORY MAPPED FILES FOR CARTRIDGE IMAGES

Linux supports memory mapped files, where I can open any of the SD card images of virtual 2315 cartridges for read/write, having the operating system map that into a 1MB range of virtual memory addresses, and then allow the FPGA side logic to do read and write to that memory. 

This automatically writes back any change to a cartridge to the file on the SD card, which eliminates the need to fetch back an updated cartridge image to rewrite as I had to do with the prior Xilinx/Arduino approach. 

All that is necessary is to have the user interface running on the Linux image on the hard ARM processor side of the board open and close the file, using the MMAP system call, then pass the memory start address over the bridge to the FPGA side. From that point forward, my FPGA logic can do reads and writes to the memory locations on the hard processor side. 

The signal that the physical 1130 drive has been switched off will trigger the Linux side to close the memory mapped file, while switching the drive on will trigger the Linux code to open and memory map the currently selected file.

The user interface shows the user a list of cartridge images and allows them to select which will be active when the drive is turned on. That selection can't change while the 1130 drive is running, just to protect the cartridge image we are using at the time.