XJTAG logo
Open search box button Shopping cart button

The Best Time to Find a Testability Problem Is Before the PCB Exists

Image of CEO of XJTAG Simon Payne Simon Payne, CEO, XJTAG |  Subscribe to LinkedIn newsletter

Last week, we looked at some of the design decisions that can significantly increase Boundary Scan test coverage.

Accessible resets.

Controllable enables.

Flexible mode pins.

A well-considered JTAG architecture.

Individually, these can seem like relatively small details.

But there is an important question that comes before all of them:

When should you actually check whether your board is testable?

The answer is simple.

Before the design is finished.

Because once the PCB has been laid out, manufactured and assembled, many of the decisions that determine testability have already been made.

Testability Should Be Reviewed Like Any Other Design Requirement

Engineering teams routinely review a design for things such as:

  • Signal integrity
  • Power integrity
  • Component availability
  • Thermal performance
  • EMC
  • Manufacturability

Testability deserves the same consideration.

Yet it is still common for the question:

“How are we going to test this?”

to be asked only after the design is complete.

At that point, the answer may be constrained by decisions made months earlier.

A much better approach is to make testability part of the design review itself.

Start with the JTAG Chain

The obvious place to begin is the JTAG architecture.

Are all the intended devices present in the chain?

Are TDI, TDO, TMS and TCK connected correctly?

How will the test system connect to the JTAG signals? Are there sufficient ground connections nearby?

Are appropriate pull-up,pull-down and signal termination options available where required?

Can every device in the chain be powered when JTAG access is needed?

Could one unpowered or optional device prevent access to everything else?

And on a more complex PCB, would separating devices into several chains provide greater flexibility?

These are much easier questions to answer while looking at a schematic than while diagnosing a board that will not respond to JTAG.

Then Look Beyond JTAG

The JTAG chain is only the beginning.

The greater opportunity is to look at what the Boundary Scan-enabled devices can reach.

Take an FPGA, processor or SoC and examine the circuitry around it.

What memories are connected?

What peripherals?

What control signals?

What analogue interfaces?

What external connectors?

Each accessible pin potentially provides another route into the hardware.

The objective is not simply to confirm that Boundary Scan is present.

It is to understand how far that access can extend into the rest of the design.

Ask What Can Be Controlled

For every important area of the PCB, ask whether the signals required to operate it can be controlled.

That might include:

  • Chip selects
  • Resets
  • Enables
  • Multiplexer controls
  • Mode-selection pins
  • Power-enable signals

Consider a peripheral that is connected perfectly to a Boundary Scan-enabled FPGA.

If the peripheral’s reset signal is controlled elsewhere and cannot be released without application software, much of that potential test access may be lost.

The connection is there.

The opportunity to test it is there.

But one control signal has effectively closed the door.

Ask What Can Be Observed

Control is only half of the story.

You also need to consider what can be observed.

If you drive a signal, how will you know whether the expected result occurred?

Sometimes another Boundary Scan device provides the observation point.

Sometimes it may be a non-JTAG component whose behaviour can be read back.

An ADC may allow a voltage to be measured.

An Ethernet PHY may provide status information.

A memory can return data that has previously been written.

The more opportunities you have to both control and observe the hardware, the more confidence your tests can provide.

Think About the Board in Its Test State

One useful exercise is to stop thinking about the PCB in normal operation for a moment.

Instead, imagine the board while it is being tested.

Which power rails are active?

Which devices are in reset?

What state are the buffers in?

Are level translators enabled?

Is the watchdog running?

Which boot mode has been selected?

Can the processor or FPGA inadvertently interfere with the test?

The board may need to occupy a very different state during structural testing from the state it uses in normal operation.

Designing so that this state can be achieved deliberately can make testing much simpler.

Look for the Small Changes with the Biggest Impact

One of the reasons to perform this review early is that improvements are often surprisingly inexpensive.

