One of the more important features designers look for these days is the ability to handle both planned and unplanned logic changes as system development progresses, and even after systems have been shipped. By incorporating the latest complex programmable logic devices (CPLDs), designers get this flexible logic capability. These CPLDs have even evolved to the point where they're supplying significant logic resources (many thousands of gates) to support system designs, just as their smaller brethren, the PLDs, did.
The growing need for in-system programming (ISP) capabilities, especially after systems have been shipped, stems from two key issues. First, time-to-market pressures often don't let manufacturers fully test systems. That means hardware anomalies may reach the field. If the system supports ISP, a field-service technician, or even the customer, can download new configuration information without taking the system apart. That reduces the cost of "servicing" the equipment. Second, feature upgrades often can be done in much the same way. Using the ISP capability, the logic could be reconfigured to add new functions or speed up existing functions.
Early CPLD architectures were not designed with ISP field upgrades in mind. However, the latest offerings from various suppliers provide robust architectures and, in a few cases, the ability to update individual sections of the CPLD. Supporting a wide range of change options suggests the need for a "finer-grain" organization than most CPLDs provide, but some of the latest CPLD designs do provide a finer-grained architecture.
Another aspect of robust architectural design includes the ability to redirect a product term from one macrocell to another, at the single-product-term level (rather than groups of product terms). Having an abundance of product terms, as well as global resources, such as clocks, sets, resets, and three-states, is another important capability. Local inversion control and independent macrocell clocking are other features that further improve the flexibility of ISP.
Software Requirements Too
Beyond the architecture are the software requirements. These include careful budgeting of resources (p-terms, clocks, etc.) when assigning position-sensitive functions within a CPLD function block. By spreading resources around and retaining pockets of functional capability, the design software delivers significant extra flexibility for making future changes.
Underlying both the architecture and software is the device technology, which must support an arbitrary number of reprogramming cycles—frequently termed "endurance." CPLD suppliers have already moved away from nonvolatile, ultraviolet-erasable EPROM technology, and every CPLD supplier now offers devices that employ some type of flash- or EEPROM-based configuration scheme.
Thus, a key factor in selection becomes the chip's endurance. Xilinx CPLDs, for example, currently allow 10,000 reprogramming cycles, allowing wide latitude for future design changes without impacting device speed or reliability. Most other vendors have opted to provide lower endurance guarantees (that is, 100 cycles), supported by the argument that anyone can get a design right in 100 attempts, and might only have to do one or two final updates.
That argument would be acceptable if the 100 attempts were only for the CPLD, and typically only if the device is used for prototypes or product development. However, the most frequent development model today is the single-controller model, in which all reprogrammable devices (SRAM, SDRAM, flash memory, FPGA, and CPLD) reside on a common JTAG download chain. To simplify on-board logic, these systems use a strategy to "reprogram everything when anything changes." To simplify matters further, the CPLDs and FPGAs are also changed even when any software update (SRAM/flash memory) occurs. In this situation, it is questionable whether even 1000 programming cycles will suffice.
Finally, all components must play together to deliver pinout retention or "pinlocking." That's the ability to retain device pinouts, therefore avoiding pc-board wiring changes for all but the most complex design changes. Where many designers get into trouble is with small changes, such as adding a p-term to an equation, inverting a signal, or adding an input to an existing p-term. When CPLDs can't support this kind of change while maintaining the previous pinout, the value of the CPLD becomes questionable. For ISP to be useful, the architecture and software must be designed to maintain pinouts for multiple design edits. Field upgrades without ISP and pinlocking have no real value, especially when older EEPROM architectures are employed.
When designing a system with CPLDs, engineers typically encounter three basic types of field upgrades:
Compensating: This can be also thought of as correcting a design error due to inaccurate system knowledge. Such an approach is frequently found in data-processing applications, as today's designers confront a massive challenge when they start to design with a new CPU or other logic part prior to actually using it.
For example, the datasheets for popular microprocessors easily exceed 100 pages, and synchronous DRAM datasheets exceed 30 pages. Therefore, there's plenty of room for unexpected behavior in a design, simply due to inaccurate system knowledge. A classic situation would be misunderstanding whether data was available on a leading or falling edge of a clock. Frequent interrupt or direct-memory access (DMA) request conditions are vague enough to be sites where a few product terms may be needed to correctly cover the requesting condition.
Adding capability: An example of this case is a board that was developed with software to operate over a target address range. However, a new version is then created to expand the memory space with new applications. But board demand requires that the new version be shipped early without the appropriate software debuggging for the new applications and memory range.
After the board has shipped—and the impact of the new applications is fully understood—a field upgrade can be used to increase the address range. Typically, this involves enabling additional memory modules and adjusting the appropriate timing signals to support the additional memory (control signals, wait states, etc.). To obtain a faster response with newer memory chips, designers may need to involve the elimination of wait states or early enabling (via clock-phase adjustment).
Planned changes: These can cover a myriad of topics. For example, in the past, board customization was a standard capability. Simple things like a font enhancement to a high-end printer were implemented by a service technician making a visit, opening the printer and setting a couple of dip switches. Today, that change would involve simply attaching an external cable and downloading the new pattern to the appropriate programmable device. And, it would not require a visit from a technician.
To gain a better understanding of how some of these techniques are applied, let's examine a specific example of an upgrade to a board that was installed in a system while in the field. Part of the board's circuitry includes an implementation of a standard microprocessor wait-state signal generator (Fig. 1). Here, most of the XC9500 macrocell logic is not shown (that is, no flip-flops or extra gates).
The circuit focuses on delivering 15 product terms worth of logic to an output pin, which drives the microprocessor wait input. At field-upgrade time, an additional I/O board is added to the system, warranting a change in the wait-state logic to account for the new board.
To compensate, three more product terms must be added (Fig. 2). The top macrocell site must retain two product terms at the existing site, but does have three available p-terms to forward down to the wait-state site to augment the previous tally to 18 p-terms. Bidirectional p-term assignment, along with individual p-term resolution, makes this sort of upgrade very easy in XC9500 CPLDs, while retaining the original design pinout.
Other applications of the same, basic field upgrade could include making coefficient changes on DSP filters, enabling (or even creating) I/O ports or adding test circuits. Although not strictly a "field upgrade," last-minute board configurations prior to shipment are similar to field upgrades. In this case, there may be multiple configura tions of a single board sold as different products. The company can inventory one product, then make last-minute changes to reconfigure and test the "standard" product on a demand basis.
Designing for field upgrades demands sound planning. First, engineers must select the right CPLD to ensure that functional and architectural resources exist for the future. This not only means adequate gates and flip-flops for a field upgrade, but also, available CPLD connection paths. Likewise, it's vital to use design software that reserves function and connection resources for future changes. Anticipating the need for higher speeds in the future is equally important.
Here are some guidelines that are appropriate for the XC9500 CPLDs, as well as for other manufacturers' CPLDs:
- Choose a CPLD family with a good pinlocking architecture.
- Select a part that meets current design requirements with speed to spare.
- Choose a part with ample remaining capacity (headroom) if significant field upgrades are expected in the future.
- Direct the design software to distribute logic resources.
- Check that connection resources remain, so future paths can be found.
- If capacity exceeds 90%, and speed is near the limit, consider the advantage of a larger or faster pin-compatible part. This will minimize future risk.
A number of other practical issues exist, and understanding them can reduce risks and ensure successful field upgrades. First, a download point must exist. Today, the standard is a JTAG port, which supports additional instructions for ISP as well as test functions. Recognize also that some aspects are not under ISP control, like the power connections of the programmable parts. There will always be things that cannot easily be changed.
A number of vendors offer circuits that have the JTAG pins do double duty. And, there are reports of reliability issues in field programming systems while those pins are operating. Designers won't be able to add functionality or speed to an installed part, so it makes sense to predict future needs here (see point 6 above).
May Need "Shut-Down" Circuit
Second, the ISP circuitry must be robust. Initial programming of the board in production is an ideal situation where lots of other wiggling signals are at a minimum. When making field upgrades, however, that may not be the case. Some devices might be so sensitive that additional circuitry must be inserted to "shut down" the system to a quiet state, so the on-chip charge pumps can deliver correct programming signals.
Additionally, most ISP CPLDs today must be properly bypassed and decoupled because their internal charge pumps generate their internal programming voltages from the supplied power. If the power is noisy, the pump may not be able to deliver its voltages properly. And, some devices have potential problems with signal ringing, which could cause internal ground rails to affect the charge pumps. Bypassing doesn't solve that one, but inserting a series resistive termination reduces it.
Depending on the noise environment, any ISP-capable CPLD may need to have additional signal gating or JTAG buffering to assure that the signals are clean. Some may require resetting the system, or gating off clocks or other pesky signals to complete the ISP operation. Each system is different.
One interesting, practical payoff is that, with sufficient planning, field upgrades can often occur without opening the box. This greatly improves system reliability. Some systems are so delicate that they cannot tolerate having their boards loosely seated by the field technician, or they may react negatively to a screwdriver left behind inside the chassis. For those systems, having an externally accessible field-upgrade port solves a critical problem.
Other practical limitations to leveraging ISP capabilities revolve around the present lack of industry standards regarding the devices. Although many vendors are working with the IEEE-1149.1 subcommittee on ISP to achieve practical standardization for downloading, no standard has yet been released, and, in fact, several standards may evolve.
Today, it's common to see one system with as many as three different JTAG download cables being driven from three download software drivers. For Xilinx programmable logic, the M1.5 JTAG download software easily handles Xilinx FPGAs and CPLDs from one utility and just one download cable.
Today, the standard download approach is to attach a simple cable. However, there is no physical reason why the connection couldn't be an infrared or RF link, a modem, a cellular telephone, or even a laser. The only problems will be in how the bitstream is passed, and whether it requires a restrictive protocol. Third-party suppliers of downloading software and diagnostic tools are also on the rise, so an abundance of technology to improve the solution is also expanding. As the demand for ISP increases, the dimensions of field upgrades will change as well.