Verifying key functionality with small focused test programs, part 4

VERIFYING THAT WE SEE THE SIGNAL WHEN THE HEADS LOAD ON DISK DRIVE

I have connected the signal -pick that comes from the IBM 1130 disk drive to GPIO8 on connector GPIO0. This is accessible from the FPGA logic where I use it to control whether we are emulating the disk drive or talking to the user interface code in the HPS side. Additionally, however, the HPS side needs to see this to control the user interface properly.

When the drive is switched off, the user interface presents a list of virtual cartridge images on the LCD screen, with buttons to scroll up and down when there are more than 40 image files installed. At the bottom is a Select button to allow the operator to select which cartridge is going to be virtually installed into the physical disk drive of the computer. 

The selection of an image causes its contents to be downloaded into the FPGA side in preparation for access by software running on the IBM 1130. The operator would then switch on the disk drive, which contains a dummy physical cartridge to spin up and provide appropriate signals to the disk controller and my FPGA logic. 

When the disk reaches speed, the drive controller sends a -pick signal, meaning it asks the drive to lower the heads down onto the drive. A microswitch in the drive informs the disk controller that the heads are indeed flying on the surface, which results in the drive going ready. My product replaces the microswitch with a signal from my FPGA logic to tell the controller the heads are down and ready. 

In order for me to send that ready signal to the controller, there must be a cartridge file image loaded into the FPGA (by the prior action of the operator pushing the Select button). Only when the -pick signal is on and an image is downloaded will I emit the signal to make the drive ready. Our challenge is that the GPIO8 pin on the FPGA side is not normally visible to code running on the HPS side.

Confusingly, Terasic names the two 40 pin connectors on the board GPIO0 and GPIO1, but these are connected only to FPGA logic and are unrelated to the GPIO1 signal bank that exists on the Cyclone V chip HPS side. There are various means of routing signals from the FPGA GPIO to the HPS GPIO, but it is convoluted. In this case, we are routing the FPGA pin GPIO8 on GPIO0 connector to the signal spim0_ss_in_n which is routed over the bridge from the HPS side to the FPGA side.

A designer can export control of the SPI master 0 link connections to the FPGA logic, which delivers signals for the clock, MOSI, MISO, four slave select lines and the master contention input spim0_ss_in_n. When that contention signal is at logic level 1, the SPI link will operate normally. However when that signal is dropped to logic 0, it blocks the SPI hardware from driving clocks or data bits. This is used so that multiple masters can share wiring to slave interfaces, with only one permitted to actively manipulate the wire signals at any instant. 

The HPS side does not provide access to the master contention signal spim0_ss_in_n but I believe I can see that state of this signal in the SPI interrupt status register. It appears that the signal is reflected in bit 5 of the ISR register, which I can access from Linux on the HPS side. The unknown was whether that state is only shown when code attempts to write on the SPI link while the signal (actually spim0_ss_in_n is the same as -pick) is low, blocking use.  

My test will interrogate that bit of the ISR register with the pick line at both 3.3V and then 0V to block the link. It then sends a word to the SPI while we are blocking it, again reflecting the state of the ISR bit. From that I can tell if this method to detect -pick will work. 

After a few self inflicted wounds in my test program, I was able to run this and discover to my dismay that the presence or absence of the -pick signal has no impact at all on the status or interrupt status registers. I dumped all the fields and verified that I had configured and enabled the SPI master. 

I will need to find a different way to pass this signal to the HPS side, verify it with a test, and then update my wiring diagram and documentation. I am thinking that I can use another of the LTC pins just as I used to pass along the touch pad interrupt signal. 

RESOLVING THE FAILURE TO SWITCH OFF DRIVE_RAM FROM COMMAND

This was another self inflicted wound, which was rapidly fixed after I spotted the issue. The drive_ram signal switches on and off exactly as it should. 

OOPSIE AND RECOVERY OF MY UBUNTU LINUX IMAGE

I was attempting to issue a command automatically on bootup rather than through a terminal, just to save some time whenever I started up my Linux in the VMWare virtual machine. Unfortunately, I didn't realize that it would hang up the boot process rendering it impossible to do any work on the machine.

I downloaded an ISO image of Ubuntu, mounted it as the CD Rom 'contents' for the virtual machine and then brought it up. First I had to jump into the virtual BIOS of the virtual machine, via F2 key, to change the boot order to make the CD drive first. I then booted up the ISO image and started it in the "Try out Linux without Install" mode.

I could then mount my hard disk into the running Linux, navigate to where I installed the bad script and remove it. Once that was done, I rebooted into the BIOS, restored the hard drive as the primary boot source and then booted up my Ubuntu system. I was back in operation. First thing I did was export all my project files out of Linux just in case something like this happens again.