For many years, the XJEase language has had the READABLE and WRITEABLE built-in functions.
Their purpose is to try to work out whether it’s possible to read or write a pin before trying to do so.
If you have no access to the /WP pin on a flash device there’s no point trying to test that you can enable and disable write-protect during tests. And so these functions allow the writing of more general purpose test files, which test the available functionality of a device in different circuit situations rather than giving failures or errors because some device is hardwired to be enabled (for example).
READABLE is relatively easily defined and though the function has been gradually improved over time to take account of logic and external hardware, the method does what you want… all good so far.
WRITEABLE on the other hand is not so clear as to what it means. An open-collector logic gate’s truthtable will show that the device output can either be tri-state or it can output Low only… is that net writeable? We can control it on/off but we can’t write it High (generally relying on a pull resistor instead). The existing method takes the approach that if any value can be driven, WRITEABLE will return TRUE. And this is useful in some situations, but unhelpful in others.
To try to be more helpful, version 3.9 of XJTAG includes a new WRITEABLE method in parallel with the old one.
The old function – WRITEABLE(bus) remains, with functionality unaltered.
The new one takes an additional parameter, which is the value you want to drive.
So the new function is WRITEABLE(bus, value) where value can be an INT or can be the letter I.
It behaves as you would expect –
WRITEABLE(bus, 1) evaluates as TRUE if the bus can be written High.
WRITEABLE(bus, I) evaluates as TRUE if the bus can be tri-stated (from the JTAG/logic/external hardware in the circuit).
So now you can write code like:
Please note – WRITEABLE is evaluated at runtime. The return value can change, depending on the state of logic blocks and whether the JTAG devices/external hardware required to perform a write are enabled in the current Profile, so call the function close to where you want to carry out the SET statement. But because the function is evaluated at runtime you should also try to avoid putting it into performance-sensitive loops where its effect may be measurable.