Atlantic City, NJ
Generously sponsored by
||Arrival and Introductions||Adam Osseiran|
||Approval of May 5, 2000 Meeting Minutes||Adam Osseiran|
||Update on an 1149.4 Test Chip||Steve Sunter|
||Industrial Application Example (Medtronic)||Charles Meyerson|
||Description Language Status||Ken Parker|
||A UTL Unified Test Language)||Rohit Kapur|
||Lunch – Thank you Synopsys|
||Review of Standard Document||Adam Cron|
||Marketing through Tutorials and Training||Adam Osseiran|
|Jeff Butler||National Semiconductor|
|Frans de Jong||Philips Research|
|Ken Filliter||National Semiconductor|
|Elbert Nhan||Johns Hopkins University|
|Adam Osseiran||Fluence Technology|
|Ken Parker||Agilent Technologies|
|Jose Machado Silva||University of Porto/INESC|
|Mani Soma||University of Washington|
John Andrews, National Semiconductor
Carl Barnhart, IBM Corp
Keith Lofstrom, KLIC
Katsuhiro Hirayama, Panasonic
John McDermid, Agilent Technologies
Arrival and Introductions
Adam Osseiran called the meeting to order and went over the agenda. Steve Sunter announced that he had a few corrections for last meeting’s minutes. Adam O. asked Steve to defer that topic to after the introductions. The attendee introductions then followed. After that, Adam mentioned that for the agenda item "A UTL (Unified Test Language)", it would be a discussion, not necessarily a presentation item.
Approval of May 5, 2000 Meeting Minutes
Steve pointed out three technical corrections to last meeting’s minutes. They are:
Steve Sunter motioned to approve the May 5, 2000 meeting minutes. Mani Soma seconded. Unanimous approval. Motion carried.
Update on 1149.4 Test Chip
Steve Sunter said Pat McHugh, Chair of the IEEE Standard Committee, approached him in March of this year to talk about a Dot-4 chip. A group consisting of Lockheed Martin, LogicVision, and National Semiconductor Corporation (NSC) subsequently was formed and came up with a Dot-4 chip.
Refer to Viewgraph VG1 for the general features of the Dot-4-compliant IC and its current status. Adam Cron asked if Lockheed and NSC would disclose information about their involvement in this project. Steve said yes.
Viewgraph VG2: This viewgraph shows the design that the group settled on. There are four transmission gates that may be reconfigured as MUX/DEMUX in three different modes: Two differential 2-to-1, a 4-to-1, or an N-to-1. Chip enable (CE) was added to group various functions together and to allow the IC to be used as nine floating analog probes. The on-resistance is 20 Ohms nominally. Ken Parker asked if the gate shown in the viewgraph whose output is CE is really an exclusive-OR gate. Steve said yes. It is for flexibility. Adam C. asked what the package style is. Steve said it is housed in a 20-pin SOIC, through-hole. Adam O. asked what the supply voltage level is. Steve said 5V, for convenient use in most systems. It was chosen because it is a popular power supply voltage level.
Viewgraph VG3: We can do high-speed capture with this architecture. All switches are transmission gates. Adam O. noted this doesn’t have a differential mode. Steve said there is an optional mode that allows AB1 and AB2 to be used as two differential lines for off-chip probing. There is no explicit switch for it. The exclusive-OR gate is for disconnecting the core, which could also be done with TAP control. Threshold is implicit, Steve said. Jose Machado Silva asked about the threshold. Ken said it is technology dependent. Adam C. asked about the AND gate with one input connected to EN. Steve said it enables the gate in half-TCLK cycles. Ken said for the AND gates there will be no mid-rail current flows.
Viewgraph VG4: There is really no need to do INTEST on this chip. It was added just for completeness so we could experiment with it. However, it is non-trivial. Steve said the digital pins are driven by boundary scan, and that signals are not left in the mission mode. ABMs are in the path of signals to the core. In INTEST, putting an ABM on a digital pin does not make it an analog pin but it does allow it to be parametrically measured. INTEST says you can go high impedance on the output. The bottom line is Dot-1 and Dot-4 can coexist on this chip. Adam C. asked whether we need to document the digital pins. Steve said the Standard explicitly says digital pins follow Dot-1 rules and analog pins follow Dot-4. Even so, Adam C. wanted to know whether we still need to document digital pins with ABMs in them. Steve replied, saying it is not necessary. He said there are two INTEST instructions: 1) If a pin is driven by boundary scan, then it is a Dot-1 pin; 2) Assume all pins are analog. Ken suggested that people might have different interpretations of the rules. Charles Meyerson agreed. Steve said he chose to interpret the Dot-4 rules his way and would welcome discussions on his interpretations. It was apparent that there was confusion arising from the various ways Dot-4 could be interpreted.
Steve said one could argue that this test chip does not implement INTEST exactly as Dot-1. In Dot-4, it says one does not need a digital boundary scan between analog pins and digital core except when in INTEST mode. Dot-1 says it is necessary to have a digital boundary scan regardless of the mode one is in. Mani said he thought Dot-1 was going to make itself more compatible with Dot-4. Ken, who was asked to comment on this, said that in spirit, you could say this Dot-4 chip’s INTEST does not follow Dot-1’s because there are some digital pins that are not observable.
A question was raised about a situation where if we don’t have INTEST, would we still need the DBMs for analog cores? Dot-4 says no, but Dot-1 says we would need DBMs there regardless. Ken said in 1993, it was written into Dot-1 not to allow any logic between the boundary and cores. So legally, this test chip does not have to have INTEST. Steve said we could not say there is no INTEST for this test chip. Ken responded to Steve’s remark by saying he would not claim this is a correct implementation of INTEST. Steve said he gave a paper on this and got questions specifically about the INTEST issue on this chip. He was broaching an issue that was more general than just with this particular chip. We need observability on digital pins to do INTEST. On this test chip, there is no such observability. Ken said INTEST might require specific actions and even manual fixturing.
At issue is the fact that Dot-1 says we do need the DBMs between digital pins and the core but Dot-4 says they are only needed in INTEST. Steve pointed out a correction on Viewgraph VG4: the analog busses go to all pins. Every pin has an ABM on it. Steve said the reason he said there are only 9 analog probes instead of 11 is that two of those are used for power and ground.
Viewgraph VG5: Steve noted that we would probably be using a lot of analog buffers. They are used mainly in monitoring signals. We’ll probably need analog buffers almost all the time. For both low & high impedance signals, we’ll need them (refer to the viewgraph). To achieve 1% linearity, we will have to do calibration. Adam C. asked if it is real time measurement. Steve said yes. Charles Meyerson asked how to control the buffers. Steve said he is using another data register for this mode. This is an extra feature to allow turning on the buffers. Steve said controlling the buffers can be done via an extra instruction to turn the them on and off.
Viewgraph VG6: BSDL listing. We can see the different types of cells that are defined in BSDL. It is clear what bit controls what by looking at the BSDL file. Charles asked what is being captured. Dot-4 always captures the pad signal, Steve said. Ken said there are 3 uncommitted flip-flops to capture whatever you want.
Viewgraph VG7: There were lots of snags in getting the chip designed and laid out. The test chip team is currently modifying the design and will have samples for the WG. The objective is to have low-cost, low risk standard test solutions. Adam O. asked what the arrows on the pins are for. They are for usable ABMs. How much is "low cost," Adam O. asked. Ken Filliter of NSC said there are selected samples for research. It could also involve some fees. NSC will probably make about 200 samples and charge a nominal fee for them. He expected a few more iterations on the design. Adam C. added he had asked people to come back with test results and report them when they got samples but the response has been sparse except for some European companies. Turgut Abacioglu asked which company would make the test boards. Steve said there are currently no plans for test boards. Lockheed will demonstrate the chips in one of their systems but test board will not be available to the public. Adam O. said the first 100 samples would be distributed free of charge. Matsushita made 100 of their boards for the last test chip. Ken said supplying chips in DIP package would be more convenient to people that don’t have the resources to work with SOICs.
A DAC1200 board and PCMCIA card can be used to hook up to the test chip and try it out, Steve pointed out. One catch of using that card is that it outputs a voltage instead of a current. For Dot-4 we need to monitor an output current. So additional circuitry is needed for that conversion. Conceivably, a laptop computer can be used with a test board to check out the test chips, and there would be no need for a tester.
Viewgraph VG8: Lessons learned. Ken asked how much of the difficulty resulted from the TAP controller. Steve said none. A standard TAP controller was used. It is the best one out there that can be obtained. There will also be lots of flexibility. Ken commented that there has been talk about a universal TAP to achieve uniformity throughout the industry because TAP controllers are not all compatible. Steve said the TAP controller is not proprietary information and that anybody can have it if he/she requested it. Adam C. said he would like to have all TAP controllers referenced to this. Ken suggested that if no uniform TAP controller is available, there could be multiple TAP controllers on a chip. This implies there could be problems with the different controllers being compatible with one another. Steve said even with BSDL, you would still need the analog parameters for compliance to Dot-4. Things like leakages, resistances, etc, would have to be documented for almost all the signals. We need the identity of the signal captured, not just its value.
Even with Dot-1 tools, we would need to integrate those with the analog stimulus/capture. Much more effort would be required to do Dot-4 boards. Boundary scan in analog chips are inevitably more complex than digital ones. Adam C. asked why we need to document what signal is capture by the uncommitted bits. Steve replied that is how he interprets the rules. Ken said he couldn’t find the rule with a quick scan of the standard.
Charles asked about the drivers on Viewgraph VG3. Steve said the same cells are used.
Ken requested that the WG recognize and appreciate the effort and energy of the test chip team of LogicVision (Steve Sunter), Lockheed Martin and NSC.
Steve Sunter presented a test chip being developed by a team consisting of LogicVision, Lockheed Martin, and NSC. The main objective is to demonstrate the Dot-4 Standard. Major features such as Dot-4 functions, mission mode functions, INTEST, TBIC, and BSDL capabilities are included. The first-cut design was done and further iterations will be necessary. NSC will fabricate test chip samples and distribute some free of charge. An issue that was heavily debated on was INTEST. The bottom line is that it depends on how INTEST is interpreted, there could be various ways of implementing it in Dot-4. There were disagreements on how to properly implement INTEST in Dot-4.
Industrial Application Example (Medtronic)
Viewgraph VG9: (Title viewgraph) Medtronic Implementation of IEEE 1149.4. Charles Meyerson will discuss an application of Dot-4 at Medtronic.
Viewgraph VG10: Agenda of discussion is shown. Charles will talk about a test chip developed at Medtronic. He will also mentioned how Medtronic defined test data for digital ABMs and what data are captured in a digital ABM and where the information goes. Two questions were posed about the permissibility to get rid of the VH driver for a digital input ABM and to add an extension to the TBIC for buffering. Mani asked why Charles is working on this project. Charles said he is designing a cell that the company could use.
Viewgraph VG11: Wafers are in fab and due out in November, 2000. The test chip consists of the familiar features of Dot-4: TAP, 4-wire ATAP, ABMs, digital input and output ABMs and digital bi-directional ABMs.
Viewgraph VG12: Test data for digital input ABMs. Charles noted that one might put an ABM on a digital pad. He interpreted Dot-4 that way. There is a truth table for this. Adam C. commented that there was no mention of VL and would like to know why. Charles said there is no need to mention it because it is just the opposite of VH. Once VH is clearly defined, VL would just fall out of that.
How does Medtronic define test data going to the core? Since a standard ABM drives a pad to VH when C and D are both high, we may have C*D fed to the core. Test data is defined as C*D. It is a tristable output. Since DBMs use one bit to define test data, will defining test data as C*D be a problem for software tools? Charles said the core data is not clearly spelled out in the Standard. Does definition of test data need to be standardized? Steve said that suppose there was a 50-Ohm load at the pin, we’d need to treat it as an analog pin because we would not be able to drive it to digital one. In this case, Dot-4 says it is undefined for connection to the core. If there is a 50-Ohm resistor, then we can’t do that. Franz de Jong pointed out that a 50-Ohm load is functionally a short.
Charles said this is for INTEST. Steve said we could put a MUX in the pad and allow for whichever definition of INTEST we are using. It is a bit in the instruction. There are two possibilities for Charles’ design. Either a pad signal goes straight to the core or it first goes through a MUX and then to the core. Charles might be wrong about the C*D assumption. We only need a bit (e.g., D) to drive to VH. Charles admitted he is not quite clear about this. He didn’t see it defined anywhere. Steve noted that the concept of using a tristable buffer to drive VL and VH to the core has been published.
Viewgraph VG13: Capture data for digital ABMs. Charles said the test chip was designed such that pad data is captured in the DATA register. Core data is captured in the CONTROL register. Data is captured in these ways for all digital input, output, and bidirectional pins. Bidirectional pins need 2:1 MUXes in front of the data and control registers to select between the input and output signals. MUXes are controlled by the input enable line. Charles asked if this approach is Dot-4 compliant. Ken said there are a lot of cell implementations out there. Adam C. asked why there is a MUX in front of DATA and CONTROL registers. Charles reiterated that it is for selecting between input and output signals.
In response to a question about the description language status, Ken said there has not been much going on with regard to his effort on a P1532 draft, which is still an unpublished standard under development. Rohit will come in here this afternoon and might throw everything we have out. Ken said to listen to Rohit’s talk to get the scoop on the unified test language progress. Ken will talk more about the description language status later.
Refer to Viewgraph VG14. Prompted by questions about the internal structure of a cell in Medtronic test chips, Charles made a sketch of a cell and its composition.
Viewgraph VG15: Digital input ABM scenario. Here is a scenario illustrating a potential problem associated with digital input ABMs. Suppose we had Chip A with ABM cells on its digital input pins. Further suppose that we wanted to scan a test vector pattern to the inputs of Chip A using INTEST and that Chip B outputs were driving the inputs of Chip A. We however do not want to connect an analog test bus to any digital input pins because they are needed for analog tests. If we want to drive the core to a one or zero without driving the pad to VH, VL, AB1 or AB2, we would need two states where there are no logic levels or analog test bus connected to the pad. Only one such state satisfies this requirement in the standard ABM truth table – p0. Steve pointed out that adding an ABM does not make a digital pin an analog pin. It simply provides the ability to perform parametric measurements. Dot-1 says one needs to provide VH or VL to the core.
Refer to Viewgraph VG16. Steve hand drew on the viewgraph a typical situation involving a pad, the core, and INTEST in an ABM.
Viewgraph VG17: Solution is no VH driver. Can we eliminate the VH driver, Charles asked? Digital input by definition is always connected to an external driver. Steve said it is not true. Adam C. pointed out that maybe because Charles assumed C*D that the assertions Charles made on this viewgraph might not be correct. We probably should say test data = D only.
Viewgraph VG18: DBM truth table for Charles’ solution. Charles came up with a truth table for an input ABM for a proposed solution to his example situation. However, this truth table which is based on the assumption that C*D being the definition of the test data, may not be completely valid.
Viewgraph VG19: TBIC extension for buffer control. Buffering is needed on AT1/AT2 for the test bus to be more useful. The buffer type should be independently selectable for each analog bus.
Viewgraph VG20: Extended TBIC implementation. For the Medtronic test chip, four scan registers were added to the existing TBIC. Mani asked if the bits need to be documented. Steve said if those are safe bits, no.
Viewgraph VG21: Diagram depicting Charles’ scheme. Steve said the analog buffers need to be able to drive outside the rails. These can’t. Maybe a charge pump circuit is needed? Any limitations should be documented for the user.
Charles Meyerson presented a Dot-4 chip being developed at Medtronic. He designed the chip with his own interpretation of the Dot-4 rules and came up with a scenario for which he formulated a solution. However, his assumption of a C*D test data signal going to the core may not be valid since it was pointed out that only D is necessary. Therefore, his solution may not be valid either. This is why Charles would like the WG to critique his design and implementation. He will review his design and the Standard to see if consistency with the Standard may be achieved.
Description Language Status
Adam O. gave a little background on the topic, saying Ken is the editor of the P1532 Working Group. An example BSDL program for a FPGA and a PLD is shown in a PDF file that will be posted on the Dot-4 web site. Basically, P1532 is experiencing similar problems as Dot-4. Ken cautioned the WG that the example is an outdated one but it gives a flavor of what a BSDL extension looks like. The draft is evolving and changes to it are expected.
Referring to his P1532 draft, a page of which is shown in Viewgraph VG22, Ken said there are several basic issues. This is an example of another group with a similar problem -- an extension to the current BSDL. Things like leakage and residuals, and so on, Ken admitted he is not an expert in this area. Steve Sunter and John McDermid can provide more information on them.
Ken said that today’s BSDL ignores the extensions because it does not know how to handle those (an example is Viewgraph VG16). If a Dot-1 tool does not know anything about P1532 (built on top of Dot-1 and board software), then we will have reams of extra data. The idea is that there is a tool out there we do not want to disturb. We want to still have the interconnect tests done by old tools. After all, the selling point of Dot-4 is that people can still use their old tools and get more testability by implementing Dot-4. Therefore, a BSDL extension would make sense.
The cell names are arbitrary. It should be noted that cells are more than just bits. We are merely working with existing tools to try to adapt them to Dot-4. An ABM has 4 cells. Adam C. asked why we couldn’t just call the bits bus names. It is certainly an option.
In addition to extending Dot-1, another approach is to be specific to implementations. Still another option is to throw all this out and go with something entirely different.
One Dot-4 issue is that residual elements must be described. CTL may be the answer. Ken said he has not done a whole lot over the summer with regard to this. A big decision needs to be made as far as the direction of a language for Dot-4 is concerned. Steve said he went over the straw proposals and saw everything was covered in there. Ken said it is good that Steve finds it complete. Maybe there will be more issues. Ken reiterated and emphasize it is important that we try to be compatible with the past tools. Adam O. asked if we should discuss it here or over email. Rohit said he could present his materials now. Adam C. asked if the straw proposal would be the ideal tool. Ken said he’s not sure if it has succeeded in describing everything. Franz said he thinks the internal cell descriptions need to be described more in detail (referring to Viewgraph VG22). He said the "internal" cells need to be clarified to point out the fact that they are not strictly internal but do have connections to other cells and bits. Now we would have to add keywords to accommodate that. Ken said the only thing critical is that the values in the code are safe in Dot-1 for things to work. Ken said that from the discussion he thinks that if we still need to be more explicit with the "internal," we could do that with additional definitions. Steve said if you want something to be accepted quickly, it would have to be compatible with Dot-1.
A UTL Unified Test Language
Rohit talked about a UTL that is in the works -- the P1500 core test language (CTL). Until 6 months ago, there were two parts to the standard: hardware and software. We need to get away from strictly Dot-1 thinking to understand CTL.
Refer to the viewgraphs Rohit presented in the May 5, 2000 WG meeting in Montreal for the following discussion. He briefly outlined his talk that would first give an overview of the language to familiarize everyone with the topic and then he would like to discuss the issues with the WG.
Fluence Technology is not yet involved in this effort. One could potentially take a design and describe all its aspects with this proposed language. The design could be Dot-1, Dot-4, or anything else but the key is to describe the external aspects, in addition to the internal ones. The most important thing is to be general. The philosophy behind the CTL is that we should be able to take any design and draw a partition and describe everything about it, especially its inner workings.
We should test a chip using CTL and not its logic model and need to describe enough about its internal aspects to do external tests. Rohit showed an example design to be described in CTL. A design has many modes, and they all need to be described. For each mode, connections, protocol, attributes are things that should be described on a signal-by- signal basis. The test language should be able to handle generic designs and all test methods. It could be a Dot-1 or Dot-4 design. As a matter of fact, analog is our next extension, Rohit claimed. That means we will need to describe the analog aspects of a design. It should be noted that all are very top-level descriptions here.
For connections, symbols have 2-D descriptions. A protocol is a sequence of events described by vectors using macros. Attributes of signals are things such as data type, data rate, properties, relationships between signals, and standardized names of pins and cells. Steve asked if this accommodates different clocks. Rohit suggested using different sequences in that case.
How do these all fit together? The framework for the information is such that each mode has connections, protocols, and attributes. Again, a chip may have multiple modes.
Concluding his viewgraph presentation, Rohit opened the floor for discussion. Rohit said anything that has anything to do with digital should be describable using CTL. Steve said it follows that anything that is Dot-1 in Dot-4 should be describable by CTL as well. If we want to supersede Dot-1, then we would need to say CTL replaces Dot-1. The question is whether we should do it straight in CTL or in ABSDL and then convert it CTL. Rohit thinks we should do it in CTL first. Mani asked about the time frame for CTL implementation. Rohit replied that it would take about two months to do the memory BIST, which would be the first application of CTL. He needs people from Dot-4 to help out with the Dot-4 CTL. There has not been anybody that came to P1500 and asked for help. Adam O. echoed Rohit’s sentiments, saying we should do CTL first and then ABSDL. There is still the question of whether it is worth developing ABSDL. Ken said that since Rohit is almost done with Dot-1 CTL, he must have already described a Dot-1 cell. Rohit said in December 2000, Douglas Kite of Cisco will present in Asia an example Dot-1 CTL. He tried to use some of the Dot-1 capabilities. The bottom line is that P1500 has been able to describe a Dot-1 cell but a lot more testing still needs to be done. Ken said it is instructive to have people with BSDL experience look at Dot-1 CTL for feedback. Rohit would like to see a test case. Adam O. asked if there is anybody dedicated to Dot-1 CTL? Not yet, Rohit replied. The P1500 WG is currently busy with the memory BIST. Mani asked if Dot-1 people should help out on the Dot-1 CTL. Rohit said they would not standardize CTL without Dot-1 involvement and would welcome it. He added that we want to move to the system-on-chip (SOC) arena, we would need CTL, and not BSDL since the latter would not be sufficient for that type of application. Ken summarized that there are two practical questions:
Adam O. said that CTL is here to stay, and there will be a need to reconcile CTL and BSDL in the future.
Ken said the principal use of BSDL is to automatically and quickly generate tests for boards and chips. It is still not clear to him how CTL can handle and duplicate those BSDL’s functions.
Mani asked if Rohit needs some people from Dot-4 involved. Rohit said yes. Adam O. said we could arrange for that.
Rohit made a pitch for CTL and indicated that the involvement of both Dot-1 and Dot-4 would be necessary in the CTL to make it a success. The key question is whether the Dot-4 WG should go ahead with ABSDL or take a big leap to the unproven and still-under-development CTL. This decision could have a significant impact on the future direction of Dot-4. Right now, it is still not clear if CTL would be the best route even though it appears to have great potential and promise, especially as circuits continue to shrink and SOCs could become the wave of the future. A concern is that ABSDL might not be adequate for future SOC chips. The issue is a complex one and further deliberations would be necessary.
Review of Standard Document – The Editor’s Status
Adam Cron talked about the edits to the published Standard. Viewgraphs VG23 and VG24 list the issues that were documented. Adam C. said we would make these changes and publish a revision. Adam O. asked if we have to submit these to the IEEE. The errata process is standard, Adam Ley said. He added that the IEEE would do that. Adam C. pointed out that some of these are erratas and others are not. Adam L. suggested that the ones that are erratas get tagged. A note: Sample/Preload is one of the things that was revised in Dot-1.
Viewgraphs VG25 and VG26: Page 25, section 6.2.2. This one is from Brian Wilkins. Basically, Brian pointed out that it is not the pins of the ATAP that are connected to Vclamp but the internal bus lines. Adam C. solicited comments on the viewgraph from the WG.
As far as other issues concerning the language of the Standard, Charles said that on p. 45, the bits should be in a clear order. Is it easier to change the table than the bit order? Ken likes the idea of changing the picture instead of the table. Adam C. announced he has a TIF file for this picture. He could go in there and make the corrections. Charles said he had tried to implement the bits in the order shown but it did not work.
Charles found a paragraph hard to read on p. 56. The paragraph is about Vdd/2, the bias voltage and resistance. Ken said it might be worthwhile to have Steve and John take a look at that paragraph.
Adam C. said we have 5 years to make the changes. He could see nothing real serious here. Adam L. said Dot-1 has a quick standard way of handling this. He asked Adam C. to check with the project editor.
Marketing through Tutorials and Training
Adam O. said he would present these materials in England.
Viewgraph VG27: Marketing through tutorials and training. The Dot-4 web site is a good starting point. There are a few things on it already. The NSC test chip test results would be a good candidate for Bullet 4 on the viewgraph. Charles Meyerson may also publish his Medtronic work on in conjunction with Dot-4.
Ken said there must be demands for the Dot-4 Standard for it to be widely adopted in the industry. We should appeal to the IC design community to offer them benefits and to the direct interests of those guys instead of cultivating the impression of the Standard being another tool for the designers to help the test guys. That way, it would probably catch on quicker. We should have a presence at IC design conferences like DAC and other workshops and conferences. Charles said Keith Lofstrom has pretty good ideas such as capture-on-a-pin (scope-on-a-pin). Keith also has looked into the characterization of DPINs. Charles said Dot-4 could reduce pin-count testing by eliminating DPIN testing because we can attach ABM to digital pins for parametric measurements. He suggested that the WG publicize "little tricks" like extra buffers on TBIC. Ken asked why not write a paper and present these ideas. Ken said if Dot-4 can help with testing, people would definitely be interested. Ken and Adam say we could use the web site as a medium of dialog between the designers and the WG. Ken said the WG is currently invisible to the average designer. So we need to gain more visibility by perhaps doing more reflector emailing. Turgut suggested publishing papers in design and engineering magazines to get more exposure to the design community. Adam O. said this might be a good idea. He said he was at a workshop where there were designers that hadn’t even heard of Dot-4. We could start publishing in magazines like EDN and Electronic Design, which have wide circulation among the designers of ICs, boards, and systems. Adam L. said the first thing to do is contact the editor of those magazines and try to get a paper in those magazines. He noted that there was a recent article on a popular design magazine written by the editor about IEEE standards and a reference was made to the Dot-4 web site. Adam O. said we need to go find designers and try to "lure" those people to the Dot-4 web site. Adam L. agreed. By running articles with reference to our web site, it will help generate more hits on the site. Turgut suggested that when publishing in a trade design magazine it would appeal more to the designers if we throw in some practical examples and different points of view.
Viewgraph VG28: Ken’s hand-drawn viewgraph. Addressing the issue of increasing "nail-count" testing, Ken drew on the viewgraph schematics of a past board versus a future board. Could we be looking at something like this in the future? In the future, we could conceivably break a low-frequency board up into smaller clusters to reduce the pin count during testing. However, this approach would create high frequency parts (i.e., nH inductances) to the otherwise low-frequency board and that might be something that we would have to deal with.
Viewgraph VG29 shows a scenario in which a resistor exists between two chips, and another scenario in which parasitic capacitance exists between the same two chips in the frequency domain.
Ken said we need help from the industry to find out what the future boards are going to look like. We should really think about future boards. He asked Charles if he has any thoughts on this issue.
Charles said Medtronic is in a niche market; so he cannot really make any generalizations. Franz said Philips is in a similar situation. Integration is increasing, resulting in smaller boards. One thing is certain, and that is analog circuits will get smaller. He said there are still analog components like SAW filters that are still hard to test. He said we should just do a functional test on highly integrated parts. Ken said that in that case we would need to write custom software if Dot-4 is used on chips. It is not just simple R, L, and C components, he cautioned. Franz said there is always a requirement for analog and mixed signal testing.
Adam O. asked how we are going to appeal to the public. An obvious answer is we need to be actively and constantly involved in workshops and tutorials.
He asked that the Medtronic test results and the NSC test chip results be put on the web site once the information becomes available. He asked everyone to try to refer people to the WG.
As far as CTL, he would like somebody in Dot-4 to work with the P1500. Ken recommended Steve Sunter because he has the best understanding of Dot-4. Ken said Steve mentioned the straw proposal is pretty complete. Adam O. said perhaps Rohit and Adam C. could serve as representatives from P1500 (Rohit) and Dot-4 (Adam C.), since both work for the same company, Synopsis. Ken said since Adam C. is overseeing (as chair of TTTC/TTSG) P1500 as well as other groups, that he would be the logical candidate to work with Rohit on the Dot-4 CLT issues. Adam C. commented that STIL has 5 dots already. Analog would be the sixth. Tony Taylor said waveform generating needs to be worked out. Rohit and Tony said we could maybe kick off a Dot-6. Adam C. asked if there was an existing language that we could make use of. Atlas is one but it’s not quite applicable. Rohit hoped the industry moves to STIL, at least for the digital side.
Ken said STIL does not make underlying assumptions like BSDL does. He is trying to imagine a tool that would not do that. A good STIL software would fit the bill. Rohit said it is an action item to work with Dot-1 to get the Dot-1 CTL to work. He said this could be done soon. He would like to talk one-on-one with Ken on the phone to work on this issue. Ken said we should start with something that is already out there, and he is receptive to working with Rohit on CTL-Dot-1. Rohit would like to see Ken initialized to CTL so that he could make a smart and informed decision on the CTL vs. ABSDL.
Tony gave a quick overview on the STIL subgroups:
There are two ways a pattern can come out of a design: 1) ATPG and 2) Test bench data and patterns. It is nevertheless not an objective of STIL for "cyclization."
Rohit and Ken are to hook up on CTL and Dot-1 issues. Rohit will also interface with Adam C. on Dot-4 Standard issues. Rohit said we should define a starting point and then move ahead. Adam O. asked if this could be done soon. Rohit would love to have data types from analog, but that is the next phase. The immediate need is to decide for Dot-4 which way to go – CTL or ABSDL. Adam O. said we would still need to move on with ABSDL. Ken agreed.
If Rohit could prove CTL work for Dot-1 and Dot-4, then we’ll let the market decide. But Adam L. was concerned about that there are no tools to support CTL from Day One. So it might not be a good idea. Adam C. said we still need the extension. Ken said we are trying to stay compatible with the past by defining new attributes for pins. Adam C. asked if we could instead of "internal" say "extension" or something, but Ken said the current tools don’t allow for that.
The following key issues were discussed.