Minutes of Weekly Meeting, 2015-09-28

Meeting called to order: 11:07 AM EDT

1. Roll Call

Ian McIntosh
Eric Cormack
Brad Van Treuren
Carl Walker
Brian Erickson
Tim Pender
Heiko Ehrenberg

By Proxy:
Michele Portolan

Adam Ley
Peter Horwood

2. Review and approve previous minutes:

  • Approval of September 21 minutes (updated draft circulated 9/24/2015):
    • No further corrections noted.
    • Brian moved to approve as amended, seconded by Carl. 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.
  • Ian to circulate revised ITC poster. 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. Poster for ITC

  • Ian had circulated an updated poster, adding a reference to Michele's talk and the QR code.
  • Heiko asked if the PDF would print at 36" x 48". Ian said he believed the paper size was set to those dimensions and Eric confirmed this.
  • As there were no further suggestions, the draft was accepted. Heiko was happy to use the PDF and did not need the original Publisher file from Ian.
  • Bill had asked for a title for the poster, having allocated a slot in the Thursday poster session.
  • Heiko noted that there were two poster sessions this year, on Wednesday and Thursday and worried that there may not be many people left for the Thursday session.
  • Ian had suggested simply using "System JTAG Initiative (SJTAG)" as the title. Brad asked if it should include "IEEE" to show it was part of the standards/TTSC activity.  Ian commented that he was unsure of the group's exact status since Saman Adham replaced Rohit Kapur as TTSC Sponsor Chair. Ian has had no contact with Saman.
  • Brad moved to adopt Ian's proposed title, seconded by Eric, no objections.
  • Ian had made minor updates to the SJTAG brochure and noted that on the two occasions he attended ITC he took a bundle of these to hand out.
  • Heiko asked if many were taken. Ian replied that a small number were picked up during the poster session but that he always left a few near the poster outside the session and a couple more were picked up that way.  Heiko noted that he could leave some in the Goepel booth so they were available before the poster session. Brian suggested catching Tony Sparks to get some in the JTAG Technologies booth and Brad suggested passing some to Adam for the Asset booth.

b. Scheduler and posting synchronisation notifications.
- Specifically, identify the requirements that differ between the static and dynamic cases.

  • Email comments carried from last week {shared}:
  • Michele, by proxy] Brad pointed out one of the main issues in 1687'software part: most of it has been developed by hardware specialists, trying to add support for the new features they needed. Unfortunately they did not notice that many times they were just reinventing what Computer Science already did, and sometimes fell into the same pitfalls.
  • [Michele, by proxy] For instance, iMerge wants to exposes parallelism, and point out were code "can be merged".  As Brad points out, this not always easy, so CS usually does the opposite: assume that everything can be executed in parallel, and provide the programmer with constructs to protect "critical sections" that can't. It might seem a detail, but this change of point of view makes things much simpler, as the programmer can easily understand the critical parts.
  • Brad: Do you want to provide a hint to the tooling on where merging can occur or define the protected sections that must be performed sequentially?
  • Ian: From my distant experience with real time software, and working with mutual exclusion zones, data pools and pipes, I can see why Brad and Michele make the case they do.
  • Brad: The question is how you define the mutual resources and the resources used by the lock mechanism. That's why 1687 looked into iMerge.  The problem there is that it's harder to re-use code and you have to re-write what was supplied for each case.
  • Brad: Some registers can be updated simultaneously, others have to be written sequentially.
  • Brad: Are we talking about procedures for a single instrument or for multiple instruments?
  • Ian: I have probably assumed that we saw multiple instruments as more in our domain. That said, maybe we need to look at a single instrument first, but then we could overlook something necessary for multiple instruments and paint ourselves into a corner.
  • Brad what I see in 1687 is that the merge is happening in the higher level calls. Maybe we need to realise that we're not controlling the low-level locking controls, but acting on some higher level.
  • Brad: Who is doing this? Is it the instrument provider or the integrator?
  • Ian: Traditionally, these would always be done by the integrator.  I think there's little incentive for the instrument provider to think outside the device.  Probably only the integrator can know the use cases.
  • Brad: I'm inclined to think of disallowance of what can be done rather than allowance. It seems easier to say "don't run these things concurrently" than to say what you can do. Since the simplest case is to serialise everything then there's scope for tool vendors to offer efficiency by using more concurrency.
  • Ian, Heiko, Eric: Agree.
  • Ian: This seems like a point where we can raise Michele's proposition {email of September 24, shared}.
  • Brad: Preclusion vs Allowance means there is only a subset of 1687 and .1-2013 that we can support - iMerge isn't something we'd support, although the operation that Michele details are OK.  We're really just tightening up on the iRead and iWrite.
  • Brad: Do we want to be more dynamic - not just setting some value with a write but allowing for the possibility of a read that influences what gets written?
  • Brad: PDL-0 can define an iRead but what is the behaviour of the tool if you have a mis-compare? This leads you to translate into the language of the tooling where that behaviour is defined.
  • Ian: I never felt PDL was meant to be used as literal code, just a model description, but I see signs that some people want to use it directly.
  • Brad: It was meant to be a description especially at PDL-1 but could also be used in a translator.
  • Brad: TCL was something that ECAD and device tools people understood.
  • Ian: I see it as a scripting language, to automate steps in a toolset, not a modelling language.
  • Brad: But it can be made to work that way.  It's probably the simplest forma of a language that you can augment.
  • Brad: Do we need to take a vote on Michele's proposition?
  • Ian: I think that given some of our discussion today that wouldn't be fair until Michele is on the call or at least has had a chance to comment, so I'd defer that until the next meeting, which will be in two weeks time.  

6. Topic for next meeting

  • Feedback from ITC.
  • Review Michele's proposition of September 24.
  • Preclusion: What gets precluded, what are the locking mechanisms?

7. Key Takeaway for today's meeting

  • Two bases for merging: What may be allowed or what may be precluded.
    • Preclusion appears to offer more flexibility for tool vendors to add value.

8. Glossary terms from this meeting

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

9. Schedule next meeting

  • October 12 (No meeting October 5 due to proximity to ITC).
  • October schedule:
    • 12, 19, 26.

10. Any other business

  • The Newsletter was due at the end of July.
  • Try to get Al Crouch on call re 1687.1.

11. Review new action items

  • None.

12. Adjourn

  • Brian moved to adjourn seconded by Eric. Meeting adjourned at 11:56 AM EDT.

Respectfully submitted,
Ian McIntosh