Use of HPS peripheral mux to GPIO, plus another toolchain whacks me in the head

DISCOVERY ABOUT THE USE OF HPS ROUTED GPIO SIGNALS

In the final phases of routing all the signals and ensuring the various modules and external pins were properly connected, I discovered that the HPS side links to GPIO are intended solely to connect to the external FPGA GPIO pins, not to furnish signals inside the FPGA which could be acted upon.

This is absolutely good for my purposes, as those pins were mostly used to route connections to the LCD/touchscreen module I will use for the user interface. The one other pin is used to send a signal from the HPS to the IBM 1130 disk drive to indicate that the heads are loaded so that the drive can switch to "ready" status. There is no need for logic in the FPGA side to be involved.

TOOLCHAIN TOMFOOLERY, ACT SEVENTEEN

Faithful readers of the blog will remember that I switched over to the Quartus toolchain and a board using the Intel/Altera System on a Chip (SoC) when I had exhausted too many weeks fighting with the Xilinx Vivado toolchain. These problems are all issues with the function of the toolchain and have ZERO relationship to any of my logic or input, yet they block me from completing the generation of a project.

Now a problem has struck with the Quartus system and to date no Google searches have located any hints as to the cause nor the solution. The toolchain helpfully handles the details of the IO pin assignments and other parameters required to fully generate the SoC logic. Helpfully as in obscurely and with almost zero documentation. Helpfully as in failing with an internal error. 

When producing a design for an SoC device, there are a number of TCL scripts that must be run from Quartus to handle these pin details. The first two, setting parameters and pin assignments, worked well. The next one, responsible for 'pin mapping', failed. In the details I see that it has to do with requesting a TCL package SDC_EXT (performs Intel SoC related functions) which throws up errors stating that it can only be loaded from Quartus_STA or Quartus_FIT packages.

I issued a load package command to TCL to load Quartus_STA, which should already have been active, but it failed with an operating system error failing to load the package.dll file which I suspect is what does the actual loading of TCL packages.

There was no direct match to others having errors loading package.dll but some had similar errors loading other dll files related to Quartus TCL operation. Those suggested that it was an issue with Windows Visual C libraries requiring installation of the 2013 Visual C Redistributable packages. Those show as already installed on my system, but I was willing to reload to see if this fixed the problem.

As I mentioned in an earlier rant, these toolchains consist of Linux command line programs scaffolded with a GUI and then that environment is further scaffolded to run within Windows. Plenty of opportunity for things to go awry. 

The Microsoft downloads recognized their prior installation status and prompted me for a Repair action which I performed. And . . . zero change. Still fails to run the script to do the pin mapping, without which the Quartus fitter can't properly assign the synthesized logic to elements within the FPGA fabric. 

I will transfer all my files over to a different laptop which has Quartus installed, on the off chance that there is something corrupted on this system. Kind of a "Hail Mary pass" but it is all I can think of to move forward past the latest gratuitous toolchain brickwall.