Parallel IO via 5 pin Tap

Discuss the generic proposals for SJTAG
Post Reply
User avatar
Tim Pender
SJTAG Member
Posts: 19
Joined: Wed Mar 12, 2008 9:21 pm
Location: Eastman Kodak, Rochester, NY

Parallel IO via 5 pin Tap

Post by Tim Pender » Mon Aug 11, 2008 12:17 pm

Using the Standard 5 pin Tap signals to interface to the system will require a method to provice parallel IO.
For instance SVF had a Parallel IO Contruct in the language however implementation details would be left to the user.
We may want to consider an optional DIO register that would allow a seperate but easy to use parallel IO register that could be used on a gateway.
This parallel io register could be capable of toggling we signals to flash or could be used as a general io register to setup chains or power management schemes. These signals will need to be synchronized.

PIO_SIZE[1]=4 # 4biits
#PIO_MAP[1][0] = Flash 1 WE
#PIO_MAP[1][1] = Flash 2 WE


PIO[1] = (0x00) #disable WE1 pulse
PIO[1] = (0x01) #enable WE1 pulse
PIO[1] = (0x10) #enable WE 2 pulse
PIO[1] = (0x00) #disable WE2 pulse

User avatar
Ian McIntosh
SJTAG Chair
Posts: 395
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Post by Ian McIntosh » Tue Aug 12, 2008 11:48 am

I agree that a feature like this is probably necessary. Another example would be controlling compliance pins on some devices to force them into (or out of) 1149.1 compliant modes.

But we have to account for all the likely permutations. These "discrete signals" may be a PIO that is part of an embedded microprocessor that is controlling the test execution, they may be a feature within a gateway device, they may be a feature on an external TAP controller or pod. From a language perspective, these cases all need to be treated the same - the physical implementation should be transparent. Further, in striving for "ease-of-use" it would be helpful to be able to be able to write simply

Code: Select all

ENABLE WE1
rather than fretting with the details of which pin is being controlled, although I accept it's impossible to account for all possibilities.

All of this re-inforces on me the need for a language which is abstracted from the underlying hardware (both the UUT and any "test" hardware") but at the same time inherits essential properties of that hardware, making the available features readily accessible in a way that is meaningful to the user (rather than just the board designer).

Post Reply