You may discover that adding:

  • A resistor option
  • A zero-ohm link
  • An accessible enable
  • An alternative mode selection
  • A way of disabling a watchdog
  • A different JTAG chain arrangement

could unlock test access to an entire section of the board.

During schematic design, that change might take minutes.

After manufacture, it might require soldering modifications, a PCB re-spin or simply accepting that the area cannot easily be tested.

Bring the Test Engineer into the Conversation

There is another benefit to doing this review early.

It gives the people who will eventually test the product an opportunity to influence the design while changes are still possible.

A test engineer looking at a schematic may ask very different questions from a hardware designer.

How will I isolate this section?

Can I force that device into the state I need?

How will I determine whether this interface is working?

What happens if this device is not fitted?

Can I access this signal without application software?

Those questions can reveal opportunities that are easy to miss when the design is considered purely from a functional perspective.

The Question You Don’t Want to Hear Too Late

There is a familiar moment in many product developments.

After months of design, layout, prototype manufacture and board bring-up, the first working system is finally ready.

The design works.

The software runs.

Everyone is pleased with the result.

Then the design is handed to the contract manufacturer and someone asks:

“How are we going to test these boards?”

It sounds like a simple question, but by this stage many of the answers have already been designed into or out of the PCB.

The test engineer can only work with the access, control and observation that the finished design provides.

A coverage review earlier in the project changes that conversation completely.

Instead of asking how to test a finished product, the team can ask while the schematic is still being developed:

Which areas can we test already?

Where are the gaps?

What additional access would make the test engineer’s job easier?

And what small changes could make those areas accessible?

Those are much easier questions to answer before the first PCB exists.

And the benefits aren’t limited to production testing.

The same additional access can help the development team during initial board bring-up, give manufacturing engineers better diagnostics when individual boards fail and provide service teams with more options later in the product’s life.

Don’t Wait Until the Test Development Phase

If the first time a test engineer sees the board is after the design has been released, their options are already limited.

They can develop tests around the access that exists.

They cannot easily create access that was never designed in.

This is why Design for Test isn’t simply about making the test engineer’s job easier.

It is about giving the organisation more options.

More options during bring-up.

More options during manufacturing.

More options when diagnosing failures.

And more options when products eventually return from the field.

Closing Thought

There will always be parts of a complex PCB that require different test techniques.

The objective isn’t necessarily to achieve 100% Boundary Scan coverage.

The objective is to understand the testability you have, identify opportunities to improve it and make those decisions while the design can still be changed.

A board shouldn’t simply be designed to work.

It should also be designed so that engineers can establish why it works or why it doesn’t.

Because the difference between discovering a testability problem on the schematic and discovering it on an assembled PCB can be enormous.

The cheapest testability problem you’ll ever fix is the one you find before the board is built.

Board Design Tip of the Week

Before your next schematic is released for layout, invite someone responsible for bring-up or production test to review it.

Don’t simply ask:

“Does the JTAG chain look right?”

Ask:

“If this board doesn’t work, what will you need access to in order to find out why?”

And:

“When we hand this design to manufacturing, have we given the test engineer enough control and visibility to build an effective test?”

Those questions can uncover small design changes that make life considerably easier for everyone who has to bring up, test, manufacture or support the product later.

Could boundary scan save time on your next design?

Discover how boundary scan can help you improve test coverage, diagnose faults faster and simplify board testing:

See what you can test with XJTAG.

Discover more about your board design with the Free XJTAG Layout Viewer.

To get started find out how the Free XJTAG Layout Viewer can help you see your board connections:

Download your Free XJTAG Layout Viewer today

Related Reading

complex development board with memories

Find the fault. Save the board.

