Careful PCB Layout Enhances Onboard Programming
Part I of this two-part series describes the PCB design techniques that can help you effectively employ onboard programming to speed the production and test of products containing complex programmable-logic devices.
Kevin Wible, Hewlett-Packard, Loveland, CO -- Test & Measurement World, 1/1/1999 2:00:00 AM
| Programmable logic devices have supplanted the many glue-logic chips that once crowded PCBs. The decade since the introduction of the pioneering 22V10 PLD (see "CPLD Background") has brought several programmable-logic advances. You can now buy complex PLDs (CPLDs) that contain the equivalent of 10 to 50 22V10s. Modern CPLDs are no longer one-time-programmable. Indeed, you can employ onboard programming (OBP) to reprogram them tens of thousands of times after soldering them to PCBs. Of particular significance to your test-engineering function, today’s ATE can program these devices while testing the boards they populate.
I used four high-performance CPLDs to implement all the circuitry required to support a 50-MHz embedded CPU coupled with DRAM and a LAN port. I used the CPLDs to build the DRAM controller, to control the LAN IC, and to implement a variety of state machines controlling CPU bus cycles, decoders and interrupts. As powerful and flexible as OBP CPLDs are, pitfalls await the OBP technology novice. In this article, first of a two-part series, I aim to help you design an OBP PCB. In March, part II will focus on CPLD internal design considerations plus manufacturing and test issues. My goal is to help you avoid the mistakes I made. The Design Phase When designing an OBP PCB, you must first decide how to program and reprogram the devices. You must be able to put the devices to sleep during programming, so plan to add the test points or jumpers necessary to continuously assert a reset signal. My reset circuit employed a large capacitor pulled to VCC through a resistor to create a long RC time constant, buffered by a low-leakage comparator with hysteresis (Fig. 1 ). A test point at each capacitor terminal permits me to short the capacitor with a jumper to hold the PCB in reset indefinitely.
You’ll find it helpful, but not imperative, to provide a way to disable the main PCB clock, thereby reducing the risk of spurious noise during the programming cycle. My clock oscillator had an output-enable pin, so I added a resistor and test points to that input so I could disable the oscillator indefinitely. An embarrassing oversight for many first-time OBP CPLD designers is forgetting to anticipate the unprogrammed initial CPLD state. I failed to note that several outputs from my address-decoder CPLD served as bidirectional bus transceiver enable signals (Fig. 2). Because most unprogrammed CPLDs set all user pins to high-impedance states by default, it was just a matter of time until several transceiver bus-enable signals floated to the enable state during OBP, thus creating massive bus fights between the various bus transceivers.
I also learned the hard way that the high-drive logic families, especially those in tiny shrink-small outline packages (SSOP), actually explode—their cases crack—in the presence of an extended bus fight. I added a few weak pull-up resistors to prevent the enable signals from floating to the enabled state—but it still bothers me that, to compensate for the CPLDs’ floating outputs, I had to clutter my design with components whose only function was to prevent fires during the first few minutes of power-up during OBP. Several CPLD vendors now offer parts that default to weak pull-up states on all user pins before the first OBP operation. Those versions were not available when I began my design, however, nor were white papers or other guidelines that could have alerted me to this issue. Another design concern is pin-locking, or the ability to define a your CPLD’s pinout early in the design cycle while retaining the flexibility to recompile new or different functionality inside the part. (All CPLD vendors claim that their pin-locking ability is the best.) The ability to recompile internal functionality without changing the pinout is critical if you hope to complete your CPLD designs while the PCB designers handle placement and routing tasks. Your PCB layout group will have trouble accommodating last-minute pinout changes. I did not have any problems related to recompilation despite having locked down every user pin on each of four large CPLDs before my first compilation. In one case, however, I suffered a 3-ns clock-to-output penalty due to my overconstrained pinout. Fortunately, I was able to remap that output to a different, unused pin to eliminate this penalty. You should strive for an initial CPLD design that consumes about 75% of the CPLD’s resources (including macrocells, D flip-flops, logic-array blocks, and user pins). With less than 75% utilization, you are paying for an unnecessarily expensive part; with higher utilization, you risk not being able to squeeze in redesigns mandated by your initial design errors or your sales and marketing department’s promises to customers. Believe me, you will experience both. I started out with 75% flip-flop utilization in each of my four CPLDs, and all four designs grew. In one case I ended up using 127 of 128 flip-flops due to creeping hardware features. To my surprise, I did not have trouble getting the design to compile and fit into the part. Employing Daisy Chains In the likely event that you have multiple CPLDs on one PCB, you will have to decide whether to cascade the CPLDs’ respective programming ports into a single daisy-chained port or to provide a separate programming port for each CPLD (see "CPLD Programming Ports"). Until the PLD industry matures further, I recommend you only daisy-chain devices from the same vendor into the same programming port. In general, CPLD Vendor A will claim to tolerate the presence of Vendor B’s CPLDs in the same programming chain; the burden is on you, however, to figure out the depth of the programming port bypass register on Vendor B’s CPLD and to modify the chain configuration information correspondingly for Vendor A’s programming software. Fearing the unknown, I designed a separate programming port for each of my four CPLDs during the my first board revision, but that approach consumed too much space. My second revision included a single port daisy-chained to all four CPLDs. I designed the chain with removable 0-V series resistors and lots of test points so I could break up the programming chain if I had to—fortunately, I didn’t. You should look for a vendor who offers devices that are fully IEEE 1149.1 compliant. By using IEEE 1149.1 compliant devices, you can develop your ATE board-test programs faster and easier than if you saddle your design with proprietary programming ports. Also, in the event you mix multiple vendors’ CPLDs into the same programming chain, you stand a better chance of getting them all programmed correctly if they all comply to the standard. Some IC vendors who claim compliance with IEEE 1149.1 actually have errors in either their 1149.1 port implementation or their corresponding Boundary Scan Description Language (BSDL) file, which describes the device’s boundary-scan register and is useful for automatically generating ATE test programs. One way to keep the CPLD vendors honest is to pass the vendor’s BSDL file through a BSDL syntax-checker, which is available on the Web at HPB ScanCentral.Invision1.com Send indicated discrepancies in the BSDL file to the vendor for correction. Despite this being my first experience designing with OBP CPLDs, and despite my embarrassing oversights in the design phase, I did find that the ability to design CPLDs during the middle of the PCB layout cycle, combined with the ability to reprogram the CPLDs while troubleshooting and modifying prototypes, sped up product development. OBP CPLDs are evolving rapidly. In the time I designed the embedded CPU/DRAM/LAN/bus-cycle systems, CPLD densities increased to the point that all the circuitry could have fit into a single device rather than the four smaller parts I used. T&MW Kevin Wible is a design engineer at Hewlett-Packard’s Manufacturing Test Division, Loveland, CO.
In part II of this article, scheduled for March, the author will explore device-internal design issues and the use of ATE for programming the devices during manufacture. |
Talkback
No related content found.
- 0 rated items found.
Datasheets.com Electronic Parts & Inventory Search
185 million searchable parts
- Part Number
- Description
- Inventory
- Products
- Manufacturers
Sponsored Links
View All Webcasts
