Minutes of Weekly Meeting, 2015-08-31

Meeting called to order: 11:08 AM EDT

1. Roll Call

Ian McIntosh
Carl Walker
Heiko Ehrenberg
Brad Van Treuren
Brian Erickson
Tim Pender (joined 11:19)

By Proxy:
Adam Ley
Peter Horwood
Michele Portolan

Eric Cormack

2. Review and approve previous minutes:

  • Approval of August 17 minutes (updated draft circulated 8/27/2015):
    • Correction in 5b:
      "Brad: What comes out in you comments is that we have three register types: Read/Write, Read only and Write only, and it's may more appropriate that we look at these for each register domain as it is extremely important to the tools."
      "Brad: What comes out in your comments is that we have three register types: Read/Write, Read only and Write only, and it's maybe more appropriate that we look at these for each register domain as it is extremely important to the tools."
    • Approval deferred until after Tim had joined the meeting.
    • Brad moved to approve as amended, seconded by Tim, 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 the 2014 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. ITC Participation.

  • Ian noted that we should probably start a discussion via email to see how we can tie a poster in with Michele’s presentation (assuming he is officially invited by now).  Ian will start such an email discussion in the next few days {ACTION}.
  • No other discussion.
  • [Adam by proxy]: His topic is listed as "14.2 Flexible and Extendable System-level JTAG Manager" in the Advance Program (which just went up last Wednesday), see http://www.itctestweek.org/files/2015_Advance_Program.pdf, p15.

