With the new Logic support in XJTAG, the connection test can find more errors
XJTAG now keeps an internal representation of each logic gate which you define, and where necessary it combines them so that it can keep track of the state of large logic blocks consisting of multiple individual gates. During the connection test, the logic blocks are manipulated to test their connections.

Logic between JTAG devices

In some scenarios both input and output of the logic gate/combination-of-gates can be read from JTAG. In this situation the connection test has it easy – it can ensure that the logic always ouputs the expected value given the state of the inputs. If one of the pins is shorted to another JTAG-controlled net, we will report that. In the event of an open-circuit error or a pin shorted to power/ground the connection test will detect an error but will probably not be able (currently) to diagnose the exact problem. However, it will say that an “unexpected value” was recorded on a net with logic on it, and output the data it has for the block. More on that below…

Logic only partially accessible from JTAG

We see a lot of logic in the situation where one side is driven from a JTAG-enabled device, and the other side goes to a Test Device.  Perhaps the obvious example is a buffer device going from a processor or FPGA to the address bus on a memory chip. Typically in XJEase projects, the chip select of the memory will be held high during the connection test. If this is the case, then the connection test will be free to drive the address bus. So during the logic part of the connection test it will do just that. In this case it will not pick up shorts between the (buffer-driven) address bus lines during the connection test – these will be picked up as failures by your RAM tests. But the buffers will be driven in the connection test, which will pick up any shorts to other JTAG-readable/writeable nets.

If you don’t wish the connection test to drive your bus via logic, you can set disable values on the test device as  in previous versions of XJTAG. In the example above, this would typically mean that the connection test will then hold the buffer’s *EN pin high, so that it can test the buffer inputs for shorts, without driving anything to the test device.

Once again in this situation, shorts are easy to diagnose – other unexpected errors will often get picked up as an “unexpected value” on a logic net.

Interpreting “unexpected value on logic net” errors

This error simply means that the values read back during the connection test did not match what XJTAG was expecting to read, given its calculations of the state of the logic blocks in the circuit.If you expand the error details on the output screen, generally you will be able to see in one or more of the rows that a pin has different values in its read and write columns (and the row should be highlighted in blue). This difference in value is what caused XJTAG to report the error.

The next step is to determine (possibly meaning you have to look at the state of all the OTHER pins in the block) whether that pin should be outputting or inputting in the state described by that row of the output text.  And here is the important bit: If the pin is an output in the row you’re looking at, the value in the W (write) column is the value that XJTAG expects the logic block to be driving. It’s not the value driven by JTAG. However, all R (read) values in the data are values actually read by JTAG devices.

Now, if the pin in question is an input, then the “write” value is set from a JTAG device, so the fault is most likely to be on that pin’s net – perhaps an open circuit on one of the JTAG pins or links/resistors/connections, perhaps a short to power/ground.

However, if the pin in question is an output, the “write” value on that net is an assumption because that value is assumed to be driven by the logic block – we have no direct observation of it. So, the fault may be on that net (open circuit, short to power/ground…) but it is also possible that the block is not driving the expected value (ie there’s a fault on one of the input nets or the wrong chip is fitted, etc). I’m afraid at this point XJTAG can’t tell you any more, you’ll have to figure it out! Some of the possibilities are easier to check than others, so go for those first.