embedded world 2012 - February 28 to March 1, 2012, 2011

The embedded world Exhibition&Conference is the world´s biggest exhibition of its kind and the meeting-place of the international embedded community. Embedded technologies are in action everywhere - whether in the car, data and telecommunication systems, industrial and consumer electronics, military systems or aerospace.

embedded world 2012 - February 28 to March 1, 2012, 2011


More here: http://www.embedded-world.de

94PK7EDWXU84 

embedded world 2011 - March 1-3, 2011

The embedded world Exhibition&Conference is the world´s biggest exhibition of its kind and the meeting-place of the international embedded community. Embedded technologies are in action everywhere -whether in the car, data and telecommunication systems, industrial and consumer electronics, military systems or aerospace. 730 exhibitors showed the 18.350 visitors the full range of products for embedded technologies in 2010: hardware, software, tools, services and lots more.

March 1-3, 2011



More here: http://www.embedded-world.de

Flash Programming Speed

Introduction

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.

(#bits in chain) * (#scans/write) * (#writes/location) * (#locations)

TCK frequency

Where the parameters are defined as:



Table 1: Flash Programming Parameter Descriptions


Example Calculation

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
improved performance.



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.

Conclusion

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

Adaptive FPGA Programming for SVF and STAPL/JAM

Introduction

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

If the worst case delay far exceeds the typical and minimum delay, then the
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.

Conclusion

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
adaptive programming.

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

HSWAP pin for FPGA

Introduction

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.

Consequences

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.

Example

Consider the four cases below:

Figure 1: Four cases of HSWAP & INIT_B/PROG_B configuration

Note: These cases make the assumption that the HSWAP_EN pin will have an effect
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.

Conclusion

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

Bypass Boundary-Scan Devices

Introduction

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.

Active TDO

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
  pins.

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
  resistor trace


• 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.

Additional Considerations

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.

Conclusion
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
website.

Source: Bypassing Boundary-Scan Devices

JTAG Program CPLDs & FPGAs

Introduction

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

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

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:

1. The FPGA and configuration device are both connected to the scan chain. The
   configuration device may be programmed directly through JTAG.

2. FPGA is on the scan chain, but the configuration device does not have a
   JTAG port. The configuration device must be programmed indirectly through
   the FPGA.

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.

Source: JTAG Programming of CPLDs & FPGAs