b. Look at SIB in detail, followed by I2C.

  • Ian noted that the submission from Adam (captured in the last minutes as proxy) presented a different position from Brad over Capture within 1687 and 1149.1-2013. Adam also inferred that what Brad had titled as 'SCANSEL' was what the 1149.1 standard titles 'SEGSEL'.
  • Brad was reviewing page 115, figure 9-19 of IEEE 1149.1-2013 again and agreed that SEGSEL was the correct term.
  • {Tim joined}
  • Brad's original point was to highlight that 1149.1-2013 explicitly shows a  Capture.
  • Brad agrees with Adam’s comment that while 1149.1 does define a Capture for the SegSel cell, it doesn’t capture the current state but rather a ready-to-scan signal.
  • Ian notes that the message he took from Adams comments is that the 1149.1 situation seems to be worse than the 1687 position for us, as 1687 permits a capture that could indicate the SIB state while 1149.1 requires a capture that would not show the SEGSEL state. Brad notes that this should be a key-takeaway for today.
  • Brad comments that the purpose of the SegSel and the SIB in 1149.1-2013 and 1687, respectively, isn’t exactly the same, so a comparison as a bit like comparing apples and oranges, adding that the standards don't have a lot of explanation of the examples. 1687 defines things using ICL, while 1149.1 has to use Packages which don't have the same clarity and there's a need to make assumptions as part of the standard.
  • Ian wondered where that left us, as we'd determined there wasn't a way to read the hardware state.
  • Brad replied that SJTAG needs to manage the state of the access link selection in our software model  and we cannot depend on the hardware (another key-takeaway).
  • Brad further noted an implication when dealing with multiple domains where a task might split into separate processes or separate threads - there needs to be a way of transferring the state from Thread A to Thread B, or it is retained in some central database.
  • Ian felt that raised the question of where the Top Level Controller is again, and also noted the lower level thread/process needed to be aware that other threads might exist else the state information might be ignored.
  • Brad responded that in the new execution model he and Michele had proposed a (central) scheduler would be the master brain for topology configuration (managing when things need to open/close, and how to accomplish that); the scheduler would manage and coordinate the access links. The data that gets sent is then pushed back to the model - it doesn't need to know how it got there. Threads are coordinated in the central scheduler.
  • In response to Brad question if the group sees the difference between where we are going with this need vs. what tools do today Heiko noted that today the test engineer is essentially the scheduler that we now want to make part of the SJTAG model.
  • Brad agreed and noted that tools today may handle access links but that handling in principle becomes part of the test itself, as opposed to be a pre-condition that is not tied to the actual test.
  • Ian agreed and commented that this engineered scheduling within the tooling does not get inherited if the test is reused elsewhere.
  • Brad noted that this linked to some of Peter's proxy remarks; sometimes you just want to change an address but there's no way to make that generic, so your writing for a specific UUT.
  • Brad remarked that with TFCL he was the scheduler when he was writing the code, but TFCL proved that it was possible to decouple the data from the Access Link.
  • Brad, adding to Peter's comments, noted that vector sets themselves may have offsets as preconditions and postconditions (such as SDR, SIR, HDR, HIR in SVF) - these also need to be considered by the scheduler. It can't be defined in the SVF proper and needs to be defined externally. TFCL defines that as part of the Test Step description and wraps the SVF with the attributes.
  • [Adam by proxy]: Asks if the above should refer to "such as HDR, HIR, TDR, TIR in SVF" noting that this didn't fit his own idea of what is meant by pre-condition and post-condition.
  • [Brad by proxy]: I did state HIR, HDR, TIR and TDR.  My comment was in reference to what Peter has been describing where pre-generated vectors are reused across multiple instances of the same design where the only difference is with the multi-drop address used as the access link between the boards and extending it further to the board level where multiple instances of the same circuit module is used.  For example, I had a board that is tested with embedded TFCL where there is a circuit of a DSP with associated memory replicated 8 times on the board.  I was able to reuse the same memory test vectors for each instances by providing the HIR, HDR, TIR, and TDR offsets externally to the SVF as pre-configuration parameters for that particular test step instance.  This let me store a single copy of the SVF and gain the advantage of reuse over the 8 instances.  This is a very important feature SJTAG needs to be able to support.
  • [Peter by proxy]: In the example I gave, the PCB selection along with target chain selection was all contained in a single vector file however it would have been possible to separate out the PCB selection/chain selection to be executed as a pre-condition. I agree with Brad there needs to be some method of adding HIR,HDR,TIR,TDR data to the vectors, as it would be required if the target was at an unknown level in the system hierarchy.
  • [Peter by proxy]: We must also take into consideration, SVF/STAPL files can specify these HIR, HDR, TIR and TDR values, we need to specify how the execution engine can modify the value if required, i.e. amend value or replace it, or just play the vectors as supplied.
  • [Brad by proxy]: In my TFCL environment, it was implemented as a wrapper around the SVF/STAPL Players logic where the TFCL attributes were applied as wrapper patterns to what was specified in the SVF/STAPL.  So the SVF HDR, HIR, TDR, and TIR values were still applied to each scan along with the additional bits supplied by the TFCL attributes.  So you are correct.  We need to be able to support the features inside of SVF as defined by SVF along with the additional wrapping.  I chose not to amend the SVF values and just wrap them for TFCL.  It was a cleaner way to implement.
    It can get a bit ugly with STAPL as there is more control inside the language of what gets scanned when.  We just ensured we used STAPL in a way that supported the wrapping for the TFCL uses.  It does not work in all cases to provide the wrapping with STAPL.
  • Ian asked how we actually do all this, and inferred that Michele's demo represented one implementation and not necessarily the definitive, generic model.
  • Brad felt Michele's demo contained some assumptions that SJTAG needed to flesh out yet. 
  • Brad wanted to respond to some of Michele's proxy comments in the previous minutes (where Michele claimed to disagree with Brad), feeling there was a way to reconcile the two views:
  • The question was how does a TDR (or lowest level leaf) notify the system that it needs to synchronise with the model? Push or Pull?
  • Brad notes that a Push needs the Transaction Level Model and Michele's remarks were that there needs to be a way to post that you have an update that needs to be performed. The question is how that notification is made, post and poll or drive it through.
  • So Brad asks how we post that: Does the leaf just post and have some mark to say it's 'dirty' and needs attention that some parent can then query or post onto a scheduler so that when it gets to a parent sees that one of its leaves has a request then lets the parent handle it?
  • Brad wondered, semantically, what do we mean by a "pending request"? Is there a single interface for and instrument or an interface for each register?
  • Ian thought it would depend on how the instrument uses its registers: If the instrument state is valid only if multiple registers are loaded then the interface should be for the instrument.
  • Brad felt we could have a model that talks to an instrument but shouldn't need to know about how the instrument works.
  • Brad asked how this was different to posting to the scheduler. NSDL's trigger to sync just says "this is the moment we want a sync to take place". How do we delineate between identifying when something has changed state vs. when we need to synchronise that?
  • Brad had hoped that Michele would have been on the call today for this discussion.
  • Brad suggests that this could be a topic for the next meeting; this notification problem would be applicable to any of the access links.
  • [Michele by proxy]: I would like to respond to Brad's comment about the "pending" and "sync" concepts, as I have been working lately to boost 1687 compliance into my engine.
    • A "pending" is basically a Circuit Model attribute that originates on a given leaf and then it is propagated upwards through the hierarchy. So, yes, is can be seen as "dirty". It can have two origins:
      • a data-driven pending is the result of a register I/O operation. In 1687 terms, this would be the effect of an iApply operation: according to the standard, iWrite/iRead are just queued and take effect only when iApply is issues, while the iGet/iGetReadData return data obtained through the last iApply. So, it is an instrument issuing an iApply command that triggers a data operation. It is then the role of the manager scheduler to decide if triggering a cycle as soon ONE instrument asked for the iApply or to wait for more (wait for all leaves to become pending, have a threshold, some ageing mechanism, etc...);
      • a configuration-driven pending can be generated during preconditioning when a linker state needs to be changed. It is what enable the execution cycle to loop until the desired state is reached and perform multi-cycle configuration. Take for instance a 1500 wrapper, like the one I showed in my demo:
        1500 Wrapper
        A PDL executed on the instrument "Dynamic_0" will cause a data-driven pending, which will ultimately result in an execution cycle being triggered. during preconditioning, a configuration-driven pending will be put in the WIR by the "select method of the wrapper Scanmux (the one at the bottom of the figure), while the "select" method of the upper Scanmux will put a "pending" on the "SWIR". The result in Circuit Model terms will be the following:
        Circuit model
        The P at the SUT level will cause the execution cycle to loop, and the scheduler will gradually change the status of the Circuit Model to iteratively satisfy the Pending: at the first cycle (1)  SWIR_CTRL will be satisfied and the "P" will disappear, so in the following cycle (2) it will be the turn of WIR_reg, while finally at cycle (3) dynamic_0 will be serviced, so at (4) there will be no more pending and the execution can stop.
    • I  hope this answers the question.
  • [Michele by proxy]: To help with the discussion, I prepared a sequence showing a step-by-step resolution of an 1500 wrapper showing how the "pending" drive the execution loop without any prior knowledge of the topology. I did not put it explicitly in the slides as I plan to use them as backup slides at ITC, but all steps use exclusively the select/deselect/is_active triplet to achieve configuration.

