Finished construction of the new 1130 MRAM board, part 3

SOLDERED DOWN THE REMAINING 24 PINS TO COMPLETE THE BOARD

Assembly is just the beginning of the work before this can be hooked to the 1130 and tested. All the solder joints have to be tested and each net checked against shorts to adjacent leads or other errors. 

CAREFUL MICROSCOPE INSPECTION TO LOOK FOR SOLDER BRIDGES

I put the board under my stereo microscope to look carefully at all the chip and part connections. Because these surface mount parts are small, the spacing between leads is tiny. It is easy for a solder bridge to short together adjacent leads. A bit of solder wick will pull out the excess solder, sometimes requiring a touch up with the manual soldering tool to ensure a good connection of the leads to the individual pads. 

I found four small solder bridges either during this inspection or while testing nets as discussed in the section below. They were easy to fix. 

CONTINUITY TESTING ALL THE NETS BETWEEN PARTS

I used my PCBite probes to check continuity between parts for each net. This tool has small pins on flexible arms that can set atop a lead and connect it to a wire to my ohmmeter. Using pairs of the arms I listened for a beep that showed a good path between the leads of the components. This will find poor solder connections from the lead to the pad on the PCB, as well as validating that the traces are correct. 

I found a lead that had no connectivity to the pad beneath, which I corrected. As well, some of the solder bridges I found were discovered in this testing and corrected. 

FIRST TEST ON THE 1130 SYSTEM

I hooked up the power wires from the 1130 (+12V and ground), then plugged in the three SLT cables to the connectors. I powered up the system and did some load and display operations on the computer. 

It appeared to be working properly even with all 16 bits of the word set to 1. I tried many variations with no sign of malfunction. I also saw that the phantom issue is gone - the one where address zero is corrupted on a Reset. 

I then used the Storage Load and Storage Display functions of the machine to mass load all addresses of memory with various bit patterns. In Storage Load, the pattern on the Console Entry Switches (CES) are stored in memory, once the Prog Start button is pressed; the machine loops repeatedly loading the data until it is stopped. In Storage Display, the machine will repeated loop through all addresses reading memory once Prog Start is pushed.

I found that almost every pattern worked properly. The only errors occurred when I loaded a pattern of 0xFFFF and then displayed it. The machine would loop and stop randomly at some point with a parity error. Any other pattern that 0xFFFF has less than 18 bits flipped on, but this one loads 16 data bits with 1 and both parity bits are also set. 

The earlier version of the board would fail with fewer bits set to 1. Whatever was causing that issue is greatly ameliorated with the new design but it seems that something is so marginal with 18 bits of 1 that it fails once in a while. That is, the machine reads back correctly on almost every one of the 8,192 words, but does fail.

I need to do more testing including capturing data with the scope and logic analyzer to figure out why I am seeing any failures at all and look at the conditions surrounding the malfunctions. I did notice, however, that the failures had a common characteristic. Bits 0, 1 and 2 are read back as 0 but were written as a 1. With the lost bits, the parity bit for that halfword should be a 0 but it is generated as a 1 which triggered the parity error stop. 

The parity bits are generated on the fly during the read operation, which tells me that the MRAM memory device returned 0xFFFF but didn't set all 16 bits into the Storage Buffer Register. I do note that bits 0, 1 and 2 are handled in one FPGA clock cycle by my logic, although electrically the FPGA turns on three separate output signals, one for each bit position.  Perhaps something is causing my FPGA state machine to skip that cycle every once in a while. 

I will look over my Verilog code and think about possible issues that might produce this result. I can then toughen up the code, generate a new bitstream and load it into the FPGA board that is mounted on my printed circuit board.