Minutes of Weekly Meeting, 2015-10-19

Meeting called to order: 11:11 AM EDT

1. Roll Call

Ian McIntosh
Carl Walker
Brad Van Treuren
Eric Cormack
Michele Portolan
Peter Horwood
Brian Erickson
Heiko Ehrenberg

By Proxy:
---

Excused:
Adam Ley
(Tim Pender tried, but was unable to join)

2. Review and approve previous minutes:

  • Approval of October 12 minutes (updated draft circulated 10/15/2015):
    • No further corrections noted.
    • Eric moved to approve, seconded by Brad. 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.
  • Michele - Copy proposal from Sep 24 email to forums. 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
  • Persistent AOB items:
    • The Newsletter was due at the end of July. Brad probably has one topic left on his list.
    • Try to get Al Crouch on call re 1687.1.

5. Discussion Topics

a. Slidepack on 1687.1.

  • Michele had emailed the group with Al Crouch's 1687.1 slidepack, presented during the ITC Meeting, and some comments had already arisen in the email thread.
  • Ian would like to put the slidepack on the SJTAG website for ease of reference but was unsure that we had Al's permission for that (Michele had noted that he had Al's permission to share the slides with our group).  Brad noted that as the slides carried a copyright mark, we probably needed Al's express written permission to publish on our website.  Agreed that the team should just retain their own local copies, as emailed.
  • Ian wondered how best to continue the discussion without diverting the SJTAG meetings to 1687.1 business.  Brad felt that the forums provided the best mechanism.  Important points could be brought to the SJTAG meetings as necessary.
  • Michele commented that it was maybe too early to ask Al onto our call.  Brad agreed and noted that one of the later slides even suggested that there wasn't yet a fixed view of what 1687.1 was.
  • Michele remarked that some people already have a solution for the protocol conversion, but need the committee to find a way of describing this.  There's currently no way of interfacing with the ATPG tooling.
  • Ian noted that there was also mention of "1687.s" relating to security.  Michele wasn't sure if that was a separate standard or something to be added to the main 1687 standard in a future revision.

