Monday, January 30, 2012
embedded world 2012 - February 28 to March 1, 2012, 2011
More here: http://www.embedded-world.de
Friday, January 21, 2011
March 1-3, 2011
More here: http://www.embedded-world.de
Wednesday, November 17, 2010
Calculating the theoretical Flash programming speed using boundary-scan can
provide a good estimate for the time it will take and allows us to evaluate how
specific factors will affect programming speed. To follow the Tips to Reduce
Flash Programming Time, we’ll look at how to calculate the theoretical
programming speed, and then use the formula to get a better idea of how
different factors may affect programming speed.
Calculating Theoretical Programming Time
For this discussion, let's assume a 16-bit wide S29GL512P Spansion device using
single-word program mode. While this device supports buffered programming with a
32-word buffer, due to the way boundary-scan accesses the Flash, the difference
between single-word and buffered programming times is often minimal. The time it
takes to scan the chain for each data write—which takes up the bulk of the
programming time—remains the same.
The following equation, pulled from our DFT Guidelines, is commonly used for
calculating the theoretical time that it takes to program Flash memory time
using the boundary-scan interface. This equation assumes ideal conditions and
will show the best programming time that can be achieved.
Where the parameters are defined as:
Table 1: Flash Programming Parameter Descriptions
We’ll perform an example calculation using the following conditions:
Table 2: Example Flash Program Speed Calculation Data
The absolute minimum programming time that can be achieved when programming the
entire device is:
370 seconds for each megabyte of data isn’t great—that’s over 6 minutes!
Hopefully there’s something we can do to improve this speed. Let’s see how the
chain length and TCK rate will affect programming speed.
How TCK Rate and Chain Length Affect Programming Speed
Using our equation for calculating program time, we can explore how different
factors affect programming speed. First, vary the TCK rate between 1 MHz and 25
MHz. The data is presented in the graph below.
Figure 1: Flash Program Rate vs. TCK Frequency
Note that utilizing the External Write signal cuts the programming time
approximately in half—utilizing this feature can often provide dramatically
Figure 2: Program vs. Scan Chain Length
Notice that as the scan chain length approaches 650 bits with external write and
300 bits without external write, the boundary-scan programming rate crosses the
programming rate based on typical write time. At this point, the boundary-scan
Flash programming performance will be similar to the programming rate described
by the device data sheet, and boundary-scan will be able to scan faster than the
device can program! To prevent data errors, the poll-for-done option will need
to be utilized to ensure that the previous program operation has completed
before the next scan begins.
Now that we have an intuitive understanding of how chain length and TCK rate
affect programming rate, we can put our knowledge into practice. Programming
rate too slow? See if the TCK rate can be adjusted for Flash programming, and
make sure that the chain is being optimized as much as possible.
Source: Calculate Flash Programming Speed
Tuesday, November 16, 2010
There are two common file standards for programming FPGAs: SVF and STAPL/JAM.
Most vendors can generate either type of file, but which should you choose?
First we should look at a significant difference between the two: STAPL allows
the use of conditional expressions, while SVF does not. In terms of FPGA & CPLD
programming, this means STAPL can provide adaptive programming, while SVF is
limited to delays.
How It Affects Programming Speed
In general, an adaptive programming algorithm will run faster than a
non-adaptive programming algorithm, since it can poll the device status and
determine exactly when programming has been completed and execution may resume.
Non-adaptive programming algorithms must wait a pre-defined time—usually the
device’s worst case program time—before proceeding.
The flow charts below show simplified examples of programming algorithms:
Figure 1: Programming flow charts
adaptive programming will finish first. In some cases, increasing the clock rate
and shortening the delay on the non-adaptive file may allow it to surpass the
adaptive programming speed.
STAPL files can often provide better programming performance than SVF files.
Despite the lack of adaptive programming features in SVF, ScanExpress Runner and
ScanExpress Programmer JTAG implement some techniques in SVF execution to speed
up programming, such as re-scanning on failure and adjusting delay time when a
particular suffix (_xilinx.svf, etc.) is used. Additionally, Lattice has
expanded their SVF files to include non-standard LOOP statements to facilitate
What is your experience with CPLD and FPGA programming? We’re always seeing new
and unusual cases—a new FPGA programs slower than its previous version, STAPL
executes much faster than SVF and in the odd case, SVF executes much faster than
STAPL, etc.—and look for input to help improve our software.
Source: SVF and STAPL/JAM: Adaptive FPGA Programming
Monday, November 15, 2010
The HSWAP pin (also known as HSWAP_EN or PUDC) is commonly found on Xilinx FPGAs.
This pin controls whether the FPGA’s user IO pins will have a pull-up resistor
or float—when HSWAP is LOW, each IO pin will have an internal pull-up resistor.
For our example we’ll look at a particular Spartan-3 case, but this may apply to
other parts as well.
In most cases, the JTAG and configuration control pins will keep their
pull-ups regardless of the state of the HSWAP—but in our experience we’ve seen
evidence of exceptions where the internal pull-up on some FPGAs has an effect on
compliance pins, such as INIT_B or PROG_B. This is an important distinction—in
certain cases INIT_B & PROG_B will have a dependence on HSWAP, so it’s often a
good practice to use external pull-up or pull-down resistors rather than relying
on the internal pull-ups to control these lines.
Consider the four cases below:
Figure 1: Four cases of HSWAP & INIT_B/PROG_B configuration
on PROG_B and INIT_B, but this is not always the case. Consult the device
documentation and errata for details.
In the cases 1 and 2, important compliance and input pins are connected to
strong pull-up/pull-down resistors and the state of HSWAP should have no effect
on the state of these pins. In case 3, INIT_B and PROG_B are floating and may
cause test failures. In case 4, the pull-down on HSWAP ensures that input pins
are pulled up, but does not cover the case where an input or compliance pin may
need to be pulled down.
When designing for boundary-scan test, it pays off to consider the
pre-configuration behavior of FPGAs. To cover all scenarios—though it may not
always be necessary for boundary-scan test—it’s a good idea to include a strong
pull-down on HSWAP during boundary-scan test, but consider the consequences of
pull-ups on IOs before relying on it for pre-configuration cases. Whenever
possible, include pull-ups/pull-downs on configuration and mode pins such as
INIT_B & PROG_B. As always, when in doubt check the device documentation!
Source: FPGA: HSWAP pin
Sunday, November 14, 2010
On occasion and due to incompatibilities, non-compliance, debugging, or various
other factors related to the boundary-scan chain, it may be necessary to
physically bypass a boundary-scan device and remove it from testing. The most
common approach is to add a bypass resistor, but there are important
consequences with this approach. We’ll discuss some considerations that should
be noted when bypassing an installed device to remove it from the scan chain.
When physically bypassing a boundary-scan device, note that the output of the
bypassed device may still be driving unless explicitly disabled. This may result
in two devices driving the input to the next device at the same time. In the
following diagram, if U2 is bypassed with U2_BYPASS_RESISTOR and U2 remains
installed, both U1.TDO and U2.TDO drive U3.TDI.
Figure 1: Common device bypass configuration
Hardware solutions to the active TDO problem
The simplest method of removing the contention between TDO pins is to physically
remove the connection between the conflicting TDO pins. Some options include:
- Remove the series termination resistor. If there is a series termination
resistor as shown below, it may be removed to eliminate the contention on TDO
Figure 2: Series termination resistor on TDO
- Lift the U2.TDO pin
- Remove U2
- Cut the trace connected to U2.TDO, before it connects to the bypass
- Lift the U3.TDI pin, and wire from U1.TDO to the lifted pin
Software solutions to the active TDO problem
In cases where modification to the hardware is undesirable, there are some
additional solutions that may be used. These solutions rely on specific behavior
with respect to the JTAG control signals and, in our experience, not all devices
will perform the same way.
Keep TMS to the device high, and provide at least 5 TCK during testing
Per the IEEE-1149.1 2001 standard section 6.2, the TDO pin should be inactive
(tri-stated) when it is not driving data. This can be guaranteed by forcing U2
into JTAG reset mode by giving it five or more clocks with TMS high. Note that
some devices may not fully conform to the standard. Additionally, in the typical
design, the TMS signal connected to U2 is connected to other devices as well.
If the device uses TRST, hold it active
Note that in a typical design, the TRST connected to U2 is connected to other
devices, too. This option is only viable if the TRST line connected the device
to be bypassed does not affect other boundary-scan devices.
TCK and TMS
Even after the TDO connection has been removed, the bypassed device still
receives TCK and TMS signals. This causes the device to receive all JTAG state
machine commands (on the still connected TMS) and data (on the still connected
TDI). This may place the device in an unknown and possibly undesirable state.
This rarely has an effect on testing or board safety, but it is a possibility.
If TMS on this device is not shared with additional boundary-scan devices, the
solution is to hold TMS high.
Boundary-scan device operation in non-boundary-scan mode
This is not a factor for boundary-scan chain operation, but is a factor in
testing. Now that the device is not in the scan chain, it will operate
“normally”, which may involve driving pins to unknown states. Just like all
other non-boundary-scan devices, for maximum test coverage it is advantageous to
control the device so that the outputs are disabled. If the outputs drive, those
nets cannot be tested due to contention.
While it’s great when things go well, it’s important to be prepared for some
debugging. Whenever possible, it’s a good idea to design the board to facilitate
test and debug—not only do series termination resistors improve signal quality,
but can ease the process of wiring around a problem device. For more tips on
designing for testability, visit the Design Tips and Guidelines section of our
Source: Bypassing Boundary-Scan Devices
Saturday, November 13, 2010
In-system programming (ISP) of CPLDs & FPGAs is a key application of JTAG. Most
modern CPLDs & FPGAs include a JTAG port for programming and boundary-scan
tests, and each vendor provides the software to generate an SVF or STAPL/JAM
file for execution in ScanExpress Runner or Programmer.
In this topic we'll discuss the basic topologies—with respect to JTAG and ISP—of
CPLDs, FPGAs, and Configuration Devices and how each one affects our approach to
ISP. For the purposes of this discussion, we’ll keep the topic vendor
agnostic—the methods for each vendor are remarkably similar.
CPLDs present the simplest case: the lack of external configuration devices
means that you’ll be directly programming the logic device through JTAG.
Creating a JTAG programming file should be a straightforward process when using
the appropriate vendor’s software—usually a matter specifying the part number,
the configuration data, then generating the SVF or STAPL/JAM file.
It should be noted that some CPLDs internal “configure” on power up, loading
data from an internal Flash to an internal SRAM. In this respect, they resemble
FPGAs. Additionally, some modern FPGAs include non-volatile memory as well,
further blurring the lines between FPGAs and CPLDs. Fear not—with respect to
ISP, these CPLDs may be treated the same as traditional CPLDs.
FPGAs present some complications due to their volatile nature. Rarely will it be
necessary to program an FPGA through JTAG—instead, we want to program the
configuration device such that the next time (and any subsequent times) the
board boots, it will load the new configuration data.
FPGA and configuration device connections usually come in one of two flavors:
The FPGA and configuration device are both connected to the scan chain. The
configuration device may be programmed directly through JTAG.
- FPGA is on the scan chain, but the configuration device does not have a
JTAG port. The configuration device must be programmed indirectly through
JTAG Programmable Configuration Device
We’ll first examine the case of a JTAG programmable configuration device, as
shown below. Since we have direct JTAG access to the configuration device, it is
simply a matter of scanning out the correct instructions and data. The vendor’s
generated SVF or STAPL/JAM file will be ideal.
Figure 1: JTAG programmable configuration device
Note that since the FPGA’s connection (other than TDO to TDI) is not necessary
for programming, the FPGA’s boundary-scan register does not need to be scanned
each time. Configuration devices generally have few pins. Taking these two
factors together, we observe that programming through JTAG is very efficient in
this case, and can result in significantly better programming times than the
cases we’ll explore next.
When a JTAG connection is available on the configuration device or CPLD,
programming is about as simple as it can get. In the next post, we’ll discuss
how to deal with FPGAs that utilize non-JTAG configuration devices.