The System JTAG Working Group

Return to index of Meeting Minutes

Minutes of Weekly Meeting, 2008-09-08

Call to order at: 8:22am

1. Roll Call

Brad Van Treuren
Eric Cormack
Tim Pender
Heiko Erhenberg
Ian McIntosh
Carl Walker
Adam Ley

Excused absences:
Carl Nielson
Peter Horwood

2. Review and approve 8/27/2008 minutes

(Moved by Ian, Second by Heiko)

Heiko noted appreciation and thanks to Ian and Peter for their help in recording the minutes.
Minutes were approved with no changes once Carl joined.

3. Review old action items

Ian to set up a forum site for the data discussion (Done)

4. Discussion Topics

Results and Status from SJTAG Survey Activity

[Brad] I think we are official that the survey is closed now.
[Ian] Gunnar was the last submission. I closed it off officially two months and one day after we started it.

Status and review of white paper sections

[Brad] I didn�t have any updates for volume one.
[Carl Walker joined at this time and minutes were approved.]
[Adam Ley joined following the approval of the minutes]
[Ian] I put some additions in. Apart from doing some minor review and tidying up, for an overview it probably has about as much in it that we can realistically do right now, I think.
[Brad] Are there any changes in the use case document?
[Heiko] Unfortunately, no.
[Brad] How about the hardware architecture?
[Carl W.] Carl Neilson and I are going to be working on changes to that this week. Unfortunately, we have been a bit delayed due to business travel. Sorry about that!
[Brad] Regarding the language and data volume, I have not put any updates into that document.

System Data Elements Continued Discussion