6. Topic for next meeting

  • Scheduler and posting synchronisation notifications.

7. Key Takeaway for today's meeting

  • 1687 allows a capture with readback of the SIB state; 1149.1-2013 requires a capture but it is not a readback of SegSel.
  • Need to manage the Access Link states in our software model as we cannot rely on the hardware to supply the state.
  • Currently, the Test Engineer is the scheduler and must manage the Access Links.

8. Glossary terms from this meeting

  • 'Scheduler' requires to be defined.

9. Schedule next meeting

  • September 7 is Labor Day in US, several people expect to be absent so skip meeting.
  • Next meeting will be September 14.
  • September schedule: 14, 21, 28.

10. Any other business

  • The Newsletter was due at the end of July.
  • Al Crouch has been in contact regarding forthcoming P1687.1 effort (serial access links other than JTAG for an P1687 instrument network). Perhaps it would be a good idea to get Al on the call one day to discuss how P1687.1 and SJTAG would 'live together'.

11. Review new action items

  • Ian: Start an email discussion in the next few days to see how we can tie our ITC poster in with Michele’s presentation.

12. Adjourn

  • Tim moved to adjourn, seconded by Heiko.
  • Meeting adjourned at 12:06 PM EDT

Thanks to Heiko for providing additional notes this week.

Respectfully submitted,
Ian McIntosh