Minutes of Weekly Meeting, 2015-07-27

Meeting called to order: 11:06 AM EDT

1. Roll Call

Ian McIntosh
Carl Walker
Eric Cormack
Peter Horwood
Brad Van Treuren
Heiko Ehrenberg (joined 11:08)
Brian Erickson (joined 11:09)
Tim Pender (joined 11:11)

Adam Ley
Michele Portolan

2. Review and approve previous minutes:

  • {Heiko and Brian joined}
  • Approval of July 13 minutes (draft circulated 7/13/2015):
    • Correction, middle of 5a: "Brad added that he'd also done that and created custom BSRs where for large FPGAs where it became slow due to the large number of cells.".
    • Correction, end of 5b: "Brad offers to try and draft some diagrams {ACTION}."
    • Eric moved to approve as amended seconded by Peter, 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.
  • Brad - Draft diagram(s) to illustrate the SJTAG Operation. COMPLETE

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.

  • {Tim joined}
  • See email thread initiated by Michele, "ITC Presence for SJTAG".
  • Continue discussion on email reflector; keep topic here as a reminder.
  • Ian concerned about attendance and ability to support presence. Michele has his own poster to man. Heiko noted that he's planning to be at ITC and should be able to support an SJTAG poster if we decide to present one.

b. Try to identify pictorially what we mean by our Scan Operation (continuation).

  • Ian commented on the email exchange between Brad and Michele. Brad explained that Michele was trying to fit the diagrams to way in in which his demo worked while Brad was trying to fit them to the role of the hardware, so that designer could claim they were compliant because the hardware followed the flow of hardware communications.
  • Diagrams submitted by Brad via email {shared}.
  • AccessLink Cycle
  • Brad: there could be none, one, or multiple preconditions and/or postconditions in such an AccessLink cycle. Typically there has to be something that needs to be done to configure the AccessLink controller (here the AccessLink_Precondition), then the pattern is applied and then there may be something that needs to be done (here AccessLink_Postcondition) to disconnect before one can move on to the next step.
  • Ian: In some simple cases you may have a Precondition and/or a Postcondition that are a NULL (not needed; they are not mandatory), but there would always be a data transfer in the middle; how would we picture this (“0 or more steps”) in the drawing?
  • Brad: Well, if you are working with a Gateway, then there would be no data to be transferred; you’d only need to condition the AccessLink.
  • Ian: OK; I forgot we are talking specifically about the AccessLink (not data transfer).
  • Brad: It may be better if we start with last diagram as that's how I drew this, then work backwards.
  • IEEE 1687 Protocol for Scan plug-and-play instruments (redrawn)
  • Brad: The Nops in the 1687 diagram were because 1687 depended on clocks and the Nops were needed to account for the states that were moved through by each clock. We probably don't have that constraint.
  • Data Cycle
  • Brad: I think this is what you are referring to Ian, when you said that there would always be a data transfer.
  • Ian: Yes, correct.
  • Brad: There are zero or more preconditions, zero or more postconditions and at least one data transfer. We probably need a way to represent that on the diagram.
  • JTAG AccessLink Precondition (Example of AccessLink Select)
  • Brad: Here we select the instruction, shift the instruction then update the instruction - that gives us access to the Data Register. We need the correct instruction to ensure that the shift is connected to the correct register.
  • AccessLink Precondition (shows Nops)
  • Brad: There are potentially two steps in the AccessLink protocol: connection and selection. In case of a Gateway, addressing it gets you connected to it, but then you also need to configure the Gateway to select a specific port and get connection. In the case of the Brocade gateway there were two different registers that had to be accessed to fully configure it.
  • Ian: It makes sense to have these two steps each as optional: In the case of an TI ASP with only one downstream port you only need to address it, but the LASP needs both steps.
  • AccessLink Postcondition
  • Brad: This is basically the reverse of the Precondition flow.
  • AccessLink Postcondition (without NOP states)
  • Brad: are the Nops important?
  • Ian: I think this looks cleaner and easier to read.
  • Brad: Nops are only necessary if adhering to a particular clock order.
  • Ian: With multiple interfaces with disparate clocks it might become confusing which clock you're referring to anyway - I2C CLK vs TCK.
  • Brad: How do we represent attributes like "zero or more of this bubble", "one or more this bubble"?
  • Heiko: Perhaps a dashed line for zero or more and a solid line for one or more?
  • Heiko expressed problems with correlating the hardware modelling and software modelling, noting that for the gateway example Michele had referred to a "select method" that was one step.
  • Brad: That "select method" in the modelling code is a group of calls that the access link designer has prepared to achieve the connection. Michele's top level method incorporates many bubbles.
  • Ian: Didn't Michele have a "crossroad" for each downstream path selection point? So that would combine both the addressing and path selection for that node?
  • Brad something has to define it to the scheduler; that's the role of the retargetter in 1687 and 1149.1-2013.
  • Ian: The two steps we've discussed here are generally hidden by the tools; that's probably how the end user's like it.
  • Peter: Different tools will handle them slightly differently, and even different pods from the same vendor may work differently: "This test works here, but doesn't work there". 
  • AccessLink Cycle (revisited)
  • Brad: This was intended to be the primitive for an AccessLink, and we could have more than one of these.
  • The group was generally agreed with what these diagrams represented and that they were understandable.
  • Brad: We need to look at the various access links we're using and how we represent them: I2C, SPI, SIB, indirects (like bit-banging a BSR), JTAG to a data register (e.g. to AXI Master).
  • Ian: Depending on the access link, we may find that a particular one is clock dependent in which case we might need to revert to the Nop version for that link. We could consider it a specialisation of the simpler version.
  • Brad: That's probably a Key Takeaway.

c. Start defining what activities need to be done during pre-conditioning.

  • {Not discussed}

6. Topic for next meeting

  • Refine Scan Operation diagrams - adding attributes.
  • Start defining what activities need to be done during pre-conditioning.

7. Key Takeaway for today's meeting

  • If the AccessLink is clock dependent then we will need Nops.

8. Glossary terms from this meeting

  • None.

9. Schedule next meeting

  • August 3 - Heiko out
  • August schedule: 3, 10, 17, 24, 31: Eric out 24 and 31.

10. Any other business

  • The Newsletter was supposed to be due at the end of this month.  Brad has one other topic in his "queue" from last year.

11. Review new action items

  • None.

12. Adjourn

  • Eric moved to adjourn, seconded by Peter.
  • Meeting adjourned at 12:00 Noon EDT

Thanks to Heiko for providing additional notes.

Respectfully submitted,
Ian McIntosh