Questions |
| Answers |
 |
|
| On some PLDs, a warning message appears on screen that says there are more fuses in the buffer than in the chip. What should I do? | This is not an error and the programmer will not be prevented from programming these parts. All PLDs have a certain number of functional fuses that can be programmed. Some PLDs contain additional programmable spaces called UES fields, U-fields, or E-fields. These can be left blank or be filled with data such as an identification number or tag. If the file to be programmed into the PLD contains a number of fuses in excess of the functional fuses, these fields will be filled with those additional fuses. They do not affect the functionality of the device in circuit. This message can be prevented from appearing by configuring the BP software for the Experienced Mode instead of Novice Mode. |
|
|
| Why are there different checksum types in the software and what are the differences? | For the vast majority of devices in the BP software, all three checksum types will yield the same checksum. There are some EEPROMS and microcontrollers that have either a reset polarity setting or configuration register that the BP software does not normally include in the checksum calculation. Other programmer manufacturers do include these in the checksum. The Compatibitility checksum type will include these settings in the checksum so customers who also use non-BP equipment can cross-verify their programmed devices. If the Compatibility type is selected the configuration options programmed according to the data in the buffer or the menu settings. The Buffer setting will calculate only the data loaded from a file. Device calculates data up to the highest address of the device selected, to cover the entire address range of the part. |
| |
| What can cause functional test failures? | Test vectors allow a user to power up and operate the device under test (DUT) to simulate operation in the user's circuit. Power is applied, high and low voltages are applied to the DUT's inputs, and its outputs are observed. Each test vector describes what inputs to apply to the device (1,0,F, C, K, U, D), which outputs to examine (H,L,Z), and which pins to ignore (X,N). |
| |
| When a part does not pass test vectors, it can be due to several causes: |
| |
| 1. The vectors do not describe what the part should be doing. Any discrepancies appear as errors. Either the designer did not simulate the vectors to verify that the vectors were written correctly, or the simulator didn't accurately model how the part will truly perform (a very common problem). The simulators that are built into most development systems are unit-delay two-state simulators that don't know the difference between an X (unknown value) and a 0. Furthermore, they assume that all gates have 1 unit of delay, and that all registers have 0 setup and hold time. These oversimplifications can easily lead to a discrepancy between the vectors and the part's behavior. |
| |
| 2. The DUT is incorrectly programmed (either the wrong file or the programming algorithm doesn't configure the part correctly, even though it may verify). If the part has a second source, try programming the alternate part and running vectors. A difference here may point to a programming problem or a difference between the parts (such as a power-up reset state, asynchronous error, or even a design defect in the silicon). If another programmer is available, program a part on each programmer and verify each part on the other programmer. Any verify errors indicate a difference in programming algorithms, and a mistake made by one or more of the programmers. |
| |
| 3. The device is defective (this is what we were looking for in the first place). Devices may pass verify but have logic errors that can only be detected in operation. This is the primary reason to run test vectors on each part programmed. |
| |
| 4. The vectors assume that undriven inputs (X,F,Z,N) will be high or low. Most simulators assume that all pins marked X will be low. The usual case is that these pins are tied to a pull-up resistor (applying a high state to the input, not low). Changing the X value in the Options box will change the vector test results, possibly fixing the problem. Note that changing the X state to 0 causes the programmer to drive all pins marked X to 0 which may cause high currents to flow if the part is driving a H on that pin, so change this switch cautiously. It is better to tell the simulator that X is high in the design software. It is even better to make no assumptions about the X state. |
| |
| 5. Ground bounce induced failures. The part doesn't work correctly in the programmer, even though it may work correctly in circuit. Ground bounce occurs when a clock input changes (C or K) and that causes several outputs to change state (H to L, L to H, Z to L, or Z to H). This transition causes large currents to flow through the Vcc and GND pins very rapidly, producing a voltage on the die's ground terminal that can produce double clocking. Worst case parts are high-speed (5 - 15 ns) CMOS parts with many outputs. Usually, ground bounce induces an extra clock pulse, and can be positively identified when the circuit advances to an extra state (such as a counter that rolls over from all HHHHHHHH to LLLLLLLH instead of LLLLLLLL). |
| |
| 6. The parts were written with a preload vector (B or P) and the preload works differently on the programmer than the compiler expected. Some parts don't support preload so you will get an error message. Sometimes, the device's spec is ambiguous, allowing a different interpretation by the simulator's and programmer's engineers. |
| |
| 7. The part doesn't perform an internal power-up reset or it is reset to a different state than expected. Failures will typically occur on the first vector that has a H,L, or Z. In general, it is not good practice to assume a power-up state either in vectors or in circuit. All asynchronous circuits with feedback must be initialized before the output will be in a known state. If the circuit uses registers, the user should consult the data sheet on the exact part to verify power-up state because sometimes similar parts from different manufacturers reset differently (e.g. AMD 22V10 v. TI 22V10). If the problem persists, it may be because the part is sensitive to slew rate of the Vcc pin. |
| |
| 8. Synchronous circuits with multiple clock pins. The vector that fails or a preceding one will have two C or K pins. The designer probably assumed that both clocks will change simultaneously. The BP-XXXX can apply two clocks with only a few ns skew, so it will probably not cause problems. The CP-1128 will apply multiple clocks successively, starting with pin 1 and working its way up to higher numbered pins. (Some other programmers apply clocks starting with the highest numbered pin, working its way down.) Unless running on the BP-XXXX, it is best to write test vectors with only one clock pin changing at a time to eliminate this problem. It is best to avoid simultaneous clocking when possible. Some devices may fail to clock registers simultaneously even when the pins are tied together due to different internal propagation delays from the pins to the registers' clock inputs. |
| |
| 9. Asynchronous circuits with multiple inputs changing simultaneously. You will see a vector that differs from the previous vector by having more than one pin changing from 1 to 0, 0 to 1, 0 to U, or 1 to D. The JEDEC standard says that no assumptions should be made about the order of pins being applied to DUT. The BP-XXXX can apply all inputs with very little skew to minimize problems of this sort. The CP-1128 applies inputs in succession from low to high numbered pins. Note, however, that any circuit that requires two inputs to change simultaneously is an arbiter, producing a different result when one changes before the other. Therefore, it is better to write two test vectors so the sequence will be known and the output can always be predicted so the programmer can test the DUT, rather than the other way around. Other programmers may apply inputs in a different order, producing different results. |
| |
| 10. Synchronous circuits with falling edge clocks (K, D). The 1128 programmers may have trouble on fast parts due to a slow falling clock edge (20-50ns). The BP-XXXX has a very clean falling clock and should not have any problem here. |
| |
| 11. Adapters or connections placed between the programmer and the DUT. Any connection between the DUT and the programmer adds inductance, capacitance, and resistance. This causes a degradation of signal quality, causing problems especially on fast parts. A cable between the programmer and an autohandler or other contactor is always suspect. The problem will go away if a part is placed directly in the programmer socket. Typically, conditions may improve if ground and Vcc traces are made as wide and short as possible, and a 100PF bypass capacitor is placed at the DUT between Vcc and GND. Also, connect all Vcc pins together and all GND pins together at the DUT. |
| |
| 12. The part is not correctly connected to the programmer. A bent or dirty pin, using the wrong adapter, an adapter with the wrong pinout, a part inserted incorrectly in its socket. Be wary of specially programmed adapters for authohandlers, and poorly labeled adapters for QFP, etc. |
| |
| 13. Asynchronous circuits with race conditions or other timing faults. These faults are difficult to detect because they are subtle and require the engineer to carefully check minimum and maximum propagation delays, setup, and hold times. The circuit will have feedback so it can latch a state. One common symptom is a design that used to pass vectors but fails on new (faster) devices. High-speed devices are more likely to exhibit these problems. The DUT may be sensitive to slew rates and output loading in this case, causing different results on other programmers. |
| |
| 14. The part has a subtle flaw. Some PLDs are pattern sensitive. They may work correctly in 99% of all designs but fail on a particular fuse pattern. This may escape detection for years but suddenly appear, causing mysterious problems. The part may have a sensitivity to the way it is being operated, (e.g. some PLDs have an over sensitive power-up reset circuit that resets registers when too many outputs change state simultaneously). |
| |
| Reasons that the BP-XXXX may fail vectors even though they pass on another programmer: 4, 6, 7, 8, 9, 13. |
| |
| Reasons that the CP/PLD-1128 may fail vectors even though they pass on another programmer: 4, 6, 7, 8, 9, 10, 11, 13. |
| |
| There are times when a file needs to be programmed into a device at an address other than zero. Other times, it is necessary to program only a portion of a particular file into a device. How can these operations be accomplished? | There are two ways to program a file into a device beginning at an address other than zero. Be aware, however, that there are devices that cannot be programmed in this manner. One way to accomplish this is to go to the Buffer/Load menu, select the file to be programmed, and press the <F8> key for more buffer options. Type the first physical address of the chip to be programmed at the Load Address in Buffer line. There is no way to specify an ending address here so the entire chip will be programmed from the designated starting point. To specify an ending address, first load the file as usual and then go to the Device/Options menu. Input the first physical address of the chip to be programmed at the Starting Word of Range line and input the last physical address to be programmed at the Ending Word of Range line.
To program only a portion of a file into a device, select the file to be programmed in Buffer/Load and press the <F8> key for more Buffer options. Type the first address of the file to be programmed at the Lowest Address to Load line. Type the last address to be programmed at the Highest Address to Load line. |
| |