Blog
Latest
“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
Testing Times
View all ›
PASS or FAIL Isn’t Enough
A production test has one obvious job, tell us whether the board passes or fails.
But sooner or later, a board will fail and at that point, FAIL is only the beginning of the engineering problem. The more useful question becomes:
Why did it fail?
The First Failed Board Changes the Question
When every board is passing, the test strategy can look excellent.
Then the first failure arrives, perhaps DDR isn't responding, an Ethernet interface doesn't come up, a peripheral can't be detected or the product simply refuses to boot.
A functional test may tell you which part of the system isn't behaving correctly.
But the test engineer still has to determine whether the cause is:
A component fault
An open connection
A short
An incorrectly fitted device
A configuration problem
Or something else entirely
Suddenly the quality of the diagnostic information matters just as much as the test itself.
Think About Diagnosis While You're Designing the Test
There is an important difference between:
“This interface failed.”
and:
“These connections associated with this interface are not behaving as expected.”
The second gives the engineer somewhere to start. That is why a good test strategy shouldn't only consider whether a fault can be detected.
It should also ask:
What information will we get when it happens?
The answer can have a major effect on repair time, manufacturing throughput and ultimately the cost of dealing with failures.
Structural Testing Adds Another Layer of Evidence
This is one area where Boundary Scan can be particularly useful. Because Boundary Scan software understands the PCB connectivity, a structural test can often relate an unexpected result back to the signals and devices involved.
Instead of knowing only that a memory test failed, for example, engineers may be able to investigate the individual connections making up that interface.
That doesn't mean Boundary Scan identifies every fault automatically.
But it can significantly reduce the area that needs investigating.
And reducing uncertainty is often the fastest way to find the real problem.
A Test Should Help the Person Who Comes Next
It is easy to develop tests from the perspective of the person creating them. But think about the engineer who receives the failed board six months later.
They may not have designed the hardware.
They may not know its history.
They may be supporting hundreds of products rather than one prototype.
For them, FAIL isn't much of a diagnostic.
A useful test should provide enough information to help answer:
Where should I look next?
Closing Thought
Detecting a faulty board is important. Understanding why it failed is considerably more valuable.
So when you're thinking about test coverage, don't stop at:
“Can we test this?”
Ask one more question:
“If it fails, what will the test tell us?”
That question can make the difference between quickly isolating a manufacturing fault and putting another board onto the growing pile marked investigate later.
Board Design Tip of the Week
When reviewing your test strategy, look at some realistic failure scenarios.
Imagine an open circuit beneath a BGA, a short between two adjacent signals or a peripheral that hasn't been assembled correctly.
Then ask: Would our test merely tell us that the board failed or would it help an engineer work out where to look?
Good diagnostics should be considered alongside good test coverage.
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 Development Board Cost Thousands. What Happens When It Stops Working?
FPGA and SoC development platforms are powerful, complex and sometimes extremely expensive. Perhaps they deserve a test strategy of their own.
Development boards have changed dramatically.
What was once a relatively simple PCB containing an FPGA, some memory and a few connectors can now be an extremely sophisticated system in its own right.
Today's FPGA and SoC development platforms may contain:
High-end FPGAs or adaptive SoCs
Multiple memory technologies
High-speed serial interfaces
Ethernet PHYs
PCIe
Power-management circuitry
ADCs and DACs
Configuration memories
Expansion connectors
Multiple voltage and power domains
They are invaluable engineering tools, they can also represent a significant investment.
So what happens when one suddenly stops behaving as expected?
The First Question Is Usually: What Changed?
Perhaps the board worked perfectly yesterday.
Now the FPGA won't configure.
The processor won't boot.
DDR initialisation fails.
An Ethernet interface has disappeared.
Or a mezzanine card that previously worked is no longer being detected.
The natural reaction is to look at whatever changed most recently.
Was it the FPGA image?
The software?
A configuration setting?
A cable?
The power supply?
The expansion card?
That is entirely reasonable.
But eventually another possibility has to be considered:
What if the development board itself has developed a hardware problem?
Development Boards Have Difficult Lives
Development platforms don't always live in gentle environments. They sit on engineers' benches, cables are connected and disconnected repeatedly. expansion cards are changed, Jumpers and switches are moved, and power is cycled constantly.
Signals may be brought onto the board from external circuitry that is itself still under development. And unlike the final product, the development platform may be used in configurations its designers could never reasonably have anticipated.
Most of the time, these boards tolerate this remarkably well.
But they are still electronic assemblies.
Components can fail.
Connectors can be damaged.
Solder joints can develop problems.
Power circuitry can be affected.
And accidental electrical overstress is always possible when prototype hardware is involved.
The Problem Is Establishing What You Know
When something stops working, the challenge isn't necessarily repairing it immediately.
The first challenge is establishing where the problem actually is.
Suppose an FPGA no longer communicates with a peripheral.
Is the FPGA configuration wrong?
Has the peripheral failed?
Is there a problem with the PCB connection between them?
Is a power rail missing?
Has a clock disappeared?
Or is the application software simply no longer configuring the interface correctly?
The symptom alone rarely tells you.
And that can turn an apparently simple problem into hours—or days—of investigation.
Vendor Support Is Valuable, but Independent Evidence Is Valuable Too
Development-board manufacturers generally provide extensive documentation, reference designs, software examples and technical support.
All of that is extremely useful.
But there is still value in being able to independently establish confidence in the hardware sitting on your own bench.
Not because vendor support has failed.
And not because you should be expected to repair every problem yourself.
But because additional evidence can dramatically improve the engineering conversation.
Instead of saying:
“The board doesn't seem to work anymore.”
you may be able to establish:
“The JTAG chain is intact, these connections test correctly, this device responds as expected, but this area of the board does not.”
That is a very different starting point.
A Development Board Is Still a PCB
It is easy to think of a development platform as a complete product.
Plug it in.
Download the tools.
Load the design.
Start developing.
But electrically, it is still a PCB full of interconnected semiconductor devices.
The FPGA or SoC at the centre of the board may provide access to a surprisingly large amount of surrounding circuitry.
That means the development board itself may already contain much of the hardware required to perform useful structural tests.
Boundary Scan Gives You Another View of the Hardware
A normal development workflow tends to look at the board through the application.
Configure the FPGA.
Boot the processor.
Run software.
Exercise the interface.
That works extremely well—until the application itself cannot run.
Boundary Scan provides a different route.
Because its test logic operates independently of the application, it may still be possible to access the hardware even when the FPGA design, processor software or operating system is unavailable.
Depending on the board and the devices fitted, Boundary Scan may help engineers investigate areas such as:
JTAG chain integrity
Connections between Boundary Scan devices
Memories
Peripheral interfaces
GPIO
Control signals
Configuration circuitry
Other accessible non-JTAG components
It doesn't replace the vendor's diagnostics or your normal development tools.
It provides another source of evidence.
Proving What Still Works
This is perhaps the most useful mindset.
When an expensive development board develops an unexplained problem, don't begin by assuming that the entire board is faulty.
Start by asking: What can I prove still works?
Can you communicate with the devices in the JTAG chain?
Can you verify connections between major devices?
Can you exercise an attached memory?
Can you control or observe the signals connected to a peripheral?
Can you establish that a particular section of the PCB is behaving correctly?
Every positive result eliminates another possible cause.
And as we've discussed throughout Testing Times, reducing the list of possibilities is often the fastest route to understanding the real problem.
The Same Principle Applies to Your Own Prototype
There is a wider lesson here.
If independent structural testing is useful for an expensive commercial development platform, it is probably worth considering for the hardware your own engineering team is developing as well.
A development board has usually been designed by an experienced engineering team with extensive debug access.
Your first prototype may not have that luxury. Thinking about test access during your own design process can provide the same advantage:
the ability to establish confidence in the hardware independently of the application running on it. That becomes especially valuable when the software and hardware are being developed at the same time.
Perhaps Development Boards Deserve a Test Strategy Too
We spend a lot of time thinking about the products we design.
Far less attention is given to the development equipment we depend on to create them.
Yet a high-end FPGA or SoC development board may be one of the most important pieces of hardware on an engineer's bench.
If losing access to it can stop development, having a way to establish whether the board itself is healthy starts to make sense.
Not necessarily as a full manufacturing test.
Not as a replacement for vendor support.
But as a practical engineering diagnostic.
Where Boundary Scan Testing Fits
This is one of the areas where Boundary Scan software such as XJTAG can be useful.
By combining the Boundary Scan capability already built into the devices with information about how the development board is connected, XJTAG can provide an independent way of exercising and checking accessible parts of the hardware.
For supported development platforms, that can turn the JTAG connection already present on the board into something more than a programming and debugging interface.
It becomes another route to understanding the PCB itself.
And importantly, it complements the manufacturer's existing tools rather than replacing them.
Closing Thought
Modern development boards are extraordinarily capable pieces of engineering.
They are also becoming increasingly complex and increasingly valuable.
When one stops behaving as expected, the most useful question isn't immediately:
“Is the board broken?”
It is: “What can I independently prove about the hardware?”
Vendor diagnostics, application software and conventional bench equipment all have an important role to play.
Boundary Scan can add another layer of evidence.
And when a development project is waiting for an answer, that additional visibility can be extremely valuable. Perhaps the expensive development board on your bench deserves a test strategy of its own.
Board Design Tip of the Week
The next time you select a development board, don't look only at the FPGA, processor, memory capacity and interfaces.
Also look at the diagnostic access the platform provides.
Is the JTAG chain readily accessible?
Are schematics available?
Can important devices and interfaces be reached independently of the application?
Those details may seem relatively unimportant when everything is working.
They become considerably more valuable the day it isn't.
Want to See What's Possible on Your Development Board?
XJTAG supports a growing range of FPGA and SoC development and evaluation boards, helping engineers use the Boundary Scan capability already built into the hardware to gain greater visibility into the PCB.
If you're using a supported platform, you can explore the available boards and see how XJTAG can help you test and diagnose the hardware here:
Explore XJTAG supported development and evaluation boards: https://www.xjtag.com/development-evaluation-boards/
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
Design Verification to Production Test Why Early Test Input Matters
There is an important transition in almost every hardware development project.
The design has progressed through schematic capture, PCB layout, prototype manufacture, bring-up and verification.
The engineering team has worked to establish that the design behaves correctly across the operating conditions, component tolerances and variations the product is expected to encounter.
As the product moves towards production, another engineering challenge becomes increasingly important:
How are we going to test every board we manufacture?
That is where the requirements of production test begin to look rather different from those of design verification.
A Proven Design Isn't the Same as a Production Test
The development team and production test team are ultimately working towards the same objective: confidence in the product.
But they approach that objective from different perspectives.
During development, engineers need to demonstrate that the design itself is correct.
They investigate interfaces, validate performance, exercise operating conditions and establish that the product meets its requirements.
Production test has a different task.
Once the design moves into manufacture, engineers need a repeatable way of determining whether each individual PCB has been assembled correctly.
And when one hasn't, they need enough information to determine where the problem is likely to be.
Both are important, but they answer different questions.
The Design Influences the Test Long Before Production Begins
By the time a design approaches production, many of the decisions that influence how it can be tested have already been made.
The PCB determines which signals are physically accessible.
The circuitry determines which devices can be controlled and observed.
The JTAG architecture determines how Boundary Scan devices can be accessed.
Reset, enable and mode circuitry affects which parts of the board can be exercised independently.
Power architecture, buffers, multiplexers and connectors can all influence the eventual production test strategy.
Test engineers may already have had some involvement during development—and in many organisations they will.
The important point is that the earlier test requirements are considered, the more opportunity there is to make useful changes.
As the design progresses towards release, those options naturally become more constrained.
Give the Test Engineer More Options
Consider a peripheral connected to a Boundary Scan-enabled FPGA.
The FPGA may provide excellent access to the interface.
But suppose the peripheral's reset can only be released once the processor is running application software.
Or perhaps a buffer sits between the FPGA and the peripheral, but its enable cannot be controlled independently during test.
The potential test path exists, but making practical use of it has become more difficult.
Identified during schematic development, the answer might be as simple as a resistor option, an alternative control path or access to an additional signal.
Identified after PCB layout or during an early production build—the available solutions are likely to be more limited.
This is why relatively small design decisions can have a disproportionate effect on testability later.
Production Testing Asks Different Questions
During development, one of the central questions is:
“Does this design operate correctly across the conditions it needs to support?”
Production test asks:
“Has this particular board been manufactured correctly?”
And if it hasn't:
“Can we identify the likely fault quickly enough to diagnose, repair or reject it?”
In a production environment, those questions need to be answered repeatedly and efficiently.
A diagnostic process that is perfectly reasonable when investigating an occasional prototype may become impractical if it has to be repeated across every failed production board.
The test therefore needs to be repeatable.
The results need to be meaningful.
And ideally, a failure should provide useful information about where further investigation should begin.
Boundary Scan Can Help Bridge the Gap
This is one of the reasons Boundary Scan can be particularly valuable as a product moves from development towards manufacturing.
The structural tests created during prototype bring-up and verification don't necessarily have to disappear once development progresses.
They can potentially become part of the production test strategy.
Tests that verify PCB connectivity during development can continue checking those same connections on manufactured boards.
Tests developed for memories, peripherals and interfaces may also be reusable.
That creates an opportunity to carry both engineering knowledge and test capability forward rather than starting again when the product reaches production.
Develop Once, Reuse Many Times
This can significantly increase the value of the original test development effort.
A Boundary Scan test might initially be created to provide confidence during prototype bring-up or design verification.
That same test capability can potentially support:
Prototype bring-up
Design verification
Production test
Repair and rework
Failure analysis
Service and support
The test doesn't have to belong to one phase of the product lifecycle.
It can become an engineering asset that continues to provide value as the product moves from development into manufacture and beyond.
Test Engineers Need More Than a Working Design
As a product approaches production, the test team benefits from understanding not only how the product works, but how it was designed to be tested.
Which areas can Boundary Scan verify?
Which devices can be controlled independently?
Which tests proved particularly useful during development?
Which areas require application software?
Where are the known gaps in coverage?
What diagnostic information will be available when a test fails?
Answering those questions earlier makes the transition into production test much easier.
It also gives the test engineer an opportunity to identify areas where a relatively small design change could provide substantially greater test access.
Bring Development and Test Together Earlier
This doesn't mean every hardware designer needs to become a production test engineer.
Nor does it mean the complete manufacturing test needs to exist before the first prototype is built.
It means giving the people responsible for production test an opportunity to contribute while their input can still influence the design.
The hardware engineer understands how the circuit is intended to operate and what must be demonstrated during design verification.
The test engineer brings a different perspective:
How can this be tested repeatedly?
How can this section be isolated?
Can this device be put into the required state without relying on the complete application?
If a board fails, what information will the test provide?
Bringing those perspectives together can produce a product that is not only well designed, but considerably easier to manufacture and support.
Avoid Making the Test Engineer Reverse-Engineer the Test Strategy
When testability has been considered during development, the production test engineer starts with a much stronger foundation.
They don't have to discover late in the process whether an enable can be overridden.
They don't have to find an unexpected way of disabling a watchdog.
They don't have to discover that one inaccessible control signal prevents an otherwise testable interface from being exercised.
Instead, many of those questions have already been considered as part of the design.
The test engineer can then concentrate on developing the most effective production test rather than finding ways around avoidable hardware constraints.
A Better Handover
Moving a product towards manufacturing shouldn't be a moment where one team simply finishes and another begins.
Ideally, knowledge moves with the product.
The design team understands what has been verified and where the difficult areas are.
The test team understands what must be proved repeatedly on each manufactured assembly.
Boundary Scan provides one way of carrying structural test capability between those stages.
And when test requirements have influenced the design early enough, the production test engineer has substantially more options available.
Closing Thought
Design verification and production test perform different jobs.
One establishes confidence that the design is correct.
The other helps establish that each manufactured board has been assembled correctly.
Thinking about both while the PCB can still be changed makes that transition considerably easier.
The objective isn't to ask the test team to design the product.
It is to make sure that, when they need to develop an effective production test, the design hasn't unnecessarily restricted the tools available to them.
Board Design Tip of the Week
Before your next design is released for layout, involve someone who understands how the product will eventually be tested in production.
Don't ask them to develop the complete production test.
Ask: “Is there anything we could change now that would give you better control, observation or diagnostic access later?”
It might be a resistor option, an accessible enable, a controllable reset, a way of disabling a watchdog or a small change to the JTAG architecture.
These changes may have little impact on the product's normal operation.
But they can give the test engineer considerably more freedom when each manufactured board needs to be tested quickly, consistently and with useful diagnostics.
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
Find out what else you could test on your board.
See at a glance where XJTAG could extend your existing test coverage and uncover faults that are difficult to reach with traditional testing methods.
