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.

The core of the code is a loop that simply calls the WAITKEY function to read a character of input at a time, until a carriage return is read. As each character is read it is appended to a string that will be returned and also printed to the screen.

STRING text;
INT key;
DO
    key := WAITKEY();
WHILE key := ASC("\n") && key != ASC("\r");
    // ignore any control characters (ASCII value less than 0x20)
    IF key >= 0x20 THEN
        PRINT(CHAR(key));
        text := text + CHAR(key);
    END;
END;

This works reasonably well until the user makes a mistake and wants to backspace. Handling backspace requires us to print the backspace character and remove the last character from the string that we’re building. We can also check the current length of the input string and not allow the user to backspace beyond its start.

INPUTBOX(STRING prompt, STRING title, STRING default)(STRING input)
    STRING text := default;
    INT key;
    INT width;

    ALERT();

    IF title != "" THEN
        PRINT(title, "\n");
    END;
    PRINT(prompt);

    DO
        key := WAITKEY();
    WHILE key := ASC("\n") && key != ASC("\r");
        IF key = ASC("\b") THEN
            width := WIDTHOF(text);
            IF width > 0 THEN
                PRINT("\b");
                IF width = 1 THEN
                    text := "";
                ELSE
                    text := text[width-2..0];
                END;
            END;
        ELSIF key >= 0x20 THEN
            // ignore any control characters (ASCII value less than 0x20)
            PRINT(CHAR(key));
            text := text + CHAR(key);
        END;
    END;

    PRINT("\n");
    input := text;
END;

GetInput()()
    STRING input;
    input := INPUTBOX("Please enter some input and press Enter:", "Input", "");
    PRINT("\nGot \"", input, "\"\n");
END;

The full function appears below, plus an example of its use. It is named INPUTBOX and has the same signature as the upcoming XJEase built-in function, which means once the new version of XJTAG arrives, this function can be deleted and the code will then continue to work. The 3 arguments are the prompt to display, a title and a string that is presented as the default (can be left as an empty string). Note that the example below simply prints the title out, whereas the real INPUTBOX will create a proper dialog box.Note also the use of the ALERT function. If you have more than one XJLink attached in XJRunner, then the output from each is displayed in its own tab; the ALERT function causes the application to draw attention to any tab that requires attention. In XJDeveloper or in XJRunner with just one XJLink attached, then the function has no effect.

The SET statement can perform both reading and writing of the pins. So:

SET nCE := 1;          //set the nCE pin to a logic 1
SET DATA := 0xAA;      //set the data bus ( DATA ) to the HEX value 0xAA
SET readvalue := DATA; //read the current value on the DATA bus into readvalue

Any signals which aren’t changed on a SET statement remain in the same state. All SET statements take one JTAG scan except if you are changing the direction of a bus from writing to reading:

SET DATA := 0xAA;      //write takes one JTAG scan 
SET readValue := DATA; //read statement after write takes 2 scans 

You can set a bus to be tristate by doing the following:

SET DATA := I; // sets the data bus into read mode

Optimisations

Once a pin is in a state, setting it again is optimised away. So the following code only takes one JTAG scan:

SET nCS :=0;
SET nCS :=0;
SET nCS :=0;

You can combine accesses so that they all happen on the same JTAG scan by using a comma:

SET nCS := 0, nOE := 0, DATA :=I ;        // All happen on the same JTAG scan
SET nCS := 1, nOE := 1, readvalue := DATA;// All happen on the same JTAG scan

In the example above all the access happen on the same JTAG scan. There is however a difference in timing between the reading and writing. “readvalue := DATA;” happens first during the "Capture" State in the JTAG state machine. The actual outputting of nCS happens later. This delay is the delay of scanning the JTAG chain and moving the JTAG state machine to the "Update" state. This on a device with 300 bits in the scan chain and running at 10MHz will be about 30μs.

The Write-to-Write time

Providing the JTAG chain speed isn’t restricted due to lack of data then the write-to-write time is just over 30μs (it is a slightly longer path through the JTAG state machine):

SET nCS := 1; //t =0 
SET nOE := 1; //t = 31us 

The Write-to-Read time

The time between writing to one pin and reading another on the following scan is much faster as the time between the "Update" (write) and the "Capture" (Read) is only a few JTAG cycles around the state machine (about 0.3μs in our example). But as explained earlier – if the pin/bus being read is the one which was just written it will take a further complete scan to read the data.

So for SRAM based devices you could have the following read cycle:

SET nWE := 1; // not always needed
SET DATA := I;
SET ADDRESS := Address_To_Read_From;
SET nCS := 0;
SET nOE := 0;
SET Readvalue := DATA;
SET nOE := 1;
SET nCS := 1;
SET nWE := 1;  // not always needed

The above takes a large number of JTAG scans. You can make it much quicker by combining SET statements:

SET nWE := 1;
SET DATA := I, ADDRESS := Address_To_Read_From, nCS := 0, nOE := 0;
SET Readvalue := DATA, nOE := 1 , nCS := 1, nWE :=1; 

If you can be sure nWE is logic 1 before starting then the first SET can be removed.