IEEE 1149.4 Mixed-Signal Test Bus Working Group Meeting Minutes for May 5th, 2000 8:30AM-4:00PM Meeting Agenda Time Topic Responsibility 08:30am Arrival and Introductions Adam Osseiran 08:35am P1500 CTL Status Rohit Kapur 09:05am Approval of October 1st, 1999 Minutes Adam Osseiran 09:15am Standard Printing Status Adam Cron 09:45am Language Definition John McDermid 10:15am P1500 Hardware Task Force Status Lee Whetsel 10:45am STIL and IEEE 1149.4 Greg Maston 11:15am Marketing the new Standard Adam Osseiran Adjourn for Lunch Thank you Bob and 12:00pm EMC2 02:00pm ABM/ATAP Design Issues Steve Sunter 02:15pm Industrial Application status Adam Osseiran 02:30pm Language Definition (Con’t) John McDermid 04:00pm Adjourn Adam Osseiran Meeting Attendees Name Company Sponsor Adam Cron Synopsys Rohit Kapur Synopsys Adam Ley ASSET InterTech Greg Maston Fluence Technology John McDermid Agilent Technologies Elbert Nhan Johns Hopkins University Adam Osseiran Fluence Technology Bob Russel EMC Steve Sunter LogicVision Tony Taylor Synopsys Lee Whetsel Texas Instruments Sending Regrets: Dan Dandapani University of Colorado at Boulder Frans de Jong Philips Keith Lofstrom KLIC Ken Parker Agilent Arrival and Introductions Adam Osseiran showed the revised meeting agenda and announced that Rohit Kapur, Chair of the P1500 CTL (Core Test Language) Working Group (WG) would kick off today’s meeting by presenting an update of the P1500 CTL activities (Viewgraph VG1). Another notable change to the original meeting agenda is the presentation of the P1500 Hardware Task Force Status by Lee Whetsel later in the day. P1500 CTL Status Since the slide presentation was not intended for the uninitiated audience, Rohit opened by providing a brief introduction of P1500 CTL to the Dot-4 WG. IEEE P1500 is standard for embedded core test (SECT) still under development. The scope of P1500 entails developing a standard test method for integrated circuits containing embedded cores, i.e., reusable megacells. This method will be independent of the underlying functionality of the integrated circuit or its individual embedded cores. The method will create the necessary testability requirements for detection and diagnosis of such integrated circuits, while allowing for ease of interoperability of cores originating from distinct sources. This method will be usable for all classes of digital cores including hierarchical ones. The purpose of P1500: There is currently no defined standard for testing integrated circuits containing embedded cores from multiple sources. Typically, each core provider builds some testability hooks into the underlying core. Without an independent, openly defined design-for-testability method, core integrators cannot automatically determine the testability features of the individual cores and integrate them with the testability of the next level circuit description. The test method will provide a solution that will allow automatic identification and configuration of testability features in integrated circuits containing embedded cores. Basically, CTL is a System-on-Chip (SoC) test methodology providing a means of communication between core providers and SoC designers. We need a unified way of representing the core. Simplistically, the hardware is 1149.1 with the TAP as its basic structure. The software is a superset of BSDL -- the core provider supplies tests that come with the cores that need to be mapped with chip boundaries. We need to specify the requirements. An example: connection to another core. It may require some complicated sequence of events. The requirement is for test patterns to be used on the chip level. The boundary CTL can provide enough information about the register/wrapper for EXTEST. We need to therefore define a structure. Then we need to take the patterns from the core to the boundaries. If I took a design and drew a boundary within reason, all we really need to do is define CTL on that boundary. If I could do that for any random design, then my core is testable. The key for CTL is to be test-method and design-independent. All this seems ambitious but Rohit said the P1500 WG believes they have got a handle on it. The members on the P1500 task force are core providers: Brion Keller (IBM), Maurice Lousberg (Philips), Tony Taylor (Synopsys), Paul Reuter (Mentor), and Douglas Kay (Cisco). Rohit announced that all P1500 slides presented in this meeting (and all the other slides and materials such as tutorials and meeting minutes for previous P1500 meetings and the one held in parallel to the Dot-4 meeting today) are available on the following password-protected web site: http://grouper.ieee.org/groups/1500/ctl_private/ Login: ctl Password: p1500ctl Viewgraph VG2: We need to define modes (those that require patterns and those that don’t). This can be done in the Environment mode as seen in the code. One mode can be the "parent"of another mode. There is a "static" mode, and there can be a parent-child relationship. In a mode, you define everything that is required to run in that mode. There will also be a Dot-4 mode, but before that can happen, the P1500 WG will have to work with Dot-4 WG. Specifically, it is necessary to work on analog issues with Dot-4. One way to implement Dot-4 is in the wrapper. Rohit said P1500 would like to handle the analog aspect natively. What is our basic requirement to describe test patterns that come with cores? It would make sense to utilize familiar concepts and formats. Pick a standard format and build on it. Work closely with STIL (Environment block, for example). John McDermid asked how that is related to BSDL. Rohit replied that BSDL is just a small subset of the P1500 scope. The intent is to fully characterize cores. Rohit mentioned his group is currently testing a real core with 1149.1. He also attended a meeting on STIL, focusing more on the CTL part of P1500. Rohit said there is an entity inside a core. One can describe the insides of the core in Scaninternal{}, things outside in External {}, and pattern information in PatternInfo{}. John asked about P1532. They are handling their language through BSDL extension. Rohit said he’s not up to speed on that. Viewgraph VG3: This viewgraph contains information that is describable in CTL. For example, there are Internal and PatternInfo blocks in which all the cell/pin, pattern, and power information is described. The structure is intended to be flexible so that modifications to say, patterns, in the future can be made in the PatternInfo block. Viewgraph VG4: Rohit said understanding of P1500 CTL can be enhanced by examining an example. The viewgraph shows an example core with access terminals on the periphery of the core and a wrapper around the perimeter. The objective is to describe everything about this core. That can be done by describing the wrapper. Viewgraph VG5: The CTL code for the example core in the previous viewgraph is shown. The scan chain is the wrapper. The core terminal labeled "wsafe" is scan enable. With the wrapper, we need to describe the boundary. It is necessary to describe how to scan registers. This description can be placed in the ScanStructures block. The MacroDefs block can then be used to define a macro on how to scan the registers. Now on the left-hand side of the viewgraph, under PatternInfo{} the ScanStructures structsUsed line is defined on the right-hand side. Testing a core with a scan chain constitutes INTEST, but what about EXTEST? Viewgraph VG6: This viewgraph shows the code necessary to perform EXTEST for input and output pins. We can handle any combinational logic in between. As can be seen, this is a simple case and involves simple context. More complicated cases would mean more involved context. Viewgraph VG7: Characteristics of test data are described in the Header and Signals blocks. Viewgraph VG8: For this CTL example, we need to define a mode called "Isolate Mode." This is where what exactly needs to be done to remain in this mode is described. For example, one would need to create a pattern to set up this mode. It could be cycling the TAP controller. At the end of the cycling, it would then be necessary to fix the pattern and configure the mode. Whatever logic value the pins are in at the end of cycling, use it. You can also create any sequence of events to do what you need to do. This particular example only requires one vector – one line of code. Viewgraph VG9: The current status of P1500 CTL is that the syntax for deterministic tests are completed and input is provided for part 2 of the overall document. Viewgraph VG10: There are still a lot to be done. This viewgraph lists the tasks to be accomplished in the near future. The WG still has to write CTL for an ARM core. Steve Sunter pointed out that Rohit hasn’t touched the subject of analog yet. Rohit said he needed help in handling analog portion. Right now, P1500 is focusing on the digital side of things to be standardized. At present, they can handle 1149.1 in the P1500 structure. There is still a need to define tools that will be needed in the future and also to handle analog "natively." Adam O. said Rohit mentioned P1500 would like to be a superset of BSDL. John said he would like to see ABSDL involved. Rohit conceded he was not yet up to speed on this. Adam O. said the group is currently working on ABSDL, which is an extension of BSDL. Rohit said he believed CTL is good for Dot-4 and felt there is a good match here and would like to work closely with Dot-4. At this point, Adam C. showed a viewgraph entitled "Proposal for TTSC Language" (Viewgraph VG11). He shared with the meeting attendees what transpired during the TTTC meeting he recently attended. In the meeting, Adam C. recommended to the TTTC that BSDL be removed from the Dot-1 standard and establish a new WG to standardize ONE language for all pertinent standards. He further proposed that STIL/CTL (Standard Test Interface Language / Core Test Language) be that standard. CTL and STIL together can define 1500, 1149.1, 1532 and some 1149.4. Besides, the industry has already created some STIL writers/parsers and this could lead to one parser for all standards. Rohit said he liked what he saw there. Steve said there is a huge body of BSDL and it is not going to go away. Rohit said he hoped companies would start upgrading to CTL from STIL. He believed most people’s agendas would contain CTL in the future. He felt that lots of people are picking up on CTL. Adam C. said Dot-4 doesn’t yet have a language and would like Dot-1 to play that role. BSDL cannot describe certain things that CTL can. It would be a mess if there was no standard language like CTL. Adam O. asked if there is a solution that is backward-compatible with existing and old boards, chips and cores. Rohit said everything that BSDL needs can be converted to CTL format. CTL’s scope is much broader than just BSDL and can be used to describe internal and external characteristics of cores. Steve said the key is to define a plan of how to convert BSDL to CTL. Adam C. said he doesn’t have a plan for this yet, and that is why he is the TTTC Chair. Steve said all creators of BSDL would probably hate CTL. The best way to convert BSDL to CTL, he said, is to have an open-code translator. John said he would like to propose something like that too. Rohit said his group would upgrade and revise CTL to allow for the ability to convert BSDL to CTL. Adam O. asked what the action plan is and what Rohit wanted from Dot-4. He said Dot-4 needs to define what has to be done. Whatever Dot-4 decides to do, P1500 will respect our decision. Regardless of the course of actions Dot-4 decides to take and even if we decided to stick with BSDL, Rohit could start an activity to define the aspect of CTL that has to do with Dot-4. The only action plan now is that he could present more materials if we like and will accommodate us anyway P1500 can. Adam O. said he would like discussions to be conducted via email and preferably by the ITC meeting in September. SUMMARY: Rohit Kapur, Chair of P1500-CTL, gave a status of the standard under development. He described what CTL is and what it is all about. CTL was created to facilitate communications among core providers for SoC’s. The key points to keep in mind are: CTL is NOT BSDL (1149.1); it is a general concept and can be used independent of the specific DFT technique; it is an information model to allow for testing of a SoC; it is based on STIL and will be part of 1450.1; and it allows for the blackboxing of any core. Rohit expressed the desire to work with Dot-4 on the analog portion of BSDL. Right now, CTL can handle Dot-1 and is intended to be compatible with Dot-4 in the future. The Dot-4 WG will work with P1500 offline to jointly develop the analog aspect of CTL. Approval of October 1st, 1999 Meeting Minutes Steve asked if last meeting’s minutes were out yet. Adam O. said they were emailed out to the WG last month. Steve said he hadn’t had a chance to read them and asked what the hold up of last meeting minutes was. He even offered to write the minutes if it was necessary. Elbert replied that he was the reason for the long delay in having the minutes published and apologized. Steve asked that meeting minutes be done promptly and not two weeks before the next WG meeting. Elbert promised to have the minutes done quickly next time. MOTION: Adam O. motioned to approve the October 1st, 1999 minutes. Steve Sunter seconded. Unaminous approval. Motion carried. Adam C. presented IEEE plaques to Dot-4 officers. He will mail Brian Wilkins the plaque for Editor. Standard Printing Status Refer to Viewgraph VG12. Adam C., Dot-4’s new Editor, announced that Dot-4 has been published (3/28/00). Plaques were received and distributed to the officers. Steve said he found some typos in the published version of the Standard. Everyone in the WG is supposed to receive a copy of Dot-4, according to Adam C. Bob Russell said a copy in the PDF format would be nice and that he would prefer an electronic copy. The IEEE sells the Standard, and a price list is shown on the viewgraph. Adam C. has the Standard in various formats -- PDF, print, MS-Word, (ASCII), image files, and will add FrameMaker to that list soon. Steve asked Bob Russell what his company, EMC, stands for. Bob replied that the name is just a bunch of initials of the founders’ names. EMC is a high-tech company in MA. EMC is closely following developments in Dot-4 and is very interested in what it is doing. The company sees benefits in Dot-4 in its products. Bob himself is primarily involved in the manufacture group, not the design group. The design people are asked to be more attentive to the manufacture group’s concerns. Adam O. asked how big the company is. Bob said it’s on the stock exchange. The stock tripled last year. Some technicians that have worked for the company for the last 5 to 10 years ago are now millionaires. EMC is interested in who is implementing Dot-4 and will potentially buy ICs from them. Adam O. said we would talk more about applications. Language Definition John McDermid said Ken Parker and he thought a "Straw Dog" proposal is in order at this stage of the Dot-4 development (Viewgraph VG13). The goals for this meeting are to propose objectives for analog BSDL (ABSDL) language, define concepts an definitions, start discussion with a "Straw Dog" proposal and to seek the WG’s approval of the objectives (Viewgraph VG14). Refer to Viewgraph VG15. The ABSDL objectives are to take advantage of the existing BSDL infrastructure by using the same subset VHDL language; use BSDL language structures where possible; adopt existing mechanism for extending BSDL in analog portions; be backward-compatible with currently available BSDL language parsers; use an efficient description while preserving as much clarity as possible. Steve said it should be an easy task to convert BSDL extension to CTL. He said a second possibility is to aim for CTL from Day One. If BSDL extension cannot be easily converted to CTL, companies that are already using BSDL cannot use CTL at all. He said there are lots of things to describe in order to test in CTL. Steve and Adam C. said Keith and Ken have been raising that question all along. John said he simply took Chapter 10 and modified it. On Viewgraphs VG40 through VG42, the code that is in black is BSDL. The colored parts are for parsing. Viewgraph VG16: A package is basically a "container" inside which the chip is housed. The chip connects to the outside world through the package and pins. Pins are physical entity and pads are just BSDL constructs for pads on the chip. Viewgraph VG17: A silicon chip can be placed into more than one package type. Ports (BSDL constructs) are mapped to pins (physical entity). Ken and John assumed the connection between a port and a pin is "ideal," that is, no resistance. Consequently, residual elements are modeled between the port and the ABM should it become necessary to account for parasitics. Viewgraph VG18: The blue square and red pin are assumed to be ideal connections. Steve asked how to handle non-ideal connections. Residual elements can be logically moved from the port to the pin. Steve agreed. Viewgraph VG19: This viewgraph shows how residual elements are modeled between two ports. Viewgraph VG20: This is BSDL code for the picture example in Viewgraph VG19. This format fits well with the standard language. Again, a port is merely a language construct for a pad. Steve asked what the exact definition of a port is since all ABMs are bi-directional. John said this is not a complete definition. Rather, it is just a core construct. Viewgraph VG21: We will use STD_1149.1_1994 .all and STD_1149_4_1999.all. There is a mistake in the viewgraph, specifically, it is supposed to be "STD_1149_4_1999.all" as opposed to "STD_1149_4_2000.all," as shown in the viewgraph. Viewgraph VG22: This viewgraph shows how pin mapping is described in the language. Viewgraph VG23: The TAP and instruction look pretty much the same. They are just the standard BSDL TAP and Instruction definitions. Steve asked if the maximum frequency is 20 MHz, as suggested in the example (see the listing). Adam C. said yes, per the BSDL. Viewgraph VG24: Again, the boundary length and boundary registers are standard. Note the attribute statement for the boundary length of the Straw Dog. Viewgraph VG25: The TBIC cell definitions parallel those of DBM constructs. The syntax for AT1, AT2, reference control cell, and internal cell are shown. There are four definitions. Every ABM has four bits, Adam C. said. He added that there are names for cells, names that don’t show up here. Steve asked which cell is controlled by what bit. John said we would need to fix that. Steve asked if there is somewhere else where that information is stored. We would need to identify those four functions since they are lines of scan. Steve and John both said this is assuming we can infer from the port functions in the listing. Viewgraph VG26: ABM cell definitions also parallel those of DBM constructs using standard BSDL nomenclature. Viewgraph VG27: Here is the point where we add the definitions. Analog attributes are captured via BSDL extension mechanism. Viewgraph VG28: The switch list is a reusable description of switches in an ABM corresponding to the first five elements in table 11 and definition of threshold voltage. This is where a list of switches that goes inside the ABM is specified. Viewgraph VG29: Mapping of switches to cells. Adam C. asked if the data is bit 10. John said yes. Viewgraph VG30: The characterize cell is mapped in the TBIC_List attribute. There is also a switch list. It is associated with switches 5 to 9 in Table 11 of the Dot-4 Standard. Viewgraph VG31: It is necessary to add a threshold voltage called V_threshold. A reference port was also added. Is there somewhere in the Standard that refers to the reference port so we would not have to mention it here? Steve said there is no mention of a reference port anywhere, just where a threshold voltage should be (a percentage of the minimum or the maximum). John said the documentation rule says we must specify this. Steve said there are cases of relative and absolute references. Implicit in this switch list are those functions in the table that correspond to the ABMs in the code listing. A parameter list was added for switches. Viewgraph VG32: This is a continuation of the switch list attribute table for switches 6 through 9, similar to the table on the previous viewgraph. Viewgraph VG33: The parametrics list is a reusable list of parameters associated with a switch. These values are the last eight numbers in the 10-valued vector of model parameters (p.116 of D26). The first two parameters are captured in the switch list. Adam C. commented that this vector is a string that BSDL parses up into bits and pieces. Viewgraph VG34: This viewgraph shows how residual elements are modeled between the ABMs and their respective pins. Viewgraphs VG35 and VG36: The residual table includes all residual elements on the chip. The table includes "from" and "to" nodes that capture the indicated direction of current flow. W1 is a special construct to show connectivity. Internal nodes are prefaced with the "Internal" keyword. Steve said the "Match/Correl" column was the one thing missing from the Vth in earlier days. John said there are more than one way to interpret the match/correlation rule. In this example, Steve said each residual element has its own value. On the last page of the Standard, John asked how to interpret the documentation rules for impedances. Steve suggested that a ratio correlation be used. We might want to use the statistical definition of correlation. He said we could say something like Z1= 6*Z2 +/- 5 %. The issue is how to clarify minimum, maximum, and match/correlation. To get a feel of what all this means, Steve said Z1 and Z2 in this example could, say, move +/-10% but the ratio between the two must stay within +/-5%. These are matching resistors. John drew on Viewgraph VG35 a voltage divider with one at 10K and the other at 1K. The ratio of R1 to R2 is 10, and the ratio between the two resistors must be within some tolerance. Steve said we should not be talking about trimming since it makes the two resistors independent of each other, which is not true here. Adam C. asked what the purpose of the line W1 in the residual table is (Viewgraph VG36). He thinks there is some redundancy in how it is defined. Also, this is saying there is a port-to-cell map, and this information is already defined in the port-to-cell map in the beginning. At this point, Adam O. interrupted the discussion and asked John to pick this topic up in the afternoon again, in the interest of time and to stick to the schedule of meeting. SUMMARY: John McDermid presented a "Straw Dog" proposal for ABSDL that he and Ken Parker collaborated on. Definitions for a port and a pin are given with residual elements modeled between a port and an ABM. Standard BSDL descriptions are employed for the TAP, instruction definitions, boundary length, and DBM. TBIC and ABM cell definitions are structured in a similar manner to that of a DBM. There is a switch list that indicates the switches in the path from a certain pin to another pin. Switch parameters such as minimum and maximum resistance, current and voltage can be specified in the parametrics list. P1500 Hardware Task Force Status Adam O. asked Lee Whetsel to present the status of P1500 activities in order to determine whether there is any potential link between Dot-4 and P1500. Viewgraph VG43: This viewgraph shows the P1500 Architecture Task Force. A list of members of the task force is displayed. Lee is the Chair of the task force. There is also a list of Chairs of individual tiger teams, with Lee being the overall task force Chair. Viewgraph VG44: P1500 consists of a two-layer wrapper development process. Step 1: Do wrapper serial interface layer Step 2: Do wrapper TAM interface layer. Each has three tiger teams Viewgraph VG45: Details of what is in a wrapper: System chip with P1500 cores. The wrapper structure has serial input interface, resembling the JTAG structure. The wrapper has registers with which one can put the cores into, say, the EXTEST mode. Lee sees a natural tendency to interface with both Dot-1 and Dot-4. Viewgraph VG46: The architecture components: The wrapper has the following components: Cells, instruction register (wrapper mode control), serial input, serial control, serial output , bypass register, TAM in and TAM out. John asked what the TAM cells are for. Lee said those TAM cells are boundary scan cells to increase the bandwidth of the die. Viewgraph VG47: Proposed required instructions are Normal, Serial Core Internal Test (core test), Serial External Test (interconnection tests for wrapper cores), and Isolation (placing cores in isolate mode). Viewgraph VG48: Standard serial scan path configuration: We can map this into the JTAG structure. The only difference between this and Dot-1 or Dot-4 structure is that both Dot-1 and Dot-4 have a state machine for serial interface control. The TAP protocol is fixed in Dot-1 and Dot-4, while the P1500 wrapper can deviate from this. The wrapper is completely user-definable but does not offer too much flexibility. Viewgraph VG49: This is an important viewgraph. P1500 wrapper with Dot-1: A wrapper control interface makes the P1500 control protocol and JTAG protocol compatible with each other. It is conceivably a coordinated operation. In this way, we can move data through a chain of 1500 wrappers and JTAG wrappers. Steve said we might not need to go through the wrapper control interface if we could make Dot-1and Dot-4 AT busses and multiple AT busses common. Lee didn’t think we must have dedicated scan cells. For analog functions, there is possibly a need for them. It would be nice to duplicate the functions of Dot-1 and Dot-4. Steve said we would at least need to define an ABM that can be shared between two cores. It could be a shared/simplified ABM. Imagine two cores and an analog signal that goes between them. It would be ideal to have just a simplified ABM to control/observe this analog signal. Lee said we should minimize the sharing of cells as much as possible. One disadvantage is one cannot pre-load cells. Steve said if we could eliminate switches in analog, then we should do it. Lee said this relationship between P1500 and Dot-1 is crucial when talking about 1532 interfacing. He anticipated people taking a bare TAP state machine and interface it directly to P1500-compatible cores. Adam O. said we would define at ITC what direction we are heading in. Adam C. is the TTTC Chair and is willing to coordinate this effort. SUMMARY: The most important point of the P1500 architecture is the wrapper control interface that enables P1500 cores to interface with Dot-1. For Dot-4, a simplified ABM may be needed to control/observe analog signals in addition to Dot-1 facilities. It is crucial to have P1500 cores interfaceable with Dot-1 and Dot-4 devices since practical applications often require mixing various types of devices (e.g., 1149.1-Compliant, 1149.4-compliant, JTAG, P1500-Compliant, etc.) STIL and 1149.4 Greg Maston, the Chair of STIL WG, gave an overview of the STIL effort. He brought the Dot-4 support team with him because he did not bring any viewgraphs. Greg talked about what STIL really is. IEEE 1450 Standard was approved last year to address what a group of customers were raising as a "gigabit problem" moving data between environments. The WG started as a consortium before becoming an IEEE standard effort. There were format and language issues initially. Some people proclaimed the language was an overkill for the transportation involved. But it was called a language anyway. Now the question is where the standard is going now that it has been approved. IC vendors have a tool set and developed it over time. There is an evolutionary process through which STIL addresses ATE issues. In VHDL domain, when a new standard comes into existence, it is often quickly picked up in Europe and Japan but not in the U.S. Companies overseas would see a new standard and say they need to update their products to make use of the latest standard. There are lots of small companies out there, and some of them would find the market is there. Right now, there are a series of dotted efforts to define what STIL is supporting. There are in fact five dotted WGs. The 1450.1’s scope is for STIL to support the design environment – simulation and ATPG link to make sure it is robust and strong. 1450.2 is DC-level. 1450.1 and .2 both have solid language proposals behind them. Now they just need to do the work and get it to the IEEE for ballot. 1450.3 is an extension for tester vectoring – a sensitive area. The question is how do you take a generic environment and make it fit with a specified platform. They are now in the holding pattern, awaiting feedback from the ATE industry. Adam C. asked if the original purpose of STIL was to address how to get the test vectors to the tester. Yes, Greg said. The goal is to come up with tester rules. That would have worked before but the roles have now been reversed. Before, it was the standard-developing people dictating what the rules were. Now it is the other way around -- generation of a format for a particular tester. The goal for STIL is for the mechanism to be generic and the implementation to be tester-specific. 1450.5 is to identify the meaning and intent of known tests. IDDQ, for example, should have a uniform definition. The last point to make is that we should allow a mechanism for the extension of features and capabilities that can be adapted to specific users. We should also make sure we can test those extensions. P1500 uses this framework and fills in this format. STIL is supporting P1500 WG but definitely does not have P1500 requirements forced onto STIL. P1500 may augment but not impose requirements on STIL. Part of STIL’s efforts is to develop and foster a good working relationship supporting P1500. Adam O. asked that with so many languages already out there like CTL and BSDL, how are we going to deal with all of them? Greg said STIL is really a mechanism for moving information but does not specify the structure. P1500 identifies a set of views of how test vectors should be moved to testers. Therefore, STIL made some additions to its own standard. If Dot-4 has something that is not addressed by STIL, Greg would be happy to hear about it. Steve asked how about analog? Greg said we might have a 1450.6 to address analog issues. STIL is basically a digital environment at present. He said not very many people have asked for analog features in STIL. A support team member interjected, saying it is somewhat out of place to address analog issues when STIL is primarily digital. Steve said STIL has nothing to do with 1149.x at all. Perhaps it would help if the STIL-CTL link is explained more in detail. CTL specifies the environment block that transforms STIL-formatted test patterns that can be run on testers. STIL defines the way of transferring digital test data from its generation environment, the EDA domain, to its application environment, the test equipment domain. In other words, STIL is vector data and how it is supplied to chips. One of the directions STIL is headed in is test interface language for embedded cores, which is where CTL comes into play. This extension is a joint effort between 1450 and P1500. P1500 uses as much STIL as possible but adds two elements to STIL. New key words are defined to augment STIL to describe test aspects specific to embedded cores and the P1500 wrapper. In addition, information model is created that allows for defining the various configurations of the cores (i.e., 1500-Compliant or 1500-Ready). CTL is all structural. STIL is just vector data. Steve said we would not need anything specific to Dot-4 in STIL. There is no need for STIL to do anything for Dot-4. Adam C. disagreed saying that is not true now with the current form of STIL. Steve said no one in Dot-4 would have incentive to help out STIL on linking Dot-4 to it. Steve thinks STIL does not need to know anything about Dot-4. John said let us keep CTL and STIL separate but at some point down the line we might want to marry them. Steve reiterated there is nothing that needs to be done to help STIL in defining an analog extension. Greg said in 1450 the goal is to come up with a standard that people can all make use of. Right now STIL’s stand is that no one in the analog world should force analog rules onto STIL. Adam O. said we still have to resolve the ABSDL issues before worrying about CTL and STIL. Greg is still waiting for companies out there to stand up and say they want analog features to be standardized in STIL. Steve said we should wait until CTL is further developed before a test language can be fully defined. For analog cores and their associated test methodology, the question is how do you make it so that you would not have to sit down in front of the tester and re-architect a test program. STIL has 15 different top-level blocks, and the basic structure is simple. Steve suggested that Dot-4 merely need to focus on CTL-Dot-4 defining the structure and leave the language part until later. SUMMARY: Greg Maston, Chair of IEEE 1450, briefed the Dot-4 WG on STIL, the standard test interface language. The basic question is what STIL can do with regard to Dot-4 since STIL is currently a digital-oriented test language. There are still debates on whether STIL needs to be concerned with Dot-4 or vice versa. Greg made it clear that he would like to work with Dot-4 but would not be inclined to have analog rules imposed on STIL. The STIL-Dot-4 issue is still up for debate, and no decision was made regarding a plan of actions. Marketing New Standard Adam O. suggested doing training and tutorials at conferences and symposia. At ITC, Steve said there will be three separate tutorials, all related to Dot-4, by Ben Bennett, Gordon Roberts on analog testing, and Steve himself on analog aspect of Dot-4. Adam O. also liked the idea of putting out brochures. Dot-1 was helped tremendously by companies embracing it when it first came out. But for us we need to advertise our Standard through brochures educating and making people aware of it. Some people don’t even look at conferences. We may need to go to specific people and tell them about Dot-4 and how it can benefit them, or maybe sell the Standard as a complementary part to Dot-1. We could come up with perhaps a two-page brochure with some nice pictures and text. Adam C. will put things on the Dot-4 web site in html format so people can easily print off the web site instead of downloading files. Adam Ley said in terms of marketing, we need to know who the target is. Adam O. said the target is everybody in the telecommunications and computer fields, test engineers, designers at the board and chip level. Steve said we need to put some incentives in it for people to adopt it. Steve said Dot-1 got a pair of helping hands from Motorola showing how Dot-1 could benefit chips. Adam L. said we perhaps need to target two groups: People that design mixed signal chips and people that design boards (designers, engineers). Steve said we would need two separate brochures, one for each group. The brochures would clearly outline the benefits specific to each group. Adam O. said we need to design attractive brochures. Adam L. said maybe people have to feel the pain before they would adopt Dot-4. It could take ten years, who knows? For Dot-1, there were people that envisioned potential benefits before they felt the pain. Adam L. commented that Dot-1 solves application problems but not automation. John asked if we should say something about commercialization . This would be a powerful motivation. Adam O. said it might happen as testing becomes expensive. ABM/ATAP Design Issues Viewgraph VG50: As design issues come up, companies are going to work out their own implementations and solutions to them. But as a WG, we need make sure solutions are known. Viewgraph VG51: Some companies have specific rules regarding things like not using a transmission gate to drive an input. All CMOS transmission gates have a SCR structure that could latch up. You don’t do ESD test because it is a destructive test. But latch-up test is nondestructive. Steve said Keith Lofstrom believed this is not an issue. Adam O. asked if there have been any tests done for latch-up and ESD on chips. Steve said he would like to see somebody report a latch-up test if one was done. Matsushita and Keith’s chips are good candidates. Adam C. chimed in, saying that nobody has done this yet and everybody is gunning for bandwidth. Adam L. said latch-up is not necessarily destructive but can be. As far as capacitance is concerned, CMOS inverter mission mode capacitance can be an issue for high-speed applications. Steve asked John when an ABM is in mission mode, would the diffusion capacitance be the only issue? John said it could "kill" some mission mode signals. With regard to leakage, Steve does not think it is an issue but left it in there for completeness. Adam L. asked if CMOS transmission gates are required in implementation. Steve said it is the most practical implementation, not necessarily required. We could use buffers but they are not bi-directional. On the other hand, transmission gates are bi-directional and therefore more flexible. The rules were written so you could use all buffers if you want. Viewgraph VG52: Buffers have three issues: 1) For measuring voltage, must have a high impedance input; 2) If you monitor the voltage outside the rails, you may go 100mV beyond the rails; 3) Non-linearity has to be less than 1%. A standard op-amp utilizes differential-pair p-channel transistors. It can handle voltage at Vss and below. N-channel has the same problem but at the opposite rail. Right now, the op amp has insufficient range. In the standard amplifier figure in the viewgraph, there are two resistors as shown, and they need to be greater than 10 MOhms. However, 1 MOhms is more practical. In the third figure, the device can handle any range above and below the rails. This device was the subject of a 1995 VTS paper by Steve himself. Steve said the voltage-out-to-voltage-in ratio is very NONLINEAR. However, the current-out-to-voltage-in ratio is very linear. Normally, people use inverters in the voltage-out mode and not current-output form. If a unity gain buffer is used, the output cannot follow the input below Vss. So, we need something else. The point is there are problems with every device/possibility. Use transmission gates, which happen to be the most practical devices. There are shortcomings with every option. Steve asked if there are any suggestions or comments of new options besides the ones mentioned here. The third option is the AB2-to-AT2 ATAP buffer. It is tristatable. The gain is 0.01. John said the original design for this was for the pad to go to virtual ground. So we could get up to 100 MHz bandwidth. Any open-loop op amp can be turned into a closed loop amplifier. AT1 and AT2 need to be separated by a ground. For more information, the interested reader may want to check out the VTS paper. There is no patent for that. Adam L. asked what exactly the problem with the transmission gate. Steve said it is the enormous capacitance with the gates. Are there any other possibilities of how to buffer signals? Viewgraph VG53: Dot-4 has no description for an enable for multiple outputs like Dot-1 does. Adam L. advised to keep it that way. In the normal operation mode, four outputs are controlled by one control bit. Steve said we are using exactly what Dot-1 has. He said Dot-4 will need one enable bit for each of the four outputs. He was thinking of the designers that would like to put Dot-4 in their digital cells. The question is do they need to have an enable boundary scan bit on each of the analog pins. Steve proposed mapping multiple ABM control bits to a single bit. What are the implications? In High-Z, there would be no changes. For simple interconnect tests, the same Dot-1 controllability/observability is achieved. Dot-1 does not generate vectors that are unsafe in exchange for a slight loss in fault coverage. If multiple drivers are driven by one bit, and if one of those is constrained, then all drivers will need to be turned off. Adam L. clarified by saying that giving up on a little bit of lost coverage will buy you additional coverage of Dot-4 in terms of the capability of measuring resistor values. Can you get away with not including a control bit for every driver in this example if you wanted to implement Dot-4? This is an example of implementation of Dot-4 on digital bits. It seems that it fits perfectly into what we are doing. One cannot do one-and-zero testing when doing parametric testing on a specific enable group. This is causing problems in Dot-1, especially in ASIC designs. ASIC designers of play hard and loose and may enable 100 drivers with just one bit. SUMMARY: Steve Sunter presented some ABM/ATAP design issues. He wanted to make sure some common design issues and their solutions are known to the public. Design issues include ESD/latch-up, transmission gate capacitance, leakage, buffer vs. transmission gate, and common enable signals were discussed. Industrial Applications Status Viewgraph VG54: Mani Soma was supposed to give this talk but was unable to be here at the meeting due to a mix-up in travel plans and to the impression that the Dot-4 meeting was going to be held on Thursday. Therefore, Adam O. was the presenter in place of Mani. Adam L. asked with whom Steve is currently working at National Semiconductors (NSC). Steve said he does not want to divulge the individual’s identity before doing significant work with regard to a Dot-4 project. Adam L.’s company, ASSET, is involved in this too. However, Steve is working with NSC on actual chips using Dot-4 and trying to prove some concepts. Viewgraph VG55: Mani is working with a company in high reliability space applications. Complex mixed signal systems are involved with the voltage range between 3 and 48 V. Mani does not want to reveal the name of the company, but this is a real-life industrial application. Viewgraph VG56: More than 200 test points in an older system were used for extensive parametric tests. Manufacturing tests for digital subsystems, and functional tests for analog/mixed-signal subsystems are defined. The intent is to identify faulty chips or components. Viewgraph VG57: Using Dot-4, test points were reduced, and digital manufacturing tests and parametric measurements of passive components are guaranteed. A partial solution to the diagnosis problem was proposed. Viewgraph VG58: The specific Dot-4 implementations include the "early capture" feature to obtain signal information at pins and BIST on new ASICs. Proprietary instructions were added. Viewgraph VG59: A current status was presented. A prototype system was demonstrated to customers. Selected technologies are implemented in subsystems. No tester with Dot-4 tools is presently available. A large amount of effort has been invested in test program development. Steve said the current software does not handle resistors and capacitors, and we would have to manually go in the software and instruct it to treat resistors and capacitors like simple interconnects. The system is real and has been used. It is indeed good news that Dot-.4 is being used in industry. Adam O. told the WG that he called Panasonic and inquired about its Dot-4 applications and application news. He tried both the offices in Japan and CA but kept getting bounced emails. He asked John if there is anything new at Agilent. John said no. He said the lack of companies using Dot-4 at present is exactly why we need to aggressively market it. Adam L. said the industry is still waiting for ABSDL to come along, and there is nothing equivalent at ASSET to grab onto. ASSET and other companies can implement ad hoc languages but until ABSDL comes out, that is when the rubber really hits the road. Adam O. agreed with Adam L. saying the next step is ABSDL before anything is available. John also concurred. Adam O. recalled PHILIPS saying they would do something with Dot-4 but have no tools or chips. Adam C. suggested sending emails to the ESD and Dot-4 reflectors that reach approximately 600 people. Adam O. said he needed to know who are on the reflectors. Adam C. will provide him with the information. Steve said the end of June is the first "tape out." If they missed the target date, it would have to be the end of August. He will let the WG know what happens with the NSC project. He expected to get the silicon by the September ITC meeting. Steve is doing it on his own and in his own time. He said it would be a lot of time and effort to train people so he might just as well design the chips himself. He said all he did was take the equations right out of Standard. He will get help from his company to put the whole thing together and then put vectors on it and see what happens. Language Definition (Con’t) We resumed the John McDermid presentation from this morning. Viewgraph VG38: Concerning the residual elements, the way the Standard is worded, we do residual elements for the entire chip. But we could define something called "terminal." The concept is that we try to reuse as much as we can. Perhaps we could come up with a construct that says there is nothing in between ABM2 and the Y terminal. Adam C. said W1 is neither a port nor an ABM. There is redundancy here. John said the key point is if we had a residual between ABM2 and Y, then we need to define "ABM2 to Y." Adam C. said we could use the pin table to define the W1 wire and not have to mention it in Residual Table. John, however, was more concerned about the case where ABM2 and Y are connected (the case in which there is something between ABM2 and Y). Adam C. proposed removing W1 wire saying the connection between ABM2 and Y was probably already mentioned elsewhere in the code. John said he is easy on that. It should be kept in mind that when we do that, we are making an implied connection in the pin table. The thing John looked for is the concept of a network. We could make a table of networks. We should think about this and decide what to do. Viewgraph VG37: John said he wanted to ask Steve if no documentation is required for S7n, S8n, S9n and S10n (n=1,2,3,..) John said he didn’t see it anywhere in Standard (S7n means Switch 7n). These switches can be found in Fig. 50 in Chapter 10. John said it is not specifically called out in Chapter 10. Switches are not called out for any TBIC. We need to think through this and decide. Steve said there is no way to verify impedance between two switches. You can only measure impedance between two pins. John said when writing BSDL, there was nothing saying he had to worry about the issues. Is that true, he asked the WG? S5 and S6 are explicitly called out in Table 11, but not S7 through S10. John just wanted to point out the grey areas. We do not need to solve it now. Rather, the point is that we should be aware of these issues. Viewgraph VG39: John showed the proposed next steps. A vote on the objectives of analog BSDL is in order. "Ruminate on" and discuss the "straw dog" over the email reflector proposing changes as required. Generate clear statement about how to obtain specification limits from "Match/Correlate." What needs to be done with switches S7 through S10. Finally, decide how to treat residuals. Steve said S9 and S10 are clamp switches. Therefore, there is no need to worry about them. S7 and S8 are from pin AT2 to pin AT1, or from pin AT1 to pin AT2. These 2 cases will cover it. In the table, it does not say this is a complete list. Adam O. asked if these cases were added whether that would cover everything. Steve said yes because we do not care about clamps or need to know clamp voltage values. Clamp voltage and impedance shall not affect our measurements. So, there is no need to worry about them. Adam C. asked if we should add two more lines to the table for AT1 to AT2 and AT2 to AT1. In the Standard, below table 12, there are items d, e, and f in Section 10.2.2. For f, there is a TBIC following the partitioning. He suggested that the WG should add both things to the table and make those a rule. Steve said there should be two more example lines for AT1 to AT2 and then we can call it a complete table. Adam L. will give his comments from a Dot-1 perspective on the straw dog through the reflector. He again urged that ABSDL be completed. He asked Adam C. to put his Viewgraph VG11 up on the projector again. Adam Ley’s initial comment was that it is overly general. He said he would tend to disagree with the contents of the viewgraph. The main reason CTL is developed the way it is now is that there is a need to have vectors for cores. Eventually we will see Dot-4 used in a silicon core rather than as a packaged chip. What we need to do today is to understand the boundary access to Dot-4 entity so we could do some useful things with it. Just like we don’t have packaged vector for Dot-1, we don’t need packaged vector for Dot-4 either. Adam C. asked Adam L. if we should expand BSDL in Dot-1 instead of coming up with just one common language for all standards? Adam L. said yes. He added that the CTL folks would say they would do everything we asked of them but Steve said they haven’t promised they would do anything for analog. That is the only thing they will not do. Adam O. asked everyone to visit the P1500 web site to learn more about CTL. Adam L. encouraged Dot-4 to get into CTL. For the long term, he said Adam C.’s proposed TTSC language is on the right track. Adam L. does not think the timing is right at this point. Dot-4 and P1532 need to move forward with the extension. It’s in everybody’s interest. CTL is not done yet, Adam L. said even though the CTL folks might think they are done. Steve said this is like Dot-4 two years ago but we were talking about analog, which is not trivial; so it is understandable. Adam C. thinks we should bring CTL along. MOTION: Adam O. motioned to adjourn the meeting. Adam C. seconded. Unaminous approval. Motion carried.