Contemplating worst-case scenarios

As I work on the replacement PCB for the Canon P170-DH calculator, I was reminded of a saying from a previous job: Design for Test.This means that you design a board with testing in mind, rather than trying to figure out how to test the thing after you've committed it to fibreglass, copper and silicon. Asking how I'm going to test this board led me to think about what might go wrong with it.

My first concern is that I not end up with a smoking, fiery pyre on my work bench. This is one of the reasons I prototyped the FPGA +3V3 and +1V2 buck regulators, the +30V grid and anode boost regulator, and the filament driver.

Quite by accident, all the power circuitry ends up on the top of this board and all the logic circuitry goes on the bottom. Thus I can easily populate the top of the board and test the power subsystems before populating the logic components. After mounting the logic circuitry I'll recheck for short circuits before applying power, in case I get a solder bridge in a critical spot.

Hopefully this will keep the chances of smoking pyre to a minimum. What's the next worst thing that could happen?

Like all my hobby projects this one is a learning exercise, and even if it doesn't work completely at first I can still learn from my mistakes. I expect a single board to cost about $185, all told. If I find flaws in the design that I can't tolerate, a respin isn't out of the question. However, if the flaws are so bad that I have to respin the board just to be able to test things, possibly leading to yet another respin, that'd be painful. Aside from the smoking pyre, that's my worst case scenario.

How might that happen? The FPGA is totally useless without having a configuration loaded into it. There are all sorts of dire warnings in the Xilinx documentation about proper routing of the SPI signals between the FPGA and the SPI Flash ROM it will load from. Especially the CCLK line, which is very susceptible to signal reflections which can cause multiple clocking of either the Flash ROM or the FPGA itself. My solution to this is multi-layered. First, I'm routing the CCLK line as a 50 ohm Microstrip transmission line, as recommended, with provision for the recommended Thevenin-equivalent parallel termination at the Flash ROM. I don't really want to use this because it will eat a lot of power (109 mW) even when idle, so I've also provided for series source termination at the FPGA. My intent is to use source termination if it works, and if it doesn't I can put a 0-ohm resistor there and use the parallel termination. But mostly I'm counting on keeping the distance between the FPGA and the Flash ROM so short (11.5mm) it all looks like a lumped circuit and termination shouldn't matter.

I spent a LOT of time thinking about the connection to the Flash ROM, especially the CCLK line. But then I started thinking about how to get a configuration written to the ROM in the first place.

There are basically two ways I could do it. One is to provide a direct connection to the Flash ROM so I could write it with the FPGA held in reset. With the reset released the FPGA would, in theory, load its configuration from the ROM. But having to blow Flash every time I want to load a new configuration would be inconvenient, and would prevent me from using any form of boundary scan software to test the FPGA connections. The other way, of course, is the JTAG interface to the FPGA. That's how I've always intended to load configurations during testing, including the configuration used by Xilinx iMPACT to blow Flash indirectly. Even if the Flash interface doesn't work I'll still be able to test the rest of the board.

Thus there has been a JTAG interface connector on the board from the start. You can see it as the 6-pin header in the upper left corner of the picture in this post. I routed this connector earlier this week, but then I started thinking about it. Like the SPI connection to the Flash ROM, JTAG is a high-speed serial interface, with the Spartan 6 able to run at up to 33 MHz. But the tracks between the intended connector and the JTAG pins on the FPGA measured over 6 inches in length, snaking down the board and changing layers several times, and were routed very near the VFD with its 30 volt swings and 420 KHz filament drive. If the JTAG doesn't work I have a dead board, which makes it a worst-case scenario worthy of some effort to avoid.

Initially I thought I wouldn't be able to fit a connector on the board behind the keypad due to the minimal vertical space available between the PCB and the calculator's shell. This prompted me to remeasure the available space, and I found I could squeeze a standard Xilinx JTAG connector (2x7 pins, 2mm pitch, 7.6mm high) near the corner of the FPGA where the JTAG pins are, and still have about 0.1 inch clearance to the calculator shell. There was even a natural gap in the tracks I'd already routed because of a mounting hole.

In this picture you can easily spot the FPGA's 144-pin TQFP footprint on the right side. The Flash ROM is the large footprint below and to the left of the FPGA. To the left of the upper-left corner of the FPGA is the mounting hole (in yellow) and then the footprint for the JTAG connector (in green). Obviously a number of existing tracks will have to be rerouted to make room for it, but this positioning keeps the longest JTAG track below an inch and all on the layer just above the solid ground plane. An ideal positioning, I believe, and well worth the effort rerouting existing tracks.

My hope is that even if other things go wrong and I decide to respin the board, having a working JTAG will allow me to work out any remaining bugs and avoid a third iteration.