|
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.
|
|
|
Fig 1.
Judicious application of jumpers in test points can
facilitate onboard programming: A means for (a)
continually asserting reset and (b) suppressing the
system clock helps to ensure a noise-free programming
environment.
|
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.
|
|
|
Fig 2. If
you're unaware of the initial state of an unprogrammed
PLD in your design, you could experience a
chip-shattering bus fight.
|
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.
|
Programmable logic
devices (PLDs) are digital ICs that you can program
to perform a digital function. PLDs come in volatile
and nonvolatile versions.
The ubiquitous
22V10-type programmable logic device (PLD) contains
10 flip-flops, each preceded by a programmable array
suited for implementing sum-of-products Boolean
equations. The outputs of the flip-flops may be fed
back to the input of the array, and any of the 22
user pins may be designated as an input to the array
or an output from the array or flip-flops. You can
program this versatile architecture to behave as a
wide, fast combinatorial circuit or a fast state
machine.
Volatile PLDs—also
called field programmable gate arrays (FPGAs)—employ
SRAM technology. They offer high density, low price
per gate, and medium speed. The host system must
reprogram volatile PLDs each time power is turned
on, and the devices can withstand an unlimited
number of reprogramming cycles without damage.
The term "PLD" used
without a qualifier generally signifies a
nonvolatile PLD—a grouping that also includes the
complex PLD (CPLD) and enhanced PLD (EPLD).
Nonvolatile PLDs employ either EEPROM or flash
memory technologies. They offer medium density and
cost more per gate than volatile devices, yet they
achieve higher operating speeds. You can use these
parts to build wide, fast decoding logic and fast
state machines. Because their memory is nonvolatile,
you need only program these parts once regardless of
subsequent power cycling. This nonvolatility is
especially important for parts that must wake up
instantly on release of the reset line, such as
address decoders or bus cycle state machines.
Early nonvolatile PLDs
were one-time-programmable and required
supervoltages (that is, voltages that greatly
exceeded the standard operating voltage) to program
the internal
EEPROM. This requirement dictated
that the programming operation take place before
soldering the PLD to a PCB. Modern nonvolatile parts
are reprogrammable over tens of thousands of cycles
and they no longer require external supervoltages.
Consequently, you can
solder unprogrammed CPLDs to a PCB and then program
(and reprogram) the parts. This onboard programming
(OBP) technique has time-to-market benefits both in
product development and in manufacturing.
During product
development, you can take advantage of what would be
a lull during PCB layout to design the internal CPLD
circuits. To gain this benefit, however, you must
have the courage to lock down the device pinout
before you have completed the internal circuits, and
not all CPLD architectures are amenable to allowing
you to define the pinout before you compile internal
CPLD circuits.
Additional
product-development benefits accrue during prototype
debug and repair cycles. With OBP, you have the
luxury of patching design errors by fixing the
internal circuit design, recompiling CPLD contents,
and reprogramming the improved functionality into
the CPLD in your existing prototype.
In low-volume
manufacturing, you can solder blank CPLDs to the
PCBs during assembly and later program the CPLDs
using a vendor-provided programming cable linked to
a PC running vendor-provided programming software.
In high-volume manufacturing you can use
bed-of-nails in-circuit ATE, which probably already
sits on your production floor, to both test the PCB
assembly process and program the CPLDs.
Either way, by
programming the CPLDs after PCB assembly, you reduce
the number of unique part numbers your company must
stock and track during manufacturing. What’s more,
eliminating off-board programming can increase PCB
assembly yields, because many new CPLDs sport
fragile fine-pitch SMT packages: The extra handling
required to program such CPLDs off-board could
introduce lead coplanarity defects.
—Kevin Wible
|
|
CPLD Programming Ports
Most CPLDs have a
four-pin serial interface port that shifts in
configuration bits and device reprogramming data.
The four pins generally include a Test Mode Select
(TMS) input pin for forcing the device into program
mode, a Test Data In (TDI) pin for shifting in
serial configuration data, a Test Clock (TCK) input
pin for clocking in the serial data, and a Test Data
Out (TDO) pin for shifting serial information out of
the device. Pull-up resistors on TMS, TDI, and TCK
ensure dormancy when the port is not in use.
Programming port
configurations include proprietary configurations
and the IEEE 1149.1 standard one. If you choose
1149.1-compliant devices, your vendor will provide a
Boundary Scan Description Language (BSDL) file,
which describes the boundary registers (if any) on
each I/O pin and the bypass registers used to shift
information through the device from the TDI pin to
the TDO pin. These files are useful to downstream
manufacturing processes, which take advantage of the
boundary-scan registers for testing.
In the degenerate case
of a single CPLD in your design, you will want each
of the programming port signals (TDI, TDO, TCK and
TMS), along with at least ground and perhaps power,
routed to a small header or connector that connects
to the CPLD vendor’s programming appliance.
Programming appliances
range in complexity from simple parallel cables to
cigarette-pack-sized modules. These appliances
connect to your PC, which, under control of your
vendor’s programming software, downloads programming
data to the CPLD. For production parts, you can omit
the connector that interfaces your PCB with the
vendor’s programming appliance, replacing its
functionality with an ATE fixture or other removable
connection.
|
|
|
A serial
programming port such as the IEEE 1149.1
Test Access Port allows you to implement
onboard test and programming for mulitple
daisy-chained PLDs.
|
Part of the attraction
of the four-pin serial port is that it lets you
daisy-chain multiple devices and program all of them
from the same programming port, as shown in the
figure. Signals TMS and TCK are broadcast to each
CPLD, and TDI flows into the first device in the
chain. Then TDO flows from that device to the TDI
pin of the second device in the chain, proceeding to
the last device in the chain, where its TDO flows
back to the programming port. In extremely long
chains, you should buffer TMS and TCK on-board to
ensure signal fidelity.—Kevin Wible
|
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.
|
