Minutes of Weekly Meeting, 2010-09-13

Meeting called to order: 10:38 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Patrick Au
Peter Horwood
Tim Pender
Brad Van Treuren
Carl Walker
Michele Portolan
Brian Erickson (joined 10:45)

Apologies:
Heiko Ehrenberg

2. Review and approve previous minutes:

8/23/2010 minutes:

  • No further corrections.
  • Motion to approve by Eric, Seconded by Patrick, no objections or abstentions.

8/30/2010 minutes:

  • No corrections noted.
  • Motion to approve by Eric, Seconded by Carl, no objections or abstentions.

3. Review old action items

  • Adam proposed we cover the following at the next meeting:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • All to consider what data items are missing from Data Elements diagram
  • 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/Brad: Draft "straw man" Volume 4 for review - Ongoing
  • All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
  • All: Review 'straw man' virtual systems and notes on forums:
    http://forums.sjtag.org/viewtopic.php?f=29&t=109. - Ongoing
  • All: Add to, or comment on, the bullet point list of architecture drivers. - Ongoing.
  • All: Provide forum comment on the graphics used during the meeting; suggest "building blocks" that may be used in future:
    http://forums.sjtag.org/viewtopic.php?f=29&p=257#p257 - Ongoing.
  • ALL: review / comment in preparation for upcoming meetings. - Ongoing
  • Tim: Draft matrix of SJTAG features against evolving solution options. - Ongoing.
  • All: Post suggestions for key SJTAG gateway features on the forum (Ian will create topic) - Ongoing
  • All: Post suggested draft texts for survey comments in existing 2009 Survey thread (http://forums.sjtag.org/viewtopic.php?f=32&t=83) - Ongoing
  • Carl: Contact Zoe about what material we could obtain for our use. - Ongoing
  • Ian: Establish if there is interest and opportunity for a SJTAG fringe meeting at ITC. - COMPLETE
  • Ian: Newsletter: Add forum link to article on gateways. Correct spelling errors (two places). Issue newsletter - COMPLETE
  • [Ian] Our plans were kind of overtaken by events, so I've submitted a request for an SJTAG Fringe meeting. I got about seven positive responses in the short time I had before I had to make a decision, which seems like enough of a justification to me.
  • [Ian] I issued the Newsletter, but after the problems with the website two weeks ago I rushed sending it out and forgot to change the email subject line from 'Spring' to 'Summer'.
  • [Carl] I've nothing to report from iNEMI at this time.

4. Discussion Topics

  1. White Paper Volume 3 - Key Gateway Features:
    • [Ian] The last couple of meetings kind of deferred too much discussion on this, believing that we needed to have Brad back on the call to make much headway.
    • [Tim] Yeah, Brad you were trying to call out what was required to connect to a chain. Then stick a gateway in and see what happens; look for commonality, that sort of thing.
    • [Brad] OK, I was looking beyond the host, to see if we're talking about building block or some higher level.
    • [Ian] We can probably go even farther back to the slides we were producing. We got up to gateways then got stuck, so we branched off down this route to see if we could find some insight into what we wanted to diagram.
    • [Brad] We seemed to be getting into difficulty trying to get to the properties of a gateway. I thought the host might be something that was easier to get a hold of.
    • [Brad] I wanted to look at the properties of building blocks, that's where the email I sent you came from.
    • [Ian] Yes. I guess you feel this isn't quite something that you'd wnat to share with the group just yet?
    • [Brad] No, I think we could; let people think about this and see what it produces.
    • {'model.py' shared}
    • [Brad] I'm not sure everyone will be familiar with Python. I was trying to find a way to represent my ideas as simply as possible.
    • [Brad] In Python, blocks are indicated by indentation; in C++ or C# a block would be indicated in the curly braces {...}.
    • [Brad] In a class declaration you have the class name then inside the parenthesis you start with the base class it's derived from.
    • [Brad] In defining a function, you use def then the function name. In many places you'll see self. self is the same as this in C++, but where this is often implicit in C++, Python needs self to be explicitly declared.
       
    • [Brad] Looking with the class ScanChainSegment, __init__ is the constructor. self.input and self.output are member variables; these aren't the same as the input and output arguments. The lines here copy input into self.input and output into self.output.
    • [Brad] In the fourth argument we have a default value declared, that will be used if the argument isn't present in the invocation. The ChainTypes is a poor man's way of enumerating in Python.
    • [Brad] You can declare abstract functions by just using the pass keyword to satisfy the semantics of the interpreter.
    • [Brad] Use pass to have a function always be successful with the interpreter without failing.
    • [Brad] I've tried to use terms that we used in the slides.
    • [Brad] In the ScanChainSegment we have TDI, TDO and type; these seemed to be the bare minimum we need to describe a segment.
      I have defined the parameters of drlength and irlength as functions instead of variables. This will become clearer later as we look at the other classes. The length is only constant for certain types of paths. Because of the dynamic nature of paths, the length has to be calculated for each configuration of the chain at run-time.
    • [Brad] In scandr, parent is maybe a linker device. This model uses delegation to perform the scan operations. The scan functions do not actually perform the scan to the hardware in this example, but rather construct up the vector to be scanned on the fly. How this is done is through the use of a callback function. Each of these path objects rely on calling the paths closest to TDO (the self.output parameter) to build up the data bits closest to TDO following this path. These then have to be appended to the bits represented by this path. The resulting vector needs to be passed back to the parent of this path to include its bits. This is the purpose of the scanCallback( ) function.
       
    • [Brad] StaticPath is derived from ScanChainSegment and we have an override of the type in the constructor. We're adding two new properties for the static path - an entityList which is a list of chains or devices although the [] shows that this is declared as an empty list, and entityCount which is simply the number of entities in the list. Here 'entity' is like a BSDL entity.
    • [Brad] This is what people may find different: I'm not representing the vectors as static storage, but as functions. So for the DR we iterate through the list to get what the DR lengths are, and the same for IR lengths.
    • [Brad] The reason for doing this is that you may have linkers in the chain, so the actual length of a configuration may change as other paths are included or excluded. Thus, each entity must report its own state and length. This makes it pluggable into a hierarchy without having to be changed.
    • [Brad] In the scandr function, parent is responsible for management of the chain. self.vector property is a Python BitString - it's just that - a set of bits. The self.vector needs to be cleared out so it can be populated with the information represented in each of the entities of the StaticPath.
    • [Brad] scandr can delegate to each entity contained on the path. The use of a list preserves the order of the entities so iteration corresponds to the traversal from TDI to TDO for this path. The StaticPath is responsible for managing the information represented by its entities.
    • [Brad] This way you can dynamically build up the scan vector that needs to be sent out, and that supports Plug and Play at any level in the hierarchy. So each entity is called and asked to "scan" out its bits. As a side effect of the scan operation the entities will call the parent's scanCallback( ) function to fill in the self.vector of the StaticPath.
    • [Brad] scanir is the same.
    • [Brad] In each of the scanCallback( ) functions, you just append your bits to the end of what's been passed in. This is probably very inefficient and you wouldn't want to do it like this, but it gets the idea across.
    • [Brad] What we're seeing here is Methods or Actions as you might see them described by Microsoft for the COM interface.
    • [Brad] In some cases I'm using a variable for some properties and functions for others.
       
    • [Brad] I run into issues of 'Where do I go from here?' In the end I opted to look at the Bypass Element. I struggled looking at how to represent the BypassElement. I considered deriving the BypassElement from the ScanChainSegment, but I ran into a problem when I got to the Linker device that needed to have BypassElement features as well as BScanDevice features. So which derived class was the ScanPathSegment instance going to align to?
      That was not going to work.
    • [Brad] I chose to separate BypassElement and Register, and not have these derived from ScanChainSegment as a result. Instead, the BypassElement is going to be contained by the Linker in a Python container - a List.
    • [Brad] For BypassElement, I arrived at four properties it needed: Is there a resynchronization bit? Is it parked? If so in what state? Is there a secondary path? You can think of these as holding state information (isResynchronized, isParked, parkValue) or structural information (scanChain).
    • [Brad] I struggled with how to represent the link bit or resynchronization bit. Do I treat it as a single bit path or not. I decided to treat it as a property of the BypassElement and deal with it if the isResynchronized flag is True. I did not have a value or vector assigned to it at this time because it could be placed closest to TDI or closest to TDO. So I have left that part undefined right now.
    • [Brad] None is like NULL in C++, meaning undefined.
    • [Tim] Does Python have types? Is it strongly typed?
    • [Brad] It's dynamic programming language. As such it uses dynamic typing where a variable can change its type over time. It has no concept of type definitions as it is an interpreted language. It uses very high level dynamic data types that are assigned to variables at run-time with the data type they represent. This loose typing can be extremely powerful.
    • [Tim] So what type is scanChain?
    • [Brad] It's a ScanChainSegment.
       
    • [Brad] The class Register is just a data value, a set of bits.
       
    • [Brad] This gets us to the BScanDevice.
    • [Brad] This is a more complex class in that it represent the first dynamic element described so far. This is why the type of chain is defined as a DYNAMIC_PATH. The particular element or Register visible over time may change depending on the scan state used and the value of the IR register.
    • [Brad] I have realized there are 3 principle types of properties used: Structural Properties, Addressing Properties and State Properties.
    • [Brad] I've listed State Properties here because, really, this is dependant on what state you're in. I tried to think what properties a device state has and I came up with four.
    • [Brad] You'll see this class has name as an argument - that allows us to have multiple instances of the same device.
      I have added a property called self.currentDR with the anticipation that the assignment of the value of the IR would reassign the self.currentDR value to point to the appropriate DR in the self.registerList. This would simplify the scandr function so it just has to know about the self.currentDR property.
    • [Brad] self.vector is a buffer for constructing the vector to go out to the hardware. input is the ScanChainSegment attached closest to TDI and output is the ScanChainSegment attached closest to TDO.
    • [Brad] In the drlength function, we check for not None in self.output meaning there's another segment following so we add the length of that to the current DR length. As each BScanDevice evaluates drlength we build up the length of the entire chain.
      We do the same thing for irlength.
    • [Brad] For scandr, we really don't care of what type the parent is. We just have to know that the parent is responsible for managing the vector the BScanDevice constructs and passes back. The parent is always a path type of element. The scandr function assigns the value of the self.currentDR to the self.vector buffer prior to iterating through the self.output entities. The self.output.scandr(self) function call passes this BScanDevice instance as the parent argument to the scandr of the next element. That element constructs up its vector segment and calls its self.output to append that data to the end of its data and passes the resulting vector back to this BScanDevice by calling the parent.scanCallback( ) the same way the BScanDevice scandr( ) function does in its code as the last thing.
      After self.output.scandr I have the whole length from TDI right through to TDO. I pass that back to parent using parent.scanCallback. scanCallback appends any child (if this is a dynamic path element) or sibling (other BScanDevices in the chain) vector buffers to our own vector buffer.
    • [Brad] It's a lot to take in but this was the simplest way I could see to represent this with few lines of code.
       
    • [Brad] BScanDevice is simpler than Linker. I couldn't figure out how to derive from both the BScanDevice and the BypassElement classes in an organization that made sense. So I decided to use a container to store the representation of the BypassElements used by the Linker device.
    • [Brad] I have bypassElementCount and then a list of bypassElements. Then I've stored input away at this level as tapInterface because the input is really the primary input port. I am really storing the object represented by the input argument into the self.tapInterface variable. So it is not really a property but a value.
    • [Brad] I got a little bit fancier for the self.selectionProtocol. I had a problem with representing this in a generalized Linker class. In one case I need the selection to be done using BScan registers. I might have another case that deals with the addressing as an I2C interface. So to accomplish the differences of function with isolating the structural representation, I decided to represent the addressing as a separate functional interface that is aware of the structural class. This is a form of the Decorator design pattern.
    • [Brad] Is everyone getting this wrinkle about using a functional placeholder for the selection protocol?
    • [Eric] Yes, OK.
    • [Brad] I iterate through the list of bypassElements checking for whether or not a scan chain is connected to it. If there is scan chain defined by that element then I want to get that chain's length.
    • [Brad] The logic is wrong here, but it'd be more confusing if I tried to add, for example, checking for parked, is the bypass element at the beginning or the end of it's element? I omitted these kinds of things to avoid confusion.
    • [Brad] If there is an output then we need to add it.
    • [Brad] I should note that order doesn't matter for drlength but it does for scandr.
       
    • [Brad] I wanted to start nailing down what the properties are and try to find what are the SNAFUs.
    • [Tim] Are we going to put this on the website, maybe in the forums?
    • [Brad] I thought about that but wasn't sure how best to do that.
    • [Ian] The forums would be a good place. I can do that right after this meeting. {ACTION}
    • [Brad] Remember this isn't working Python code although it wouldn't take much to make it work. It's more a catalyst for discussion: A lot of current tooling doesn't follow this kind of model. It is not an efficient representation, but it does give insights into what kinds of properties are going to be important.
      There are probably better ways to represent this, but I only worked on it a couple of hours. There is a lot that has not been fleshed out that clearly is missing. I hope this will get people thinking about the issues and look at what is really needed. Shoot holes in this work as it is not cast in stone or even something that is working. As I said, its purpose is to try to foster discussion and insights into this domain.
    • {Michele left at 11:32}
    • {Carl left at 11:34}
  2. BIST Activity at iNEMI - Feedback (if any) from contact with iNEMI group
    • {Covered in review of actions}

5. Schedule next meeting

September 20th - Eric and Peter will likely miss

Schedule for September 2010:
27th - Eric will likely miss

6. Any other business

The motion on signal naming conventions from the meeting of May 3rd remains tabled.

7. Review new action items

  • Ian: Copy Brad's model code onto a forum post.

8. Adjourn

Tim moved to adjourn at 11:47 AM EST, seconded by Brian.

Special thanks to Brad for reviewing and revising the notes on the Python model.

Respectfully submitted,
Ian McIntosh