- Discuss merits of generic assembly descriptions vs. board/system descriptions
[Brad] I sent out a diagram and the HSDL document link in the reminder for this meeting. I believe the diagram shows some of this contrast from the previous diagram.
[Tim] Now what you are calling an assembly, is that just a board that has a daughter board connected to it or is that just a single board?
[Brad] I think what the intent was (and Ian you can correct me) is that assembly is the object that is going to capture the idea of a hierarchy relationship.
[Ian] Yeah, that�s right. Now it could be a board or it could be a board with a daughter board or it could be some higher level of assembly. That was the kind of view that I had of it certainly.
[Tim] I was wondering how that was related to native files created from your CAD tools for your netlists. You are normally going to have a netlist for an individual board. You are not going to have a merged netlist if it was considered an assembly with like a daughter board on it.
[Ian] Yeah�um. I think this is where the hierarchy and the inheritance of the properties of the lower level assemblies come into play. In the same way as you have a netlist of the board, from the point of view of inheriting a test, you inherit the properties, if you like, of the BSDL files. If you have a daughter board on there, then it is a lower level assembly and your higher level assemblies inherits the properties of its netlist and its bill of materials and so on. That�s the kind of view that I have on it� Unlike the idea of trying to produce a merged netlist that gives you a netlist of the whole system, each of the netlists gives you a description of each of the netlists exists as their own distinct entity and your descriptions of your devices exist as their distinct entities, but they just get pulled in as you explore the hierarchy.
[Brad] I�m just curious if there are identifiable features that are going to be significantly different between the different domain elements, be it a board, a carrier, a shelf/chassis, or even a whole cabinet where you have multiple chassis.
[Ian] This is why I had a problem with the idea of having a separate entity and even if it was derived from a base class, if you like, for a system because for me what you cast as a system could really depend on what you were actually looking at. So if you had something like a carrier board with a couple of mezzanine boards on it, from a point of view in testing that you could classify that as a system. If the object you had that described the system was different from an object that would describe a board it would be more difficult to integrate that board into a high level assembly. I was trying to see how all that would seamlessly tie up as you increased the level of integration as you get up into the situation of systems of systems.
[Brad] Ultimately, I think we are going to need to support this level of hierarchical complexity down the road. Maybe not in a dot one version, but later on I think SJTAG is going to need to support something like that.
[Tim] I agree. We really do need a hierarchy because you can�t just go on and have one netlist, for example, as a carrier board with a mezzanine. What happens if one of the mezzanine cards is depopulated? Will you need to have 15 different netlists depending on which mezzanine cards are depopulated and which ones aren�t? So you need to have that hierarchy support.
[Brad] Exactly. That is what was concerning me regarding some of these data representations because with a board, by itself, and not a carrier board, you pretty much have pretty much a static netlist and a static topology taking place. When you get into the cases with carriers with mezzanines and you get into the chassis themselves, then you get into the case where, especially if you have a hot swap capability, you have a variation of what that topology looks like at that aggregate level, and it�s even more difficult with a hot swap because as you may plug things into it that haven�t yet been defined to the software, and so you got to deal with adding in new technologies or new features into an existing environment and be able to seamlessly integrate that.
[Ian] Yeah.
[Brad] That�s were I see a difference from what a board object is and what a system type or carrier object would be. You have that dynamic aspect in there that doesn�t exist for the lower level hierarchies.
[Ian] Yeah. Perhaps. But this could maybe be an optional feature that isn�t used when you have a simple board.
[Brad] Yeah. That is possible.
[Eric] Don�t we have some kind of interrogation that goes around the system, board or what ever and decides what is there and what isn�t?
[Ian] That is certainly something that we had talked about, being able to probe the system architecture or probing the system configuration to find out what was there, but that makes an assumption that we do have a means of providing a board id. I don�t know if we actually decided on that that was something that we mandatorily have. It certainly sounds like it would be a good idea, but I think we haven�t quite buttoned that one out. It was something that we had discussed when we had the ATCA discussions a while back.
[Brad, Eric] Right.
[Ian] My memory fails me on that where I can quite remember what we concluded on that right now� I don�t think we actually did come to a conclusion on that. I think it was discussed as something that might be a nice feature to have.
[Brad] I think where we were ending up on that was the addressing for connection to a particular slot was going to give us that id, potentially. We may need to add some additional bits to it to be able to give a unique coding to the type as well as the location, but I don�t think we really concluded a discussion on that.
[Eric] Is that something that Adam might want? Would that alleviate some of his problems, especially with the hot swapping and the daughter cards and the variation in the daughter cards with the different configurations on that?
[Heiko] I think it would certainly be helpful for tools.
[Eric] We probably need to have a nice hot topic on that one sometime soon.
[Brad] Yeah.
[Tim] I think one of the first things when you interrogate the system is you would want to know what boards are out there and what firmware versions are out there as well. So it would be nice to have that easily managed at one location at the higher level.
[Ian] I think it would certainly be quite a nice feature to have that would be a kind of auto discover what�s in your system effectively. To start at the top level and then you automatically propagate down to the lowest level.
[Brad] Although, I am not so sure I could sell that to my designers because we already have other features in the software that do provide a lot of that same capability.
[Ian] I�m sure. It�s just that from the point of view to the support form the tooling perspective, if you can derive the system through the JTAG chain, particularly if you are using something like an external tester, then the potential can exist for you to effectively generate the tests almost on the fly if you can extract what all the �part numbers�, if you like, from the composition of your system. Then you can tie that up to even a library of even data files that contain all the descriptions of the boards and the components.
[Brad] I can understand what you are saying there, but I am also concerned about containing and storing all of that kind of information in a system can be quite expensive.
[Ian] Yeah. I am certainly not going to argue, but it�s things that we maybe need to explore and see whether they are valuable or not.
[Brad] Right. Back in 2005, I presented a paper at ITC talking about a mechanism that is able to extract the test data from the UUT through the boundary-scan port in a multi-drop environment. And basically everything that is needed to test that board is multi-drop interface with everything residing in a repository that we could extract and copy via the JTAG into the local storage on the test controller card that we would be able to apply to the UUT. And what that let us be able to do is not have to worry about all of the data that is associated with generating tests, but have the tests pre-generated and stored on the UUT that we could extract and then apply those from a test controller within the chassis. That let us be able to do basically the equivalent of a boundary-scan plug-n-play so that any new design that would be plugged into the system, as long as it followed the convention for being able to do that extraction, we were able to add in new designs without having to change any of the system software. They could be tested using the exact same software that was delivered with the system to test the other boards. So there are ways to abstract out that information as pre-generated information that we should be considering as well.
[Ian] That would let you be able to do test at the individual board level, but not necessarily board to board interconnect test for example.
[Brad] That is correct.
[Ian] There may be a way of storing a compact version of the data that would at least get you the information about the periphery of the board.
[Brad] At least what may be driven or observed at the periphery.
[Ian] It may not be reaching too far to store that data on a board.
[Brad] I would agree with that.
[Brad] So what I am hearing is that this generalization to have assemblies as a generic form may actually be easier to implement from a software tooling perspective vs. trying to derive from some common class and have specialization for boards and for systems and subsystems. That seems to be the consensus the majority of the people are talking about here.
[Ian] That seems to make more sense to me, but I think the real proof will be when somebody tries to implement it in a piece of software.
[Brad] Part of that discussion then, since we started talking about board to board type testing, the difficulty I have with implementation within systems is how do you represent that interconnection from one board to another board? A lot of times that does not exist in a CAD file, but is in some sort of architectural document on how modules plug together.
[Ian] The thought that I was having on that, Brad, was if you make an assumption that you have some kind of backplane, the boards plugged into a backplane are near equivalent to devices plugged into a board (i.e., the backplane itself provides the interconnection) and if you have a bill of materials, you actually know what boards are plugged into which slots.
[Brad] Yes and no. For a backplane you can get the CAD data for that to give you the netlist, but I tell you what I have run into is with multiple sites doing designs, like one site doing the backplane design, another site is doing a board design and a third site is doing another board design. A lot of times they don�t always talk together and the nomenclature they are using for the pin designations don�t match.
[Ian] That is exactly the concern I had in my mind when I was saying that. You are likely to come into the situation where you have one pin called P126 and J126 on the other side. I mean that is the obvious one.
[Brad] Then you also get into subsets of connectors mating to connectors.
[Ian] Yep. Sure.
[Heiko] You should still be able to provide ways of merging that though.
[Brad] Obviously we have tooling today that can deal with that. Typically, it has been a manual effort to be able to do that mapping as something provided to the tooling, but it is not something that can be automated.
[Heiko] Ok, yeah.
[Brad] That�s the problem I have.
[Ian] One of the thoughts I have that is running through my mind is that one of the areas we don�t have represented in the group here is the ECAD tools. At the end of the day, the same as generating the BSDL files for an ASIC and so on, a lot of that is down to the ECAD tools doing it. It may be that with some of these board description things, we might need some help from the ECAD tools companies as well.
[Brad] You�re right.
[Ian] Maybe there is a gap there that we need to get some ECAD people into to get their take on things as well.
[Brad] That definitely would help, but I am not sure who we can ask.
[Ian] I don�t know either.
[Tim] Another gap too is harnessing. You generally don�t have a netlist for harnessing. So when I was doing system level test, I was manually creating a netlist for my cables.
[Ian] That may be the case and then some cases you might get CAD drawings for the wiring that can be used to produce netlists for testing. I mean we use things like that some times, but not all the time certainly. The other thing that was going through my mind is obviously the issue of having a backplane, but sometimes you don�t even have a backplane as such. If you look at something like a PC104 type form factor where basically you have a bunch of boards that plug into each other through stacking connector, you don�t really have a backplane or you don�t really have something that tells you how boards are plugged together apart from the fact that there is a bus.
[Brad] That is also the case where you have a carrier and a mezzanine. You wonder what is the mapping that goes on between the mezzanine and the carrier.
[Tim] Somehow there has to be in the BOM something that tell you that you have a load or a no load of a mezzanine card you might say what flavors of the mezzanine cards are available and then you are going to say which card is populated or not. So there has to be some way to state whether a mezzanine card is loaded or not. And with your tests is assuming that both boards are populated and in your current configuration one of them is not populated you may not be able to run certain tests either. So you almost need to know given what is connected you can only run these sets of tests as available.
[Brad] That is a very good point.
[Brad] I think as we deal with standardized interfaces we may be able to have the tooling do that mapping based on some standard to get the automation leverage out of it. If you are going to design something to an ATCA or a MicroTCA there is a definite pin nomenclature that you are going to adhere to in your design. So if you can state this is the form factor used from this standard, the tooling might be able to do that mapping for you automatically.
[Brad] Back to the issue of board ids or assembly ids, I think that is going to be useful from the perspective of an external test tool even more so than what is needed for an embedded system test tool. With embedded system testing, we already have a lot of that capability already in the system, but the problem is how do you access that information when you plug in a laptop or some other external test tool to do a system integration test for example. You need to be able to query what the configuration is.
[Brad] We are struggling with a similar issue in P1687 IJTAG as we were discussing how you hand off the state of a chain topology and the gateway settings when you transition from one controller to another. There is still an open discussion on that. Some say the software should know that and be able to pass it on, but that does not address the case when the other controller is an external controller. Others are talking about having a way to interrogate the state of the topology directly from the new controller.
[Brad] I think we have beat this subject up long enough. Let�s move on to our HSDL discussion.
- Contrast and begin analysis of HSDL (Since IJTAG started their discussion with this language)
Specification for HSDL may be found at: http://asset-intertech.com/support/hsdlspec.pdf
- I have attached a simple UML model diagram of the relationships of the entity descriptions for HSDL for our discussion.
[Brad] Doing a contrast on what we were just discussing with what capabilities are available in HSDL and what capabilities are missing will give us a good reference or baseline to grow from, similar to what the IJTAG team did early on when looking at HSDL. I plan to have some other discussions with some other language types as we proceed, but I though HSDL was a good starting point for the language example discussion. The key is to begin analyzing and contrasting what we have right now as a baseline for future discussions.
[Brad] Is there anyone that is not familiar with HSDL?
[Heiko] I am aware of it, but I have not had any practical experience with it.
[Ian] I only have cursory knowledge of it.
[Brad] I would bet that most of the �USERS� of HSDL have only scratched the surface of what can be done with the language. There is a lot there and I know my application engineers use on average only 20% of the language in their day to day work. There are a lot of things it brings to the table depending on what your architecture is and how you partition your testing.
[Ian] We have Adam on the call today. He must be an expert in it.
(Chuckles)
[Adam] If there is such a thing as an expert, I guess I will have to raise my hand.
[Brad] Yeah, It was really the other Adam that was teaching me about HSDL. You can see his name as the author of the document.
[Tim] I think one thing that needs to be represented in HSDL is the TAP voltages. Currently in VHDL, you are kind of limited. You know there is a high and a low and that is pretty much the default. So on your board you may actually have two different devices connected to each other with different voltages required for their TAPs. One might have 3.3V and the other have 1.8V and you won�t know it in your simulation. Ideally in simulation you would want some sort of identifier for that so you can in the simulation be able to detect that you are going to blow your part because the voltages are different. It is better to find that out in simulation than on the board. It is possible if you have different identifiers for different voltages. I don�t even know how they do it in ICT when they are testing. It used to be in the old days that you wired everything up to your power bus that was 5V. Today you have to discriminate all the power nets and I can imagine this is a nightmare to manage and describe. With HSDL there are possibilities to handle the mixed voltage situation.
[Brad] One of the advantages of having a language like BSDL and HSDL that is based on VHDL is the ability to add different types of attributes to the description.
[Brad] One of the greatest concerns I have with HSDL is what I was trying to describe in the graphic is that HSDL is really only trying to describe the boundary scan topology and how the scan chains are wired together, but it is deficient, at least in my mind, at being able to identify the topology of the netlist itself and what the bill of materials are that is being used. The way HSDL was described to me was that HSDL was trying to describe the boundary-scan circuitry so you could generate tests by knowing how things were wired together in a hierarchical fashion, but not necessarily have all the information you need for specific types of tests. It was more trying to capture what the netlists were unable to capture. That is capture the connectivity across netlists regarding the boundary-scan interface as well as attributes about that connectivity.
[Ian] In the way I read it was that HSDL was basically an extended BSDL that supported these hierarchical structures. For straight forward basic interconnect tests, it would work OK for that, but if you started getting logic clusters in between it would probably begin to start to miss out. Does that sound right?
[Brad] Yes, but more because of the deficiency in not being able to represent entire netlists.
[Ian] Especially since it is only modeling the boundary-scan components and not the non-boundary-scan components.
[Brad] But what it models of the scannable components is somewhat limited as well. It is really the scan pins them self and the cells within the device.
[Brad] The interesting thing about HSDL is the ability to define static paths, external paths, and dynamic paths. That is something you cannot capture in any of the current netlist formats. You can capture the static path relationships from the netlists and the tooling can actually build up the static path from the netlist directly, but you have to identify particular types of devices as gateways or linkers in the tooling to be able to automatically determine how to glue these different chains together. If you have some new design, you are at the mercy of the tooling to try to implement a description of that.
[Ian] Yes. That is often the problem that we run into when designers have used different methods for linking chains together. Sometimes it is using a simple multiplexer. Sometimes they are using ScanBRIDGEs and such where the tooling can really struggle with trying to figure out how to control the chains because some of it is just so obscure that the control lines that need to be set to get some of the chains to exist, especially from some of our work share partners, are a lot harder than it needs to be.
[Brad] Yeah. I know we had some early designs that required preconditioning of some CPLD signals to actually enable or disable chains. So we had to do some prescan operations before we could even begin to do testing.
[Ian] Yeah. That is exactly what we have found in some of our sub-contracted designs.
[Brad] Even modeling something like that was difficult in HSDL, but it was easier than just trying to rely on the tooling to do that. So that is a big benefit.
[Brad] A difficulty I have, that I have been sharing a lot in the P1687 group is the constructs for the dynamic path describe what the dynamic aspect is of the chain selection, but they are not defining just how that selection protocol takes place. That is left as an exercise outside of the scope of HSDL for the tooling to deal with. So I can see there are differences in the way HSDL is interpreted because there isn�t a definition of the procedural aspect of the structural language to define how you do that connectivity.
[Adam] Adam here. I will suggest that all of that is quite fair and that it can certainly be interpreted as a limitation of the HSDL approach or another way to look at it is that they represent opportunities for improvement. In other words, the HSDL does not have to be considered as something that is monolithic and unchangeable.
[Brad] Right. I know, and I don�t know how much can be shared, Adam, but back in the late 1990s, Adam Sheppard and I were looking at possible changes to HSDL to include some of the stuff like netlist information or referencing of netlist information and being able to solve some of those issues that were more needed to do better automation of gluing different circuits together. I don�t know how much of that can actually be shared publicly or not.
[Adam] Well Brad, you are more likely the only one who has an on-going memory of that discussion. I would welcome you to share as much of it as you care to do.
[Brad] Alright, I will have to try to dig up my archives on that and see if I still have it. I could share it with you first and then you can make a decision on that.
[Adam] I just wanted to say, and know, Brad you already know this, that Adam Sheppard left this industry years ago and does not have any on-going interest in this subject that I am aware of.
[Brad] I think HSDL is a good example of how the kinds of information we were discussing in our first part can be described in a language that can allow automation of a tool and be able to help with the automation.
[Adam] The one thing that I will say is that from the outset, HSDL was conceived as essentially a chain description language and pretty much all of the tooling approaches involve some sort of a chain description language at some point. The HSDL was expressly designed to try to, in a structured fashion, ring in some of the complexity of dynamic chains, but for example as Brad has suggested, there�s no means currently to specify how a given dynamic segment of a path would be opened or placed in the effective path. And, frankly, at the time HSDL was initially defined or designed the schemes by which that would be done were essentially unknowable. Certainly, one could have taken a highly procedural approach to it such that one could define just about anything one wanted to do and that may be where one has to go in today�s current environment, but the approach that was taken, and you have to realize that it predates BSDL. Certainly, there has not been any ratification of this to date or consensus vote, but the 1149.7 group is considering of using some aspects of HSDL in its description environment.
[Brad] I think one of the most powerful attributes that is in HSDL that is missing from the BSDL, only because BSDL does not control the hierarchies, is the idea of the bus composition. In being able to define these virtual registers, if I may call them that, which is a new ordering of the bits in a given architecture, there is a valuable feature in the architecture that I think we can use when we have been talking about in being able to define what those edge connections are from a board to a backplane to define what can be controlled and what can�t be. A bus composition might be a significant structural entity or attribute to be able to describe that kind of information.
[Ian] I could see that as a possibility.
[Brad] There are a lot of things there in the HSDL document. As you can see the document is 106 pages long. As Adam said, just to put a perspective on it, this document was written quite early in the life cycle of 1149.1 and this language was written to help resolve tooling issues that TI had at the time with their internal stuff that they shared publicly. So it is somewhat dated and may need to be revised or addressed to deal with the issues of today, but I thought it was a good starting point to get people to start looking at the problem domain aspects and this document, I thought, was extremely well written to describe the various types of configurations that hierarchies would have to describe. If anything, it is a very good reference for the SJTAG committee to be able to use to understand the problem domain even better.
[Brad] What I would like us to look at in the future, as well, are some additional languages that may even point to problems that we have with our existing vector languages. One of the items that maybe next week is Gunnar Carlsson�s STAPL++ that is trying to deal with some of the aspects of concurrent operations that can take place on a board and that is especially true when you get into thinks like having multiple BIST blocks within a particular device and you want to be able to run as many of these BIST operations of the Memory BIST, for example, on as many of the memory blocks within an ASIC as possible, concurrently, but being able to define that in a way that is going to be useful and then managing it from a hierarchical perspective on how you get connectivity to that kind of information in managing the chain structures. So HSDL gives us some insights on how to actually get to that information.
[Brad] What I would like us to look at in this next week, before next meeting, is try to do the two sided contrast of is it able to be described up front, with HSDL or some other kind of language, to be able to define what a topology looks like or should it be something that the tooling should be able to figure out from the information available, like the CAD netlist , the Bill of Materials, and things like that. Where can we rely on automation and where do we have to rely on manual intervention by some sort of a description or some sort of description that could be machine generated? That is some of the homework I will ask you guys to look at as we go through this next week as we go before the next meeting.
[Tim] Brad, the HSDL document you are referring to, can some of that be put on our web site?
[Ian] Well, it is not ours. So we can�t just copy it.
[Tim] I thought you said it was public?
[Ian] I think, technically its ASSET�s asset.
[Brad] It is copyrighted by TI and now ASSET InterTech which is shown on the document cover sheet. It is copyrighted in 1997. We could put a link to the document from our site.
[Tim] OK. So you are saying ASSET already has it on their web site?
[Brad] Yes. The link I sent in the reminder message for this meeting is the link to the ASSET web site where that is available. It is in a section that is labeled publicly available information or free information, something like that.
[Tim] OK. I gotcha.
[Adam] Certainly, we wouldn�t take any issue with providing a link and, in fact, I don�t have any legal authority to do so, but I don�t see any reason why ASSET wouldn�t allow the document to be distributed through the SJTAG site. I can seek approval for that if that is of interest.
[Brad] I think with the technologies we have, a link is just as reliable as having a copy.
[Ian] It�s not going to make it any faster to get at, really. There is no point in propagating multiple copies of things across the web.
[Adam] That sounds just fine to me.
[Brad] I would be more concerned about revisioning and things like that. I would rather have a link that you guys are maintaining with your revision control and just reference that instead of having to manage a revision locally.
[Adam] Very well.
[Brad] I am looking at my time and I have 9:20. I think we have come to a time where we can stop our discussion on HSDL. If we want to pick this up some more as people get more familiar with it, that is perfectly fine. I wanted to get it out at least today to be able to provide some sort of an overview of the language and to get people familiar with it so they can look at it in a better light than just seeing this large PDF file. Adam, I am glad that you joined to be able to give us some historical perspective to it and to be able to share some things as to why things were done the way that they were done at the time, especially regarding the issue of the dynamic path. I was familiar with that problem being I was involved with an early phase of it, but I was not sure everyone else was familiar with why you guys chose to go the route that you did for the dynamic path definition.

