Minutes of Weekly Meeting, 2014-03-03

Meeting called to order: 11:06 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Michele Portolan
Peter Horwood
Carl Walker (left 11:53)
Heiko Ehrenberg
Brad Van Treuren (joined 11:08)

Adam Ley
Brian Erickson

2. Review and approve previous minutes:


  • Updated draft circulated 02/25/2014.
  • The status of the action from the preceding week had been omitted (action complete) and should be added.
  • Eric moved to approve with the above amendment, 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 - Circulate voting invitation for reaffirmation of officers. - 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. Group Officers - Reaffirmation results.

  • For Chair (Ian): Motion to reaffirm by Heiko, seconded by Adam: Eight votes of approval, one abstention.
  • For Vice-Chair (Heiko): Motion to reaffirm by Ian, seconded by Adam: Eight votes of approval, one abstention.
  • Ian and Heiko are both reaffirmed in role.

b. ETS'14 proposal

  • Michele has circulated "draft 1" and "draft 2" versions of the paper.  Ian had noted one minor typo in draft 2 but otherwise there were no further comments. Brad noted that he hasn't had time to read over draft 2 yet but will do so in the next few days.

c. Newsletter

  • Brad has prepared text around three of the four pictures so far, and expects to complete the fourth in the coming week. Current size is around 3½ pages and will probably be 4½-5 pages when complete.

d. Brad/Michele - Presentation on Domain Specifc Languages

  • Slide set for reference: http://files.sjtag.org/Brad/NSDL_Process_Flow.pdf
  • {Chairman's note: It is rather difficult to provide a detailed summary of the presentation here - partly because the slide set Brad used for the first part of the presentation differed from the reference set linked here, so the slide numbers in my notes don't always match up (I've tried to map as best as I can to the slides actually used), but also because the oral commentary contained far more than can easily be captured in summary notes.}
  • This was a presentation given to the P1687 group by Brad and Michele in November 2008.  This presented NSDL as an example of a Domain Specific Language for P1687-type instruments, a Domain Specific Language being a common point that may be adapted to the preferred language of the tool vendor.  The ideas also apply to boards and systems as many of the same "nouns" and "verbs" exist at those higher assembly levels.
  • There is a unified process flow {slide 19} which starts with the Model Composition Process where a circuit model is built up from netlists and library data, and then moves on through Instrument Access, Vector Generation and finally Analysis of Results.
  • In Model Composition {slide 33} netlists and BSDLs are typically used to create the model.  If there are add-in instruments then they need to be described and that could be by PDL, ICL, BSDL package extensions, etc.  That could then be pre-compiled into an intermediate form, e.g. XML. Rather than define everything up-front, for compactness you can preselect what instruments and operations you intend to use and import only those.
  • The data in the intermediate format augments the data in the native model in the toolset.
  • In the Instrument Access Process {slide 23}, any required preconditioning or configuration is detailed.  Having determined what operations are to be performed you need to ask whether this is to be done interactively.  If not, then we can pass on to the retargeting, along with any user defined constraints that determine how the retargeting should behave. Most tooling wont actually support interactive behaviour; debugging is typically the closest thing but not quite the same as changing flow based on the result of a test action.
  • Vector Generation Process {slide 24}: Creates the raw vectors applied to the hardware, having already been through the retargeting process.  This could produce SVF, STAPL or use a tool native vector language.
  • Vector Application and Analysis {slide 25}: Vector are executed and result collected in a log. This is (intentionally) similar to the demonstration shown by Peter and Adam at the 2006 EBTW.
  • In a typical system-level embedded application {slide 5} you will have a board designated as the Controller with a Diagnostic Manager operating alongside a Diagnostic Agent on each of the testable boards and can treat the diagnostics for any embedded application just like any other "plug-in".
  • SJTAG Integration Role {slide 6}: Some of the more recent standards were still emerging when this slide was prepared, and newer ones have come in (the "hills" in the background at the top represent the most far off items).  The intent is to decouple the languages from System Diagnostic Interface.  There needs to be some form of "player".
  • NSDL Instrument Description Model {slide 35}: Order the procedures - maintain a repeatable, ordered flow whatever language is used.  Additional consideration is what you need to do for concurrency.
  • Model Elements {slide 36}: An inference of the usage can be made from the Syntax Tree - is this something we can use interactively or is it only available in "batch mode". It is easier to parse the syntax tree if it is already tokenised.  You can check that referenced procedures are defined.
  • Procedural Elements {no comparable slide}: Referred to port assignments and noted that PDL's iapply is loosely similar to HDL's iwrite.
  • Dynamic Programming Languages {slide 43} are often referred to as "scripting languages" and are interpretive like Tcl and Python.  They can do error checking but it is deferred to run-time: Tcl needs to play it before you can do a semantic check, but you need to check it before you apply it to the hardware.  Users can add language extensions but the byte code can't always understand that.  Typically, there is a need/expectation for error handling that is not always written.  SWIG and other open source tools are often used as code generators.
  • Relationship between Instrument Description Model and Dynamic Programming Languages {slide 44}: Tool vendor creates their own circuit model.  Device vendor can really only contribute model elements if a standard language is used.  In embedded applications, it's always good if you can reduce the amount of code to generate.  An intermediate language could have an API that can be attached to vendors tools.
  • iJTAG S/W problem statement {slide 8} gives four alternate views on porting code between Instrument Provider and the Chip Integrator:
    1. Burden on the Provider to support all language options
    2. Burden on the Integrator to support the Provider's language on all platforms
    3. Ecosystem, where all parties try to support all options
    4. Transfer from Provider to Integrator is via a common intermediate language
  • SWIG can be used as an interface wrapper.  May be a plug-in to the tooling or a plug-in to the engine playing the code {slide 9}.
  • LabView model {slides 15, 16}: Some people saw the LabView model as something to aspire to - you have an infrastructure where you don't care what the instrument is, you just know that they have a common interface.  Uses a queued state machine.  Instruments need to advertise the registers that they use.
  • {Carl left}
  • LabView and P1687 differ {slide 17} - For LabView all instruments are represented by registers, and you can't get that pure abstraction in P1687.  P1687 needs modelling of the access path as it may vary depending on the state of other instruments - not an issue for LabView.
  • Flexible Command Interpreter (Design Pattern) {slides 34, 37}: Illustration of how applying this design pattern offers an extensible language interpreter.  Some language translations offer near one-to-one mapping between languages, as shown by the NSDL to C++ example, hence it should be possible to translate any Domain Specific Language in this way.
  • Ian offered the anecdote of his former C/C++ lecturer who had created a header file of macro substitutions that allowed him to write what was essentially Pascal code but build it using the C compiler.

e. Moving forward:
- How has Scope and Purpose changed? See http://www.sjtag.org/ home page.
- Continue with 'Purpose'.
- Can we outline a hierarchy/structure of SJTAG standards? See Heiko's additional notes from BTW in the previous minutes, Brad's email of 12/09 and Ian's email of 12/31.

  • Not discussed

6. Key Takeaway for today's meeting

  • It is possible to translate from an intermediate Domain Specific Language to a language preferred by the tool vendor..

7. Schedule next meeting

  • Next Meeting: March 10 (11AM EDT, 3PM GMT).
  • March schedule:
    10, 17, 24, 31 - Note: March 17 is St Patrick's Day, US daylight saving begins March 9 while British Summer Time begins March 30.

8. Any other business

  • None.

9. Review new action items

  • None.

10. Adjourn

Eric moved to adjourn at 12:13 PM EST, seconded by Peter.

Respectfully submitted,
Ian McIntosh