Start free trial
“It’s Only a Small Board Change…” What Could Possibly Go Wrong? We recently spoke to an engineer about a new revision of an existing PCB. The message was: “It’s only an iterative change.” The implication was understandable: the design changes are small, so the additional test work should also be small. And they may be absolutely right. But it raises an important question: How do you know? A small PCB revision does not automatically mean a small test impact. How Much Test Work Does a Small PCB Revision Really Create? The answer depends less on how many things changed and more on what those changes affect. A reset signal may have moved. A buffer may have been added. A memory device may have been replaced. A previously unused FPGA pin may now be connected. A power rail or enable sequence may have changed. Each change may be small on the schematic, but if an existing test depends on it, the impact can be much greater. Every test makes assumptions about the hardware: which devices are fitted, how signals are connected, what can be controlled and observed, and how devices behave during test. Change one of those assumptions and the existing test may need to change too. What If the Change Is at the Centre of the Board? Now consider replacing the FPGA or processor at the heart of the design. Perhaps the new device performs essentially the same function and most of the surrounding circuitry is unchanged. It may look like a straightforward substitution. But that device may interact with a significant proportion of the board and therefore affect many existing tests. For teams using Boundary Scan, there is another important consideration: Is the BSDL file correct for the exact device and package now fitted? Boundary Scan software relies on the BSDL file to describe the device's pins, Boundary Scan cells, instructions and test capability. So a change that appears on the design change list as: “FPGA changed from A to B” could potentially affect considerably more of the existing test strategy than the change list initially suggests. This is why test effort isn't proportional to the number of changes. It depends on how central those changes are to the tests already developed. Regression Testing Isn't Just for Software Software engineers are familiar with regression testing. A small code change doesn't mean rewriting the entire application, but it does mean understanding what else could have been affected. PCB test deserves the same approach. For every revision, ask: What changed? Which existing tests depend on it? Which assumptions are still valid? Which tests can remain unchanged? Which tests need modifying? Is any additional test coverage required? The objective isn't to assume everything has changed. It's to avoid assuming nothing has. Reuse Should Still Be the Goal Last week, we looked at the value of reusing tests developed during bring-up through production, repair and support. A new board revision shouldn't change that principle. Good reusable tests should make iterative development easier. The aim is to preserve everything that remains valid and concentrate engineering effort only on the tests affected by the new design. Reuse the test — but validate the assumptions behind it. That is far more efficient than designing a complete test strategy again for every PCB revision. Closing Thought “It’s only an iterative change” may be completely true. And the additional test-development work may genuinely be trivial. But that should be the conclusion of an impact review, not the assumption at the start of one. When the next PCB revision is released, ask: What changed? Which of our existing tests depend on those changes? Are the assumptions behind those tests still valid? Then preserve everything that still works. The objective isn't to design a complete test from scratch. It's to know which tests need changing — and why. Board Design Tip of the Week When documenting your next PCB revision, add one more item to the change list: Test impact. For each design change, consider whether it affects: Component functionality or pinout Signal routing or connectivity Resets, enables or mode settings Power rails or sequencing Interfaces and control signals Physical test access Programming or configuration Existing test assumptions And if Boundary Scan forms part of your test strategy, also check whether the change affects the BSDL/device model or JTAG architecture. A short review at this stage can prevent a “small change” from becoming an unexpected test-development problem when the revised boards arrive. Discover more about your board design with the Free XJTAG Layout Viewer. To get started find out how the Free XJTAG Layout Viewer can help you see on your board: Download your Free XJTAG Layout Viewer today
Don’t Throw Away the Tests That Got Your Prototype Working The first prototype arrives and the engineering team begins the process of proving the hardware. Connections are checked. Memories are exercised. Peripherals are tested. Problems are found, understood and fixed. Eventually, the board works. And then something slightly strange can happen. Much of the test capability that helped get it working is never used again. Bring-Up Creates More Than a Working Board During bring-up, engineers build up a significant amount of knowledge about the hardware. They learn how to initialise devices. They discover which signals need to be controlled. They find ways of checking memories and peripherals. They work out how to distinguish between a software problem and a hardware problem. Sometimes this knowledge becomes a formal test. Sometimes it is a small utility written by one engineer. Sometimes it is little more than a sequence of commands, measurements or notes that helped prove a particular part of the board. But whatever form it takes, it has value. The question is: What happens to it once the prototype works? A Test Shouldn't Necessarily Be Used Only Once Some bring-up tests are naturally temporary. But many aren't. If a test helped prove that an interface was correctly connected on the first prototype, there may be no reason why the same test cannot help verify that interface again later. The purpose simply changes. During bring-up, the question might be: “Did we design this correctly?” During production: “Has this particular board been assembled correctly?” During repair: “Which part of this board is no longer behaving correctly?” Different stages of the product lifecycle. But often the same underlying hardware evidence is useful. Turn Engineering Knowledge into Something Repeatable There is an important difference between knowing how to test something and having a test that someone else can run. If an engineer manually performs a sequence of checks during bring-up, that knowledge may disappear when the project moves on. If the same procedure is documented and automated where practical, it becomes reusable. That means the effort invested during development can continue providing value. Instead of every new team starting again, the product carries some of its diagnostic knowledge with it. Boundary Scan Is Particularly Well Suited to Reuse Boundary Scan can be especially useful here because structural tests are based on the hardware and its connectivity rather than depending entirely on the final application software. A test created to verify connections between devices during bring-up can potentially verify those same connections during manufacturing. A test used to exercise a memory, peripheral or other accessible device may remain useful during fault diagnosis. The reason for running the test changes. The physical hardware being checked does not. That gives structural tests the potential to move with the product from development into production and later support. Don't Lose the Tests at Handover When a product moves from development into manufacturing, the handover typically includes things such as: Schematics PCB data BOMs Manufacturing information Firmware Programming files Test specifications It is worth asking whether the diagnostic capability developed during bring-up should be treated in exactly the same way. Which tests proved particularly useful? Which interfaces can be independently verified? Which procedures helped isolate previous faults? Which tools or scripts should be retained? If that knowledge stays with one engineer rather than moving with the product, its value can easily be lost. One Investment, Several Uses The same test capability can potentially support: Prototype bring-up — establishing confidence in the first hardware. Design verification — proving that important areas of the PCB behave as intended. Production — checking whether individual assemblies have been manufactured correctly. Repair and rework — confirming whether a fault has been successfully corrected. Failure analysis — narrowing down where to investigate a returned board. Long-term support — providing engineers with diagnostic capability years after the original development team has moved on. That starts to change the way we think about the cost of developing a test. It isn't necessarily an investment for one stage of the project. It can be an investment in the product's entire lifecycle. Where XJTAG Fits This is one reason an XJTAG project can become more than something used to bring up the first prototype. Once the design information, device models and tests have been developed, that work can potentially be reused as the product moves into manufacturing, repair and support. Rather than rebuilding the test strategy at every stage, the same underlying project can evolve with the hardware. The value isn't simply in running another test. It is in preserving and reusing what the engineering team has already learned. Closing Thought Getting the first prototype working shouldn't necessarily be the point at which your test investment ends. It can be the point at which that investment starts becoming reusable. The tests that help an engineer understand board number one may also help manufacturing verify board number 1,000—or help a service engineer understand a failure years later. A good test isn't just something you run. It's engineering knowledge you can reuse. Board Design Tip of the Week When your next prototype reaches the point where everyone agrees it is working, don't immediately move on. Ask: “Which of the tests and diagnostic procedures we've developed should follow this product into production and support?” Capture them. Document them. Automate them where practical. And consider keeping them under the same configuration control as the rest of the product. The knowledge required to prove the first board works may be just as valuable when a board much later in the product's lifecycle doesn't. Discover more about your board design with the Free XJTAG Layout Viewer. To get started find out how the Free XJTAG Layout Viewer can help you see on your board: Download your Free XJTAG Layout Viewer today
Your Board Already Has a Powerful PCB Test Capability The design has been verified, production starts, the first boards come through test successfully. Then one fails. That is the moment you discover how good your test strategy really is. Finding a fault on a prototype is one thing. The development team knows the design intimately, has access to schematics, debug software and bench equipment, and may be prepared to spend hours investigating an unusual problem. Production is different. When a manufactured board fails, the question isn't simply: “Does it work?” It becomes: “What's wrong with this particular board, and how quickly can we find the fault?” Prototype Debugging and Production Diagnosis Are Different During development, engineers are often investigating the design itself. Is the interface configured correctly? Does the circuit behave as expected? Are the component values right? Does the software initialise the hardware correctly? By the time a product reaches production, the design should already have been proven. The production test is answering a different question: Has this particular assembly been manufactured correctly? That changes the nature of the investigation. A Failure Needs to Narrow the Search Imagine a board fails because an interface is not responding. A basic production test may tell you exactly that: Interface failed. But the engineer still has to work out why. Is there an open connection? A short? A missing component? A badly soldered pin beneath a BGA? An incorrectly fitted device? Or is the problem somewhere else entirely? A useful test strategy should progressively reduce that search area. The closer the test can get from: “Something is wrong.” to: “Start looking here.” the more useful it becomes. This Is Where Structural Information Helps Functional testing is extremely valuable in production because it proves that the completed product behaves as expected. But when a functional test fails, the symptom can sometimes cover a large area of hardware. Structural testing provides a different layer of evidence. Boundary Scan can often verify inaccessible PCB connections independently of the application software and relate unexpected results back to the nets and devices involved. That can help answer an important question: Is this an assembly problem, and if so, where should we investigate first? Boundary Scan does not replace functional production testing. It complements it by providing another way to understand the hardware beneath the symptom. One Failed Board May Be Manageable If one board fails, spending an hour investigating it may not seem significant. But what happens when ten fail? Or fifty? Or when the same type of fault appears repeatedly? At that point, diagnostic time starts affecting manufacturing throughput. That is why the economics of production test aren't determined only by how quickly passing boards can be tested. They are also influenced by how efficiently failed boards can be diagnosed. A fast PASS/FAIL test followed by hours of fault finding may not be as efficient as it first appears. Don't Wait for the First Failure to Think About Diagnosis There is an important Design for Test lesson here. When the first failed production board arrives, the PCB design is already complete. If a reset cannot be controlled, an enable is inaccessible or an important interface cannot be exercised independently, the test engineer has to work within those constraints. The opportunity to make a simple schematic change may have disappeared months earlier. This is why testability shouldn't only ask: “Can we detect a failure?” It should also ask: “If it fails, what information will we have?” That question is much easier to answer while the schematic is still open. Carry What You Learned During Bring-Up into Production There is another opportunity that is often overlooked. Structural tests developed during prototype bring-up don't necessarily need to be discarded once the design is working. Tests that proved connectivity, memories, peripherals or interfaces during development may also provide useful coverage in production. That means the effort invested in understanding the first prototypes can potentially become part of the manufacturing test strategy. Instead of starting again, knowledge moves forward with the product. Closing Thought A string of passing boards doesn't really test your diagnostic strategy. The first failure does. That is when you discover whether your test simply detects a problem or actually helps the engineer understand it. And the difference between knowing: “This board failed.” and: “This is where you should start looking.” can determine whether the problem is diagnosed in minutes, investigated for hours or placed on a growing bone pile marked: Investigate later. The best production tests don't just catch faults. They help engineers understand them. Board Design Tip of the Week Before releasing your next design, choose three realistic manufacturing faults. For example: An open connection beneath a BGA A short between two adjacent signals An incorrectly fitted peripheral Then ask: “If this happened on the production line, what would our test actually tell us?” If the answer is simply: FAIL there may still be work to do. Discover more about your board design with the Free XJTAG Layout Viewer. To get started find out how the Free XJTAG Layout Viewer can help you see on your board: Download your Free XJTAG Layout Viewer today