Focusing on chip programming
Higher density chips, harder-to-handle packages, and the need for manufacturing flexibility are stressing the capabilities of traditional PROM programmers. Can yesterday's hardware and software, with a few modern tweaks, still meet your needs? If not, where can you turn?
By Brian Dipert, Technical Editor -- EDN, January 7, 1999
|
When considering various hardware and software options for programming embedded microcontrollers, programmable-logic devices, and nonvolatile memory components and modules, you have a number of factors to consider (Table 1). First and most obvious is how big a check you have to write to obtain the equipment. But if initial purchase price is the only factor you research, shelling out less money up-front may turn into a lot of cash—and headaches—down the road. Will you use your programming equipment in the lab, in the manufacturing line, or both? How versatile does it need to be in the types of devices it supports, including the range of densities, packages, and manufacturers? How quickly will you need to obtain new device support, and how much are you willing to pay to get timely firmware upgrades? When you need technical assistance, do you have to get immediate response from a warm body at the other end of a toll-free line in your time zone, or can you handle a week-or-longer turnaround to an e-mail-submitted question that traveled halfway around the world?
How long do you plan to own the equipment, and does each option you’re considering provide sufficient feature-set head room to support the inevitable pin-count and logic/memory-density growth over that time frame? How many devices, in what shipping media, and with what yield do you need to program per day, and are additional capabilities, such as device marking, desirable? Finally, instead of purchasing dedicated programming equipment, can you upgrade a board test station to support the programming function? Perhaps the cheapest and simplest programming platform available consists of a serial- or parallel-port cable plugged into the system board containing the devices you are programming. Software running on the host computer controls this cable and drives onboard address, data, and control signals and supply voltages. Increase your budget to a few hundred or few thousand dollars, and you can afford a single-socket or even multisocket PROM programmer. Or don’t buy any equipment at all, but instead contract the device programming to your silicon vendor or to a distributor or other service organization (see Table 2 and sidebar "Spending money one chip at a time"). You can obtain low-end automated handlers for a few 10s of 1000s of dollars, whereas high-end platforms, such as robotic pick-and-place handlers and automatic test equipment (ATE), can set you back several 100s of 1000s of dollars. Although this high-end equipment might sound expensive, the per-device cost in a high-volume consumer- or PC-system manufacturing environment can be much lower than other options. And, if your chip comes in a fine-pitch leaded or leadless package or if you want to exploit just-in-time manufacturing flexibility, you may have no alternative. Support isn’t simple The life of a programmer vendor is by no means easy. Consider that these companies must support dozens of semiconductor manufacturers, each with dozens of devices in their product lines. Each of these devices goes through numerous product and process steppings during its lifetime, some of which force alterations in the programming algorithm. Because multiple device versions can simultaneously exist in a manufacturer’s or a distributor’s inventory, the programmer must somehow support them all . In a best-case scenario, the programmer vendor receives silicon samples that may not even be fully functional from one of the first few new-device manufacturing runs. Alpha- and beta-site customers are also receiving these samples and need programmer support "yesterday." If the programmer vendor receives no notification of a device stepping that alters the algorithm, the only warning will be when its customers’ manufacturing lines have gone down or when their customer returns increase because of programming failures. Bug-free algorithm development is crucial to ensuring that the chip holds its configuration data not only when the programmer initially verifies it, but also several years later in the end system. If you’ve never seen the device-programming section of an FPGA, PLD, memory, or microcontroller data sheet, a brief inspection might prove a real eye opener. Placing a high-performance processor less than 1 in. away from the device being programmed on the system board makes it easy to achieve noise-intolerant control inputs with stringent minimum and maximum pulse-width specifications, multiple loops, and branches. The challenge is much greater, however, when the programmer interfaces to the device it’s configuring via several inches or feet of cabling and the programming intelligence is barely more advanced than an ancient, 4-bit CPU. Sufficient processor horsepower and command-set robustness must be available to run the algorithms, and the programmer must contain adequate onboard memory to store the programming code, to buffer the configuration file, and to use for scratchpad data. The closer the programmer hardware is to the device it’s programmed, the faster the hardware can transition signals. Noise is also less of a concern with short interconnect runs. How do semiconductor manufacturers try to simplify the jobs of their programming partners and quickly establish robust device support? It makes little sense to deliver a chip to a customer if the customer’s programming equipment doesn’t recognize it, just as a microprocessor is nothing more than an ineffective paperweight without corresponding development-tool support. Most semiconductor companies dedicate personnel to working with programmer vendors, developing and delivering specifications, conducting regular meetings, answering ad hoc questions, and jointly resolving customer issues as they arise. A few chip companies take partnership to the next level, paying for on-site algorithm-development engineers from first-tier programmer vendors. Others develop the algorithms themselves when possible, using tools such as Data I/O’s Mercury development system. Many chips contain manufacturer, device, and stepping IDs, allowing the programmer to confirm that the part in the socket matches the one the operator selected via the user interface and sometimes even enabling autoselection. Altera (www.altera.com) sells programmable-logic-device versions supporting a tester-friendly, nonbranching algorithm. The company even embeds erase and programming pulse-width information in each CPLD as part of outgoing tests to account for wafer lot-to-lot process variation. The company claims that this feature allows it to maximize device-testing yield and, consequently, minimize per-device cost. Other CPLD manufacturers counter that they don’t need to burden the programming algorithm with this added complexity because they have tighter process control and thus require no pulse-width variations. Reality is probably somewhere in the middle of these opposing viewpoints. Latest generation nonvolatile memories and programmable-logic devices contain on-chip state machines with command and status registers. These state machines integrate portions of the program and erase algorithms that the PROM programmer previously controlled, and, by minimizing system overhead, they also speed effective programming throughput. Other features, such as onboard address counters, RAM page buffers, and wide data buses, reduce the average number of bus cycles to program each memory location. Flexibility isn’t free Other silicon requirements further complicate programmer design and force tough feature-versus-price decisions. Many chips require application of various high currents and high voltages to one or several pins—sometimes to turn on special programming command modes, sometimes to unlock and enable alteration of memory locations, and sometimes to generate necessary erase and program voltages. Even when the chip contains internal charge pumps that boost an externally applied 3.3 or 5V, it sometimes allows an optional external high voltage to bypass the charge pump for maximum speed, as with Intel (www.intel.com) and Sharp’s (www.sharpmeg.com) SmartVoltage flash memories and the latest devices from AMD (www.amd.com) and Fujitsu (www.fujitsumicro.com). Other flash-memory technologies that are more efficient at the transistor level need not support the internal charge-pump-bypass feature, however. Unfortunately, little standardization exists concerning the necessary high-voltage levels or pin locations. For a given package type and pin count, such as 32-lead PLCCs or 144-lead TQFPs, therefore, programmer vendors have a couple of choices. They might supply only a few highly flexible, high-current output drivers and rely on vendor or third-party pin scramblers to route the necessary signals to appropriate device pins (Table 3). This approach minimizes the base programmer cost but means that you probably have to make a significant investment in adapters throughout the life of your programmer. Alternatively, the vendor can beef up the number of configurable output drivers, adding to programmer cost but providing a more universal out-of-box solution. Two other device-pin requirements further complicate the issue. Bidirectional signals, such as data buses, require transceivers instead of one-way buffers on the programmer. Also, if the chip operates at low voltage and can’t handle 5V inputs, the programmer must support voltage flexibility even in the absence of a greater-than-5V requirement. For this reason, many programmers designed a few years ago can’t support 5V-intolerant chips. To show the range of features available in PROM programmers, consider two hypothetical examples at different ends of the spectrum. A low-end unit might simply be an ISA add-in card for a PC, containing interrupt-signal and I/O-port decoding logic, bus transceivers, and minimal high-voltage circuitry. The user interface is DOS-based, and the PC’s microprocessor runs the programming algorithm, stored on the computer hard drive along with the data programmed to the chip. Signals travel down a long ribbon cable that connects to the ISA board on one end and to a socket containing the chip on the other. This programmer is low-speed (although if you program small or inherently slow programming devices, you might not even notice) and perhaps even noise-prone. But, by using existing PC hardware and software, it is also low-cost. Some of these units even fit into a spare drive bay (Figure 1)! Now, let’s define a hypothetical high-end single-socket PROM programmer (Figure 2). It needs to contain enough upgradable storage memory (perhaps flash memory or a hard drive) for all the programming algorithms, plus RAM for code execution, scratchpad, and a memory buffer the size of the largest supported device. Onboard processing intelligence and memory combine to let you operate the programmer while it’s both tethered to a PC and stand-alone. Instead of using an embedded microcontroller, you download the programming algorithm directly to an SRAM-based FPGA state machine for highest perform-ance. Fast logic, along with a short interconnect to the chip being programmed, minimize noise and system-induced programming overhead. Add lots of highly flexible and individually configurable pin drivers and a graphical user interface running on the PC, and your high-end programmer is complete. Single-socket programmers work well in engineering labs but are often impractical for all but the lowest volume manufacturing environments. The time necessary to transfer chips one by one between incoming and outgoing shipping tubes, trays, or tape-and-reel packages is often longer than it takes to program the chips. Plus, this scenario is manually intensive and, frankly, a monotonous and boring assembly-line routine. Enter the gang programmer, one of several production-programming-equipment alternatives (Figure 3). Conceptually similar to a row of single-socket programmers but sharing a power supply, processor, and other electronics, the traditional gang programmer offers limited socket-to-socket independence. If one program pulse is sufficient to program the device in Socket 1 but programming of other chips in other sockets is incomplete, the gang programmer is intelligent enough to terminate pulse generation to Socket 1 and continue running the algorithm on other sockets. However, you can’t begin programming the first of a next set of devices until the last device in the first set completes. The concurrent programmer builds on the gang-programmer foundation and can improve programming throughput in some cases. Each socket has a corresponding processor, memory, and pin drivers, meaning that the programming algorithm begins as soon as you insert a device. If one device fails to program, others continue without interruption. Note though that all devices must be of the same type and from the same manufacturer; you can’t have an embedded controller in Socket 1, a CPLD in Socket 2, and two flash memories from different manufacturers in sockets 3 and 4, for example. Concurrent programmers’ advantages are most evident with chips that program very fast and with high-socket-count programmer configurations. If your devices, such as high-density nonvolatile memories or antifuse FPGAs, take a long time to program or if your programmer offers only a few sockets, a gang programmer might be a comparable-speed and cheaper option. Eliminate the entity Operator error makes manual programming, using either single-socket or gang/ concurrent equipment, a less-than-ideal situation. People, unlike machines, occasionally lose their concentration or are imprecise in their movements, and the result is bent pins or other problems caused by improper device insertion in the socket. This scenario reduces programming yield and creates poor lead integrity when you subsequently attempt to solder the chip onto your board. With large and relatively robust packages, such as DIPs and PLCCs, bent pins aren’t too much of a problem. SOPs, TQFPs, and BGAs, on the other hand, are more challenging to successfully place manually into sockets. Vacuum wands and other aids can reduce—but not eliminate—handling-yield loss. An operator with insufficient antistatic protection or who enters the incorrect device or manufacturer information into the programmer can even ruin an entire batch of parts! Automated handlers are one potential solution to these problems (Figure 4). Low-end units are basically single-site programmers with gravity-fed input shipping tubes that contain a mechanical apparatus that inserts and removes chips from the programmer socket. Depending on whether a device passes or fails programming, the handler routes it to an appropriate gravity-fed output tube. Project-based software controls the setup, allowing the user to input the device type, number of devices, manufacturer, and programming data file. As prices increase from 10s to 100s of 1000s of dollars, handler capabilities also dramatically expand. At this level, you have a choice of mix-and-match input and output shipping-media support, including tubes, trays, and tapes and reels. Optical inspection equipment works with robotic control systems to precisely align, place, and remove chips from programmer sockets. As with gang or concurrent programmers, high-end handlers usually provide multiple sockets to maximize throughput. Many handlers also offer optional postprogramming device marking, which is useful for helping you keep track of which ROM code you put in batches of programmed memory chips, for example. Labels and laser marking—for the smallest packages—are two alternatives here. Instead of programming your chips before soldering them onto the system board, why not install them and program them later in the manufacturing line? This technique, "onboard programming" (OBP), is becoming increasingly popular. For ultrasmall chip packages, such as Tessera’s (www.tessera.com) µBGA, which are a challenge to manage even in the most expensive handlers, OBP may be your only option. Like anything else, however, OBP also has limitations and, consequently, isn’t for everyone. What are OBP’s advantages? First, the technique requires neither you nor automated machinery to contact the device leads any more than is necessary to place them on the board, which minimizes lead-coplanarity defects. You also minimize your inventory of programmed-device line items. This selling point is especially attractive if, for example, you manufacture a hardware platform with end-product options that you differentiate solely by software revisions or programmable-logic-enabled capabilities. OBP enables just-in-time manufacturing, the ability to configure the system at the very end of the assembly line in response to customer orders. You can customize the system on a customer-by-customer basis and quickly implement new ROM versions in response to bug fixes or feature additions. You can achieve these capabilities using traditional offboard-programming methods, but they require that you install expensive and board-space-intensive chip sockets on the system board. If you own expensive board-test hardware and software, using the same equipment for OBP maximizes the return on your investment. On the other hand, adding device programming often impactsthe per-board test time and, therefore, each manufacturing line’s "beat rate," the number of system boards it can assemble in a given amount of time. Concurrently programming multiple parts reduces the beat-rate impact, but not all hardware platforms, software standards, and interface protocols allow this technique or make it easy to implement. Alternatively, you might therefore choose to implement OBP after board test on a separate line or multiple parallel lines using less expensive dedicated OBP equipment. You should also consider the likelihood that a percentage of the devices will exhibit errors during programming and the cost and complexity of subsequent rework. Removing and replacing faulty chips is at best a human-assisted, if not a fully human-implemented, technique. Finally, OBP can make the board design more complicated than an approach that relies on offboard programming before soldering. The earliest OBP platforms were products such as Data I/O’s BoardSite, which relies on a dedicated connector to route necessary signals to the chips you’re pro- gramming (Figure 5). A more common approach nowadays uses ATE with its bed-of-nails interface to test points on the board to exercise all device pins at once (Figure 6). Parallel interface programming, like that in a PROM-programmer socket, maximizes how quickly you can transfer information to and from the device you are programming. It minimizes system overhead and, consequently, the impact to overall test time. If the programmable device contains a JTAG, I2C, Microwire, SPI, or another serial interface, you might want to consider using 1149.1 test equipment or an alternative serial platform for programming (Figure 7). Serial interfaces are inherently slower than parallel alternatives at the same clock frequency, but the JTAG or equivalent approach might still be fast enough to meet your requirements. You need to answer the following questions to determine whether serial programming makes sense for you:
One key advantage of serial programming, especially JTAG, is that it often uses a dedicated and low-pin-count interface port, so you don’t have to design around potential bus contention and improper device power-up issues. JTAG testers are significantly cheaper than parallel ATE equipment, although ATE allows more elaborate testing than JTAG testers, which are primarily restricted to evaluating chip-to-chip interconnect and rudimentary chip functions. Make sure you carefully design your serial signal routing to achieve the highest interface frequency. Even if your nonvolatile memory, for example, doesn’t provide an integrated serial port because of limited pin count, you might still be able to program it with a serial interface. If the system’s embedded processor contains a JTAG or Motorola’s (www.motorola.com) background-debug-mode port, you can control the processor’s external address, data, and control buses via an emulator and drive necessary signal transitions to send commands and read back information from the memory. Just realize that using this approach significantly increases the number of serial bits you need to program a location. Whereas one bit sequence might be sufficient to program a device with an integrated JTAG port, you need multiple sequences under the indirect programming method—one to set up the address and data pins, another to toggle the write-enable pin active, a third to transition it back to inactive, and so on. Data I/O’s BoundarySite programmer, which the company developed with JTAG Technologies, addresses this shortcoming by providing an optional dedicated AutoWrite pin that directly controls the flash-memory write-enable input (Figure 8). In-system write Another common programming technique is in-system write. This approach derives from OBP but uses the onboard CPU to configure the memory and programmable logic instead of offboard logic, such as a tester, running the programming algorithm. The new programming data can come from resident mass-storage media, such as a hard drive; or removable media, such as a floppy drive or PCMCIA card; or a parallel or serial external interface, such as RS-232C or a wireless link. Although you can use in-system write in an assembly line, it more commonly finds use in code and logic upgrades after you ship the system to the end customer. Such an update scheme, as in upgradable PC BIOSs, cellular-phone firmware, and networking-equipment logic functions, is cheaper and requires less downtime than calling a technician. When in-system programming flash memory, keep a few issues in mind. Because erasing or improperly reprogramming boot code renders the system brain-dead, you should place the initialization and programming algorithms either in a separate, programmed memory chip or in a protected block within the memory. Also, most flash memories do not allow you to read from part of the device while you’re rewriting another area, so you need to copy and execute the reprogramming code from system RAM. (Intel’s Advanced BootBlock, AMD and Fujitsu’s Simultaneous Read/ Write, and Hitachi (www.hitachi.com) and Mitsubishi’s (www.mitsubishichips.com) Background Operation components are notable exceptions.) For programmable logic, you again need to consider several factors. You can rewrite most programmable logic only in bulk, meaning that you lose any logic functions as you begin rewriting the chip. Make sure not to implement any control logic necessary for reprogramming in the device you’re planning to overwrite! Also, in spite of your vendor’s pin-locking claims to the contrary, when you finalize your initial logic design, do not populate at least one-fourth to one-third of the device’s logic and I/O pins. This head room gives you a lot of flexibility in the logic changes you can make without impacting design pinouts or timing. Reconfigurable computing using SRAM-based FPGAs, which heavily depends on in-system-rewrite capability, continues to find use in audio and image processing and other niche applications. Easy-to-use development software, not hardware, primarily limits broader acceptance. Although Xilinx (www.xilinx.com) has obsoleted its high-flexibility XC6200 reconfigurable silicon platform, the company’s new Virtex line retains some partial reconfigurability. Xilinx points out that using such an architecture even lets you implement the CPU core internally within the FPGA and use it to reprogram other logic within the device. Other examples of partially reconfigurable FPGAs include products from Atmel (www.atmel.com) and DynaChip (www.dyna.com). References
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Acknowledgments Special thanks to Bob Beachler and the troops from Altera, Peter Larsen from Intel’s flash-memory group, Steve Stark and Tim Schnettler from Lattice Semiconductor, Eric Sells and the folks at Microchip Technology, Andy Robin from Vantis, and Neil Jacobson and his team from Xilinx for giving me the silicon vendors’ perspectives on device-programming issues and alternatives. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Brian Dipert, Technical EditorYou can reach Technical Editor Brian Dipert at 1-916-454-5242, fax 1-916-454-5101, e-mail edndipert@worldnet.att.net, http://members.aol.com/bdipert. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Large numbers of silicon manufacturers and new devices to support, plus algorithm changes resulting from steppings on chips, create both hassles and opportunities for programmer vendors.For more information:
For more information on products such as those discussed in this article, use EDN's InfoAccess service. When you contact any of the following manufacturers directly, please let them know you read about their products in EDN.
Advantech Instrument Corp
Taipei, Taiwan
886-2-218-4567
fax 886-2-218-2435
www.aec.com.tw
Advantest Corp
Tokyo, Japan
81-33-342-7500
fax 81-33-342-7510
www.advantest.co.jp
Advin Systems Inc
Sunnyvale, CA
1-408-243-7000
fax 1-408-736-2503
www.advin.com
Ando Corp
San Jose, CA
1-408-941-0100
fax 1-408-941-0103
www.ando.com
Applied Microsystems Corp
Redmond, WA
1-425-882-2000
fax 1-425-883-3049
www.amc.com
Asset Intertech Inc
Richardson, TX
1-972-437-2800
fax 1-972-437-2826
www.asset-intertech.com
Aval Data Corp
Tokyo, Japan
81-427-32-1000
fax 81-427-32-1022
www.avaldata.com
B&C Microsystems Inc
Sunnyvale, CA
1-408-730-5511
fax 1-408-730-5521
www.bcmicro.com
Beijing Stone Group Ltd
Beijing, China
fax 86-1-257-2748
BP Microsystems Inc
Houston, TX
1-713-688-4600
fax 1-713-688-0920
www.bpmicro.com
Bytek Corp
Boca Raton, FL
1-561-994-3520
fax 1-561-994-3615
www.bytek.com
Capro Inc
Franklin, MA
1-508-520-7500
fax 1-508-520-7555
Ceibo Ltd
Herzelia, Israel
972-9-555387
fax 972-9-553297
www.ceibo.com
Corelis Inc
Cerritos, CA
1-562-926-6727
fax 1-562-404-6196
www.corelis.com
Data I/O Corp
Redmond, WA
1-425-881-6444
fax 1-425-882-1043
www.data-io.com
Dataman Programmers Inc
Orange City, FL
1-904-774-7785
fax 1-904-774-7796
www.dataman.com
Eden Engineering
Grass Valley, CA
1-916-272-2770
fax 1-916-477-1057
Elan Digital Systems Ltd
Fareham, UK
44-1-489-579799
fax 44-1-489-577516
www.elan-digital-systems.co.uk
Electronic Engineering Tools Inc
Sunnyvale, CA
1-408-734-8184
fax 1-408-734-8185
www.eetools.com
Exatron Inc
San Jose, CA
1-408-629-7600
fax 1-408-629-2832
www.exatron.com
GenRad Inc
Concord, MA
1-508-589-7769
fax 1-508-287-2050
www.genrad.com
Goepel Electronic GmbH
Jena, Germany
49-3641-6896-63
fax 49-3641-6896-44
www.goepel.com
Gtek Inc
Bay St Louis, MS
1-601-467-8048
fax 1-601-467-0935
www.gtek.com
Hewlett Packard
Loveland, CO
1-970-679-3584
fax 1-970-679-5122
www.hp.com
Hi-Lo System Research Co Ltd
Taipei, Taiwan
886-02-2764-0215
fax 886-02-2760-1559
www.hilosystems.com.tw
Ice Technology Ltd
South Yorkshire, UK
44-1-226-767404
fax 44-1-226-370434
www.icetech.com
International Microsystems Inc
Milpitas, CA
1-408-942-1001
fax 1-408-942-1051
www.imtest.com
Ismeca Inc
Carlsbad, CA
1-619-931-1153
fax 1-619-931-8713
www.ismeca.com
JTAG Technologies BV
Eindhoven, The Netherlands
31-40-295-08-70
fax 31-40-246-84-71
www.jtag.com
Link Computer Graphics Inc
Fairfield, NJ
1-201-808-8990
fax 1-201-808-8786
Lloyd Research Ltd
Southampton, UK
44-1489-574040
fax 44-1489-885853
www.lloydres.co.uk
Logical Devices Inc
Denver, CO
1-303-722-6868
fax 1-303-733-6869
www.logicaldevices.com
LogiKit Designs
Louisville, CO
1-303-449-2327
MicroPross
Lille, France
33-20-151133
fax 33-20-151166
www.micropross.com
Minato Electronics Inc
Yokohama, Japan
81-45-591-5605
fax 81-45-592-2854
www.minato.co.jp
Needham’s Electronics
Sacramento, CA
1-916-924-8037
fax 1-916-924-8065
www.needhams.com
Okaya Electronics Corp
Yokohama, Japan
81-45-475-1502
fax 81-45-475-1503
Owen Electronic GmbH
Kusel, Germany
49-6381-4202-1
fax 49-6381-4202-85
P&E Microcomputer Systems
Boston, MA
1-617-353-9206
fax 1-617-353-9205
www.pemicro.com
ProLogic Systems
Broomfield, CO
1-303-460-0103
fax 1-303-469-5565
SMS Mikrocomputer
Systeme GmbH
Wangen, Germany
49-7522-97280
fax 49-7522-972850
www.sms-sprint.com
Stag Programmers Ltd
Welwyn Garden City, UK
44-1-707-332148
fax 44-1-707-371503
www.stag.co.uk
Sunrise Electronics Inc
Walnut, CA
1-909-595-7774
fax 1-909-594-7009
www.sunriseelectronics.com
Sunshine Electronics Co Ltd
Taipei, Taiwan
886-2-763-3732
fax 886-2-765-4065
System General Corp
Taipei, Taiwan
886-2-917-3005
fax 886-2-911-1283
www.sg.com.tw
Teradyne Inc
Walnut Creek, CA
1-510-932-6900
fax 1-510-932-7965
www.teradyne.com
Tribal Microsystems Inc
Fremont, CA
1-510-623-8859
fax 1-510-623-9925
www.tribalmicro.com
Unmanned Solutions
Fremont, CA
1-510-656-4300
fax 1-510-656-7480
www.unmanned.com
Wave Technology Co Ltd
Tokyo, Japan
81-35-791-7535
fax 81-35-791-7536
White Mountain DSP Inc
Nashua, NH
1-603-883-2430
fax 1-603-882-2655
www.wmdsp.com
Xeltek
Santa Clara, CA
1-408-524-1932
fax 1-408-524-1936
www.xeltek.com
Talkback
