Blog
Latest
You’ve Routed Out JTAG. Now Make Sure It Actually Works
Last week, we looked at the importance of making the JTAG capability inside your FPGA, processor or SoC accessible on the PCB.
But routing the signals out is only part of the job. Once you've provided access, you also need to make sure the JTAG interface is electrically reliable, and that means thinking about termination.
“But JTAG Isn't Particularly Fast...”
JTAG is not normally thought of as a high-speed interface. So it can be tempting to route TCK, TMS, TDI and TDO around the board and assume they will simply work.
Often they will. But when they don't, the symptoms can be frustratingly intermittent.
Devices aren't detected reliably.
Programming fails occasionally.
Tests work at one clock frequency but not another.
Or the JTAG chain works on one PCB and behaves differently on the next.
These problems can easily be mistaken for software, device or connection faults when the underlying problem is signal integrity.
Pay Particular Attention to TCK
TCK is the clock for the JTAG interface, so maintaining a clean clock signal is particularly important.
Reflections, noise or poor routing can create unwanted transitions that corrupt communication with devices in the chain.
The XJTAG Design & Test Guidelines recommend terminating TCK using a 68 Ω resistor and 100 pF capacitor in series to ground, positioned at the end of the TCK trace furthest from the JTAG connector.
The exact implementation should, of course, be considered alongside the devices, PCB design, signal voltages and target TCK frequency being used.
The important principle is simple:
Don't assume that because JTAG is relatively slow, signal integrity doesn't matter.
Give the Other TAP Signals Defined Behaviour
Termination isn't only about the clock.
TMS and TDI should not be allowed to float, and TDO also deserves attention.
The XJTAG guidelines recommend:
10 kΩ pull-ups on TDI and TMS
10 kΩ pull-ups on the TDO of every device
A 22 Ω series resistor on the TDO of the final device, close to the device pin
If nTRST is used, the guidelines also recommend a pull-down to give it a defined state, and protection against noise that could cause unwanted resets.
These are small components.
But they can make the difference between a JTAG interface that is consistently reliable and one that produces difficult-to-reproduce problems.
Design in the Options
One of the most useful things you can do during schematic design is provide the footprints for the appropriate termination components, even if experience later shows that not every component is required.
A resistor or capacitor footprint costs very little at the design stage.
Trying to add one onto an assembled PCB is rather less convenient.
It also gives engineers options during first-board bring-up.
If the chain is reliable, excellent.
If it isn't, there is somewhere to make controlled adjustments without immediately reaching for wire modifications and a soldering iron.
Layout Still Matters
Termination cannot compensate for every layout problem.
The TAP signals should still be routed sensibly.
In particular, avoid unnecessary interaction with noisy signals, keep skew between important TAP signals under control and consider how the JTAG signals travel through buffers or between different voltage domains.
The objective isn't to turn JTAG routing into a major PCB design exercise.
It is simply to give a useful diagnostic interface the same basic engineering consideration you would give any other digital interface.
Larger and more complex boards, with physically long JTAG runs, many devices in the chain or buffered TAP signals, bring some extra considerations.
We'll look at those next week.
Closing Thought
JTAG access is extremely valuable when you need it.
But an accessible JTAG connector isn't much help if the signals reaching it are unreliable.
The good news is that improving robustness usually doesn't require expensive circuitry.
Often it comes down to sensible routing, defined signal states and a handful of inexpensive termination components.
Design the access in, then make sure the signals are good enough to use it.
Board Design Tip of the Week
JTAG termination is only one of many small design decisions that can significantly improve the testability of a PCB.
The XJTAG Design & Test Guidelines cover termination, JTAG chain design, connector layout, mode selection, watchdogs, multiple chains, FPGA configuration, test coverage and many other practical Design for Test considerations.
Before releasing your next PCB design, take a few minutes to review the guidelines.
Read the full XJTAG Design & Test Guidelines on the XJTAG website.
Could JTAG boundary scan help you test your next design?
Discover how boundary scan can help you improve test coverage, diagnose faults faster and simplify board testing:
Find out more about JTAG boundary scan and how it can help you.
Discover more about your board design with the XJTAG Layout Viewer.
To get started find out how the XJTAG Layout Viewer can help you see on your board:
Download your XJTAG Layout Viewer today, did I mention it's Free!
Your Device Has JTAG. But Can You Actually Use It?
Many engineers select an FPGA, processor or SoC and see JTAG support listed in the device specification.
That sounds reassuring.
The capability is there.
But there is an important catch:
If the PCB design doesn't provide practical access to that JTAG interface, much of the value has already been lost before the first board is built.
And that can mean giving up access to one of the most useful diagnostic capabilities already built into the silicon.
JTAG Is Easy to Overlook During Design
When a new PCB is being developed, there is a lot competing for attention. DDR, PCIe, Ethernet, Clocks, Power, High-speed interfaces and Peripherals. Compared with those, JTAG can look relatively unimportant.
It may be seen simply as something required to program an FPGA or connect a processor debugger. And if programming is going to happen through another mechanism, it can be tempting to think:
“We don't really need JTAG on the finished board.”
That decision may remove considerably more capability than expected.
JTAG Is More Than a Programming Interface
Programming and processor debug are probably the most familiar uses of JTAG.
But, as we've explored throughout Testing Times, many modern semiconductor devices also contain Boundary Scan logic. That can give engineers access to the signals around the device independently of the application software.
With the right board design, that access may help verify PCB connectivity, investigate memories and peripherals, exercise control signals and establish confidence in hardware before the application is even running.
The semiconductor manufacturer has already provided much of this capability inside the device. The PCB designer decides whether it remains accessible.
The Capability Is Already There
This is an important point.
Adding JTAG access doesn't mean adding an entirely new test technology to the design.
For many devices, the hardware is already in the silicon.
The design task is largely about making sensible provision for using it.
That might mean routing the JTAG signals to a connector, test pads or another accessible interface.
On a more complex board, it may mean considering how several devices should be arranged into one or more JTAG chains.
The incremental design effort can be small.
The potential value later can be considerable.
Think Beyond the First Prototype
The obvious time to value JTAG access is during bring-up.
If the processor doesn't boot or the FPGA application isn't ready, JTAG and Boundary Scan may provide another route into the hardware. But its usefulness doesn't necessarily stop once the prototype works.
The same access can potentially support:
Programming and configuration
Development and debug
Structural testing
Manufacturing test
Failure analysis
Repair and rework
Long-term product support
A connector that seems unnecessary during schematic capture may become extremely useful several years later when someone has to diagnose a board that no longer behaves as expected.
Don't Just Put the JTAG Pins on the Schematic
Providing JTAG access requires a little more thought than simply connecting TCK, TMS, TDI and TDO.
During design, it is worth asking:
Where will the interface actually be accessed?
Are all the devices you may want to reach included in a usable chain?
What happens if one device is unpowered or not fitted?
Are suitable pull resistors and termination options provided?
Can relevant mode or configuration pins be placed into the required state?
Would several JTAG chains provide better flexibility on a complex system?
Will JTAG still be accessible on the production board?
These are relatively easy questions to answer before layout. They become much harder to solve once assembled PCBs are sitting on the bench.
What Happens If You Don't Route It Out?
Perhaps nothing.
The board may work perfectly.
The firmware may work first time.
Production may run smoothly.
But if something does go wrong, one useful source of visibility is no longer available.
A processor that won't boot becomes harder to investigate.
An FPGA board with incomplete firmware may provide fewer diagnostic options.
A production failure may need to be approached entirely through functional testing or physical probing. The problem isn't that the product suddenly cannot be tested. It is that an existing diagnostic option has been designed away.
Closing Thought
Seeing “JTAG supported” in the device datasheet isn't enough.
The semiconductor manufacturer has provided the capability.
The PCB designer decides whether anyone will actually be able to use it.
Routing JTAG access may occupy only a very small part of the schematic.
But it can provide useful visibility throughout the life of the product.
And the easiest time to preserve that capability is before the PCB exists.
Board Design Tip of the Week
If you're providing JTAG access, build in a little flexibility rather than designing only for the configuration you expect to use today.
Consider providing footprints for appropriate JTAG pull resistors and termination components, even if some are initially left unpopulated. Where device configuration or mode pins can affect JTAG operation, consider providing resistor options that allow those states to be changed if necessary.
And if a permanent JTAG connector isn't desirable on the production PCB, consider retaining accessible test pads or another practical connection method.
Those small provisions cost very little at the design stage, but they can give engineers considerably more options during bring-up, test and fault diagnosis later.
Could JTAG boundary scan help you test your next design?
Discover how boundary scan can help you improve test coverage, diagnose faults faster and simplify board testing:
Find out more about JTAG boundary scan and how it can help you.
Discover more about your board design with the XJTAG Layout Viewer.
To get started find out how the XJTAG Layout Viewer can help you see on your board:
Download your free XJTAG Layout Viewer today
Testing Times
View all ›
“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
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.
