It's ALIVE!!!

Last night I created a very simple Verilog test configuration. It drives the two debug interface clock lines with true and inverted versions of the 20 MHz external clock, and then walks a single "1" bit down the length of the 32-bit debug interface data bus. It's such a trivial setup that I didn't even bother simulating it.

This morning I went down to my lab to see whether it'd load into the FPGA through the JTAG interface. As I mentioned in my post "Contemplating worst-case scenarios", this is a critical step. If I've made an error in the board layout or some minor aspect of the design, I can still test out the other areas of the system. But if I can't load a bitstream into the FPGA via the JTAG interface the only thing I could do is respin the board and hope I hadn't made any mistakes that would force me to respin it again.

Connecting my pod to my board, I brought up iMPACT and allowed it to scan the JTAG bus. Sure enough, it recognized the FPGA! I simply cannot express how satisfying it was to see that happen.

Tempting fate, I then selected the bitstream file I built last night and loaded it into the FPGA. The programmer reported success, so I touched my oscilloscope probe to the first pin on the debug interface and saw a series of narrow pulses. Touching a second 'scope probe to the second pin I saw another pulse, this one after and immediately adjacent to the first. More success!

I almost quit then, as I have other things that will keep me busy for the weekend, but I decided I really wanted to know if the SPI interface to the Flash ROM worked. I configured iMPACT to know about the Flash on a 1-bit wide SPI and told it to verify the ID code. The ID code it reported matched the ID code for the Flash ROM I'd used. Throwing caution to the wind I told iMPACT to program the Flash ROM. It took longer than I expected, but it worked! Power-cycling the board now causes my initial test bitstream to load from the Flash ROM. It's slow because it's still in 1-bit mode at its default bit rate, but if nothing else worked this would be fine.

I wish I could finish this post with everything working perfectly, but this is the real world. The first thing I noticed when looking at the signals on the debug interface with my 'scope was a lot of ringing on both the rising and falling edges. That's not terribly surprising, given that these are unterminated signals. I can probably suppress a lot of this by properly setting the I/O standard to LVCMOS33, selecting the QUIETIO slew rate, and reducing the drive strength from the default 12 mA to 2 mA.

More concerning is what I saw when I connected the debug interface connector to my logic analyzer pod. I should have seen a nice logic high walking along the connector from D0 to D31 and repeating. This is a common test to check for unintended connections between pins often caused by solder bridges. While most of the outputs sequenced nicely, some of them did not. Obviously there is a problem on the board that I'll need to look at. Unfortunately, since I assigned the pins for ease of routing, pins representing adjacent data bits are generally not on physically adjacent pins. It's going to take some analysis to figure out where the problems are.

One more thing that concerns me is the current draw on the calculator's AC mains transformer. The calculator's transformer is labeled as supplying 5.2 VDC at 600 mA, and the original PCB has an 800 mA fuse between the transformer's secondary and the full-wave bridge rectifier. My attempts at estimating the FPGA's power requirements using the Xilinx spreadsheet indicated this wouldn't be a problem, even when driving the VFD and printer. For my tests I'm running the board from my bench power supply, feeding +7.5 VDC directly to the output of the rectifier. Running my basic test configuration I see only a small current draw. However, when the Xilinx SPI Access core is loaded by iMPACT to be able to program the Flash ROM, I'm seeing a sustained draw in excess of 1 amp [This is wrong. See note at the end]. The +3V3 and +1V2 regulators seem to be happy with this, but this would blow the 800 mA fuse even if the transformer could supply it.

I'm not sure what would cause this, but I noticed that this core also seems to be enabling the VFD +30V boost regulator, which really shouldn't happen. The enable input to this regulator is pulled down with a 100K resistor, but I'm seeing 3.3V being driven onto this input. That makes no sense at all, as this FPGA pin is nowhere near the pins associated with the SPI bus interface to the Flash ROM. When the FPGA is unconfigured, or when my Walking-Ones test is loaded, this pin is configured as High-Z and the 100K pull-down keeps this regulator turned off.

HP 6236B Power Supply with dual scale meters

Note: I misread the ammeter on my power supply. It's marked with two scales, and which one you read depends on which output you're looking at. I'd forgotten that I was deliberately using the 0-20V output instead of the higher-current 0-6V output. So instead of more than 1 amp, the board is drawing a bit over 200 mA. The problem still must be addressed, but I'm no longer as worried about blowing the fuse or overloading the transformer. Whew!