Minutes of Weekly Meeting, 2015-06-15

Meeting called to order: 11:06 AM EDT

1. Roll Call

Brian Erickson
Eric Cormack
Brad Van Treuren
Michele Portolan
Heiko Ehrenberg

By Proxy:
Adam Ley
Peter Horwood

Excused:
Tim Pender
Ian McIntosh
Carl Walker

2. Review and approve previous minutes:

Approval of June 8 minutes (draft sent June 8, pending update):

  • Any corrections?
    • None advised so far.
  • Michele submitted additional notes inline in a reply to the draft minutes on June 9 (last Tuesday)
  • Brad  submitted additional notes inline in a reply to the draft minutes on June 15 (today, prior to this meeting)
  • Heiko proposed to defer the approving the minutes until next week after Ian is able to see the updates provided.

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: Write up process for linking discussions between email, forums and meetings. ONGOING
  • Michele: Create description of the bottom-up approach as a forum post. COMPLETED

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. Control/feature set of selector devices - Describe what the methods need to do (more than just the API)

  • Brad: I think there is still a confusion of the difference between the update of the model and the update of the hardware.
  • Michele: I released an example trying to use the IEEE 1687 commands to show the iWrite and iRead does not affect the hardware until the iScan.
  • {Brad and Michele clarified the examples they provided via email in regards to the synchronization of model and target states;}
  • Heiko: This all makes sense, but who provides these sequences?  The device vendor or the tool vendor?
  • Michele: I think it is the responsibility of the device vendor who provides overloadings of the select and the deselect methods.  What we have been given now is just a description of the structural description.  We are proposing the vendor provides the behavioral description of how the select and deselect operates.
  • Heiko: what was meant with “Describe what the methods need to do (more than just the API)(continued)”?
  • Brad: The API is defining the syntax and semantics of the method.  The method description actually describes what the method has to do to the various registers (IR and DR) to change the state of the model.
  • Heiko: So the Select and Deselect names are the API and the methods are describing what gets done.
  • Michele: The methods are really changing the state of the model, not the hardware.  The hardware gets updated when the synchronization takes place.  The method adds events to the work that has to be done to the hardware when called.  So the method may have to apply an IR change event followed by a DR change event for particular registers of the device.  The configuration loop is exactly the same.
  • Heiko: How should we define this?  Should we take the example of the SPL and define the methods for them or something more general.
  • Heiko: What features do we need beyond "select" and "deselect"?
  • Brad: a “select” may require many steps to accomplish that behavior; take a Scan Path Linker, for example; To select a sub-chain, one has to select the appropriate IR to gain access to the control of the access link.  Then, one has to set the appropriate bits in the associated DR for that instruction issued to the IR.  For each chain selection, the precondition has to ensure the correct instruction is loaded into the IR and that the correct bits are altered in the associated DR.  There is also a dependency where the correct TAP stable state needs to be entered before the connection takes place and if the state is not compatible, either move the TAP to that state or issue an error that a precondition dependency is not met.  Once all conditions are met, and no other sub-chains are to be selected or deselected, then the hardware needs to be updated to synchronize the model with the hardware.  This flow will be different for each type of chain selection device we need to support.  There may be some common features as well.  All the details for the IR and DR operations need to be hidden from the end user as a "Select" abstraction so the common behavior is exposed and not the details of how this behavior is implemented differently in different devices.
  • Michele: I think we need to define the set of primitives that can be used to express the set of features for the general linker and then applied to a specific example to see how that would be applied to one of these linkers.
  • Heiko: Was that in one of the forum posts you mentioned earlier? {referring to Michele’s forum post on the "bottom-up approach": http://forums.sjtag.org/viewtopic.php?f=13&t=728}.
  • Michele: It was one of the main contents of the forum post, but I need to refine some things later.  You are actually changing the model state and the system hardware state.  At some point they will not be the same.  It requires a synchronization to take place to make them identical.  So you have to iterate over a series of operations until the system hardware state is the same as the model state.  You continue this iteration until the system hardware state matches what is in the model state.  When the model state changes, each of these elements that are changed puts in a request to change the state of the hardware.  If the hardware is not in a state to allow access to that register, the execution model will then have to include this sub-chain to get access to the requested TDR.  Once accessible, the TDR may then be updated when the scan reaches that portion of the scan chain.
  • Michele: each time you are making a selection you are changing the system model state, when you want to modify the target system you use the applicable methods to apply actions that bring target system hardware state back into sync with the system model state; once we agree on an execution model, we can from there define what the various methods need to do;
  • Heiko: So the requests to change the sub-chain may not always come from the model and could actually come from an external manager that is able to manage the overall structure of the hardware access.
  • Michele: Yes it could, but these are additional primitives we have not yet defined that are outside of the model space.
  • Heiko: Will you say the post defines the primitives in the API?
  • Michele: The post defines the execution model behind these methods.  The list of steps is the beginning of an initial outline of the execution flow between synchronizing the model states with the actual hardware states.  This was intended to be the start of a minimum feature set.
  • Michele: I am trying to apply my execution model and see how it can be made more general to be applied to SJTAG.
  • Heiko: and that way come up with a minimum feature set of selector devices?
  • Michele: yes
  • Heiko: So what do others feel about this bottom up approach?  We basically agreed to a bottom up approach last week? Brian, does this make sense for your execution model.
  • Brian: It is different from our approach, but it seems reasonable.
  • Heiko: We also rely on predefined vectors and a more top down approach, but it seems easier to deal with including the details of the device bottom up instead of hard coding the details for each device that comes out.
  • Michele: Instead of supporting each device differently, I wanted to find a way device vendors could define what to do with their device instead of rewriting the vendor tools each time.
  • Brad: My concern is this bottom up approach requires a very different execution model from what is used today.  If you try to apply the top down execution model with a global vector, you end up requiring the retargeting perspective adopted by 1687 to apply to the execution models used by tool vendors today for traditional scan based tests.  Since the vector topology changes over time, the global vector size changes requiring the freeing and allocating of memory for each scan operations making the execution very inefficient.  So overlaying the bottom up approach to a top down execution model becomes inefficient.
  • Heiko: What makes the inefficiencies?
  • Brad: There are many instructions in 1687 that are specific to a retargeting model that would not be appropriate for the execution model we are describing.
  • Michele: I agree; bottom-up is a much more efficient way to configure access to a specific instrument than top-down retargeting;
  • Heiko: so, we still need to agree on whether we want to adopt the bottom-up approach before we can continue discussing a control / feature set of selector devices?
  • Michele: There is a need to analyze the instructions for 1687 and how it relates to the overall control flow.
  • Brad: I think Michele is right.  We have to analyze the relevance and incompatibilities of 1687 instruction in the PDL to what we need to do. Where do we see problems with something like 1687 execution flows when we need to deal with scan operations to data registers as well as instruction registers (our "SJTAG access link")?
  • Michele: This is really a scaling problem for SJTAG with a lot more interdependencies that are not existent in 1687.  This is where a top-down approach makes it more difficult if not impossible to scale.  Whereas the bottom-up approach scales easier as you add more levels to the top.
  • Brad: In SJTAG, what do we define as the top?  It could be an SoC, a board, a board with mezzanines, a shelf, multiple shelves, etc.  What is our top?  It depends on the application.  This is why a top down approach to modeling is not going to work.  We don't have a rigid "top".  1687 has a top, the device TAP controller interface to the SO and SI data flow.
  • The following are post meeting notes:
    • Michele: I would like to add a comment that did not come up during the meeting. There is another often-overlooked good point in choosing a behavioural rather than a structural description for linkers: confidentiality. When a device vendor provides a structural description (ex: in ICL) detailed enough for the tooling to infer its usage, he is also disclosing an awful lot of information about the internals of the device itself. On the other hand, in a behavioural description you can hide the real circuit that is behind, as you are only saying how it will work and not how it achieves the functionality. It is the same level of information you find in a datasheet : enough to operate, but not to reveal internal IP.
    • The level of disclosed information can be modulated through the exchange method/format, in the most extreme case only having to expose the primitive methods (select/deselect/is_active) while keeping everything else private....
    • Adam: I'm sure that Michele is much more familiar with the topic than am I, but my impression of ICL in this application is that it is more on the behavioral side of the line. I wonder, Michele, if you might have an example of the sort of exposure of confidential IP that seems to be of concern.
    • Michele: Thanks for the comment Adam, I will try and explain my thoughts. This comes from my integrated digital designer side, so it might not be too familiar with some of the members that are expert in board testing.
    • When you are making some IP-based design, instead of having to specify and implement everything yourself, you try using IPs designed and verified by 3rd parties. The simplest way of doing it is to take the source RTL code (VHDL or Verilog usually) of a device and add it to your project. However, this means that the device vendor is sharing everything to you about his IP, which is not always desirable. The solution comes from encapsulation: the vendor shares with you only the prototype of the device (i.e. its external definition complete with I/O ports) and some instructions to instantiate and use the device. The actual implementation is delivered as pre-compiled libraries that are directly read by your synthesis/simulation tools (considered as a trusted party), and nothing is disclosed to you. It is similar to when you buy a software; you get the compiled executables/object files, not the source files.
    • Now, in the current standards (1687 and 1149.1-13 alike) you actually have to share the source files. In these terms, ICL is just a lightweight structural HDL: without going into all the details of VHDL/Verilog, you still have to expose all of you internal registers, and the PDL is the source code of the operations. So, when giving a 1687-compliant device, the vendor is actually exposing all of its internal choices. Same goes for every subsystem you want to add. The more information is exposed, the more you are open to reverse engineering.
    • On the other hand, in the Object Oriented bottom-up approach I propose the device vendor just needs to provide a node object exposing the base primitives select/deselect/is_active, while keeping private the internal implementation. The tool can therefore operate them, but the end user does not have any knowledge of what the linker is actually doing.
    • Peter: I agree with Michelle on the confidentiality aspects when integrating Gateway IP with other logic and that you can implement the encrypted netlist route via the FPGA vendors tools.
    • I see the thread looking at how to pass the command sequences not just for base primitives such as select/deselect/is_active, but to also support extensions  (for example our Firecron devices have many features to absorb the glue on the PCBA and reduce the componet count/cost to the end user) to the ATPG tools in a secure manner.

6. Topic for next meeting

  • Come up with definitions for bottom-up and top-down (to be added to the glossary).
  • expand on bottom-up execution model; review and flesh out the 8 steps Michele presented in his forum post http://forums.sjtag.org/viewtopic.php?f=13&t=728; attempt to come up with a minimum feature set for selector devices to support such an execution model;

7. Key Takeaway for today's meeting

  • bottom-up is the only execution model that seems to make sense for SJTAG; (SJTAG does not have a defined "TOP”; because of this, we have to look bottom up to support scalability)

8. Glossary terms from this meeting

  • Consider adding bottom-up and top-down definitions to the glossary.

9. Schedule next meeting

  • June 22 - Carl will be absent.
  • June schedule – 22, 29

10. Any other business

  • None.

11. Review new action items

  • None.

12. Adjourn

  • Brian moves to adjourn, Eric seconds.
  • Meeting adjourned at 12:01 PM EDT

Many thanks to Brad for providing his extensive notes.

Respectfully submitted,
Heiko Ehrenberg