Minutes of Weekly Meeting, 2015-08-17

Meeting called to order: 11:08 AM EDT

1. Roll Call

Ian McIntosh
Carl Walker
Eric Cormack
Heiko Ehrenberg
Brad Van Treuren
Brian Erickson
Tim Pender
Michele Portolan (joined 11:13)

By Proxy:
Peter Horwood
Adam Ley


2. Review and approve previous minutes:

  • Approval of August 10 minutes (updated draft circulated 8/13/2015):
    • No corrections noted.
    • Eric moved to approve, seconded by Brad, no objections or abstentions.
  • Ian: How should we best handle a comments coming in on a set of minutes late in the week or over the weekend? I wasn't happy about that pushing things to the forums was keeping things "connected" enough, so had been adding then in to the draft notes as proxy comments, but it get awkward to get a draft out late in the week.
  • Heiko: You could defer it for a week or so.
  • Brad: Or, the emails coming in later in the week or over the weekend could become the initial part of the discussion in the next meeting.
  • Ian: Kind of a topic "matters arising from the previous week" - I was thinking something similar.
  • {Michele joined}
  • Ian: I typically try to get the minutes out Monday evening (or Tuesday, if need extra time), and the invite for the next meeting on Wednesday. We could agree on close of business (Pacific Time) on Wednesday to be the cut-off for proxy-submissions for that week’s meeting; that way I could get the revised draft of the minutes and the calling notice out on Thursday. If someone submits any proxy comments after the cut-off, those comments become a precursor to the discussion in the next meeting.
  • Brad moved to adopt the policy "Initial draft issued on Monday or Tuesday, comments submitted by close of business Wednesday (Pacific Time) to be incorporated in updated draft issued on Thursday with any subsequent comments carried into the following week's discussion". Seconded by Eric, with no objections.

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.

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. ITC Participation.

  • Ian: Need to think about how we tie in our poster with Michele's talk. 
  • Michele: I have not received a formal invitation yet, but as a talk I think it is something that updated right up to the last minute.
  • Ian: I'll send out the poster from last year as a reminder of what we did, but there's no reason we need to follow the same format. One thing I do remember from last year's feedback was the need for a QR Code {ACTION}.
  • Michele: I thought the poster worked well last year and got a lot of interest.

