Boundary scan - High speed interfaces

Question

I was given the task to evaluate existing boundary scan systems. At this moment, we are using a simple solution which allows us to define boundary scan vectors which we can check. This is fine for simple tests and is perfectly integrated into our ICT/Flying Probe/AOI chain. For a new project we require testing of various high speed interfaces. We've been talking with Goepel about our requirements but I am not completely satisfied with the answers from their sales guys. I simply do not trust them (I think this is more my being than not believing the actual sales guys). When talking about more advanced microcontrollers (Cortex-A8/A9 core, ..) they said it was just a question of purchasing the appropriate model for the controller and an appropriate model for the DDR-RAM and it would be able to create the checks automatically. I believe that this holds true for interfaces which do not have the timing requirements and can be considered static (SRAM, various logic ICs, ...). I asked about DDR-RAM (actually it's gonna be DDR2 or DDR3) functionality and they said it should work, but on the other side the demonstrated a "simple" SRAM.

Now for my question: Has anyone of you made an experience with such high speed circuits in conjunction with boundary scan? I just want to avoid telling our customer "Yes, we can do this" when it's just all wrong. Furthermore: Using JTAG, we are definitely not able to achieve the timing requirements of DDR2/DDR3, this alone already seems like a problem to me. How do you do testing of such high speed interfaces (GBit Eth, various SERDES, DDR)? We've been thinking about functional testing, would this be the way to go?

EDIT: Additional Information due to response from Dave Tweed:

I am in fact targeting manufacturing flaws. In no way I expect components to work out of specs or to differ between production runs, this is out of scope. Also, timing is no concern to me. Basically I would just like to rule out any shorts or unconnects which may happen during production (this is especially hard with BGAs which cannot be checked using AOI).

To have DDR-RAM work as expected, I need to stay within timing restrictions. Due to the speed of the JTAG interface (and its nature) it's just not possible to to stay within the specified timing. The main question is now: Is there something I might have left out or forgotten which makes testing (e.g. DDR-RAM) very easy or is this something which can only be done by performing a functional test at a later stage?

I'll give an example: I have a controller which supports Boundary Scan on its DDR lines. BUT the memory itself does NOT. Therefore I have the following options: 1) Do a functional test (a la memtest in Linux); 2) Build a "kind of" memory access sequence via Boundary Scan (which will be out of specs) to test memory access (address and data lines, write some data to RAM, read it back).

Answer 1

You need to distinguish the kinds of flaws you're looking for and pick tests appropriate for those flaws. In particular, there are design flaws, and there are manufacturing flaws.

Design flaws would include things like not meeting criteria such as timing, voltage and current levels. These things are verified in the design lab, before a product moves into production. Design verification testing should include adequate margins for the inevitable tolerances found in the components you're using and your manufacturing processes.

On the other hand, manufacturing flaws include errors in PCB fabrication and assembly, including poor solder joints, missing or incorrect components, etc.

In general, if a product is both designed correctly and manufactured correctly, it will work. Since the design doesn't chage from one unit to the next, you generally only need to detect manufacturing flaws on the production line.

Boundary scan is specifically directed at finding manufacturing flaws, and for this, static or low-speed tests are generally fine. It sounds like you are trying to use boundary scan to verify design parameters (timing), and it really isn't intended to support this.

If you really need to this kind of testing in a production environment, you will almost certainly have to design a custom test that's specific to the product.

If you're concerned about whether the components you're buying meet their specifications, it is almost always better to test them separately, before they're assembled into your product.

For the specific problem of testing, e.g., DDR SDRAM, which has some very tight timing restrictions (both min and max) in order to function at all, but no boundary scan of its own, then a custom functional test is pretty much the only choice.

There are a number of ways to get there. You could use the JTAG debug features of your CPU to load and execute a small test program (or even more than one) during boundary scan. This may in fact be what your vendor is offering, but you'll need to dig deeper to be sure. The other alternative is to integrate such memory tests with the rest of your system functional testing, rather than doing them during boundary scan. This is probably the more common choice.

Answer 2

Dave, Tom

I work for a boundary-scan company in the UK and I must say there is still some confusion regarding the distinction between IEEE std 1149.1 boundary-scan and 'JTAG'. JTAG (Joint Test Action Group) was the committee that formulated the boundary-scan standard which was ratified in 1990 as IEEE 1149.1 BUT the term JTAG has since come to mean other things as well.

