Compiled program, now ready to set up the test on the DE10-Nano board

COMPILER ISSUE RESOLVED

I decided that part of my issue was the existence of the separately downloaded Quartus and SoC EDS products, which resulted in divided path names FPGA and FPGA-lite. I removed all and reinstalled just the SoC EDS with its option to include Quartus. 

To test this I verified that I could open my FPGA project and regenerate it successfully. From there I would move on to test the compilation. 

This did NOT work; couldn't open the project nor generate the FPGA side. Apparently there are two Quartus products, one for compiling the code and another for the FPGA, but confusingly named. Thus, I did have to download and install a second product. At least I could make sure that the path name was the same, rather than FPGA versus FPGA-lite.

Before I loaded the other Quartus, I did try a make of my C code. It did run the compiler and attempt to compile my code but it was missing the special headers for the Altera HWLIB. I assume this was due to the lack of the second product installation, so I fixed that issue before focusing on the C code side 

The term FPGA-lite comes from one of the three licensing levels set up by Intel. Professional, standard and lite. Only the lite version is free for hobbyists, but that comes with the default naming for the path which differs from the SOC EDS tool. That latter tool can be run without a license as a hobbyist but does NOT have a lite version. Unaligned product naming conventions are the issue here. 

Loading the FPGA tool Quartus, not the same as the Quartus Prime used for the ARM side processing, I changed the path name and installed over the path for the other toolchain. I was able to open the project, open Qsys, then compile the FPGA code once again successfully.

Back to the HPS side compilation, I reran the make on my C program. Previously it through up errors related to the lack of the headers for the Altera HWLIB, where I was using library calls and defined names for the bridge. 

The same errors came up with the SOC EDS command shell. I switched over to the NIOS II shell which failed with an inability to find the compiler. Sigh. Back to the SOC shell, where I realized that the socal and hwlib includes and libraries were not in the path for the make. 

This is apparently another popular problem people encounter often, as it came up with a quick Google search. First step was to locate the actual libraries and include files, so I knew how to point to them when compiling. There are three command shells, confusingly, NIOS II, SOC EDS and ARM DS, with no clear direction as to which to use.

I found the files at C:\intelFPGA\17.0\embedded\ip\altera\hps\altera_hps\hwlib\include\soc_cv_av thus the fix is just to point to them for my make process. When I looked at the makefile it appeared to do just this, but there seems to be some weird interaction with the Cygnus linux under windows behavior and the command shell. 

CLEAN MAKE OF THE PROGRAM

I was able to bodge things temporarily by copying all the include files which got me to compile and then I discovered there were no compiled versions of the HWLIB modules available to link. I am being run ragged by vendors pointing at vendors pointing at vendors. I can't get the ARM compiler to run without a serial number but since it was provided as part of the Intel SOC EDS I don't have a serial number. 

Nowhere do I find any references to where I grab the object code associated with the HWLIB. I do see a github project but it requires an entirely different set of pseudo Linux tools to be set up in order to compile the source. Sheesh. 

HOW TO TRANSFER C PROGRAM AND FPGA IMAGE TO THE BOARD

Once the object module is built, I can transfer it over to the SD card image on my DE10-Nano board where it will be visible to the Linux image after it boots up. I can use the programming links to get the FPGA bitstream loaded onto that side of the board as well. 

SETTING UP THE PHYSICAL TEST IS EASY

After hooking some cables to do the file transfers, then booting the board, all I would need to do is issue the command to execute my C program, which will transfer the address and print it out for me at the same time. 

Using the slide switches I can pick the four bytes of the latched register. I should see it matching the address from the C program execution as proof that I accomplished the task. 

Once I get the program linked this can be done. Back to the library run around.