Clean build again, time to move onward to Linux side development and testing of the board

BUILT NEW PROJECT AND WORKED THROUGH VARIOUS ERROR MESSAGES

I carried over the files produced by SystemBuilder, used them to open the project in Quartus, added in all my files, updated the top level file and generated the SoC in Platform Designer. I then began rounds of compilation, knocking down various minor errors that arose.

REVERTED TO ISSUE WITH THE TCL SCRIPTS NOT WORKING PROPERLY

It is typical of all toolchains for FPGA, at least the ones from Xilinx, Altera and Intel, that the internal files beneath the GUI can get in a confused state, such that residue of old logic or parameters remain in the files and cause obscure problems when trying to generate results. 

At least with Intel/Altera, these are reasonably well described and can be read with an editor like Notepad or Linux vi/ed/etc. It does allow me to look into the files and spot why the errors are arising, although the toolchain won't easily correct them. I have found that doing a clean of the files will cause the toolchain to rebuild them all from the current contents entered on the files visible through the GUI, thus resolving the stale data problem.

After a clean and some careful review of my code, I did a compilation. The first pass produces fitter errors because the pins and parameters for the sdram connections are not set up; the TCL scripts are run to establish these settings. The second try of compilation, after script execution, should complete successfully. It did not. The TCL script was still failing SILENTLY and not adding the sdram pin assignments.

I manually appended them to the settings file xxxx.qsf to complete the assignments. Next I added IO Buffers for the signals coming from and going to the HPS side (the three HPS_GPIO signals) and did a compile. 

There were some battles with hidden tristate connections for a signal I wanted to connect to the FPGA IO connector and route that to the HPS side to be read by the Linux application. After I abandoned attempts to use the HPS GPIO pins, it completed the build without error.

THE CHALLENGE OF OVERLOADED WORDS

Altera, Intel and Terasic toss around the term GPIO in a number of contexts with different meanings or subtleties, which is quite confusing. Having read around 6000 pages of documentation to date, I recognize the places where this term switches meaning but it was hard fought knowledge, not spelled out anywhere clearly.

FPGAs have a building block called a General Purpose Input Output block - GPIO - which is basically all the normal pins that you would connect to other chips or the outside world. It includes debouncing, control over drive strength and slew rate, voltage standard selection and other capabilities.

The Cyclone V chip on its HPS side also has GPIOs - a facility that routes 67 bidirectional signals from the HPS side over to the FPGA side, but only when the peripheral mux bits are set. Essentially every pin (pad on the chip) has multiple possible connections, up to four, selected by the mux bits. A given pad might connect to an I2C serial signal, to another device on the HPS, or to the GPIO facility. Note this is NOT the same GPIO as the paragraph above.

The documentation on the HPS GPIO function shows that the signals are assigned across three GPIO banks - 0, 1 and 2. Signals 0 to 28 are on bank 0, signals 29 to 57 are on bank 1, and the remaining signals are on bank 2. 

Terasic provides two 40 pin connectors on the DE10-Nano board which is based on the Cyclone V chip. These are called GPIO 0 and GPIO 1. Each of the two provide 36 input/output pins as well as power and ground. This is a third use of the term GPIO. The HPS GPIO signals have no routing to the board GPIO connectors. The only way to connect them is via IO buffer functions in the FPGA side, using a signal passed through the hps_io conduit from the HPS side which can be redriven out a GPIO pin (of your choice). 

Just to add insult to injury, Terasic provides a single pin on the 2 x 7 pin LTC connector on the HPS side which is called a GPIO signal. That is a fourth use of the term. This GPIO signal is connected to one of the HPS GPIO signals, but also acts as a drive to a relay to switch contacts on the LTC connector between the SPI and the I2C functions on the SoC chip. 

SUCCESS IN BUILD

After some time tweaking things, I had a successfully built file for the Field Programmable Gate Array (FPGA) side of the System on a Chip (SoC). It was time to install some C code onto the Linux image for the Hard Processor System (HPS) side of the SoC then fire up the board.