Close, too close for the fates to allow, thus . . .

WORKED THROUGH THE TCL SCRIPT ISSUES AND ABLE TO WORK ON COMPILATION

I eventually sorted out the environmental variables and paths in order to get the two key scripts, hps_sdram_p0_parameters.tcl and hps_sdram_p0_pin_assignments.tcl, to execute successfully. As a consequence the bizarre errors of the fitter process of compilation were not occurring. 

DISCOVERED THAT THE GPIO SIGNALS FROM HPS ARE HARD ASSIGNED

The Hard Processor System (HPS) side of the chip has a peripheral multiplexing capability that allows some signals to be routed as LoanerIO or GPIO to the Field Programmable Gate Array (FPGA) side. There are almost 70 possible GPIO or LoanerIO numbers to be assigned. 

Since I was going to route signals related to driving the LCD touch module, I put the GPIO signals close to the Serial Peripheral Interface (SPI) master signals, which gave them numbers in the 60s. I assumed that on the FPGA side this was just a signal that I could then assign to some real FPGA side connector pin in an arbitrary manner.

I came across a small section in one of the manuals (of the tens of thousands of pages of such documents that are essential to reference to work with the System on a Chip - SoC) that showed me a fixed assignment of these almost 70 numbers from the HPS side to the connector pins on the FPGA side. For example, the signals in the 60s are routed to GPIO Bank 2, which is NOT implemented on the board I am using. 

I changed these down to the range of numbers that correspond to the second 40 pin connector block on my board. Thus, GPIO-29 in the HPS side is GPIO Bank 1 pin 0 on the FPGA side. Some of the errors I was experiencing were due to the use of Bank 2 numbers. 

NEARING FINAL STROKES, I THINK

With these sorted out, I just had a few minor HDL issues to repair and I expect that I can finish the Compilation to produce the binary load file that will configure the SoC chip on my board. I had a meeting in a restaurant, after which I will complete the work, or so I thought. 

ALAS IT IS NOT TO BE

I returned, fired up VMWare Player, and attempted to start my Ubuntu image. It failed to activate due to a corrupt Virtual disk image. Unless I can find a way to recover this, which doesn't sound promising from the Google searches I have done so far, then I am going to have to back way up, set up another Ubuntu virtual machine, install Quartus again, then do all the fixes if I can remember them to make it operational.

This won't stop me in the long term but it does senselessly waste a day or so of effort fighting my way through all those steps to return to this afternoon's state.