b. Look at SIB in detail, followed by I2C.

  • Ian: prior to starting the discussion on this, perhaps we should review the later proxy comments that came in later last week and were not incorporated in the last draft minutes.
  • [Peter by proxy]: Looking at the usage cases there are two possibilities
    • The vectors to be delivered have already been generated and just need to be targeted to a specific bus i.e. SVF or STAPL file for example. Hence my suggestion of the API providing the target bus. How ever we also need to provide a way for tools generate the vectors. Which can the use the delivery API to transmit the vectors.
  • Ian: This seems to recognise that both "canned vectors" and the dynamic case.
  • Brad: My question would be: what is the scope of the vector set?
  • Ian: My inference would be that it was a single TDR.
  • Brad: But canned vectors imply that the vector set has been created for a complete chain.
  • Brad: I'm thinking of a backplane testing with several instances of the same board type. The vector set may be reusable across each instance but will likely be touching more than one Test Data Register.
  • {A side discussion arose in email on "Duck Typing" - from this, Adam made the following observation}
  • [Adam by proxy]: Actually, it seems to me that, between the two of you, you’ve distilled key takeaways that should be recorded somewhere (though perhaps more succinctly) that is more persistent than this thread!
    • we have to be very careful about what characteristics we deem important
    • when we type or categorise something, we need to be sure that the criteria used are pertinent differentiators
  • [Michele by proxy]: Brad, I think we finally found a point where we do not agree, an occurrence which hasn't happened often so far!
    • If Don King wants to act like a duck, well it is ok for me as long as he quacks right!
    • What I mean is that I believe you are trying to put your bottom too far down, with too many details which make the problem too complex. I believe on the other hand that we need an intermediate abstraction level, and then we can work from them: going up to make the abstraction work, and going down to make the hardware work.
    • My model is High-Level Modeling like SystemC: to be able to push abstraction up, you define the Transaction Level Model (TLM), where (to simplify it) entities communicate in full transactions: read, write, burst, etc... You define the functionality, but not the actual implementation. So you can have complex IP communicating via a complex bus, and validate the functional behaviour immediately. Notably, you can even start writing the software drivers before the actual RTL modeling has been done. Of course there are some points you cannot control (ex: the notion of timing is quite relaxed, you cannot make cycle-based verifications), but you gain a lot of system-level features. I know people who have been doing this for years in ST Microelectronics: they start by making a SystemC TLM model of their complex IP and then launch the different teams on the actual developments (software, buses, ips, etc...). When the IPs are mature enough, they can be co-simulated with the systemC model to check compliance of their high-level functionalities, and so when development is complete, the whole system-level functionalities have been (reasonably) checked without having to run system-level RTL simulations, which are usually computationally close to impossible.
    • So, IMHO we need so TLM-like abstractions in SJTAG if we want to push abstraction up, and actual examples will easily fit in there. All buses are quite similar, so for instance a JTAG2AXI and a JTAGtoWishbone (or any other bus) would be the same: they just need to provide some transactional primitives like read(data, address, size) etc... It would be the provider's duty to actually implement them and provide an STAG-compliant API (a process which, by the way, would preserve his confidential data about the internal implementation of the IP itself).
    • To take up your example, a sequence JTAG2AXI <-> AXI2SPIMaster would be trivial as the transactions  would be nested transparently: JTAG.read(data, position, size) -> JTAG2AXI.read(data, address, size) -> AXI2SPIMaster(read, data, address, size)
    • In this example, the only thing for SJTAG to define would be the JTAG.read(data, position, size) primitive transaction (in fact, a 1687/1149.1-2013 iGet, not much work here).  The JTAG2AXI.read(data, address, size) primitive would provide the translation to the bus address size, and the JTAG register-level operations to operate the bus (ex: which register must be loaded with the address, which one with the data size, how is a transaction started, how the end is detected and where can the result data be collected, etc.. All this could be packed in a PDL-like function). The actual bus operation is hidden behind, and it is of no interest to SJTAG. Some thing for the AXI2SPI.
    • There are many others point to be discussed (ex: would these bridges be considered as AccessLinks? Where does SJTAG stops in such a sequence?), but I think this email is already long enough!
  • Ian: I gather you feel the viewpoint needs to be a little higher than Brad proposes?
  • Michele: Yes there are too many low level details.  We'll need them later but we need to have an abstraction that is easy to work with, that we can work up from and down from.
  • Michele: These are basically general comments of mine; I did not intent to offer any particular solution with those.
  • Brad: I was thinking that we could categorise different families of Data Register and how we communicate with them.
  • Michele: In 1687, ICL has several low level signals but these is almost never any need to use them.
  • Michele: It is possible to go to a register by SPI or JTAG.  You can respect the timing but don't need to have all the details of how. Duck Typing was what I needed here - I just need to see that it's a duck and I know how to handle it.
  • Brad: What comes out in your comments is that we have three register types: Read/Write, Read only and Write only, and it's maybe more appropriate that we look at these for each register domain as it is extremely important to the tools.
  • Michele: Also, we have both static control and run-time control, e.g. when applying PDL, you need to understand that that you're not trying to read something that can't be read. You can't solve everything with static checks.
  • Ian: now, to looking at SIB in detail...
  • Brad: The SIB is not really the final TDR, it's part of the AccessLink but includes a 1 bit data register and still requires a Capture / Shift / Update (CSU) cycle to be managed. The question would be: is this a read/write or just a write access register?
  • Michele: I think with the SIB it would always be a read/write register (reading the status to "sanity-check" the configuration).
  • Brad: I’m not sure whether 1687 defines it as either, but I agree with you, Michele; it makes sense for it to be Read/Write.
  • Brad: {after checking the standard doc} 1687 calls the SIB a "single register with an update stage"; so, they don’t require capture capability (also supported by figure 15).
  • Michele: If you can't trust the state, then you'd need to do a full reset of that portion of the scan chain first.
  • Brad: we could make it an SJTAG requirement that a SIB has CSU capability to be compliant.
  • Michele: I think it is just an omission in the standard; there has been no thought about verification.
  • Brian: Maybe we can check with Adam?
  • Brad/Michele: Don't remember the subject ever being raised.
  • Ian: Are we suggesting that most people would have included Capture because it is obviously useful?
  • Brad: I'm thinking that it's unlikely, because the standard doesn't require it. I'm trying to compare with 1149.1-2013's SCANSEL, but I'm struggling to find it quickly.
  • Michele: I think you can poll whether a segment is active in 1149.1-2013.
  • Brad: We can maybe look at this next time.
  • Brad can we look at the sequence of events for the SIB?
  • You really have two types of SIB: A top-level SIB and a nested SIB. With the top-level SIB you select the appropriate TDR by inserting an instruction into the IR. With the nested SIB you need to select the parent in order to get access.
  • Michele: I simplify this by using a MUX:
    • First of all, I believe that we should better define the role of an AccessLink, as it is a little ambiguous now. I will use this terminology:
      • An AccessLink role is to provide a resolution for the "pull" method of a register, i.e. to provide an access method. The most typical is the 1149.1 TAP, which connects a TDR register with the TMS/TDI/TDO/TCK protocol. Another example could be a I2C controller, or maybe even a bridge (ex: the JTAG2I2C we have been discussing over emails);
      • A Register node has the role of holding data for R/W operations;
      • A Linker has the role of providing dynamic topology modifications based on its internal status, and it is controlled by the triplet Select/Deselect/Is_active.
    • This decomposition makes things quite easy: 
    • Most of the times a basic component is composed of many of this elements, for instance:
      • A SIB is a composition of a Linker (the ScanMux) and a Register (the SIB control register);
      • a TAP is composed of an AccessLink (the 1149.1 FSM), a special Register (the IR) and a Linker (the Instruction decode logic).
    • So, the SIB Select/Deselect/is_active methods are actions regarding the Circuit Model (CM) status of the Control Register. While is_active is only a query, the other two involve a modification of the value, that is to say of status of the Circuit Model. This will trigger an execution cycle to synchronise the System Under Test with the CM.
    • For the TAP, things are quite similar: select/deselct will cause a modification to the CM value of the IR register. During execution/configuration, the "pull" method of the IR registers will be used, causing a a TIR register.
    • That is why for me is easy to model a BSCAN2 Linker: it is just like a tap, but without the AccessLink part. similarly, to get the Brocade Linker example, I just need to change the "pull" methods to invoke a I2C operation.
    • The Control Register can either be a standard CM register (like for the SIB), or just be an internal value of the Linker node. I do the latter for IR and I2C to simplify, but it believe it could be possible to express them a CM nodes too.
  • Brad: Is it truly a dependency or a parent/child relationship? I see the child asking the parent "give me control" and that recursing upwards and then the control being returned back down.
  • Brad: The target AccessLink has to have some primitive that configures its parent and then say to the parent "I need control".
  • Michele: The child can flow "I have a request" from the bottom up, then you can go from the top down. The parent knows how to query its own children. The child doesn't need knowledge of the parent.
  • Brad: But it's only the leaf node that knows when it needs to update it's configuration. The push model then becomes more efficient than continual polling.
  • Michele: The way I see it, update requests are a status of a node, and then you can decide how to propagate or poll them. What I do not like with a Push model is that a child needs to be aware of its parent to push the update, which can be problematic in a pure bottom-up approach (what do you do when the parent changes or if there is no parent at all?). But if you look at it like a status rather and a propagation the problem is not even there. For instance: in my engine the configuration function is recursive, and the return value is the need for a given sub-path to be activated. So I have a push model without the actual need of implementing it.
  • Michele: That said, we might need some provision for interrupt-like communications in case of high priority actions that need immediate attention... there was a paper from Jutman in the 1687 D&T Special Issue proposing, for instance, a way of propagating fault information through the hierarchy by some special register, but it would be better to have a standardized way of doing it...
  • {The following comments were supplied post-meeting by email. The text has been minimally edited to fit the format of the notes, but is otherwise the commentor's original text. The comments are not in time sequence order but in the order that best represents the flow of the exchanges.}
  • [Brad by proxy]: I have searched IEEE 1687 and IEEE 1149.1-2013 and found the following showing Capture in almost both standards for the selection bit.
    • IEEE 1687
    • In 1687, the SIB definition states on page 9:
    • "segment insertion bit (SIB): A single-bit register (including an update stage) on a scan chain that controls
      whether or not a bypassable segment of that scan chain is included in the active shift path."
      Indicating the SIB must contain an update stage as part of this single bit.  Figure 15 on page 26 and the corresponding text goes as far as stating the SIB is comprised of a Shift-Update architecture and does not include a Capture element.  I can find no where that it states a Capture element is not allowed, but the only requirement is for the Shift and Update stages.

    • IEEE 1149.1-2013
    • On page 115, Figure 9-19 shows a typical SCANSEL control architecture.  The paragraph preceding this diagram as the commentary for the diagram states:
      Figure 9-19 shows an example segment-select or selection-field cell meeting all of the rules of this clause. For a selection-field cell, the capture logic in Figure 9-19 is optional, as shown with the dashed lines, although it is recommended that it capture the state of the update or delay stage. For a segment-select cell, the capture is required and must capture the “Ready-to-scan” signal.

    • So you see in 1149.1, the capture stage is required for the selection cell whereas 1687 has the capture not defined.
  • {Adam asked by email if he was expected to comment (in response to Brian's suggestion)}
  • [Adam by proxy]: I never participated in any such discussion, and, in fact, was not party to the proceedings of the working group, though I know some who were – if needed, I can make some inquires.
    • But note that the following may be instructive.
    • First, the SIB, while defined by 1687 is NOT actually an element that is SPECIFIED by 1687.
    • Rather, the SIB is a construct that is an exemplary (perhaps typical) combination of elements that ARE SPECIFIED by 1687, namely the ScanRegister (bit) and the ScanMux.
    • For reference, see this small snip from Example E.6:
      • ScanRegister SR {
        ScanInSource SIBmux; CaptureSource SR; ResetValue 1'b0;
        ScanMux SIBmux SelectedBy SR {
        1'b0 : SI;
        1'b1 : fromSO;
        Copyright © 2014 IEEE. All rights reserved.

    • Since every ScanRegister (just as every 1149.1 TDR) can define a CaptureSource, then it certainly may be part of the SIB setup cycle. In fact, of course, every ScanRegister is expected to cycle from Capture to Shift to Update (CSU) in that order, though the CaptureSource might be undefined.
    • In fact, considering the Example E.6 as excerpted above, it is plain that this most prominently published example does make use of the CaptureSource and defines the ScanRegister as self-monitoring (in 1149.1 terms, the Capture “PI” is sourced from the Update "PO")
    • ON  THE OTHER HAND, consider that the 1149.1 "SCANSEL" (as it was named by Brad, but which text does NOT appear in 1149.1), when used in its "segment-select" sense, while mandating a defined CaptureSource requires that it be the "Ready-to-Scan" indication, which is an INDEPENDENT cell PI, AS OPPOSED to being sourced from the cell PO. (NOTE: this is chiefly to deal with partial-power architectures, where the segment to be selected might be, at least at time of the initial selection request, powered off, such that ready-to-scan would be inactive (0); where the segment to be selected is always on, the descriptive text indicates that the CaptureSource should be ONE – always active)
  • [Brad by proxy]: Adam,
    • 1687 has no requirement for a capture value from a SIB; only an Update value is required.
    • 1149.1-2013 has a requirement for a Capture value from the SELSCAN which is a difference.
    • Certainly a model could keep track of a cell's state if it is initialized by the model first.  So is a Capture value required?  We bounced around always setting it when needed whether it was set or not and that seemed inefficient.  Keeping track of the value of the SIB in the model is most likely being done anyway, but requires an initialized state as dictated by the model.  Being able to read back the state (as discussed in 1149.1) allows one to confirm the SIB is in the desired state as well as being able to synchronize the model state on each scan through the SIB.  That seemed to be a benefit.  I remember some discussion in 1687 regarding the SIB and because there was no read back on the SIB state, there had to be added instructions to the PDL to export and import the current state between executions of different model domains.  We want to avoid that problem in SJTAG.
    • Comments?
  • [Adam by proxy]: Thanks Brad.
    • Congruent with my separate reply to Ian’s request (Sent: Tuesday, August 18, 2015 3:40 PM, under the same subject heading), which I encourage all to read carefully, I don’t concur with your assessment of what is required per the two standards and, consequently, what is the difference.
    • Here, then, is my synopsis:
    • The real difference:
      • While 1687 permits the capture (readback/self-monitoring) of the cell state, it does NOT require it (or any other defined capture).
      • Whereas, 1149.1 requires a defined capture, BUT that capture is NOT a readback.
    • Please let me know what you think about these observations.
    • As far as the desire to "avoid that problem in SJTAG", I believe that you can do so for the 1687 SIB by teaching best practice, BUT you can’t avoid it for 1149.1 "SEGSEL" (because it MANDATES the capture of "ready-to-scan", which is NOT THE SAME AS the cell state).
  • [Peter by proxy]: A further comment on the topic of "Canned vectors" vs "Dynamic case" and the impact on the system. Canned vectors will have the least system overhead requirements, compared to Dynamic where the vectors will be compiled in real time. Not all systems will be able to warrant the over head requirements for Dynamic case.
    • There are real world examples where the "Canned case" vectors will be provided for a single device e.g. FPGA programming file, then the total vectors to target the device on a PCBA through a Firecron Gateway which is multi-drop capable are pre - compiled for delivery. The same is true for interconnect testing or any other required test function, you generate the test once, so the test intent is selected by the vector set to be executed.
    • Then the overall system consists of a shelf that contains multiple PCBA's each at a different slot address, the Firecron embedded controllers just amend the target address for the multi-drop selection and plays the remaining vectors. Providing a cost effective solution to a system as the memory/processing requirements are kept to a minimum.
    • The same could be done using the "Dynamic" method but the requirements on the system would be greater as you would need the source files and target information and design constraints. Total test execution time will be longer as the vectors will need to be generated before application.
  • [Michele by proxy]: Peter, what you are describing is indeed a fully "Dynamic" case where all ATPG is done on the fly, at it would indeed be a quite troublesome use case. Maybe a better definition would be "Dynamic composition and application" of vectors, where the ATPG per-se is already done for each one of the base IPs of the system, and what is done dynamically is the composition of the basic vectors into system-level ones based on the SUT status and requirements. Anyway, 1687 and such push towards some sort of "fully dynamic" case for functional testing, as you might have complex algorithms (not necessarily only ATPG) based on the instruments that would need to execute and coordinate with the traditional vector delivery.
  • [Peter by proxy]: I would disagree that it is a totally dynamic case you have multiple instances of the same pcba on the same multi drop bus. The vectors being delivered to each card are the same it's the pcba address that is being changed that's all... Lets discuss on next call.

6. Topic for next meeting

  • Look at SIB in detail, followed by I2C (continuation).

7. Key Takeaway for today's meeting

  • Access Flow and Data Flow look similar although purpose is different.
  • Addressing may occur before or at the same time as the data transfer.

8. Glossary terms from this meeting

  • None.

9. Schedule next meeting

  • Michele and Brad are both doubtful for August 24. Added to the known absences, Ian proposed to cancel the meeting on 24th and carry the agenda to 31st.
  • August 31 - Eric out

10. Any other business

  • The Newsletter was due at the end of July.

11. Review new action items

  • Ian: Circulate the 2014 ITC Poster.

12. Adjourn

  • Eric moved to adjourn, seconded by Tim.
  • Meeting adjourned at 12:10 PM EDT

Thanks to Heiko for providing additional notes this week.

Respectfully submitted,
Ian McIntosh