Minutes of Weekly Meeting, 2015-09-14

Meeting called to order: 11:05 AM EDT

1. Roll Call

Carl Walker
Brian Erickson
Peter Horwood
Eric Cormack
Brad Van Treuren

By Proxy:
---

Excused:
Adam Ley
Ian McIntosh
Michele Portolan
Heiko Ehrenberg

2. Review and approve previous minutes:

  • Approval of August 31 minutes (updated draft circulated 9/10/2015):
    • No corrections noted, but not enough present to approve minutes.  Needed Tim to join, so minutes were left unapproved.

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.
  • Ian: Start an email discussion in the next few days to see how we can tie our ITC poster in with Michele’s presentation. - Completed by Michele's email!

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. Scheduler and posting synchronisation notifications.

  • Brad shared the slides Michele sent out during the week.
  • Brad went through the presentation attempting to describe what Michele was presenting in Michele's absence.
  • Discussion notes after the presentation:
  • Brad: I think the iWrite and iRead actually are the forces to cause the pending to be necessary and that the iApply is registering the pending with the scheduler at the time the synchronization is required.
  • Brad reviewed the first couple of slides showing how the leaf of device_2 needed to have its contents changed first before the pending need was realized.  It is at the point of the iApply where this pending need is realized back into the model tree, somehow.  This is what we need to discuss.
  • Eric: Does it have to be that interactive?  It seems to be overly complex to what we need to perform.
  • Brad: We need to be changing the SUT's state over time so we need to have the iterative process.
  • Peter: If the structure of the system does not change, you don't need the iterations.  With a dynamic configuration, you need to handle the change over time and that is were we are needing the iteration.
  • Eric: My experience shows systems are becoming more dynamic and change configurations during the life of a test.
  • Eric: I really think this needs to be a System Engineer's problem to define the configuration and not a Test Engineer's problem.  Systems want to change on the fly.  Could there be a way that we could interrogate the configuration of a system to get the information by reading it somehow?  It would be a standard format that we could read in and not have to require a Test Engineer to define.
  • Peter: It comes down to where you want to generate the vectors.  If the system controller is used, the SUT requirements increase significantly.  You will need more memory, probably a faster CPU, some storage space for more than just vectors, etc.  Some people are satisfied with just playing back vectors and some are not.  SJTAG needs to be able to support both types of end users.
  • Brad: We are talking about the static structure vs. dynamic structure that we already identified in our use case analysis.  We are getting back to the same discussion now.
  • Brad: Perhaps we are discovering we have two sets of requirements for these different use cases that can't really be resolved in a single generic standard and needs to be handled in separate dot standards.
  • Eric: I agree.
  • Brad: We need to define the structure of the entire system that is possible to be realized as the configuration at any moment in time.  In some cases this gets set once and remains in place for the rest of the applications.  In others, this may be changing for every scan.
  • Eric: Maybe we need to table the discussion until we have more people on the call.
  • Brad:  Even so, we can still focus the rest of our time on the dynamic case and talk about how we propagate the "pending" notification back to the scheduler.
  • Eric: We have to use the notify in the tree as described by Michele.
  • Brad: But that can be handled two ways: The push model and the pull model.  With the push model, the leaf not would notify either the parent or the scheduler of the need to synchronize its state with the hardware.  In the pull model, the leaf provides a way for the parent to observe there has been a change of state of the child node and that a synchronization with the hardware needs to take place.  That synchronization may not be able to happen until some other state synchronization takes place (what Michele was trying to present).
  • Brad: Brian, you seem to be the only vendor representative today, so I will put you on the spot and ask if, based on your current operating model, you have any preference to how this notification is performed by your tools set.
  • Brian: Due to some internal discussions happening right now, I am unable to answer that and will have to withhold my comment for now.
  • Brad: That's fair.
  • Brad: I have used JTAG Technologies, ASSET, and Goepel and have seen enough demonstrations of the other vendors to note they all seems to partition their tests with a precondition, that defines the configuration of the scan chain prior to application of the real test, a data section, that represents the actual test being applied, and a post condition, that represents some change to the state of the system after the test like a TAP Reset or other conditions that may occur.
  • Peter: I think there are some that treat these as separate modules defined for a test whereas other define all of this in the single application test file.
  • Brad: Yes, but I think from a modularity perspective they all partition the execution into these 3 sections regardless of whether they are separate modules or separate blocks within the same module.
  • Brian:  I think it is important to note that what you termed as precondition is really static during the test and what you termed the body of the test is really dynamic during the test.  So you really have a static section and a dynamic section to an entire test.
  • Brad: That is interesting.  You are presenting a different perspective from what we discussed in the past.  What I termed as precondition is what I have been referring to as the AccessLink and said that changes over time based on what configurations are required.  The actual test section is remaining the same as the DataLink over time in that the same data may be applied to every instance of that type of scan segment.  I looked at this as the DataLink and modeled that as a static configuration over time.  So my perspective of AccessLink and DataLink is really inside out of your perspective.  What makes this interesting is I am looking at it from a control perspective and you are looking at it from a data perspective as to what is changing per scan.  I think this is a very important insight we have not appreciated yet.  There are two different perspectives with how we look at the data being sent to the SUT.  In the control case, the AccessLink operations are changing the state over time until the synchronization occurs.  Then the transactions to the data register are then propagated "as is" until all the data transactions are complete.  However, it must be noted that the AccessLink registers are static and unchanged during the application of the DataLink transactions.  I will note this as a key takeaway.
  • Brad: Given the time, I am going to move on to the rest of the agenda.

6. Topic for next meeting

  • Scheduler and posting synchronisation notifications
    • Specifically, identify the requirements that differ between the static and dynamic use cases

7. Key Takeaway for today's meeting

  • There are two perspectives regarding the AccessLink and DataLink portions: Control Flow vs. Data Flow.  In control flow, data in the AccessLink changes over time until the required configuration is resolved and the DataLink portion is not realized until the configuration is resolved.  In the Data Flow, the data in the AccessLink remains constant over time while the data transmitted during the DataLink portion changes over time.

8. Glossary terms from this meeting

  • 'Scheduler' (from Aug 31) is TBD.

9. Schedule next meeting

  • September 21 (Eric will be starting a new job that day and may not be able to attend.).
  • September schedule: 21, 28.

10. Any other business

  • The Newsletter was due at the end of July.
  • Email from Al Crouch re 1687.1 (Ian omitted to put this in the agenda: Hasn't spoken to Al again, but we ought     to arrange to set a meeting aside sometime to get him on our call).

11. Review new action items

  • None.

12. Adjourn

  • Eric moved to adjourn. Peter second. Meeting adjourned at 11:57am EDT.

Respectfully submitted,
Bradford G. Van Treuren - Chair Emeritus