[Design Application]
Use In-System Programming To Simplify Field Upgrades
The Latest Complex Programmable Logic Devices Help Designers Reduce System Upgrade Costs And Speed Time-To-Market
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.
Supporting Changes 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.
Reprints
