Embedded Systems: System Implementation— Hardware Test and Debug

Embedded Systems:

System Implementation—Hardware Test and Debug

fig_09_09

System Development--V cycle model: “ideal”

Code / hardware

Question: what are detailed activities at each level? What is plan?

Example: hardware test and debug

Good idea: keep a record of your “best practices” (organization / individual)

Testing: important terms

UUT / DUT—unit or device under test

Resolution—fineness of measure possible. Ex: 3 levels of res. = 3 decimal places

Mean, variance---note this implies REPEATED tests (computer, automation mean there is no excuse for scrimping on repetitions)

RMS—root mean square—how closely does mean value in repeated set of measurements approach “true value”?

Let xi be ith measurement, x= mean, vi = (xi – x)2: RMS = { (v1 + … + vN) / N } ½

Bias—how closely does mean approach true value?

Residual—measured value minus mean

Statistical tolerance level—how much variability was due to test system? Test limits must be outside this

Test limits—upper and lower physical limits of the measurement

Golden unit—unit whose behavior is completely known—can be used as a standard

fig_10_00

Why do we test?Principal reasons

fig_10_01

Example: UUT = and gate

Possible plan:a. Ensure logical functionality—this is an AND gate

b. Verify signal values: VOHmin, VOLmax, VIL min, VILmax

c. Verify dynamic behavior, confirm values of tPDHL, tPDLH, trise, tfall

fig_10_02

Test specification:Step 1:

Step 2: test voltage levels; must decide on error tolerance (e.g., +/- 0.003 VDC)

Step 3: test timing. Must decide on error tolerance (e.g., +/- 0.001 ns)

fig_10_02

Carry out tests

Requires “egoless design”

Do a design review—what if anything needs to change?

Note that prototype and production tests may need to be different

fig_10_02

Terms:

Black box

White box

Gray box: mixture of white and black box example: system includes parts from outside

vendor

There will be a series of tests (“V” strategy):individual componentsmore complex modules……entire system

Hardware / software strategies may be different; UML can provide some measure of commonality int erms of strategy

fig_10_07

Be aware of common problems: example—component works individually; part of system works, but when component added system no longer works:

Why? As current demand increases,there is increasing drop acrossinternal impedance of powersupply, so output voltage isdecreasing.Fix: increase current limit if powersupply not part of design under test or modify design

fig_10_09

Testing combinational logic: path sensitizing

fig_10_11

Example: test C, then B / A

fig_10_14

Example: shared path—or gate

fig_10_17

Example: shared path—and gate– test A, C, then B

fig_10_18

Masking / untestable faultsExample: 1 0 on B can produce transient 1 on D

Can include redundant term to mask this but if bottom AND gate is stuck at 1 we get an untestable potential fault

In practice: maximize what you can test, strategy will be design-specific

fig_10_20

Other cases that will be encountered (examples):

Single variable-multiple paths—path sensitizing

Bridge faults:

fig_10_25

Sequential logic: scan path testing: example

fig_10_28

Adding coded state values

table_10_01

Test steps (first two rows of table):

fig_10_30

Testing terms:

• Alpha—inhouse• Beta—friendly outside users• Verification—”proof” of product—”only as good as test suite”• Validation—verification tests are testing what they claim• Acceptance—customer tests on acceptance & during use• Production—ensure quality, execute quickly—these do not “add value”

Self tests—built-in; note testing is overhead, can introduce its own errors--on startup--on demand--in background