IEEE P1687: Toward Standardized Access of Embedded Instrumentation

Ken Posse: Independent DFT ConsultantAl Crouch: Inovys

Jeff Rearick: Agilent TechnologiesBill Eklow: Cisco SystemsMike Laisne: Qualcomm

Ben Bennetts: Bennetts AssociatesJason Doege: DA TestMike Ricchetti: ATIJ-F Cote: LogicVision

AbstractThe effort to standardize a methodology for accessingembedded instrumentation as IEEE P1687 continues toprogress. This paper captures the current state ofmind ofthe IJTAG Working Group with respect to the frameworkbuilt to date and presents a discussion of other issues onwhich decisions are pending. The key elements of anarchitectural description language, a procedurallanguage, and a hardware interface scheme are all takingshape, but still have many details to complete. Since thisis a snapshot taken during the standard developmentprocess, the final form of the draft standard may differfrom what is described here; any feedback to the workinggroup is welcome.

1. Introduction to P1687In November of 2005, the IEEE recognized the year-longeffort of an ad hoc working group [1] by designating theirwork as "IEEE P1687: Draft Standard for Access andControl of Instrumentation Embedded Within aSemiconductor Device." This paper provides an updateon the activities surrounding the initiative and a roadmapof upcoming work. Current and background informationon IEEE P1687 can also be found on the official web siteat: http://grouper.ieee.org/groups/1687/.

This effort, commonly referred to as IJTAG (for InternalJTAG), is primarily intended to facilitate automation of on-chip instrument access, and in the process overcome theshortcomings of IEEE Std 1149.1 [2] with respect to theaccess and control of internally embedded instrumentation.In this context, the terms "instrument" and"instrumentation" are loosely defined to mean virtually anycircuit internal to a semiconductor device that can be usedto test, debug, calibrate, characterize, or measure any part(or all) of that device or other devices connected to it.

Lecture 4.1 INTERNATIONAL1-4244-0292-1/06/$20.00 C 2006 IEEE

The scope of P1687 is limited to the access of theinstruments, not the instrument functions themselves. Ittherefore focuses on the hardware connectivity andprocedural activity between the TAP and theinstrumentation, using scan mechanisms in order to notovercomplicate the interface. At the same time, there is arecognized need for high-bandwidth communication withcertain types of instrumentation, and P1687 intends toaddress this by allowing hand-off from the TAP to other(user-specified) interfaces to such instruments.

Just as IEEE Std 1149.1 uses BSDL (Boundary ScanDescription Language) to articulate TAP configuration andboundary scan connectivity, P 1687 will use a similararchitectural description language to specify the location ofinstrument content. Additionally, P 1687 will use aprocedural language to describe the operations required toutilize the instruments.

The objectives of P1687 can therefore be summarized as:

I. Specify documentation of debug and test featuresfor re-usability.

II. Maintain access compatibility with IEEE 1149.1.

III. Specify optional handoff to high bandwidthinterface.

IV. Enable automation of instrument use.

Likewise, it is important to recognize the objectives notwithin the scope of P1687:

E> Specify instrument architecture.

E> Specify protocol for the optional high-bandwidth interface(s).

E> Specify mechanism for encryption of scanprocedures or scan data.

With this guidance in mind, the working group has beenengaged in the process of making the technical trade-offsto define the details of the proposed standard. This paperwill review the distillation of the above objectives into a

TEST CONFERENCE 1

list of requirements in section 2 and introduce the solutionframework in Section 3. The open issues with thearchitectural description language, the procedurallanguage, and the hardware interfaces are reviewed inSections 4, 5, and 6, respectively, followed by conclusionsin Section 7.

2. Requirements P1687 Must AddressThe objectives listed above imply certain capabilities,which can be thought of as constituting the requirements ofa P1687 solution. In light of the last year's worth of effortby the IJTAG working group, these required capabilitieshave taken the form of a set of deliverables, each discussedin the next eight subsections.