b. Preclusion: What gets precluded, what are the locking mechanisms?.

  • Ian started out by reminding the group that we chose to consider "preclusion" as we expected that to be simpler to manage than "allowance".  Brad reaffirmed this.
  • Brad asked how you can identify what can be shared between process that don't know about each other and thus what might be used for locking, noting that even in software there aren't great solutions; sometimes the address of the resource is all that is used as the reference for the lock.
  • Brad suggested the TDR itself could be the locking mechanism, but that may be at too low a level as some instruments are an aggregation of TDRs.  Brad was unsure if the models used in some tooling would be able to retain references to instances of instruments.
  • Michele thought it may be too early to making decision like this, since it could be influenced by the choice of language.  Brad agreed, but thought it should be possible to list potential locking mechanisms.
  • Brad suggested two candidates: TDR and Instrument instance (although leaving the latter relatively undefined).
  • Ian felt that the instrument instance was more readily mappable to an OO object, where the data is stored within the object and manipulated by access functions; some of those access functions could implement the locking.
  • Heiko confessed that he was struggling to follow this discussion asked for clarification of what was being locked.
  • Ian replied that if there are multiple threads/processes running then sometimes a process will need exclusive access to one or more instruments/registers to complete its task, so needs to lock out other processes during that time.  Brad added that typically a process will first request access to the resource.  If granted it will then preclude other processes until it has completed the task and then releases the resource.
  • Brad gave an example of using emulation on an AMD processor which tries to access the internal registers to report to the system developer while another task wants to check internal temperature and voltage monitoring registers.  You need to decide who gets to control access at a particular time.  Peter noted that we talking about a form of arbitration.
  • Heiko understood, but remarked that he was probably thrown by the use of the term "locking".
  • Brad noted that we were really talking about software locking and not a hardware lock.
  • Ian started to wonder if a hardware lock was possible but doubted it would be.
  • Michele commented that it was possible, although not trivial. Peter suggested that a process could set a flag bit to say the resource was in use; a process would know whether or not it had set the flag. Ian noted that a rogue process could simply ignore the flag.  Michele suggested that writing a "key" to a write-only register to gain access to or release the resource would overcome that, provided there was a way to exchange keys.  This was most typically for use for security rather than preclusion.
  • Ian couldn't suggest any locking mechanisms other than the two Brad had proposed.
  • Brad felt that we need to consider protocol, as the instrument may be too low and noted the lock on an AMD processor could be at the device level rather than the individual instrument.  Locking needed to be at a delineation level in the protocol.
  • Michele considered that there also needed to be some hierarchical information.  Brad remarked that was similar to what happens in software, but also noted it would be possible to lock the IR which would prevent change without locking the device.
  • Michele preferred the notion of assigning different privileges to tasks, similar to Linux and where no-one can lock everything.
  • Brad felt that tools vendors could bring value add in how they managed locking.  Michele felt that they should be adhering to a standardised method, at least.
  • Brad noted that even with the managed privileges suggested by Michele, it was still possible to run into a deadlock situation. Michele felt that was partly dependent on the operating system, e.g. it shouldn't be possible to lock out a higher priority task.
  • Brad noted that was an implication of a need to record and roll-back the state; this was all to do with context.  Do we need to worry about context when changing the locking?  Brad noted that this resulted in IJTAG applications dumping out state to a file that is then used by the next application.
  • Michele thought this type of operation may be too specific - the implementer can choose whether or not to use the context.
  • {The following comments are provided by Brad and Michele to explain a case where a simple preclusion method would be inadequate}
  • Brad:
    • In NSDL, we realized there are dependencies that may not be known between entities.  So a simple preclusion or allowance methodology does not handle all cases.  The reality is there are dependencies at various levels and between different types of resources within the system being tested.  The notion chosen in NSDL was to mark operations as complete or busy and any resource being used by a busy operation was locked from any other thread from operating on it.  This could be a register, an instrument, a scan chain, etc.  So if an operation was not complete (e.g., configuring an instrument operation that required all cycles to be completed unobstructed), the operation could block any access to its registers by any other operation.  Generally, this is handled by ensuring no other scan operations could be performed on the scan chain providing access to this instrument.  Thus, the scheduler identifies that a particular scan segment is busy and does not allow any other operation to scan data through this chain.  This notification is done with an attribute defined indicating this operation needs to complete before any further scans may be made to this resource path.  So a resource has a two state attribute of busy or not-busy that the scheduler checks before allowing other operations permission to perform their work.
    • In the example case, Register A has a level sensitive bit that starts a BIST operation.  The BIST has a finite time in which it need to run and the operation waits for that time.  Register B is another instrument that resides on the same scan chain path.  The problem comes in that writing to the start bit in Register A restarts the BIST operation.  Rescanning the values known to be last written will cause a reset of the BIST when updating Register B.  So nothing may touch Register A until the time has expired on the BIST operation, at which point Register A may be written to with an opposite value to the start bit while reading the result of the BIST operation as part of the capture sequence.  Once complete, Register B may then be accessed.
  • Michele:
    • I will try to add some details: the problem Brad and myself arose comes from the remark that instruments constraints affect the environment around them, and that this must be considered when managing them. In bottom-up terms, the constraints on a given element are propagated through the hierarchy, eventually resulting in system-level constraints or actions. These propagation and composition laws are what we should identify.
    • In our example, instrument A has a strict constraint: once a certain value is written in the TDR, no activity must be done on the TDR for a certain amount of time. In traditional 1149.1, the TDR would be alone and a "runbist" operation would take care of letting this time pass. In 1687 terms, this constraint on instrument A will be inherited by all the chain it belongs to, but instead of blocking the whole system with a runbist, it would be more sensible to act on other chains, or to simply deselect A if there is a suitable linker (ex: a SIB) among its parent hierarchy.
    • A takeaway would be the need to identify the possible constraint set, so that it can added to the System Model. In my engine, each TDR node has three fields
      1. the data to be scanned in the next iApply cycle
      2. the bypass sequence
      3. a pending flag
    • When a data cycle is triggered, each time a TDR is reached one between 1 and 2 is chosen to be added to the overall vector, based on the pending flag. So by changing the bypass sequence you can address some of the constraints (ex: rewrite the same value), but not all of them. Typically, the use case I just described above is not covered: if you arrive to the TDR of instrument A is already too late, you should have some rule that assures you the branch containing A wasn't chosen.
  • Brian suggested that a "lock all" flag might be useful.
  • Brad commented that there should be a "pending" state on Reg A, which is recognised by the manager that it can't do another op on that chain because it is busy.

6. Topic for next meeting

  • Preclusion: What gets precluded, why should it be precluded?

7. Key Takeaway for today's meeting

  • SJTAG locking is really describing locking of the software resource model and not locking of the physical hardware.
  • Locking needs to be delineated at the protocol level.
  • True locking needs to be able to manage state context of targeted resources.

8. Glossary terms from this meeting

  • 'Scheduler' (from Aug 31) is TBD.
  • Locking Mechanism.
  • Preclusion (which may then require "Allowance").

9. Schedule next meeting

  • October 26.
  • November schedule:
    • 2, 9, 16, 23, 30.  Eric expects to be absent on 9th.

10. Any other business

  • None.

11. Review new action items

  • None.

12. Adjourn

  • Eric moved to adjourn seconded by Brian. Meeting adjourned at 12:03 PM EDT.

Respectfully submitted,
Ian McIntosh