In the last inches before the completion line, defeat was snatched from the jaws of victory, with a big snag

I helped my daughter and son-in-law move to their new apartment this weekend and up thru Wednesday, which ate up all the time I would have spend with the 1130. My daughter was driving over to her new place to meet the cable modem installer when her tire blew out.

After AAA mounted her spare, we took the car to replace the tire during the time we were moving boxes into her apartment. Tuesday, my wife and I picked up the car and drove over to swap it for the one we loaned my daughter, when five minutes away from our destination we had another tire self-destruct! As you will read further down in this blog entry, it is a week of unforeseen failures.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I made a few changes to the core store/fetch logic and began testing, hoping to quash that last annoying hiccup. The logic analyzer shows the main link FSM jumping backwards for one cycle to a state it had already vacated, but there is no path in my VHDL to make that movement.

I asked the tool to use one-hot encoding to ensure against glitches, which should block such undesired movements, but this could be an instrumentation error rather than a real logic error. The analyzer I am using is an open source unit based on an old fpga board, which adds a third possible source of contaminated data.

Once I found the conditions that led to the glitching of states, I worked on the basic transactional flow until I felt it was solid. At that point, I began testing the core load and virtual 2501 driver functionality to see whether it now passed muster, free of small anomalies or glitches that could cause sporadic failures.

Everything was looking good, although I found one of my data lines going into the 1131 was not working properly. I think I located and fixed the loose connection on the driver board. Before doing more testing, I decided to replace the serial flash chip that was not working on the fpga board.

I dealt with the serial flash chip problem on the fpga board, by removing the presumably bad chip in order to solder a replacement into place. Alas, catastrophe struck.  I damaged one of the pads during removal, even though I thought I was careful enough.

I examined the board to find a way to solder in a way that would create an electrical contact for the damaged pin (pin 2), but that does not seem feasible. It is possible that my only recourses are 1) a replacement board or 2) an external JTAG oriented board with a flash chip to hold the power-up file.

I have just ordered a replacement fgpa board, which should come in three weeks; meanwhile I could continue to load the fpga after powerup manually, as I have been. However, to underscore the major setback I suffered, when I tried to load the fpga directly as I had, the firmware no longer does the load. The 'done' line is damaged somehow, probably it was part of the trace to the damaged pad.

At this time, I can't load the fpga so I can't test anything until my replacement board arrives three weeks from now. I may find a way to restore the fpga loading function, or even to repair the board pad, but at present I am blocked from any futher work on the SAC Interface.