5. Schedule next meeting

Monday, September 15th, 2008, 8:15am EDT
Wednesday, September 24th, 2008, 8:15am EDT

6. Any other business

- "New Electronics" article
[Ian] The copy deadline was the 10th, Wednesday. The last I knew, Vanessa hadn�t been in touch with Heiko.
[Heiko] Yes, she did talk to me, I believe it was Thursday. Basically focused on question number eight and some similar issues.
[Ian] I must have gotten the bigger part of the interview then.
[Heiko] I think you did, yes.
[Group chuckles]
Brad addressed caution regarding sharing with interview. His legal advice given to him was to make sure the interviewer knows what hat you are wearing (corporate or working group) for you interview questions so you don�t get in trouble with your own legal departments. Brad is going to contact Rohit to find out if there is an IEEE policy regarding interviews with media for working groups.
- SJTAG newsletter was sent out last week.

7. Review new action items

[Brad] What I would like us to look at in this next week, before next meeting, is try to do the two sided contrast of is it able to be described up front, with HSDL or some other kind of language, to be able to define what a topology looks like or should it be something that the tooling should be able to figure out from the information available, like the CAD netlist, the Bill of Materials, and things like that. Where can we rely on automation and where do we have to rely on manual intervention by some sort of a description or some sort of description that could be machine generated? That is some of the homework I will ask you guys to look at as we go through this next week as we go before the next meeting.
Brad to contact Rohit regarding IEEE policy for interviews.

8. Adjourn

(Moved by Ian, Second by Heiko)
Time of adjournment: 9:28