Minutes of Weekly Meeting, 2015-01-12

Meeting called to order: 11:06 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Tim Pender
Heiko Ehrenberg
Peter Horwood
Carl Walker
Brian Erickson (joined 11:08)
Brad Van Treuren (joined 11:11)
Bill Eklow (joined 11:12)
Michele Portolan (joined 11:17)

(Several people had difficulty joining via the web service)

By Proxy:
Adam Ley (purple highlight)
Al Crouch (green highlight)

2. Review and approve previous minutes:


  • Updated draft circulated 12/16/2014.
  • No corrections noted.
  • Eric moved to approve, seconded by Carl. No objections or abstentions.


  • Draft circulated 01/05/2015.
  • No corrections noted (but see note in "10. Actions").
  • Peter moved to approve, seconded by Eric. No objections or abstentions.

3. Review old action items

  • All: do we feel SJTAG is requiring a new test language to obtain the information needed for diagnostics or is STAPL/SVF sufficient? See also Gunnar's presentation, in particular the new information he'd be looking for in a test language (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • Ian: Add the previously discussed lists to the 'master' template. Ongoing.
    • Some sections need further expansion that may take time to develop.
  • post Gunnar’s submission (text and slide) to SJTAG Forum ?
    • Ian was unsure if there was a decision here.  Brad advised that Gunnar had said it was OK to share and that the material was helpful to the context of the meeting minutes.

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172

5. Discussion Topics

a. Clarification on Ian's 1687.1 remarks.

  • Ian wished to explain the cryptic comment he'd made the previous week.  This arose from a conversation with Al Crouch on aspirations for an extension to 1687 and some of the problems that perhaps remain to be addressed, some which might overlap with SJTAG problems or echo thoughts we have had.  Ian had summarised some of the main points on a slide:
    • JTAG embedded instruments may run on TCK, SPI instruments on SCLK, I2C on SCK – so how to coordinate across different clock domains/periods?
      • Al Crouch, proxy: Basically, the stance of 1687.x (dot-x - an extension to 1687) is that any chip may have embedded instruments, and any chip may benefit from managing access to that instrument by using 1687 network constructs (i.e., SIBs) and documentation — even if those chips do not have 1149.1 JTAG TAP interfaces. This means that any test/debug/instrumentation access port may be valid for accessing an embedded instrument or embedded 1687 network with embedded instruments. The goal of the first extension, 1687.1, is to define the rules and guidelines for incorporating “serial” access controllers. This means to define the AccessLink and architectural constructs necessary to use, for example, a SPI SLAVE Interface as a method to access and operate a 1687 network. If there are any ICL (network description) or PDL (vector description) constructs needed, those will be added as well. Note that 1687 is a “per chip” type of standard meant to define the access and management of embedded instruments inside of a chip — therefore, 1687.1 will also be a “per chip”, not a “board level” standard. Some of the more sticky problems were brought up in a discussion with Ian. For example, as Brad talks about later — what if both a JTAG interface and a SPI interface could be used to address the same instrument — is that a 1687 HW or documentation problem — or is that out of scope for 1687.
    • May need a “trigger” or “semaphore” to aid coordination between instruments.
      • Al Crouch, proxy: Given that a chip may have multiple controllers (and for the case of 1687.1), for example, a JTAG, a SPI, and an I2C — how do 2 or more on-chip instruments coordinate with each other, especially if they each source from different controllers? Is it the job of 1687.1 to define these instrument synchronization elements?
    • Some shared resources may not be known to the 1687 architecture: e.g. a PLL that needs to be set to 250MHz for one instrument and 400MHz for another, even within the same chip.
      • Al Crouch, proxy: One of the limiting factors to instruments communicating with each other is what is called the hidden resource — these are resources that are not within the scope of 1149.1, 1500, or 1687 and so are not described by any off their languages (BSDL/SVF, CTL/STIL, or ICL/PDL). For example, what if instruments use a bus to transmit data but only one item can take the bus at a time — then 2 instruments could not operate at the same time if they relied on this bus that is not documented. The more common example, is “what if the PLL is not a controllable instrument, but different instruments — when selected — will change the PLL setting? If you choose instrument #1 it automatically adjusts the PLL to 250MHz, if you choose instrument #2 it automatically adjust the PLL to 400MHz — then you cannot choose both of these instruments at the same time, one of them would not work — possibly both would not work correctly. These undocumented items are generally known as “hidden resources”.
    • Idea of a “whitelist” and “blacklist” of instruments that can be run concurrently without conflict and those that have shared resource conflicts and cannot be run together (tool warnings).
      • Al Crouch, proxy: the only way to include the information of embedded instruments that could work together and ones that cannot work together is for the chip designer or integrator to actually document this fact. They can document the fact without having to document “why”, which may be some proprietary information or chip construct, by simply creating a white list (can work together or be operated simultaneously) and/or a black list (cannot work together or be operated simultaneously).
  • The first point was the crux of where Al wanted to go with 1687.1 - accommodating other serial access links - and the issue of reconciling clock domains and speeds was direct result of having multiple interfaces in use.  Brad added that there was also the question of arbitrating when an instrument is accessible by more than one interface (which interface has the priority over the others), although Michele pointed out that there were two issues: Arbitration was largely a software question while the coordination between the clock domains was largely a hardware problem.  1687 could in place some rules for the hardware aspect but arbitration is usually done in software so may be outside 1687's scope.
    • Al Crouch, proxy: Largely, I believe if we did address the “multiple access” hardware, we would do it “generically” so that it would be up to the software to decide which hardware access to choose to meet  a particular goal. Remember that PDL (vectors) should be written at the instrument and it would be up to the software to identify the pathway through the network and controller to retarget the vectors to the edge of the chip — the software could retarget to a JTAG TAP or to a SPI, for example, if both existed. It is up to the software to include the algorithms or the selection criteria (test time, access time, access length, manual selection or override, etc.) to make the best decision. We would not create a forced limitation such as, if the JTAG TAP is active, then the SPI cannot be active — however, if the chip design does have “hidden resource” problems, then the black list or white list could go so far as to stipulate that when instrument A is active, that instrument B could only be active when accessed from the SPI interface. Remember, that 1687 is about managing embedded instruments, not about managing the controllers — they just provide access to the access mechanism for the embedded instrument.
    • Adam Ley, proxy: (As Brad seems to hint below) I presume that there would be some level of arbitration facilitated in the retargeting of the PDL for the various instruments involved. That ratifies Michele’s point that it’s a software issue, but, on the other hand, that would seem to place it well within the 1687 scope (at a behavioural level – not an implementation level). 
  • Brad remarked that 1687 placed a great dependency on the retargetter for the JTAG interface, so wondered if that would then mean that the retargetter would need to be extended to deal with any other interfaces.  Would the retargetter now need to be the coordinator between the domains?  {Brad, post-meeting addition: If coordination between domains is required, a pregeneration model of the vectors proposed by the current IEEE 1687 standard will have to include a new representation partitioning the current global vector representation into coordinated smaller vectors that are applied to specific serial access links at specific points in a particular order.  The current single global scan vector approach, as demonstrated by existing tools touting IEEE 1687 support, does not support this kind of scaling.}
    • Adam Ley, proxy: In answer to Brad’s supposition (then) and question, I believe the answer is yes. As for Brad’s post-meeting addition, I won’t pretend to understand it, but, at any rate, why would existing 1687 tools support scaling of a kind that is not presently disclosed by 1687?
    • Al Crouch, proxy: the main goal of 1687 was to provide the documentation of the access network and the controller so that the vectors could be retargeted to the edge of the chip. Right now, many tools will retarget to the edge of an 1149.1 TAP controller. If 1687.1 provides the documentation and rules to allow retargeting to the edge of the chip and that chip has a SPI or I2C, then some of the existing tools may need to expand to handle this. A worst case scenario would be that a different tool is made to retarget to the edge of a SPI chip, for example — then there would be one tool to retarget to a SPI and one tool to retarget to an 1149.1 TAP. In any case, since there would now be the capability at the board level to operate instruments, and possibly to coordinate instrument operation, in many different chips — through all of the serial protocols — then there is the opportunity for board test tools that do not exist today. For example, one software that drives a hardware controller, and the hardware controller connects to the TAP, the SPI, and the I2C and maybe uWire and other ports on the board. It is not the goal of 1687.1 to solve this board level problem or even the problem of talking to just one chip with multiple serial ports at the edge of the chip — it is the goal of 1687.1 to provide the capability (hardware and documentation) to enable embedded instruments to be operated from the edge of the chip through any serial protocol. It is up to the tool companies to come up with the solutions to either provide different hardware that can somehow coordinate, or with one software+hardware that can coordinate.
  • The remaining points on Ian's slide were really follow-on notions from the first.  The point wasn't to critique plans for 1687 but see if there was anything that should be part of SJTAG or anything we could "hand-off" to 1687. 
  • The semaphore idea is akin to something that we had discussed when we considered signalling that a commanded action had taken place when disparate interface were in use.  Brad added that coordination was key, knowing what scan segments to apply at what time and in what order.
    • Adam Ley, proxy: I think the matter of coordination between instruments is more fundamental that what target interfaces are involved. There are many use cases where a stimulus is a function of one instrument (such as in a transmitting chip) while a response is a function of another instrument (such as in a receiving chip) …
    • Al Crouch, proxy: since I was also on the iNEMI side of embedded instrument communication, I will put a comment or two down here as well. 1687 and 1687.1 is about documenting the instrument interface, the instrument vectors, and the pathway from the instrument to and through the controller to the edge of the chip. If PDL needs to be coordinated, for example, to start a couple of instruments at the same time, then the iWrite to start both instruments should arrive at the instrument interface at the same time (or thereabouts given that the instruments may run on different clocks). What is not handled by 1687 or 1687.1 is the instrument itself — it has always been the working groups contention that “we do not tell people how to make their instruments. That is for someone else to do (and that was part of the iNEMI BIST Phase 3 work).” The piece that is missing is for the “board and system development community” to tell the IC provider what instruments are needed and how they should work together. For example, if every PCIe should allow a loopback — then this needs to be specified by board test people to the IC providers and then 1687 can document it and have PDL to put it in that mode, but it is not 1687’s job to tell people that PCIe’s need to have loopback and here is how to do it.
  • Michele thought we could hand-off some of the hardware aspects to 1687 and have the higher level aspect within SJTAG but he wasn't sure that some of the 1687 people would look at it that way.  Bill didn't think we needed to consider 1687's plans too much as we could still do things ourselves.  Ian was concerned about different solutions being developed for the same (or similar) problems, resulting in confusion.
    • Al Crouch, proxy: I have had a very clear idea of the “partitioning” of the solution space. IJTAG (1687) is an “inside the chip” solution, 1500 is an “inside the chip, border of the core” solution, JTAG (1149.1) is a “border of the chip” solution. What is missing — and what the iNEMI Phase 3 was about, is the space between the chips and how tests are defined. All that 1687, 1500, and 1149.1 document are the chips, there test logic, their access, etc. — what they do not document is the interaction between any two chips. For example, if one chip provides PCIe source vectors and another chip provides receiver processing — then this needs to be described at the chip level. A side effect of this would be on the controller end — 1149.1, 1500, and 1687 describe how the controller may access on-chip features that could be used for on-chip test or could be used for on-to-off-chip test (an embedded instrument on-chip that can drive or receive to/from off-chip) — but their operation or coordination are not defined off-chip. So, there is a need to create a language at the board/system level to define the goals, coordination, operation, and interactions between chips. This would be above and beyond the current chip test standards. The operation of any embedded chip instruments would just layer in as part of this — for example, one chip may be a DDR controller and another chip may be a DDR memory, and the DDR controller may contain a memory BIST. There would be a description of the operation between these two chips and there would be a description of the control to both chips, then layered into this description may be the specific PDL of the instruments.
  • Bill was aware that there had been mention in the past of 1687 extending into SPI or I2C but didn't think anyone had seriously looked into yet.  There had been significant concerns about boundaries for the original standard and .1, .2, etc., were suggested to address different protocols.  Ian noted that Al had expressed that he was considering only serial protocols at this stage.
    • Al Crouch, proxy: At ITC in Seattle, at the IEEE Standards meeting, I announced that I would be responsible for 1687.1 and would start the study group and would drive the effort to PAR if the study group felt there was merit (anyone interested should contact me). So, I was given the go-ahead. I already have several IC providers that are interested. I have also traded emails with several of these IC providers and have a good amount of preliminary material collected (as can be seen from previous discussions in this document). To summarize: it should be a chip-level standard that is based on the use of embedded instruments and the use or reuse of 1687 compatible networks — however, the controller should now be any other serial chip port other than an 1149.1TAP. The effort should include the definition of an AccessLink (documenting how a serial port selects or accesses a 1687 compatible network); how to drive the network signals (ShiftEn, UpdateEn, CaptureEn, Reset, Select, ScanIn, ScanOut, and TCK); and how to process PDL through the controller (i.e. iWrite, iRead, iApply) if items such as stall, bidirect-change, etc. are needed. In addition, if any new ICL and PDL is needed to accommodate the use of a different serial access controller. Note, advanced ideas such as those discussed with Ian are also possibilities — the synchronization of PDL to operate different embedded instruments when sourced from different controllers.
    • Adam Ley, proxy: I think that the 1687.1 for serial interfaces is an idea that more than just a mention ... I think I’ve also heard tell of a 1687.2, but I don’t remember what that was about.
    • Al Crouch, proxy: There has been discussion of a 1687.2 as the “parallel access controllers” — for example, a CPU bus can directly drive a 1687 network. This effort has been mentioned as an interest for Jeff Rearick at AMD and J-F Cote at Mentor. If an effort is started, it will most likely be started by Jeff.
  • Brad commented that he has encountered push back against JTAG for small instruments that have SPI or I2C interfaces and small pin count and that this was understandable.  Ian had similar experiences.
    • Al Crouch, proxy: And so has Al, but Al has found out that some of these small chips and small instruments can benefit from reuse by having PDL associated with the instruments. Sometimes 1687 does not need hardware changed, but just the addition of ICL and PDL to describe how to operate the instrument and how to get to the instrument.
  • Bill imagined that people will look to have PDL that tells the instrument what needs to be done.  Brad added that SJTAG would coordinate across different domains, but also wondered if we intended to support only IEEE defined or recognised interfaces or if we would allow user defined interfaces.  Bill tended towards the latter.
    • Al Crouch, proxy: The thing that was really learned from 1687 is that PDL is one of the most powerful concepts. To make instruments portable and reusable (with no rework), requires that the instrument be delivered with its operation procedures. To make them fully reusable and automatically retargetable required documenting how to reach the instrument from a port on the edge of a chip. However, there is a tradeoff on “full description” such as Verilog — and a lesser description that maintains proprietary interest. So, ICL must be something less than a full Verilog simulation model. It is hoped that the “generic” treatment of serial interfaces for 1687.1 would allow any serial interface to be described. A similar hope would exist for parallel interfaces that would be the 1687.2 effort.
    • Adam Ley, proxy: What sorts of user defined interfaces? And how to document their behaviour and usage??
  • The SCC20 group was mentioned by Bill:  It seems to be looking at some areas similar to ours so there may be some things we can learn from there.  Bill will try find out more for next time.
  • The third bullet on Ian's list highlighted an issue of resource dependency/conflict that may not be apparent when considering only a single instrument.  Al was considering "whitelists" and "blacklists" as a means of managing that but Brad and Michele felt that managing the dependencies would supersede those lists.  Michele added that the lists would be essentially "static" lists that would be difficult to scale up.
    • Adam Ley, proxy: I believe that PDL has some degree of resource management by way of iTake and iRelease. But perhaps there’s an idea that dependency relationships might be considered as well in the ICL (or the like)??
    • Al Crouch, proxy: iTake and iRelease are actually a way to manage things without knowing these hidden dependencies. However, they are “test-scheduling limiters”. When it is not known if, for example, there is a PLL that must be shared between two instruments and with different settings, then the writer of the PDL for an instrument may include an iTake for some resource. What this actually does is to tell the “vector retargeter” that iReads and iWrites from other instruments cannot be scheduled and processed until the instrument with the iTake does an iRelease. This is kind of a brute force White-List/Black-List. This really only works when the PLL is an instrument and can be seen by the retargeter. At the board level, this would scale if the hidden resources are at the board level. For example, if an adjustable clock-source on the board drives chip #1, #6, and #8, and it is documented that this clock operated embedded instruments within the chips (ICL does include a functional clock identifier for the instrument) then the board-level restriction can be extended to the white-lists and black-lists.
  • Bill felt we could leverage 1687 and 1149.1 but didn't need to be bound by them.  We could extend a standard if there was additional stuff we needed.
    • Adam Ley, proxy: Of course, but it may be easier to extend and coordinate, rather to invent new; especially since the existing stuff has to be considered in the total solution anyhow? At any rate, is there any particular thought as to what additional stuff might be needed?? (it might be nice to know what sort of stuff may issue from Pandora’s box before we open it ...)
  • Bill asked if we needed to be a sub-group of 1149.1.  Ian wasn't sure if he was answering exactly Bill's question but he had asked Rohit's advice over whether SJTAG should be within the 1149 series or a new number.  Since we felt SJTAG might originate a number of related standards, the preference was for a new number rather than "double dotting" to make, e.g., 1149.X.Y.  Bill thought that we may also need a different acronym in that case.  Ian felt that 1149.1 was still a key technology for us, but we had realised that we needed to wrap in other things to get the "system control".
    • Adam Ley, proxy: Of course, I think we’ve understood for some time that SJTAG is more than just 1149.1 adopted within the system context. But that’s not categorically different that IJTAG being more than just 1149.1 adopted within the embedded instrumentation context. I think SJTAG is a great acronym unless and until a particular alternative might be considered (most likely as a natural outgrowth of where the embodiment of the activity is heading).
    • Al Crouch, proxy: Just an input on this, as the Vice-Chair of 1687: on the one hand, we thought about getting an 1149.x number at the beginning and we called our effort IJTAG at the beginning. As we went on and defined what we were doing, we were actually glad that we didn’t have the 1149.x number and we were sorry that we had already labeled our effort IJTAG. We really wanted to expand beyond pure JTAG and the fact that we called it IJTAG attracted many JTAG purists to the working group. Our basic goals were to 1) access embedded instruments; 2) document the pathway to the instrument; 3) provide instrument-centric vectors or procedures; 4) enable vector retargeting. It was procedural mistakes that we made early on in the PAR process that limited us to doing it with a JTAG TAP controller and defining it to look, smell, and taste like JTAG. So, my recommendation is to be very generic with the PAR and write the Scope and Purpose of the par like I wrote the 4 goals above — do not mention JTAG or other JTAG-like standards. For example (just my shot at some mythical bullets): “SJTAG includes the 1) description of how to access and operate the various controller interfaces on the chips on the board; 2) description of the various interactions between the chips on the board; 3) definition of necessary test and debug features required at the board, system, or backplane level; and 4) description or pointer to description of various test, debug, monitor, and configuration features contained within chips on the board — for the purpose of providing and documenting efficient test, debug, configuration, or programming operations; or to provide test/defect/fault coverage.

b. Revisit draft PAR statements - continuation.

  • {Not discussed due to lack of time}

6. Key Takeaway for today's meeting

  • None.

7. Glossary terms from this meeting

  • None.

8. Schedule next meeting

  • Next meeting January 19.  Brad Carl and Bill are all likely to be absent.
  • January schedule: 19, 26.

9. Any other business

  • The newsletter is due at the end of the month.  Brad will endeavour to get the next green paper ready for then.
  • Bill noted that he has some influence on the content of ITC this year and was keen to see a paper, panel or even a full session on SJTAG/system-level topics this year, but there is only about a month and a half to get submissions in.

10. Review new action items

  • Ian - Put Gunnar's material on the SJTAG website.
    • Add link to the location to last week's minutes.
    • This replaces the action from the previous minutes.

11. Adjourn

Eric moved to adjourn at 12:00 Noon EST, seconded by Tim.

Respectfully submitted,
Ian McIntosh