Design A Production Test Strategy

In the early days of 22V10-type PLD designs, PLDs were so small that an engineer had to determine how many devices would be required to create a function and had to partition that function into "blocks" that could each reside on one of multiple PLDs. Today, CPLDs can exceed 10 to 50 times the logic resources of those older PLDs, and the issue becomes "how many functions can I incorporate into this single CPLD?"

The partitioning issue proved surprisingly difficult to resolve for my design. I made several trial-and-error iterations in an attempt to use each of my four devices approximately evenly, leave spare capacity, yet locate similar functions requiring similar input signals inside the same CPLD. Sometimes these goals were mutually exclusive.

You should develop a strategy for managing CPLD-design hierarchy. A two-level hierarchy worked well for me:

1. A single top-level schematic sheet within each CPLD contained several functional blocks.

2. A VHDL source file for the low-level state machines represented each functional block.

My team found it easy to use the schematic to follow input signals to each functional block that used them. And the one-function-per-VHDL-module strategy allowed us to focus on basic circuits at the design/simulation/debugging phase.

I wish we had exploited the use of inverters and "not" bubbles on the functional blocks: This would have allowed us to code lower-level VHDL modules in high-true logic, which results in much more legible VHDL code.

The reprogrammable nature of CPLDs, and the quick edit/recompile/reprogram/retest spin cycle associated with programmable logic, mandates some kind of revision-control strategy. I made do by making safety copies of the entire CPLD design tree just before major changes. We maintained meticulous records of which prototypes had received which CPLD modifications as we resolved design errors. If you build a lot of prototypes, do not underestimate the maintenance required for monitoring revisions.

Strategic Considerations
The two most strategic CPLD internal considerations related to turn-on and debug are designing your circuits so they are both observable and controllable:

•   To make your circuits controllable, you can use spare input pins with external pullup resistors as enable signals for each major CPLD function. This approach allows you to separately disable each major function while you are debugging. If you need those spare input pins for another purpose later, you can simply give up the debug controllability of that function.
•   To make your circuits observable (which is invaluable for debug), you can connect your state-machine state bits to unused output pins. This pinout lets you observe the present state of your state machines. If you have few output pins, you can multiplex the state bits from multiple state machines to the available pins and debug the state machines one at a time.

You’ll find it useful to use a logic analyzer to observe all the pinned-out state-machine state bits simultaneously. Most logic analyzers can display the VHDL symbolic name for each possible state-bit combination, which in turn allows you the luxury of troubleshooting your state machines at the VHDL level (Fig. 1).

If you commit one spare input pin as an Output Enable pin and use it to drive the outputs of three-state drivers to a high-impedance state, a CPLD can be put to sleep during in-circuit test of the devices around it. This in turn reduces spurious noise and raises the quality and coverage of the tests. It took about one day for me to add three-state buffers to all the outputs on all four CPLDs (Fig. 2). I figure this step paid for itself in the resulting ATE in-circuit test coverage improvements.

PCB Layout Considerations
You can add test points as necessary to ensure that you can continuously assert reset, disable the clock, and connect the programming appliance to the board. At the same time, ensure that there are probeable targets on the same nets, so your ATE can provide the same operations in manufacturing.

Consider adding a test point, or at least a via, to every unused CPLD user pin to simplify future design modifications or so you can observe your state bits with scopes or logic analyzers (Fig. 3). Since most CAD layout tools will not allow you to connect vias and traces to pins that are not connected in the schematic, you may have to create a "test via" schematic symbol and use it in your schematic. These test vias are especially useful for soldering circuit modifications when your CPLD is a fine-pitch SMT part.

In general, you want to keep the traces short for the TCK, TDI and TDO nets. An additional signal-

fidelity trick that I added to speed up programming time on ATE was adding VCC and ground diode clamps to TCK and TMS nets to clamp overshoot and ringing (Fig. 4). These clamps allowed the ATE to deliver the programming vectors at a higher frequency, thus shortening the programming time.

When you get your prototypes back, simply hold RESET asserted with a jumper, disable the clock with a jumper, connect the programming appliance your CPLD vendor provided (Fig. 5), and apply power. Start the vendor’s programming software on your PC and sit back and wait for the parts to be programmed.

Generally, the programming software will use the silicon ID and revision registers inside the CPLDs to verify that the JTAG chain you have hooked up matches the chain configuration described on the PC. The software will program each device in the chain and then verify that each device has been programmed correctly using a checksum or CRC mechanism. As soon as the last device verifies the programming is correct, all devices are enabled and begin functioning. Programming and verifying all four CPLDs on my board took about one minute, using Altera’s ByteBlaster.

