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:

Flash Programming Parameter Descriptions
Table 1: Flash Programming Parameter Descriptions

Example Calculation
We’ll perform an example calculation using the following conditions:

Flash Program Speed Calculation Data
Table 2: Example Flash Program Speed Calculation Data

The absolute minimum programming time that can be achieved when programming the
entire device is:

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.

Flash Program Rate vs. TCK Frequency
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.

Program vs. Scan Chain Length
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.

Published On: September 24, 2010Categories: Corelis Boundary-Scan Blog, JTAG Boundary-Scan

Share This Story, Choose Your Platform!