User interface test verification part 6

PLAN (WHATEVER LETTER I AM UP TO, I CANT REMEMBER)

The H2F bridge remains stubbornly frozen, nothing I do seems to unlock it and make it ready. I prefer it because my logic was shaped around the 64 bit wide interface it provides, but I already am able to communicate over the H2F LW (lightweight) bridge. 

It has a lower thruput and is only 32 bits wide, but my only use for H2F is to load a virtual cartridge file into RAM once when we select it and then unload its contents after the drive is switched off at the end of a session (or power fails). Thus, performance is not a major issue. 

I hacked up my design to transfer only two 1130 words (a 32 bit transfer) over the H2FLW bridge, but not downrating the F2SDRAM bridge where I access RAM from 64 bit at a time. No change to my load and unload transactions up in the Linux side. Too much in the disk emulation depends on the 64 bit RAM width to change it. I just need to buffer words and combine the pair to send on as a pseudo-64 bit block. 

If I figure out the H2F issue later I can always go back, doubling the words per transfer, but this seems to be the most direct route to having things work. I had to change my code for the Linux side as well as the loop control and addressing logic in the FPGA side, but it is worthwhile to have some success.

The magic of how these bridges work on the Cyclone V System on a Chip is that the real memory address range FF200000 to FF200007 is passed to my original code that sends commands and status over H2FLW. The range FF200008 to FF20000F is passed to the modified logic which moves pairs of 1130 words between H2FLW and F2SDRAM interfaces. 

This ultimately places the megabyte of virtual cartridge file data in the last 1MB of the SDRAM. Linux is blocked from using that part of the SDRAM thus it is my dedicated buffer for the disk emulation. The load operation memory maps the SD card file that is a cartridge image into virtual storage, where I loop transferring the data through the FPGA to its home in the SDRAM. Unload is the reverse, grabbing the content two words at a time from SDRAM and letting it be read from the Linux app at the magic address. 

One minor complication is that addresses like FF200000 are real thus I have to memory map it into virtual storage in order for my application to write or read over the bridge by accessing the virtual address that is mapped to FF200008. SDRAM addresses are their own thing, separate from real and virtual addresses of the processor (MPU). See the diagram below.

RESULT - IMMEDIATELY WORKED

The load operation cycled through a full virtual cartridge load. It was not that slow a process. However I could see that the FPGA and the Linux app were not in sync, because when the application through it was done and checked status, it was sent a code that implies the load was still underway. 

That is next to debug, but it does show that I can communicate using the H2F LW bridge and ignore the troublesome H2F version. One strategic weakness is that my H2F LW bridge operates on 32 bit transactions but the memory interface to SDRAM is 64 bit. My logic may be hanging up dealing with pairs of transactions - more instrumenting is needed to figure this out. Still I am not moving forward which is wonderful.