Boundary-scan testing implies that you are using the IEEE 1149.1 defined boundary-scan register (a shift register that sits between the core logic of an IC and it's (digital) signal pins) to control pins at a rate that is determined by the length of that register and the frequency of the clock that is used to shift the data. This gives an approximate pattern/vector data rate of shift_length/clock frequency. Thus for a small FPGA with 1000 bits in the BSR clocked at 10 MHz the vector rate would be approx 10 KHz provided it can be sustained by the boundary-scan controller which must then feature 'memory behind the pin'.

To use this technique to fully test every location of a DRAM, SDRAM or DDR ram would be folly as the write times would be prohibitively long. BUT, if you can achieve a memory write (this sometimes involves working out side the timing specs of the device) and read then it is possible to use a compact test vector set in order to detect open and short circuit faults on the connections to the memory. such vector sets include 'walk patterns' and 'binary counts'. Advanced boundary-scan developer tools such as JTAG ProVision which our company provides will import the BSDL models for your IEEE Std 1149.1 parts along with schematic connection data (a netlist) and custom test models for the DRAM, SDRAM DDR memory that are provided by us and that provide the system with the test vector data. ProVision then will automatically generate test for the memory interconnects. Interestingly our tests and test equipment are often combined with both structural testers (in-circuit types) and functional testers.

With regards to other uses for JTAG then many people will be familiar with its use as a configuration port (for CPLDs and FPGAs) and also as an emulation/debug port for microprocessors/controllers. It is the latter use that I think you are also eluding to for test possibilities. Indeed at JTAG Technologies we have created a range of tools that allow the user to enter the processor debug mode and control the embedded peripherals (memory controllers and the like) in order to activate, among other things, memory tests without recourse to the boundary-scan register. This can be most useful if the device is not already equipped with a BSR (sometimes the case in lower-cost ARM core micros) or if the BSR that is installed on the chip is deficient in some way (i.e. not all critical pins have a controlling register bit behind them). The core control tools I am referring to here are called JTAGLive CoreCommander.

If you are open to also evaluating tools from JTAG Technologies then do please feel free to get in touch with me and I can arrange this.

Answer 3

As James mentioned, boundary-scan can be used to perform opens and shorts testing on memory even if the memory itself does not support IEEE-1149.1. The component under boundary-scan control acts as a memory controller and uses the functional behavior of the memory to write and read test patterns for opens and shorts detection.

Most DDR/DDR2/DDR3 components will still operate "well enough" for structural testing as long as the PLL/DLL is disabled. Of course, once you go outside of the published memory timing specifications you cannot be sure that parts from different vendors will behave the same way or, to be frank, be sure that they will work at all. The good news is that most memories we see (I also work at a boundary-scan company) will work with a bit of test tweaking (see additional notes below).

See the point "Can I run Micron’s DDR3 memory at clock speeds slower than 300 MHz?" from Micron's DDR3 FAQ at http://www.micron.com/products/dram/ddr3-sdram. Your effective clock rate must be high enough to meet tREFI requirements, which at 64ms is usually not a problem. In my experience it is rare to see a board design with a boundary-scan chain that cannot be optimized to meet this requirement.

Edit to clarify:

I don't mean to give the impression that all DDR/DDR2/DDR3 memory will function in low clock rate boundary-scan tests. As James points out, newer Hynix SDRAMs generally won't respond at low clock rates, even with the DLL disabled. When in doubt, ask your boundary-scan tool vendor if they have a memory model for your part that has been proven to work. I'll also point out that sometimes you may run into other unforeseen issues with the controlling device--perhaps the boundary-scan register does not include the memory clock signal or the data bus boundary-scan register does not include input capabilities.

When boundary-scan cannot be used for structural testing of the memory interface, many engineers will opt to wait until functional test to verify the control/address/data line interconnections. CPU emulation/debug-based test tools are also a good way to move memory-centric functional tests earlier in the test process, usually immediately after boundary-scan.

Answer 4

Tom et al

One small correction to Bob's message is that the DLL (Delay Lock Loop) within the DDR is the one that is often required to be disabled. As Bob stated Micron parts seem to respond well to testing via the boundary-scan register/interface which is usually a fair bit slower than using the Core via JTAG debug commands. Others though (e.g.Hynix) do not respond so well to testing via boundary-scan and are better suited to testing via the processor core or other JTAG-related.

Do feel free to contact the JTAG Technologies office in Maryland (I assume you are in the USA) if you wish to pitch our tools alongside Bobs - competition is what keeps us sharp eh ?