Now power back down, remove the programming appliance and jumpers, re-apply power, and cross your fingers that your design works correctly.

CPLDs have predictable setup, hold, and propagation times that are relatively independent of your application. Unless you are using your CPLD at the extreme edge of it’s performance limit, you probably won’t encounter any working subcircuits that stop working as a result of changing and recompiling a different subcircuit in the same CPLD. In more than 50 design changes and recompiles across all four CPLDs, I never had this problem. (I am not proud of that revision count.)

Programming the CPLDS in Manufacturing
If your manufacturing volume is low enough, you may be able to use the CPLD vendor’s programming appliance to program the CPLDs, the same way you did your prototypes. More likely, though, your volumes will require a faster solution.

One alternative is to pay extra to procure the CPLDs already programmed, from distributors that offer programming and labeling services. Another option is to use your in-house programming department, if you have one. With these solutions, the extra handling associated with programming the fragile, fine-pitch parts off board may cause more PCB solder-joint defects than the convenience merits. Regardless of assembly yield, these approaches add to the number of unique parts your company must stock for your PCB.

If you have in-circuit test equipment, you could program blank CPLDs after they have been soldered onto the PCB. In the likely case of your PCB containing multiple CPLDs of the same type, you gain the further advantage of requiring fewer unique part numbers and greater part volumes.

The process by which you convert the CPLD programming files into vectors for your ATE is relatively straightforward (Fig. 6):

1. Since CPLD design changes occurred frequently during prototype debug, we automatically notified the board test programmer of design changes whenever any of the CPLDs was recompiled. Nightly, we ran a daemon that inspected each CPLD’s Programming Object File (*.pof), looking for a new time stamp. If a file had been updated, the board test programmer received an e-mail notification.

2. The board-test programmer then used the CPLD vendor’s CAD tool (Altera’s MaxPlus2) to convert the four *.pof files into a single Serial Vector Format file (*.svf), which represented all the vectors needed to erase, program, and verify all four CPLDs. This step required a JTAG Configuration File (*.jcf), which stipulates the order in which each CPLD design appears in the JTAG chain. (Imagine accidentally programming the correct behavior into the wrong CPLD!)

3. Next, the board test programmer used a command-line tool provided by the vendor (Altera’s svf2pcf utility), which converts the single *.svf file into a series of Pattern Capture Format files (*.pcf), which are suitable for compiling on our HP 3070 board-test ATE (Fig. 7). In addition, the board test programmer wrapped the svf2pcf utility inside a larger script file that maintained header and comment information in the *.pcf files.

4. The board test programmer then compiled the *.pcf files into test object files using the HP 3070 test development software.

5. Finally, the board test programmer modified the HP 3070 Testplan file for my board, to target the newly compiled test object files. The new board test was then ready to program CPLDs with the new download bits.

This process was repeated several times because of my design changes. The board test programmer was able to completely regenerate the OBP portion of the board test in about a half day.

Before performing this process, the board test programmer also had to assign the TCK and TMS nodes as critical to the HP 3070. This notified the HP 3070 software to assign close tester resources to these nodes, resulting in short fixture wires to these nodes to improve signal fidelity.

Shortened Programming Time
We are now using our HP 3070 board tester to program the CPLDs in manufacturing. We are using a version of the CPLDs warranted by the vendor to work with fixed programming-pulse-width algorithms. The programming time is 12 s total for four CPLDs. Your mileage may vary.

Regardless of how you program the parts onboard, you will have to establish new PCB rework procedures to ensure that PCBs that have CPLDs replaced go back through the programming cycle. Of course, it’s usually obvious if a device has not been programmed—your PCB won’t function. You can, however, use one of your unused pins as an output that will light an LED indicating that the device is programmed.

We are only just beginning to appreciate the benefits of using ATE to program the CPLDs in manufacturing: After finding a hardware bug in one CPLD, we were able to easily fix all production boards before first shipment by reprogramming the CPLD on the ATE—try doing that with greenwire.

The high performance and density of modern CPLDs, combined with dropping prices, make CPLDs increasingly popular design choices. Further, the time-to-market advantages of onboard-programmable CPLDs during development and debug were a strategic asset in our product development. We also believe that, at 12 s programming time for four parts, programming the CPLDs using our existing ATE is a strategic asset in manufacturing. T&MW

ACKNOWLEDGEMENT
Fred Florence, of FourCom (Dallas, TX), designed several of the larger VHDL code modules in this project.