2.1 Instrument Inventory IdentificationSince the foundation of P 1687 is the instrumentationcontent embedded in a device, it is essential that amechanism exist to collect an inventory of availableinstruments. In a manner analogous to that used in IEEE1149.1 to identify the boundary scan chain length andorder along with the valid TAP opcodes from DUT datafiles (i.e.BSDL), IEEE P 1687 must include a similararchitectural description language from which instrumentinstances, including their number, location, andconnectivity, can be extracted. In this context, the locationand connectivity of an instrument refers to its position onthe internal scan chain(s) of a device, or alternatively itsconnection to the pins of the device.

Since a given device may include many different types ofinstruments, as well as multiple unique instances of thesame instrument, the architectural description languagemust include provisions for instrument type and nameidentification. It is quite likely that the instruments willexist in a hierarchical netlist, and also likely that corescontaining instruments will be re-used in other hierarchicalcontexts, so explicit handling of hierarchy is essential forthis architectural description language. BSDL, as it standstoday, has no concept of hierarchy and thus appears to beunsuitable for this task unless augmented.

The goal of P1687 with respect to this requirement is notto specify the exact process to be used for automatinginstrument identification, but simply to enable it byspecifying the documentation that must accompany theinstruments and devices. Fortunately, this requirementoverlaps the next one to be discussed, so a properlydesigned description language should cover both.

2.2 Access Point MappingThe essence of providing access to embedded instrumentsis to understand how the ports and/or registers of theinstrument are connected to the device in which they areembedded. Figure 1 illustrates an example that will help

explain the concept of mapping the access points of theinstruments to access points of the device.

AO

1 2

TAP ....... .7U7....4 ............ ..... I/ o

........................................................... ...........

.0 ......................................... in

0000

Figure 1 Embedded Instrument Connectivity Example

The example device in Figure 1 contains a TAP, fourfunctional blocks of circuitry (AO, B1, B2, and CO), andfive embedded instruments (two in AO and one each in theother blocks). There are three internal scan chains (lightlydashed arrows) connecting the blocks (including theinstruments embedded inside them) to the TAP. Alsoshown are the four required TAP pins on the bottom left,as well as an arbitrary 8-pin I/0 interface on the bottomright. The instruments in blocks AO, B1, and B2 are allcaptive on scan chains; the instrument in block CO isscanned and also connects to the 8-pin I/0 interface. Asdiscussed in section 2.1, a description language thatcaptures the structure conveyed in this diagram will be ableto uniquely locate each of the five instruments, even ifthere are multiple instruments per block (AO), or multiplecopies of the same instrument (blocks BI and B2).

Access to instruments is accomplished in either of twoways: through scan-based access to their constituentregisters via scan chains connected to the TAP, or throughdirect pin access to their ports, or perhaps both, dependingon the nature of the instrument. For example, consider amemory BIST ( Built-In Self Test) instrument for an on-chip RAM (Random Access Memory), which could beblock CO in Figure 1. The basic memory test operationcould be as simple as scanning in a "start" bit, waiting for aknown period of time, then scanning out a result bit fromthe BIST state machine. Only scan-based access isnecessary for this operation. A more complex operationcould be to sequentially read every address and drive theresulting data out from the memory to the pins of thedevice for consumption by external equipment. A mixtureof scan actions (to set up and launch this debug operation)and parallel actions (to coherently digest the data readfrom the memory) are required.

One critical item in this process is to exactly understandwhich instrument registers are located at which scan path

INTERNATIONAL TEST CONFERENCELecture 4. 1 2

bit positions, and which instrument ports (the data outputbus of the memory in this example) are connected to whichdevice ports (the 8-bit I/0 interface). This is access pointmapping, and it must be facilitated by P1687 through anarchitectural description language capable of correlatingthe register names and port names of standaloneinstruments to their final locations in the device containingthem. Again, the specific process of access point mappingis not the concern of the standard, just the provision of thedata necessary to enable it.

2.3 Instrument Usage InstructionsDocumentation of the mere presence of instruments in adevice, which is sufficient to satisfy the requirements ofthe previous two sections if done properly, is still notenough to make those instruments useful to the owner ofthe device. For that, there must also be instructions to theend user that detail the operations which can be performedwith the instruments. Armed with that information, the enduser will be capable of incorporating various instrumentfunctions into test and debug activities, which are likely tobe codified in some programming language. Note that thislist of instrument capabilities does not need to go intoexplicit detail of exactly how the instrument does itsvarious functions, it just tells the end user what theinstrument can do. For example, the memory BISTfunctions described earlier may be represented simply asprocedure calls like these:

