Minutes of Weekly Meeting, 2015-11-02

Meeting called to order: 11:08 AM EST

1. Roll Call

Carl Walker
Eric Cormack
Peter Horwood
Heiko Ehrenberg
Brad Van Treuren

By Proxy:

Adam Ley
Brian Erickson
Michele Portolan
Ian McIntosh
Tim Pender

2. Review and approve previous minutes:

  • 10/26/2015 minutes (updated draft circulated 10/29/2015).
    • Ian noted that there's an incorrect date on the previous minutes - 19/12 instead of 10/19.
    • no other corrections noted;
    • motion to approve minutes by Eric;
    • second by Peter; 
    • no objections -> 10/26/2015 meeting minutes approved with aforementioned correction.

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
  • 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. Preclusions: Are there any other elements in the hierarchy we need to consider for preclusions?.

  • Given that Ian and Michele both are not on the call, those on the call decided to table this discussion for a later date and instead talk about possible definitions for glossary terms;

  • 'Scheduler' (from Aug 31).
  • Brad: this refers to a software scheduler;
  • Eric: this is event scheduling, right?
  • Brad: yes; perhaps we need to add "scheduling" first to the glossary; there is a decent definition on "https://en.wikipedia.org/wiki/Scheduling_(computing)"
  • Brad: we should be able to flesh out more detail for the ‘scheduler’, coming up with the key aspects that are important for us for an SJTAG scheduler:
    • the scheduler is an intrinsic part of the SJTAG execution model;
    • ensure there are no access conflicts with resources;
    • minimizing response time (required ?)
    • minimizing latency (required ?)
    • organizing scan operations into the ready queue
    • an SJTAG scheduler would be more administrative than preemptive;
  • Eric: I think Peter brought up last week that we are thinking more of an interrupt type scheduling process;
  • Peter: yes; I may want to get a process done quickly even though the system thinks it is not a high priority process;  we probably need a non-exclusive round-robin style scheduler (allows other scheduling methods when needed);
  • Brad: yes, there needs to be flexibility and not just one fixed method of scheduling;

  • 'Locking Mechanism' (from Oct 19)
  • Eric: so, are we talking about a TDR that needs to be locked so that other processes don’t interfere with it?
  • Brad: that is one example;
  • Brad: We are not talking about the actual TDR register or placing a lock on it.  We are talking about a key that may be used as a common key between threads wanting to access the same resource.  Typically in software, the key is the address of the shared message queue.  It is a reference (e.g., the address value) being used as the key and not the message queue itself.  This assumes the reference will be the same number for each thread.  It could be the address of a scan chain object in the model or something else we need to lock.  This is what we are trying to identify as the set of resource types that need to be able to be locked.
  • Peter: are we talking about device security?
  • Brad: I think that is a separate issue; right now we are talking about assuring that a resource is used by only one process at a time (i.e. a resource can be restricted to be accessible by only a single process at a time);
  • Peter: so, we kind of need a flagging mechanism that allows us to say this resource is currently being accessed by a certain process and is not available for use by any other processes;
  • Brad: a good reference on wiki is https://en.wikipedia.org/wiki/Lock_(computer_science)
    • A Locking Mechanism is a synchronization mechanism for enforcing limits on access to a resource in an environment where there are many accesses to SJTAG resources.
  • Peter: I may want to be able to handle such locks also in a multi-task environment;
  • Brad: context needs to be preserved;
  • Brad: Our goal with the locking mechanism is to be able to leverage and reuse as much of the facilities and mechanisms already made available by the OS running on the system.
  • Peter: Right.  We don't want to reinvent the wheel if someone already has a way of accomplishing this.
  • Brad: We want to make sure we have the hooks in our standard and our primitives or functional API that provides the hooks in a standardized way to access a common locking mechanism found in operating systems.  For example, we may want to have a callable procedure called test_and_set that would be able to test if a resource is being used and if not be able to lock it up for our use and release it when done.
  • Peter: But we have to make sure it is available in a standardized way that it is able to use the OS mechanism.
  • Brad: Most of these types of software procedures have a way of disabling the interrupts so no other thread may preempt the routine while it is testing and setting the lock on the resource.

  • 'Preclusion' (which may then require 'Allowance') (from Oct 19).
  • "To exclude or prevent a given system sensitive access condition or activity". (based on http://www.thefreedictionary.com/preclusion)
  • 'Allowance'
  • "To authorize / grant a given system sensitive access condition or activity".  (antonym to preclusion)

6. Topic for next meeting

  • continue "Preclusions: Are there any other elements in the hierarchy we need to consider for preclusions?"
  • fine tune definitions as needed

7. Key Takeaway for today's meeting

  • We want to leverage as much as possible of the existing software mechanisms for locking.

8. Glossary terms from this meeting

  • None.

9. Schedule next meeting

  • November 9 (Eric and Heiko will be missing);
  • November schedule:
    • 9, 16, 23, 30.
    • (Heiko will also miss 11/16)

10. Any other business

  • None.

11. Review new action items

  • None.

12. Adjourn

  • moved by Eric, seconded by Brad;
    • Meeting adjourned at 12:01 PM EST.

Respectfully submitted,
Heiko Ehrenberg