C CODE FOR FIRST BOARD TESTS IS ALMOST READY

FIRST C PROGRAM TO USE WITH THE SOC FPGA LOGIC

I wrote a quick bit of code to make use of the HPS to FPGA bridges to communicate with my logic. Basically the bridges are mapped into memory and thus can be accessed with simple C assignments and references. These are real memory addresses in the 4GB addressing range of the ARM processors. 

The special Linux file /dev/mem has accessibility to all the installed real memory. We open that file and then use the memory map (mmap) command to grab some virtual memory locations that are mapped to parts of the file. In this case, if I use the starting address of the H2F Lightweight bridge (xFF200000 in real memory) and map four bytes with mmap, that is a variable pointer which stores and fetches from xFF200000 to xFF200003. 

In the same way, I mapped eight bytes of real memory at xC0000000 to xC0000007 which is the location of the H2F bridge. Storing and fetching from that pointer to the virtual storage block returned by mmap allows me to send or receive over that bridge. 

My first test, other than having successful open and mmap system calls, is to read from the H2F LW variable, which is the status word I return from the FPGA side. It should be 0000 to represent the proper idle condition of my logic, else I return an error. 

Writing to the variable from the H2F LW mmap call will transfer a command word to my logic. I flip the driveram state on and off with various commands, checking the status after each and observing the LED on the board I use to report the state of driveram. 

If all this seems to be functioning properly, I will code up the logic to transfer a virtual 2315 cartridge image over to the SDRAM by passing it through the FPGA logic, then retrieve the data I transferred to verify it was faithfully transported. That will be done in a later version of the code 

The loading of the image to SDRAM is triggered by storing the Load command to the H2F LW bridge variable, which causes my logic in the FPGA to wait for me to write the eight byte block to H2F bridge for all the data from the start to the end of the cartridge file - 130, 326 writes. My FPGA logic will accept each write of the block and write it to SDRAM, advancing the address one block at a time. I should see a successful completion status when I read from the H2F LW bridge.

Unloading is a mirror, where I store the Unload command to H2F LW and then loop 130, 326 times reading blocks from H2F bridge and comparing them to that portion of the virtual cartridge file I used for the original loading. It should match to prove out the functioning. 

NEW TOOLCHAIN - INSTALLING IT ON UBUNTU LINUX

Although the documentation from Terasic for the board mentions installed the Intel SoC EDS development toolchain, the Intel site asserts that is superceded by the ARM development suite. I loaded the ARM toolchain, based on Linaro GCC, to cross compile my C code under Linux on my laptop to produce binaries that execute on the ARM processors which are in the HPS side of my Cyclone V chip on the Terasic board. 

ARM shows Windows, Mac and Linux versions but it is immediately obvious that the Windows version requires a shim of a Linux emulator. If the code is Unix native, then the best platform is my Linux image on VMware. 

NEED TO SORT OUT PATHS TO HEADER FILES

My first trial at compiling the program threw errors as it couldn't fetch the #include files that are needed for file IO, memory mapping and other standard C functions. I will need to dive into this a bit to sort out the proper setup to build my binaries for the Cyclone V chip's ARM processors. They will run under the Yocto Linux image that is provided by Intel for their System on Chip (SoC) products.