* Run_CO RAM_BIST(;* Dump_CO RAM(start_addr, end_addr);

The justification for this "black-box" view of theinstrument as a requirement for P 1687 has twocomponents. First, the provider of the instrument maywish to protect the details of his intellectual property,which can be accomplished by simply listing the functionswhich can be invoked instead of divulging the entiredetailed sequence of scan and/or parallel events whichoccur during those functions. Second, the end user maydesire a modular and portable version of the instrumentusage instructions which can be applied in differentcontexts, rather than just the detailed sequence of events.For example, even if the instrument provider deliveredonly the detailed sequence of scan chain events necessaryto operate his instrument, in all likelihood the consumerwould wrap that sequence up into a macro or procedurethat could be easily called from his end program.

The implication of this requirement is that P1687 mustspecify some flavor of a procedural language that iscapable of listing the operations that can be performed byan embedded instrument without diving into the low-leveldetails of those operations.

2.4 Instrument Action SequencesThe previous section made the case for specifying theoperations that can be performed by an embeddedinstrument at a high level. Despite the solid rationale forthat requirement, a high-level description alone would beinsufficient to actually do anything useful with aninstrument. Obviously, at some point in time, the specificlow-level sequence of scan and/or parallel actions must beapplied to the device in order to cause the instrument tooperate. The implication is quite clear: anotherrequirement of P1687 is that it must provide a method tospecify the low-level scan and parallel operations requiredto operate embedded instruments, much like a typical testvector language would do.

Though this requirement is seemingly contradictory withthe one in the previous section, the two can actually coexistquite nicely. Consider the common situation in thesoftware development world where code written by oneauthor is made available for re-use by another. Thoughsource-level sharing by the first author is one option, it isnot the only option. The other widely used practice is toencapsulate the interface, i.e. the procedure calls, in apublicly available format but to keep the body of the codein a separate and human-unreadable library that is linkedinto the second author's application.

The lesson from this analogy is that P1687 must provide amethod for the low-level details of instrument operation tobe specified, but to be able to obscure them in such a waythat they are not visible to the end user in cases whereprivacy is desired. Note that this is not a guarantee ofimmunity to reverse engineering; it is sufficient for thepurposes of the standard that due diligence be taken, butnot necessary that impenetrable security be achieved.

2.5 Support for Real-Time SignalsThere is a fundamental conflict between the nature ofmany embedded instruments and the TAP with respect tosignal timing. The TAP is a synchronous circuit based onthe relatively slow TCK signal, and has only one (optional)asynchronous input (TRST) for reset. Both this featureand the fixed architecture of the finite state machine in thecontroller render it inherently incapable of responding toreal-time events (that occur on time scales faster thanTCK). Many instruments, on the other hand, operate atmuch higher frequencies and, more importantly, requirereal-time response to events that are asynchronous withTCK. Using the TAP as the sole pipeline for interactionwith such instruments would impose a fundamentallimitation on the applicability of the standard, so there is arequirement for some (optional) additional capability tosupport real-time signals.

A simple example of an instrument that demonstrates thisneed is an on-chip logic analyzer that captures a sequenceof internal signal values into memory based on the

INTERNATIONAL TEST CONFERENCELecture 4. 1 3

occurrence of some trigger condition. If the triggercondition is generated internal to the chip, then this systemwill capture the internal signal values in a timely fashionwith minimal latency after the trigger event. If, however,the trigger condition is generated externally, then a real-time path must be provided from the chip boundary to theon-chip logic analyzer. The alternative of executing aTAP command or a scanpath load to set a "trigger in"register would introduce so much latency between thetrigger event and the on-chip signal capture as to renderthe instrument useless in this mode. The same would betrue if an internally generated trigger from the on-chiplogic analyzer needed to be made available externally:shipping it out via a TAP status bit or unloading a scanpathwould destroy the utility of cross-triggering. Support forreal-time signaling must be available for some instrumentapplications like these.

The impact of this requirement on P1687 is not as severeas it might seem at first. It does not require a re-architecture of the TAP to support asynchronous inputsand outputs or a change in the TAP state machine to allowinterrupt handling; such changes are not only beyond thescope of the P1687 but also bad ideas at this stage of TAPdeployment. What this requirement does imply is amechanism to allow accessible chip pins to act asinstrument ports, which may involve some scan-basedsetup sequences. The need for real-time signals will alsoforce the P 1687 language elements to handle parallelsignals, but this expectation has already been established inthe previous sections.

2.6 Translation to TAP SequencesOne premise that underlies P1687 is that end users ofdevices, whether they are at wafer, package, module,board, or system level, will access the instrumentsembedded in the devices through the IEEE 1149.1 TAP atthe device boundary. The ubiquity of the TAP (originallyto facilitate board test, but now for many other purposes;see [1]) and of the associated test equipment tocommunicate with it justify this assumption. In addition,the lack of alternative physical access to any otherinterfaces at many stages in the product test and debug lifecycle warrant the use of the TAP as a mandatory interfacefor embedded instruments. This then results in therequirement that the instrument usage proceduresdescribed in Sections 2.3 and 2.4 be translatable intosequences ofTAP operations.

The practical implication of this requirement is thatinstruments must have a scan-based interface that isconnected to the TAP. Note that this requirement comesdangerously close to the specification of instrumentarchitecture, which was on the list of don'ts for P1687.However, given the nearly universal use of scan-basedtesting, particularly for the style of devices which willinclude embedded instruments (i.e. high-end chips), the

assumption that instruments will be scannable is notunreasonable and is unlikely to limit the applicability ofthe standard. Furthermore, the alternative of having P1687support the access to embedded instruments through anyarbitrary interface in a standard fashion is so daunting atask that it is likely to be unachievable. Therefore, theTAP must be the focal interface for P1687, and translationof instrument usage procedures to TAP-only sequences isrequired. Note that this does not necessarily preclude theuse of instruments with real-time signals as described inSection 2.5 - those signals are either connected to theproper system resources in situ or may be connected to thecommonly available parallel I/0 pins available in manyTAP drivers.

2.7 TAP Interface HandoffNotwithstanding all the good reasons for P1687 to beTAP-centric, there is no question that the bandwidth of theTAP as commonly implemented is far below the leveldesired for many instrument applications in which highdata throughput is important. Consider the memory dumpexample for the CO block of Figure 1 used earlier. The useof the BIST instrument to unload the memory through the8-bit I/0 interface can achieve a read rate of one memoryword per system clock cycle. The TAP, on the other hand,can only unload a memory word (assuming that the RAMoutput data is registered) each time the scan chaincontaining that register is shifted out, which happens atTCK frequency. For a system clock rate of 100 MHzcompared to a TCK rate of 10 MHz with a 100-bit scanchain, there is already three orders of magnitudedifference, and none of the extra shift latency for otherserial commands has been taken into account. Real worlddifferences are likely to be much greater. The utility andvalue of using other, non-TAP, higher-bandwidthinterfaces is clear.

However, the ever-changing nature of interface technologyargues strongly against standardization on any givenalternative interface, as it will likely be outdated in just afew years. Hence the dilemma for P1687: being stuck withthe widely used but slow TAP interface and not being ableto standardize on the interface-of-the-day. There is,fortunately, an elegant solution to this dilemma: requirethat there be a methodology in place to hand off instrumentaccess from the TAP to some other interface withoutspecifying exactly what that other interface is. Thehandshake between the TAP and the other interface is allthat need be in place; the other interface is then free tochange with technology.

This requirement does come with a price, however: theend-user is left responsible for handling thecommunication with the instrument over the other (non-standardized) interface. All the benefits of a standardaccess method, including automation, tooling, andvalidation, are unlikely to be available in this scenario.

INTERNATIONAL TEST CONFERENCELecture 4. 1 4

Moreover, the lack of physical access to the other interfacein any given configuration in which the device finds itselfmay severely limit the re-usability of the embeddedinstruments. On the other hand, this model does allow forthe future standardization, or even de factostandardization, of popular alternative interfaces that couldindeed become very widespread on their own, along withinfrastructure support.

2.8 Mixed TAP / Other I/O TranslationThe combination of the previous two requirements (fortranslation to TAP-based access and for handoff to analternative interface) implies a new requirement: the abilityto perform mixed translation of sequences that containTAP-based accesses interleaved with alternative interfaceaccesses. Also driving this requirement is the occasionalneed for real-time signaling as described in Section 2.5.

This combination requires the ability to effectively mergeTAP patterns, which are usually simple, linear streams ofTAP IR SCAN and DR SCAN commands, with moretraditional parallel vector language patterns, which mayinvolve much more complex constructs across many pins.It also implies some mechanism for managing thehandshake for switching between TAP actions and thosedirected at either the alternate interface or any real-timesignals. Ultimately, this requirement will imply a set ofcriteria that the P1687 language choice must meet. It isimportant to keep in mind that the parallel features areoptional and intended for use only with instruments thatrequire high-bandwidth access or real time signalinterfaces; the bulk of the instrument access is expected tobe via the TAP.

3. P1687 FrameworkIn light of the eight requirements described in Section 2,the IJTAG working group has decided upon the frameworkfor the proposed standard. Though somewhat firm, thisframework is not cast in stone (or electrons, as it were)since the draft standard is still in development. The threepillars of the P1687 framework are the architecturaldescription language, the procedural language, and thehardware interface, each briefly described below.

3.1 Hierarchical, BSDL-like ArchitecturalDescriptionThe first two requirements in Section 2 (instrumentinventory and access point mapping) both imply the needfor a description of the scan- based instrument contentwithin the context of the entire device. Such a descriptionmust allow the embedded instruments to be identified andlocated with respect to their positions on the scan chainsinternal to the device, and allow any parallel portconnections to be mapped to top-level device ports.Although all this information may be derived from thenetlist for a chip, the size, complexity, and possible

encryption of portions of the netlist (such as the instrumentIP) argue against standardizing on any given netlist formatto contain this data. Instead, it makes more sense to followthe lead of IEEE 1149.1 and consolidate this informationin a separate, well-defined format like BSDL, thoughBSDL itself lacks the hierarchical constructs necessary toenable instrument and core reuse elegantly. To addressthat omission, a slightly extended version of BSDL (calledHSDL, for Hierarchical Scan Description Language [3]) isbeing seriously considered by the working group as thearchitectural description language.

The choice of a hierarchical language would allow thedesigner to create descriptions of instrument entities andthen reference those entities by name when they are used ina higher-level core or chip description. This is akin to classdefinitions in C++, where a class, once defined, may beinstantiated multiple times by reference. Such constructsmean that a circuit definition utilizing multiple entitiesdoes not have to define the entity each time it is used, andthat in some circumstances only the entity prototype needsto be visible, which is consistent with the "black-box" viewof instrument actions described earlier. The specificextensions beyond BSDL to support hierarchy include theability to define nested entities, the ability to form registergroupings of arbitrarily ordered bits, and the ability tosupport internal test data registers that act as instrumentinstruction registers.

The information contained in this architectural descriptionlanguage is only structural (instrument names, registernames and groupings, scanpath order, bit positions, portnames, pin connections, etc.). There is no functionalinformation included (how to operate an instrument, whichbits contain results, what sequences of patterns to use toactivate alternative interfaces, etc.); this functionalinformation is contained in the procedural language(described next). The reason for separating those twotypes of information is to enable instrument descriptions tobe portable to different chip contexts, to allow independentstructural and functional analyses, to allow packaging ofdifferent instrument capabilities for different end-users,and to facilitate automated translation of instrument actionsequences to chip-specific commands in much the sameway as is done with BSDL.

3.2 Procedural APIThe third and fourth requirements in Section 2 (instrumentusage instructions and instrument action sequences) clearlyestablish the need for a procedural language to capture thesteps required to operate the embedded instruments.Furthermore, the required separation of these operationsteps into high-level actions that are visible to the end userand low-level actions that actually touch the internals ofthe instrument strongly suggest the use of a layeredapproach, commonly referred to in the software world asan API (Application Program Interface). The essence of

INTERNATIONAL TEST CONFERENCELecture 4. 1 5

an API is to present the end-user with a set of high-levelfunctions, specified as procedure calls, which executeprimitive operations whose details are hidden in acompiled library of object code. An API offers the enduser with a level of abstraction that makes his job ofwriting an application program much easier, since he isable to work with procedures containing many sub-operations that would require a great deal of effort to re-invent and maintain. Decades of success by modularprogramming languages make the use of an API language aclear choice for this application.

What is not so clear, however, is the exact form that theAPI will take for P1687. A four-layer API has beenimplemented in a case study of embedded high-speed I/0instruments [4]. This example API is strictly procedural innature: the instrument operations are represented bymacro-level procedures, whose contents at the next layerbelow consist of nothing but register reads and writes,which, at the next layer below that, consist of nothing butTAP operations for scanning in and out those registers. Avery different model of the API also being considered bythe working group is object-oriented in nature: theinstruments are described as objects and come with publicand private methods for use that are propagated up thehierarchy. The trade-offs with respect to automation andusability between these two paradigms are still in activediscussion by the working group at the time of publication,but the concept of using an API of some flavor for theprocedural language is an essential part of the P1687framework.

3.3 Flexible Hardware InterfaceThe final four requirements in Section 2 (real-time signals,TAP connectivity, optional high-bandwidth I/0connectivity, and mixed TAP and other I/0communication) all have implications on the hardwareinterface between the embedded instrument and the hostchip. In addition, the working group is also consideringthe issue of backward compatibility with legacyinstruments and cores that already contain embeddedTAPs, all while keeping in mind the objective of notspecifying instrument architecture. The net result of allthis guidance is that the hardware interface between theinstruments and the top-level of the chip containing theinstruments will be somewhat flexible, but with thefollowing properties:

* There must be at least one scan connection betweeneach instrument and the TAP.

* If needed, real-time ports of the instrument must becapable of being connected to top-level pins of thedevice. If not hardwired, any routing logic must becontrollable from the TAP.

* If needed, connection of ports of the instrument to analternate I/0 interface of the device must be made. If

not hardwired, this path must be selectable via theTAP. Furthermore, the instrument must be able toindicate when it is using the alternate interface (viastatus bits or signals available via the TAP).

These general rules can be satisfied by many possibleinstrument interface implementations. The working groupis attempting to strike a balance between formulating ameaningful standard and not restricting designer creativity.It is expected that the draft standard will contain referencedesign examples showing a variety of acceptableimplementations and their associated trade-offs.

The three elements of the P 1687 framework, thoughroughly defined at the time of this writing, all still haveseveral open issues which will be lightly discussed inSections 4, 5, and 6, respectively.

4. Architectural Description LanguageOpen IssuesThe primary weaknesses identified with the architecturallanguage revolve around its capability to handle allpossible instrument interface architectures. The workinggroup has collected a large list of example instruments,some of which already expose some issues, and there isalways the possibility for future instrument innovations toexceed the capabilities of the language.

4.1 HSDL or CTL?The case has been presented for a BSDL-like language,namely HSDL, to serve as the architectural descriptionlanguage. This is based primarily on the widespread usageofBSDL in TAP-based boundary scan applications and theassociated tool support, as well as the basic capability ofBSDL to represent scan chain data. However, BSDL, as asubset of VHDL, has a number of limitations and issomewhat dated compared to newer languages like CTL(Core Test Language), which is standardized as IEEE1450.6 [5]. Consideration must be given to the relativemerits of HSDL and CTL for all envisioned instrumentdescription applications

4.2 Completeness for Unusual InstrumentsThe typical instrument interface architecture assumed forP 1687 is based on simple internal scan chains, andpossible port-to-pin connections. However, it is quitelikely that some instruments, either legacy or not yetcreated, will have very different interfaces. It is essentialthat the architecture description language be sufficientlycomplete that it is capable of representing these as well.One stressful example is almost painfully obvious: the casewhere the instrument interface is itself a TAP (commonlyreferred to as a child TAP). Child TAPs are occasionallyfound on embedded cores and serve as gateways to moredeeply embedded instruments inside those cores, butthereby interfere with the model of direct scan access to

INTERNATIONAL TEST CONFERENCELecture 4. 1 6

those instruments assumed thus far. In order for thesechild TAPs to be IEEE 1149.1 compliant, there is usuallysome mechanism in place to promote the child TAP to thetop-level (such as a compliance pin or a master/slavemuxing scheme), which would allow P 1687 to sidestep thissituation using the same mechanism. However, the issueof a more integrated access method for child TAPs doesdeserve consideration, and this will have an impact on thearchitectural description language. Similar issues exist forother atypical scan interfaces such as reconfigurable-lengthscan chains and nested scan chains, as well as for non-scaninterfaces.

4.3 Linkage to Procedural APIWhatever the final form of the architectural descriptionlanguage for an instrument, it must somehow be linked tothe corresponding procedural description for that sameinstrument. One possibility is to include both linguisticelements in the same file, but this could present seriousparsing issues given the disparate nature of HSDL and anysuitable procedural programming language. A workaroundfor this option would be to use the generic string handlingcapability of BSDL/HSDL to skirt the parsing problems,though this is not exactly elegant. A different option is tolink the two different pieces of information via instrumentname, but the possibility for name collision seems likelyand puts the burden on the end user to defensively organizeall P1687 data. A clean mechanism for handling thislinkage must be found.

5. Procedural Language Open IssuesAs complex as the architectural description language issuesmay be, they are dwarfed by those with the procedurallanguage since this task is much more general. In additionto the open question about the form of the API mentionedin Section 3.2, there are several other issues as well.

5.1 Pattern Language or ProgrammingLanguage?If all instrument actions were simple scan-basedtransactions, then it is quite possible that the low-levelprocedural language could be any one of a number ofpopular pattern languages (like STIL (Standard TestInterface Language) IEEE 1450 [6]) to represent the scandata. However, it is not difficult to visualize instrumentactivity that involves much more complex low-levelbehavior than could be captured with simple, staticpatterns. Furthermore, the efficiency of the instrumentprovider in producing the low-level procedures may bemuch higher if given the flexibility of a full programminglanguage (see Figure 8 in [4] for a simple example). Thenagain, a full programming language may introduce somuch complexity that one of the key objectives of P1687 -

automatability - is hindered. This trade-off will have to be

carefully managed during the selection of the procedurallanguage.

5.2 Compiled Object Code or TextualShift Data?The goal of being able to obscure the low-level details ofthe instrument operation can be served in a number ofways. The traditional software approach is to compile thebody of the API procedures into an object code library thatis not human readable. Unfortunately, this object code isgenerally tied to a given platform and is usually notportable, which argues against it being part of P1687.Another approach would be to translate the low-levelregister reads and writes into scanpath and parallel portdata which could be re-targeted at each level of hierarchybased solely on the data in the architectural description filefor that level. Though this pattern data is still humanreadable, it may be sufficiently obscure (with optionalrandom data filling and register renaming to neutral terms)to achieve the objective.

5.3 Handling Parallel Operation,Interoperation, and SynchronizationThe simple case of a single instrument operated on a singledevice is a starting point for P 1687, but much morecomplicated arrangements are likely to occur and will trulyreveal the value of the standard. To that end, theprocedural language must have some allowance forfacilitating activity that involves multiple instruments onmultiple devices, perhaps in coordinated fashion. Forexample, if a user wishes to measure a single event on twodifferent instruments, then both instruments must be armedand able to operate in parallel when a common triggersignal is delivered. If the language somehow forced thetrigger event to be serially delivered to each instrument,this operation would be inhibited. Likewise, someinstruments may need to interact with one another, perhapswithout the need for supervision or direction from thecentral TAP. Finally, the language must be capable ofsupporting synchronization points and allowing executionof low-level instrument operation to be scheduled.

6. Hardware Interface Open IssuesSeveral of the preceding language issues have a directbearing on the hardware interface issues as well,specifically, handling child TAPs, handling instrument-to-instrument communication, and handling legacyinstruments without scan interfaces. In addition, there area few more hardware issues as well.

6.1 Standardized Central I/O Hub?The optional requirement for high-bandwidth I/0connectivity can be handled in several different ways. If asingle instrument needs to be connected to a single I/0

INTERNATIONAL TEST CONFERENCELecture 4. 1 7

interface (as in the example shown in Figure 1 anddescribed in Section 2.2), then it is probably simplest tojust mux the instrument directly to that I/0 interface. If,however, there may be several instruments that all need to

share the same alternate I/0 interface, then a standardizedcentral I/O hub may be a better solution, as shown inFigure 2.

Figure 2 Central 1/0 Hub

The proposed central I/0 hub shown in Figure 2 providesfor configurable switching of high bandwidth data in andout (the HDI and HDO arrows) to and from theinstruments in the core. The control of the switching isbased on the values in a configuration register that isconnected to the TAP (between TDI and TDO in the samemanner as any other test data register). In addition, thehub design also includes real-time signals (Done andSynch) that may be redirected between the device pins andthe instruments. The implications of adding this hubhardware specification to the standard are beingconsidered.

6.2 Private Instructions to Modify TAPState MachineAmong the proposed solutions for handling the presence ofchild TAPs is the use of a private instruction thateffectively re-maps the logic path through the top-leveldevice's TAP state machine. The details are beyond thescope of this work, but the key impact of this proposal is toopen the door to allowing changes to the well-entrenchedbasis of the IEEE 1149.1 boundary scan interface. Thoughsomewhat frightening at first glance, this step is actuallynot as dangerous as it sounds because it can be done with aprivate instruction that is applied only to the TAP inquestion - all other TAPs that may share the same signalswould not change their behavior, and that privateinstruction would only apply to devices that are capable ofsupporting it. Without that feature, the option ofmodifying the TAP would surely be off the table, but as itstands it will be considered.

6.3 IEEE 1500 CompatibilityThe final hardware issue concerns compatibility with IEEE1500 [6] (the wrapper methodology for testing embeddedcores). IEEE 1500 introduces one flavor of reconfigurablescan chain in that the wrapper instruction register (WIR) isitself a test data register of the top-level TAP as commonlyimplemented, which thus allows other test data registers tovary in length depending on the wrapper instructionchosen. Given the likely possibility that 1500-wrappedcores may contain embedded instruments, it is importantfor P1687 to directly address this case.

7. ConclusionsThe progress of the IJTAG working group in identifyingthe requirements for P1687 based on the objectives setforth for the proposed standard has led to the creation ofthe framework for a solution. Careful examination of theramifications of various aspects of the proposed solutioncontinue to drive refinements in the ongoing definition andimplementation of the standard. Interaction with otherIEEE standards that affect both the hardware and softwareaspects of P1687 is being carefully structured and the otherstandards are being leveraged wherever possible. Theworking group will continue to use real-world examples totest the validity of the proposed solution, and activelyencourages participation from the wider community via theofficial P1687 web site at [8].

9. References[1] J. Rearick, B. Eklow, K. Posse, A. Crouch, B.

Bennetts, "IJTAG (Internal JTAG): A Step Toward aDFT Standard," Proceedings of the International TestConference 2005, paper 32.4.

[2] IEEE Std 1149.1-2001, "IEEE Standard Test AccessPort and Boundary-Scan Architecture," IEEE, USA,2001.

[3] http://www.asset-intertech.com/support/hsdlspec.pdf.[4] J. Rearick, A. Volz, "A Case Study of Using IEEE

P 1687 (IJTAG) for High-Speed Serial I/0Characterization and Testing," Proceedings of theInternational Test Conference 2006, paper 10.2.

[5] IEEE 1450.6-2005, "IEEE Standard for Standard TestInterface Language (STIL) for Digital Test VectorData - Core Test Language (CTL)," IEEE, USA,2005.

[6] IEEE 1450-1999, "IEEE Standard Test InterfaceLanguage (STIL) for Digital Test Vector Data,",IEEE, USA, 1999.

[7] IEEE 1500-2005, "IEEE Standard Testability Methodfor Embedded Core-based Integrated Circuits," IEEE,USA, 2005.

[8] http://grouper.ieee.org/groups/1687/.

INTERNATIONAL TEST CONFERENCELecture 4. 1 8