We see a lot of logic components used on boards that come through our office. Most often we see buffers, bus transceivers and devices of that nature, but also plenty of the usual discrete logic chips – simple gates, decoders, encoders etc.

We decided a long time ago that XJTAG should support “simple” logic devices in such a way that the logic is handled transparently when it comes to XJEase code, thus allowing the Test Device code to remain device-centric. We also decided that the built-in connection test had to support logic devices to the same extent. The work was on-going behind the scenes here at XJTAG for some time, and is a major part of the version 2.4 release.

So, in previous versions of XJEase if you had a memory chip with a data bus which was accessed through a buffer, you had to modify the chip’s device file so that the data bus pins were actually the buffer inputs rather than the chip’s own data pins. This will still work… but it’s no longer necessary – XJTAG will now realise (for example) that if you want to write to a particular pin on that data bus then it means setting the appropriate buffer direction, enable and input pins, and that if you later want to read the pin, XJTAG will stop driving the buffer, change the buffer’s direction and then read the value through from the memory.

Limitations

No Logic with State

XJTAG  version 2.4 does not support logic with state.  This does not only apply to individual gates – we also do not support the situation where blocks are combined to store state, for example constructing a flip-flop from NAND gates. XJTAG will attempt to spot such situations and object to them… but if you manage to be more cunning than our compile-time state detection algorithms it still won’t work correctly at runtime!

Wind-up of logic blocks

When you make SET statements in XJEase you are asking XJTAG to put the circuit in a state and leave it that way until told to do otherwise.  And with logic that gets complicated. For example, imagine a logic device with 2 outputs and a truth table set up such that they can’t both output a 1 (ie valid output states are 00, 01, 10 only). The user makes a SET statement that sets the first one high. Fine so far. But then later the user SETs the 2nd one high. Now we have a dilemma. Should we refuse? Or should we set the first one back low in order to comply with the 2nd request? The problem would be worse if there were 3 outputs and any two could be high – which one should we set back low in order to set the 3rd one high?

Because we can’t know what the user actually wants, we will stop and show an error if this situation arises. In general that’s easy for you to get around because having SET a value on a pin, you can always SET a different value on it – so you can SET the first pin back low once you’re done with it (or as you SET the 2nd one high)

If the situation gets far too complicated for you to work out what is causing the conflict, which may mean the SET causing the problem was made in some other test a long way from where you are, then we do have a (slightly drastic) get-out, which is to make a  SAFE; statement in your code. This resets all pins (and logic blocks) in the circuit to their default state.

We hope that the new logic features in XJTAG are useful to you – please give us feedback if you feel you have a situation that we should support and don’t, or if you have further suggestions as to how we can improve the products.