Minutes of Weekly Meeting, 2015-09-21

Meeting called to order: 11:09 AM EDT

1. Roll Call

Ian McIntosh
Michele Portolan
Peter Horwood
Carl Walker
Brian Erickson
Tim Pender
Heiko Ehrenberg
Eric Cormack (joined 11:22)

By Proxy:
Adam Ley
Brad Van Treuren


2. Review and approve previous minutes:

  • Approval of August 31 minutes (updated draft circulated 9/10/2015):
    • No corrections noted.
    • Brian moved to approve, seconded by Heiko. No objections or abstentions.
  • Approval of September 14 minutes (updated draft circulated 9/17/2015):
    • Change "pinding" to "pending" (early in 5a).
    • Michele moved to approve as amended, seconded by Brian. 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.

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.
- Specifically, identify the requirements that differ between the static and dynamic cases.

  • Email comments carried from last week {shared}:
  • [Brad, for context] 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.
  • [Michele, by proxy] First I must point out that in my scheme the Manager is not doing any scheduling. Its role is to arbitrate access to a shared resource (the TAP(s) ) for all test algorithms. The latter are executed in parallel by the Linux scheduler, but the SJTAG manager itself is not involved. For Brad: this is because I do not use the TISA operations, but rather a traditional vector composition.
  • [Michele, by proxy] iWrite and iRead/iGet do not generate any pending because in PDL semantics it is only iApply that generates a scan operations. iRead simply accesses the value stored in the System Model, while iWrite changes the value that will be scanned during the following cycle, but it will not take effect until the next iApply.
  • [Adam, by proxy] We have to be very careful that our descriptions, here, of the PDL semantics are consistent with standards (i.e., 1687-2014 and/or 1149.1-2013).
    • While the above description of iWrite is largely correct, as is the key concept that scan operations are only generated by iApply, the description given for iRead and iGet is misleading, if not entirely incorrect … First, while iRead and iGet have some relation, they have no more relation than do iWrite and iGet. Further, most importantly, the iRead does NOT access a value stored in the System Model == rather, it sets a value in the System Model – that which corresponds to an Expected value for data to be scanned out at the next iApply.
    • Let me explain a little bit more at first principles:
      • iWrite and iRead, in the Tcl sense, are both like “set” = but, of course, they operate not on Tcl variables, but on the iJTAG system model
    • while,
      • iWrite sets values for data to be scanned in at the next iApply
      • iRead sets values for data expected to be scanned out in the next iApply
    • on the other hand, iGet, in the Tcl sense, is like a “$” evaluation (sorry if that’s not the right CS term) = but, of course, it operates not on Tcl variables, but on the iJTAG system model
      • iGet –si returns the values for data to be scanned in at the next iApply
      • iGet –so returns the value for data that WAS scanned out in the previous iApply
      • etc.
  • [Brad, by proxy] Good point about the manager being  a manager of a shared resource (the TAP).  I used the term scheduler loosely because it is what Michele called it in some slide from the past.  He is right that it is not scheduling, per se, but is instead managing a coordinated access to a shared resource.  It could be thought of as some type of scheduler, but the difference is the flow of allowance is not guaranteed to be repeatable depending on how Linux schedules each thread accessing the resource.  So Michele is correct that it is dependent on the Linux scheduler's timing and not the manager's timing.
  • [Michele, by proxy] Thanks for the comments and clarifications Adam, it is true that I am being a little too easygoing with the PDL terminology : in my discussions I focus on writing and reading data to/from instruments. For iWrite it is quite straightforward, as it is clearly defined.
  • [Michele, by proxy] On the other hand, PDL 0 for 1687 (and I suppose it is the same for 1149.1-2013) is not really interested in the value of TDR registers, but rather in comparing them with expected values. So iRead sets an expected value for a register to be compared at the next iApply cycle.
    PDL 1 has an iGetxxx "family" to retrieve information:  
    • iGetStatus and iGetMiscompares to get the number of miscompares
    • iGetReadData is the only command that actually returns the data
  • [Michele, by proxy] So, iGetReadData is the command we should consider as specular to iWrite. I tend to use "iGet" to keep it short, but it can probably being confusing with 1149.1-2013. It is true we should probably decide  on a clear nomenclature.
  • [Adam, by proxy] Thank you, Michele!
  • [Adam, by proxy] I agree completely with your statement about PDL 0 and affirm that it is the same for 1149.1-2013.
  • [Adam, by proxy] To reiterate,
    • iRead sets an expect value for a register to be compare on the next iApply cycle
    • of course, for such compare to be effective, it is implied that the register will be, somehow, selected and operated (scanned) during the next iApply cycle.
  • [Adam, by proxy] Thanks, too, for your clarification about iGetxxx for 1687-2014 versus iGet –xxx for 1149.1-2013.
  • [Adam, by proxy] In that case, I was guilty of adopting the shorthand, when, since I was striving to dispel ambiguity, I probably should have been more pedantic!
  • [Adam, by proxy] And, again, thanks for pointing out that the “iGet” keywords, whether for 1687-2014 or 1149.1-2013, all stand at level PDL 1, which means that they stand outside the set of keywords that can be exported to conventional test vectors (stepwise stimulus/expected response strings).
  • [Adam, by proxy] Now, I had to look up “specular” (to confirm its meaning before commenting on your penultimate paragraph. In the end, I think that it makes sense if we consider iApply to be the “mirror” with iWrite presenting the state of the system model before the iApply (the “actual”) and the iGetReadData reflecting the state of the system model after the iApply (the “reflection”).
  • [Adam, by proxy] On the other hand, back to the point above for PDL 1 versus PDL 0, I think the bias should generally be towards using PDL 0 to the exclusion of PDL 1, unless the latter is incontrovertibly necessary.
  • [Michele, by proxy] As Brad knows well, I am far from being the biggest supporter of 1687's software infrastructure, but it is there to stay and we need to take it into account, otherwise it will be too difficult for newcomers to understand SJTAG.
  • [Michele, by proxy] This is especially true for PDL: its semantics as clarified by Adam describe a low-level protocol that will be implicit for most test engineers in the future: iApply causes a scan cycle (data cycle in our terms), iWrite/iRead set values and constraints for the following iApply cycle while iGetxx returns data obtained from the last cycle.
  • [Michele, by proxy] We can fix this protocol and work on it, and this will assure compatibility with 1687 or 1149.1-2013 algorithms. This does not mean using PDL as a language per se, but just a data exchange protocol. I, for instance, define an API interface with C/C++ functions having these three names and prototypes coherent with the instruction definitions. So, any program written in C/C++ and using this API will be coherent with a pure-PDL implementation.
  • [Brad, by proxy] The point I was making about iWrite and iRead/iGet is that the model has to be marked as "dirty" at some point and that something needs to be done by that instrument when the iApply is executed.  Yes, the iApply is the only statement that performs the scan operation, but the scan is being done with the data already posted in the model.  That posting was done by the iWrite or the request for a capture is done by the iRead/iGet statements.  The iWrite and iRead/iGet are manipulators of the circuit model and not the SUT.  They are the triggers that something needs to be done for this instrument when an iApply statement is reached in the PDL.
  • [Adam, by proxy] Here again, let’s please be clear – iGet does NOT post a request for capture – it works on the data in the system model as it presently stands, and nothing more.
  • [Brad, by proxy] The iApply is responsible for two things: 1) Make a request to the manager that an instrument needs to be synchronized, 2) Apply the synchronizing data to the SUT when the manager gives control to that instrument.
  • [Adam, by proxy] While I’ll beg off on claiming to understand this discussion fully, in my mind, at least, it begs the question = are we considering merging iApply across multiple PDLs??
  • [Michele, by proxy] As for you other comment yes, we are considering merging (or I would rather say, synchronize) iApply over different PDL executed in parallel. It is quite different from 1687, where iMerge would flatten everything into one PDL file.
  • [Adam, by proxy] Finally, I don’t get what you’re saying about iMerge – I think we should discuss that offline (perhaps, soon, over a beer in the land of Disney? wink
  • [For context] 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.
  • [Michele, by proxy] I do not understand this comment, a live discussion is probably the best.
  • [Brad, for context] We need to be changing the SUT's state over time so we need to have the iterative process.[Michele, by proxy] Iterations are needed to change the state of the SUT to synchronize it with the state on the System Model. That said, not all the iterations I showed are forcefully necessary: you can optimize the code and avoid some of them while having the same functionality, but I believe that mentioning them explicitly makes explanations easier.
  • [Brad, for context] 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).
  • [Michele, by proxy] The pull model comes more natural because it follows JTAG principles: if you want to allow also push notifications, we need to understand exactly how they would be handled: would it be just software, or would it allow specific hardware (ex: interrupt lines)? Another point is also that pending could be prioritized, so that during configuration some instruments would be preferred over others.
  • [Brad, by proxy] I think we can only support one or the other method.  Pull is more natural, but also more inefficient in execution as it requires polling of all the active and near active nodes to determine if a synchronization is pending or not.  The Push model I was referring to does not involve the SUT, but instead is merely a notification mechanism from the source of the change.  Thus, if an instrument is altered by an iWrite statement, it will post that it needs to be synchronized.  That is usually done via callbacks registered with the instrument for what objects are interested in this bit of information.  This is the pure publisher/subscriber design pattern.  This optimizes the performance of the model code in that it eliminates the need to poll every node to check for their status on whether they have pending data to be synchronized or not.  Likewise, the iRead and iGet would have their own list of subscribers.  This has nothing to do with hardware, but is instead a computer science tool to improve the operation of code.  This implementation detail may actually be the differentiators between tool vendors in their performance of execution.  So the implementation detail may not actually be defined by the SJTAG standard and just the concept of notification in the standard.
  • [Adam, by proxy] These expressions of pull and push methods don’t really line up with how I had thought those terms to be used in the past. One problem may be that, where an agent might pull or be pushed, then another agent might be the one pulled or doing the pushing … so we need to either state emphatically what agents are involved, or we need to use these terms on a common basis – whether that be the leaves or the top of the hierarchy (or otherwise), but define it clearly and be consistent ...
  • [Brad, by proxy] To give example of the difference between push and pull you can reference the following concepts that are computer science design patterns used for such cases.  They each have their benefits and consequences and it is very dependent on the overall intent of the architecture.  Neither is correct or wrong.  It comes down to what strategy makes sense for the intended architectural purpose.
  • [Brad, by proxy] These are just two patterns of a whole library of patterns that describe solutions to the problem in different ways.  It all comes down to who is the initiator of the operation.  In one case it is the element that notifies of the event (its change of state) that has taken place on itself.  The other is the observer needing to know if the state of the element has changed at a given time in the control flow and asks the element for its state.  Therein is the difference between push and pull model for messaging communications.  These patterns do the best, I think, at describing the consequences of each method.  It is all about trade-offs and what best fits your architectural performance and needs.  This is why I said we may not want to define the method used and leave that as the way tool vendors are able to differentiate themselves from their competition.  As SJTAG, we need to ensure we describe what needs to be passed and the point in time of processing the control flow the data needs to be available.  How it gets there is really outside the scope of the SJTAG standard.
  • [Brad, by proxy] Personally, I am not convinced that PDL (whether 1149.1-2013 or 1687 version) is the magic language that describes all that we need for SJTAG.  The analysis of iWrite, iRead, iGet, iScan, and iApply are just examples of problem domain usage and we need to clearly understand the semantics and the benefits and consequences of such commands in the overall flow of an SJTAG transaction.
  • [Brad, by proxy] What further compounds our problem is the implementation of iGet is similar in concept between these 2 standards, but the language implementation is different where one uses a single command and different arguments to define the semantic behavior of that command and the other uses explicitly different commands to define each semantic case.  This is one of my reasons for not being convinced "PDL" is the answer as one has to ask the question, "What is PDL?"  Thank you, Adam, for keeping us focused on the semantics of the problem space.
  • [Adam, by proxy] Thanks Brad! I think you just sent me to school! (but that’s cool!)
  • [Adam, by proxy] It’s clear that I need to undertake a review of (at least) the references that you have kindly provided in order to comment more usefully on the architectural aspects …
  • [Adam, by proxy] That said, I’m glad that (at least), you found my comments on PDL to be useful smile
  • Ian: Today's theme was the difference between static and dynamic cases but does anyone want to add to these comments?
  • Michele: Everything from the emails is there.
  • Peter: On the static versus dynamic, you can have a static set of vectors that you apply to the board, or you can generate vectors on the board from PDLs, although we seem to be proposing our own procedures for that, or they can be generated on a remote PC and delivered locally by a dumb player, so there are really three cases.
  • Peter: It depends on the resources available: You can't mandate that you'll always have a full blown PC with Linux, tools, etc., or you'll cut a lot of people out.
  • Michele: Yes, the final application environment will influence what you can do. Maybe a takeaway is that we could define a minimum environment and the features that can be supported by it.
  • Michele: There could be classes: Minimum, intermediate, full with increasing feature sets.
  • Michele: there are two types of dynamic to consider: The simplest is to do with flow control and the delivery of the vectors, the other is to do with topology and accessing chain segments.
  • Michele: You could have some richer form of description that allows you to arrange the topology but the resources needed to use that richer description would cut people out.
  • Ian: Peter, could you clarify your three cases you mentioned earlier?
  • Peter: Sure, you can deliver vectors to the board, that's the most fundamental thing and something you must be able to do. Then you can use PDLs to generate vectors on the board and thirdly, you can use PDLs to generate vectors on a remote system - that could be complete vector sets or individual vectors that are applied one at a time and the next vector might depend on the result.
  • Ian: That reminds me of a slide we had for XBST and EBST - I'll try to look it out.
  • Michele: The topology dynamic is about being able to adapt to the system. When you want to change the flow it's maybe what data you're collecting from the system at that moment.
  • Michele: What came out in those emails is that PDL0 has no knowledge od the data returned, it is only concerned with delivering vectors. This is complementary to what Peter was talking about.
  • Peter: We also need to know what units are populated in the system, but don't want to mandate a specific memory device. So maybe we just require a text file with the data that can be fitted into the hierarchy tree.
  • Ian: We've talked in the past about storing configuration data on the UUTs, and Brad's JTAG Plug'n'Play was a particular form of that, or having some form of auto discovery. Many current systems won't have any obvious means to support identification.
  • Peter: Most modern boards will have locations where an ID can be stored.
  • Ian: Do we want to specify a text file or just define the data that should be available, and leave it open to how it is presented, so it could be in a device or a file?
  • Michele: I'm thinking of USB where you just get some identifier then you can look it up and find the right driver. I think we need a way to identify the hardware but maybe it's a bit too early to do that.
  • Ian: I know we have cases where we could have dozens of near identical boards in a fully populated system, but often we'll be doing lab testing with only a few of those installed. You don't want to test empty slots, so you'd like to have the tests adapt to what actually there.
  • Michele: If a test is board-to-board then you need to have both boards.
  • Michele: We are already considering a platform where you do some vector manipulation.
  • Ian: Once we have a system deployed in the field, then notionally it is a known configuration. But with redundant and fault tolerant designs, a board could take it self out of service, and simply not power up during test and appear to be absent.
  • {Ian shared XBST - EBST slide}
  • This shows that the Test Manager, the TAP Controller, etc. can be in different places in different cases. When SJTAG started it was considered that there was simply XBST and EBST, but this showed there was a kind of hybrid in between.
  • Michele: You could add a fourth case to that. Instead of the last one with the off-line analysis, the analysis could be done on the board if it has the right resources.
  • Michele: In all these, the SJTAG features are the same, it's just the locality and partitioning that is different, so we should be able to come up with common SJTAG features that we can access.
  • Peter: Like an API stack where the lowest level is a basic scan?
  • Michele: Yes.
  • {The following are post-meeting proxy comments, but follow on from the previous proxy remarks at the top of this section}
  • [Adam, by proxy] I’m not aware that 1687 defines a software infrastructure, per se.  While I suppose I may get your gist from reading between the lines, I should ask: can you be more specific? And expository?  That is, can you specifically identify the elements of 1687’s software infrastructure to which you refer and describe the reasons that it (they) fail to garner your support?
  • [Michele, by proxy] What I meant is the software part of the standard, that is to say ICL and PDL, which in my opinion are too short-sighted and while they can be used to address the immediate problems for today, I do not believe they will stand to the test of time. That is one of the reasons I never tried and formalized a language for SJTAG: the domain is still too fuzzy to give a precise modelling. This is some of reasons why I see problems in the future:
    • the main issue I have with ICL is that it is a structural description. At the end of the day, it is just an HDL-lite: you take the Verilog/VHDL description, you simplify it and there it is. There is no real added value, and you are still constrained to instantiating the main cells and their connections. This seriously limits future extensions, as you can only build on the main elements and you cannot really describe the behaviour of your system. Having a tool understand the behaviour from the structure can rapidly become a formidable task: I see how much my colleague doing verification struggle to scale their algorithms to real-life circuits without having computational complexity kill them. Moreover, this means that in ICL you are exposing a lot of your DfT infrastructure and the underlying component, and this can e an issue for IP-based design as third-party providers might not want to give you so much information. Reverting to pre-compiled vectors kinda kill the whole interest of 1687 and 1149.1-2013, because you forfeit the possibility of system-level optimization and reuse. A language is a double-edged sword: it allows you it describe something, but in the meantime it makes things outside of it seem impossible, while in reality they might not be.
      The whole point of my 1687/SJTAG engine is to demonstrate the power of this strategy by showing how a back-end putting these notions in action can solve most of the open issues, and then use this experience to extract the basic primitives and then come back to an optimized language approach: this is why I tried some UML modelling.
    • PDL is IMHO just too low level. It is really defined only to shift vectors and make basic comparisons with expected data. The qui-pro-quo we had on iGetxxx shows how extracting data is not really its main feature, and how to put it into use in more complex algorithms is not really explored. At most 1687 allows you to obtain a vector as a string: before using it you have to convert it to your internal representation (char? int? array?), and then back to be able to have TCL procedures. But TCL is not really adapted to this domain for a series of reasons, the main I see are:
      • it is intrinsically single task, so expressing the behaviour of a complex systems composed of independent sub-systems would be fare from trivial;
      • it requires an interpreter to be executed, and you are imposing a really specific environment.
      • it is a scripting language, not really a programming one. It excels at "hacking things out" fast and to connect together different modules, but it is not really made to do more than this.
    • For instance, I am working with some mixed-signal colleagues who want to use 1687 to access some deeply embedded instruments to retrieve some data, process it with their specific algorithms and obtain commands/tuning for other instruments. If I told them they had to port their algorithms in TCL they would have thrown me out of the window!
  • [Michele, by proxy] But of course these are just some of my thoughts!
  • [Brad, by proxy] Adam, I hope this will give you and Michele some basis for your conversation at the table in Disney.
  • [Brad, by proxy] I think the greatest concern I have with PDL is the variability in implementation I see in the community.  There are some that are using strict PDL-0 as a description language of the behavioral model.  They then use it to compose into the tooling of the native languages of the test equipment (e.g., STIL, CTL) and the execution model becomes a vector based scan and compare application like they have always done using the equipment's native environment.  Then there are others, some of whom are advertizing commercial tooling now, who use PDL-1 as the execution language directly to be able to make the dynamic decisions that are required for more advanced applications that rely on feedback from the UUT to decide what path in the program to take next.  These are still simple applications in the SJTAG sense, but the key is they are attempting to use Tcl as the execution platform for instrument control.  So again I have to ask, "What is PDL?"  Is it a description language or an application execution language or both?  Just because PDL is part of two standards finds it is not used in standard ways.  This is dangerous for SJTAG as we are needing to define an application framework for more than just instrument access via JTAG and the coordination of accesses with multiple instruments over a specific time period.  1149.1-2013 defines PDL as, "PDL is defined in this standard to allow IC and IP providers to document vendor-independent test data register access procedures that are callable from other test languages. It is not intended to be a full board or IC test language."  (NOTE: "not full board or IC test language" and the point "that are callable from other test languages")  1687 defines PDL as, "The purpose of PDL is to provide a means to define procedures to operate an instrument. These instrument procedures are documented by PDL in terms of stimuli and expected responses for the ports and/or registers described in the ICL module for the instrument."  However, 1687 also describes PDL-0 as, "PDL level-0 is a pattern specification format that allows specification of procedures that can be called programmatically to operate instruments. PDL level-0 has two classes of commands: setup commands and action commands."  The term "can be called programmatically to operate instruments" would seem to indicate that PDL-0 is really an application language of some form and not just a documentation of behavior.  Others have argued, during the 1687 WG meetings, that it is an execution languages which operates on the model of the instrument and not necessarily on the actual physical instrument.  So that leads to the further confusion.
  • [Brad, by proxy] Regarding iMerge, this command tries to enlighten the retargeter as to what code is independent and may be applied at the same time without contention.  That is subtly different than concurrency.  iMerge does not control the concurrency, per se.  Both standards agree that the command is a mechanism for the programmer to use to inform the tooling of places a limited set of commands may be executed in parallel.  "The iMerge command is used to identify which called procedures could be optimized to minimize the number of scans required." (1149.1-2013 C.3.9.1)  "The purpose of the iMerge command is to expose potential parallelism in iProc execution." (1687 7.9.18)  Both standards limit the command set allowed to be used inside an iMerge block.  I think it is key to note what 1149.1-2013 has to say regarding the requirement of the concurrency.  "The primary requirement for merging is that the end results of merged scans be the same as the results without any merging." (1149.1-2013 C.3.9.1)  The flattening aspect Michele is referring to has to do with the description of the semantics of the rules as described in 1687 and not necessarily mandated as the only approach.  1687 states, "iMerge indicates that a set of iCall commands may be first flattened and then merged (only iCall and iNote are allowed in an iMerge block of an iProc). A flattened iCall has all its Prefixes, Argument substitutions, and iCall statements recursively substituted for the literal equivalent (see iCall semantic rules). Hence it consists of a flat, linear sequence of just the basic setup/action commands with literal names and numbers. Note that the flattening approach is just a model to describe the semantic rules for merging. Actual implementation of merging may use different approaches, especially when considering merging for PDL-1."
  • [Brad, by proxy] In computer science, concurrency, on the other hand, is the direct coordination of the execution in parallel.  A definition for this is, "In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other." (https://en.wikipedia.org/wiki/Concurrency_%28computer_science%29)  A more general definition would be: accordance in opinion; agreement: cooperation, as of agents or causes; combined action or effort. simultaneous occurrence; coincidence: (www.dictionary.com)  The difference from iMerge in what Michele describes, as I see it, is the informing vs. the actual execution mechanism for providing the concurrency using traditional computer science proven mechanisms without needing the programmer to hint at what "might" be possible for concurrency.  This is why Michele and I presented to industry this alternative execution method to reveal the problems with the current approach and how computer science has already solved this problem for many other applications.  We need to look at how to apply such methods for SJTAG that clearly provide a solution and not just a hint.
  • [Brad, by proxy] The PDL iMerge approach requires the integrator of the code to understand what can be merged and cannot be merged when trying to coordinate multiple instruments.  This may require alteration of the PDL provided by an instrument provider to allow the code to be merged.  This may not be possible in all circumstances.  It is far better to let the tooling do controlled merging using known techniques that already exist in other problem domains.  This is also the value add tool vendors may provide in their tools.  My personal opinion, that I aired during the 1687 meetings, is iMerge is a hardware designer's attempt to define a software problem space.  It falls short of the real potential required for instrument control.
  • [Adam, by proxy] Thanks to you, both, Michele and Brad, for a heaping serving of food for thought! (it’s going to take me a while to digest …)

6. Topic for next meeting

  • Finalise poster for ITC.
  • 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

  • SJTAG could define an minimum environment and detail what features can be supported within it.
  • Within the XBST/EBST spectrum the SJTAG features are the same and only location/partitioning change.

8. Glossary terms from this meeting

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

9. Schedule next meeting

  • September 28 (Michele will be absent).
  • October schedule:
    • October 5 is immediately before ITC so there will be a few absences. Meeting cancelled. 
    • 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 (after ITC).
  • ITC is only a couple of weeks away.
    • In the absence of any other suggestions, Ian proposes to make minimal changes to last year's poster, to reference Michele's invited talk.
    • Heiko should be able to get the poster printed provided he gets the file in the week before ITC.

11. Review new action items

  • Ian to circulate revised ITC poster.

12. Adjourn

  • Eric moved to adjourn. Peter second. Meeting adjourned at 12:03 PM EDT.

Respectfully submitted,
Ian McIntosh