IEEE P1149.4 Mixed-Signal Test Bus Working Group
Meeting Minutes

Generously sponsored by University of Washington

Access the Minutes of the March, 1997 Working Group Meeting.

Arrival and Introductions

There were several first-time attendees: Lori Hamoline, Paul Spitalny, and Martin Snowden. Adam Cron reminded everyone the 3rd Annual Mixed Signal Testing Workshop would be held in seattle. Steve Sunter noted this is the only conference in the world devoted entirely to mixed signal testing. Adam said there is a change made to the Draft at the end of May. He will get copies of Draft to people at this meeting. Adam showed the statistics for the WG. There are currently about 400 subscribers. People can now log onto the web page and access the Draft and obtain news pertaining to the WG. There are more countries and more participants involved. If anyone's name is not on the official WG list, then it has been deleted. Adam announced that the March minutes are now on the Web. He reiterated the voting policy of the WG: required attendance at two of three consecutive meetings to be a voting WG member.

Approval of March, 1997 Minutes

Ken Parker moved to approve the minutes. Seconded. Unanimous approval.

New TBIC Architecture and MEASURE Ramification

There were some changes made to the TBIC hierarchical structure. Ken asked if anyone had read Draft D16 (more people had read D15 since D16 was released not long before this meeting). Both versions are similar. D16 saw typing errors corrected and comments over the e-mail taken into account.

Ken proceeded to explain how the changes came about, referring to Fig. 11 in Ch. 6 on Page 36 of Draft D16: Brian, Steve, and Ken met for a week before this meeting to talk about the concept of TBIC and drew on a blackboard the switches that are required by rule. Fig. 11 shows an essentially established TBIC architecture. The intention is to mandate the architecture as opposed to possible implementations. One can make a convincing case that the rules can be interpreted into a different architecture. That is one of the reasons why we asked that the Draft be read more carefully. When reading the Draft, try to put yourselves in a designer's shoes. Each of us has a role; so try to do some role playing here.

Fig. 12 in D16 points out that the TBIC shows there is some degree of implementation freedom to the designers. Page 41, Table 1: there may be other patterns beside what is shown in the table which should be checked more carefully. This table will be revisited. Table 2 p. 42: there are now 16 entries in the table compared to just 8 before. A 4th bit (the calibrate bit) has been added which doubles the number of entries in the table. In the "calibrate" mode, only two entries under "EXTEST, CLAMP, RUNBIST" are defined but the rest are undefined. NOTE 4 essentially said that even though the codes marked with asterisk are unused at present, they should not have anything assigned to them since the codes may be used in the future for unforeseen purposes.

In this table, every entry for CLAMP and EXTEST is identical except when in the characterization mode. There are minor differences between these two instructions. It's much easier to add another bit in TBIC and get rid of the MEASURE instruction entirely (so that the tiger team can sleep easy). Brian Wilkins put about 100 hours into this effort. We (the team) believe it's an improvement but need the WG's views on these changes. We basically need a lot of eyes to look at this to make sure we've not oversimplified it.

Adam said EXTEST and MEASURE are instructions in the instruction register and are similar to each other. We've chosen to add a bit. Brian said one question is whether the internal bus should be partitioned.

Steve Sunter on partitioning with respect to AB1 and AB2. The need to partition AB1 and AB2 into AB1a, AB1b, etc. for safety reasons, arises when designing and manufacturing large-size chips, high frequency chips, and high voltage section of a chip. Also, leakage current is important (typically in the mA range and depends on temperature). The addressing scheme for the partitioning is however not trivial. In the Draft, we showed how we can partition into 4 sections. Brian said if we want more partitions, just add another bit in the TBIC (for characterization purpose only). Steve said we need to agree on the best way to extend the capability in the future, perhaps, like Brian said, by adding more bits to the TBIC or some other technique. Ken cautioned that we should not let this to be a "show stopper." Right now, there are 4 partitions already in the Draft. TBIC is a localized area of the chip, not global. The logic equations can be modified as the undefined asterisks cannot be made no care. Steve explained to the new attendees that the reason the Draft is undefined with regard to the TBIC is because this topic has only come up during the last WG meeting. He added that he himself is part of a mixed signal circuit core working group and was trying to think of a way to take both hard and soft mixed signal cores into account in our mixed signal test bus scheme.

Adam said perhaps this problem should be left to Dot-1 to solve. Steve said another issue is cascading switches. There are now two types of switches: TBIC and AB1 switches. The switching architecture works but the question is how to control them (Fig. 14). Steve added that we need to be able to calibrate. We should not be constrained by only 4 partitions. For high leakage currents or other conditions, we can just use more partitions. The bottom line is to be able to perform calibration. Steve said BSDL will have to be able to accommodate this capability.

Refer to Viewgraph VG1: the software controlled scheme is fundamentally limited to 4 partitions while the automatic scheme is unlimited. Any number of partitions may theoretically be added to the existing partitions as necessary.

In Viewgraph VG2, Ken pointed out that adding a bit to the code will add 8 more pairs of AB buses. This is one way we could architect the structure, and we can show the 4-bit TBIC and how to extend it to additional bits.

The automatic scheme is more appealing to Ken since software does not need to know which pin is which. Keith is concerned with the break up of modularity of the ABM and the TBIC. Adam said if circuit cores are dropped into a unit, we must use the automatic scheme. Ken said each core has its own independent TBIC but if we combine them, only one will be used (the 2 independent ones replaced by the single TBIC). It's messy if we require automatic scheme and will get 2 extra global buses. Keith said maybe we can break it up into external and internal switches. But Ken pointed out this would make characterization and test less possible. Steve said, in response to Keith's comment, that it's already been partitioned. Adam reminded everyone that the issue is whether the automatic scheme should be left in the Draft. We are trying to accommodate as many people as possible. On the account of lack of experience with circuit cores, Ken will reconsider the merits of auto addressing. Keith said there may be cases where pins need to be clamped or driven by AT buses, to which Ken responded by saying we can do that with individual instructions. Ken said forget about the auto addressing and that we should deal with unlimited expandability.

Ken initiated a motion to remove "auto selection" mechanism for ATn-to-ABn connectivity for multiple ABn scenarios. Keith seconded. Brian said we need a replacement for this mechanism if it is removed for the Draft. It was then agreed that Ken, Steve and Keith would get together tonight (6/2) to work on this topic, and the topic was tabled until the next day.

Draft Review

Adam asked if anybody has a topic to discuss at this meeting. John Andrews broached the differential I/O issue on p. 47. Steve said that in Chapter 9, P1149.4 is the only IEEE standard that mentions performance, specifications, and documentation. Mani Soma said that in Chapter 6, (the TBIC organization/recommendations) a few sections should be reshuffled to produce a better flow, but the scope is broader than what can be discussed tonight.

Steve said we don't mandate input core disconnect (merely implied), but we did on output. There is no explicit language in the Draft that requires core disconnect be at an input. Steve explained that a core disconnect switch is NOT mandated, but core disconnect FUNCTION is for an input. If there is a pull up resistor at an input, then the function may not defined for all voltages. Also, what does "*" mean? Right now, "*" means don't care but it shouldn't be, Brian said; we need to define the asterisks.

Adam asked that the WG go over the entire document page by page. Brian said he will point out the changes in D16 since it has just been released. Ken suggested that we flag issue as we move along and then go back to discuss them more thoroughly after going through the complete Draft.

P. 1, Abstract: Remove one "IEEE Standard."

P. 2: Add Katsuhiro Hirayama, John Andrews, and Ted Eaton to Working Group list and remove Katsuhiro Hirayama and John Andrews from the list of those to thank for their contributions.

Pps. 6, 7, 8, and 9 have not changed for several revisions. Ken urged the WG to revisit the Overview section to take into account the most recent addition to the Draft - the cores. Keith said we will take a look at the scope and purpose. He pointed out that the cores have not been clearly and completely defined yet. On Page 9, the Bibliography can be modified to References or background reading.

P. 12: ATAP. What clarifies ATAP is Fig. 5. Section 3.3 should say, instead of " a set of pins" use "AT1 and AT2 or any combination of those two or AT1n, AT2n" since they cannot be just ANY switches. Let's be downright explicit here. Wherever we can be unambiguous and clear, we should. Ken said the newer members can bring with them a fresh perception to this review, and that is a plus.

Adam said the phrase "must be Dot-1 compliant" should appear somewhere before Chapter 10. We should make a rule out of it, and it is a very important one. Brian mentioned this in his e-mails. The latest revision of Dot-1 still says that "nothing should be on analog pins" which should be eliminated. C.J. said the latest version will explicitly say "there should be Whet cells on analog pins." Keith asked why not just say "conformant to 1997 Dot-1." C.J. said the PAR is in and Adam Ley needs to make the necessary revisions to the Dot-1 Standard.

P. 18: The Overview section did not mention that differential port is an option. The Overview only describes the test bus in general terms. Many new WG members might have flagged the phrase "analog function pin" but it became a non-issue as they finish reading the document. There were questions raised on how detailed the Overview should be. It should capture the essence of the test bus but at the same time should not be too detailed. We can say "logically, there is one AB bus but physically there can be several," but phrases like this tend to be too detailed. The IEEE will fix the format, wording, etc.

Brian said we need only put in rules that are additional to Dot-1, not repeating those Dot-1 rules. He said he will NOT put in the Draft any rules that are already in Dot-1 (since we must be Dot-1 compliant). Add a rule saying an 1149.4 chip must have a TAP.

P. 19, top of page: change "...optionally on other pins ..." to "optionally on other function pins..." Refer to AT1/2N pins in the paragraph. In general, VH and VL should be V subscript H and V subscript L, respectively.

P. 20, 4.2.3a: Delete rule since compliance to Dot-1 is assumed. Need rule stating TAP also controls TBIC.

Section 4.3: Brian said he talks about the unpartitioned structure first and partitioned later to less complicate things. Rule (a) will be deleted since it is mentioned in Dot-1. Rule (b) needs a partner.

P. 22, Section 4.4: Register Architecture. The "compliant to Dot-1" comment is reiterated to emphasize this point. Ken voiced his approval saying it's a good point.

P. 23: The contents on this page have not changed appreciably. The TRST* line did not appear in previous versions. Adam said let's put all the optional pins in there but Brian said it is fine as is. The question is: Where do you draw the line (how detailed or general you should be in showing pins and functions)? Either remove TRST* or add AT1N and AT2N.

P. 24: Steve asked what is meant by the verb "provide." A component does not "provide" instructions; rather, it "supports" instructions. But Dot-1 uses the word "provide." Steve said he wanted to see the exact sentence in Dot-1 that contains word "provide."

Ken said PROBE is now mandatory; before it was optional. A number of people think it is very handy to have PROBE. MEASURE is still mandatory but is now part of EXTEST.

MOTION: PROBE is mandatory. Seconded. Unaminous approval. Motion carried.

Section 5.2a is a superset of 5.1a; why have 2 rules instead of one. This will be revisited.

P. 25: Should we say an example is shown in Dot-1?

P. 26: C.J. said those ABMs should not be doing anything when in BYPASS mode. He said it should be worded out that is the case for digital function pins. However, this is already mentioned in Dot-1. It is guaranteed by the rule.

Revisiting the core disconnect pin vs. the disconnect function. Definition 3.6 specifies core disconnect and is contradicts with the notes on P. 27. Steve gave an example: If a 50-Ohm resistor is on-chip, there is no way to make it high impedance at core disconnect - it would require a large transistor. So just document it so the user knows there is a 50 Ohm impedance there when making measurements. The 50 Ohm impedance can be on- or off-chip; it doesn't matter. The only requirement is there should be no DC or AC sources. There is no need to specify analog or digital pins. Ken said core disconnect means everything within the dotted line on Viewgraph VG3. But there are components that may be impossible to include in the core disconnect function and therefore must be documented, e.g., the 50 Ohm resistor. We are concerned about both "the pin affecting the core" AND "the core affecting the pin." Ken said this is a good example of a word having different significance to different people with varying viewpoint. Keith mentioned there are high impedance CMOS drivers that could complicate the document. Perhaps we should give a recommendation or example. It should say in Chapter 5 that DC and AC isolated sources should be turned off at core disconnect.

P. 26, 5.3.1: Add rule b for function pins.

Add these rules to SAMPLE, PRELOAD, IDCODE, and USERCODE also.

Steve said the rules for EXTEST are sort of a hodgepodge. Rule c, for example, does not even make sense.

P. 27, 5.3.4b: Not applicable only to ABMs with core disconnect facility.

P. 27, 5.3.4c: Does c belong here?

P. 28, EXTEST: Add the word "analog" in Note 2 between "the" and "value." Delete the last line of the Description section in the second paragraph of the page.

C.J. said we should spell out that we allow different binary values other than 0000.000 as specified in the note at the end of the Description section on P. 28.

P. 29: Brian and Mani debated about INTEST. Brian's view is that we should not pretend INTEST can do everything in analog or even in digital domain. INTEST has limited capabilities. Mani would like the capabilities spelled out and delineated. Ken said, number 1, we need to preserve the Dot-1 INTEST at least for digital mode; number 2, PROBE allows partitioning of digital and analog circuits during testing. Mani said this is fine and wanted to make sure this point gets across to the reader. That is, INTEST is limited and the user must be aware of that. What we are putting in the Draft is a starting point or an infrastructure that can be extended/expanded. Brian said this is why INTEST is an option in Dot-1 (not very helpful function/instruction). It is up to the designer to be clever and make use of it. The first paragraph in 5.4.1 needs to be reworded.

Ken said Brian has done a good job extending the INTEST paradigm in trying to guide the reader away from the old way of thinking. PROBE is the way to go.

P. 30, Fig. 8: TBIC should be one block (instead of 4), conceptually.

P. 32: We should tell people what they CAN do, rather than CANNOT (capabilities rather than limitations). C.J. thinks we should let the reader know we as a WG know the limitations and practical concerns as well as realistic expectations.

P. 34: RUNBIST does not test the interfaces to the outside world. As stated in Dot-1, the function of RUNBIST is independent of the outside world. Steve said this is for analog outputs only -- we can't do anything unless a load is provided. Steve would like a permission in the Standard that allows hanging a load at an analog output so that meaningful measurements can be performed. Brian said there's nothing in the rules that prevent one from doing that. Ken said this is a system-level BIST. Steve said we always put loads on an output pin. Ken said what we have at the moment preserves the Dot-1 paradigm. RUNBIST is just to test the core functionality, independent of outside or off-chip influences.

P. 35, 5.4.5, add rule that states analog pins can also be in a high Z mode.

P. 36, 6.1: Move list to Ch. 4 or add to Ch. 5 and 7?

P. 36, 6.2: Delete the NOTE on ATE drive capability since it appears in Ch. 9.

P. 37, 6.2, Description: Brian will check out the "?".

PP. 39 and 40: Both AT1 and AT2 are driven by the same Vh.

P. 41: Steve said Table 1 and Fig. 11 are meant to be looked at together to better interpret it. Keith suggested grouping the switches into 2 groups that may simplify Table 1. Group 1 would contain switches 1 to 4, 9, and 10 which would all be functionally tied together. Group 2 would contain switches 5 to 8 all of which would also be functionally tied together. One can just draw an imaginary line vertically down the middle of the diagram in Fig. 11 to segregate the groups.

Adam suggested renumbering p1-p10 to p0-p9 to match up with Table 2. Keith said if we do decide to change the numbers, the Verilog models he has can be modified in a matter of minutes.

Ken said tonight we will try to preserve as much of what we have already.

Adam asked if everyone sees the fact that the instructions have been divided partly into TBIC and partly into instruction register.

Brian said the reason for choosing these particular codes is to simplify the logic gates involved.

Ken said he's glad Keith will be able to simulate the modifications and the switches. He asked if Keith can simulate make-before-break situations since there are cases where we do care when the switches make or break and the resulting glitches. Adam said these are all implementation-specific. Keith said we should warn users of potential problems though. Keith said we might want to warn users if they used other decoding scheme that the mission core should not be affected.

John Andrews said he would like a rule that says the "*" are reserved and NOT to be used.

P. 43: Steve suggested putting a note below Table 2 that says the "*"s are "reserved."

C.J. said he's not happy with wording in Section 6.4. Rules c and h: Rule c is has a definitive tone while Rule h sounds unsure. Lori Hamoline suggested taking out the word "when" to make it more emphatic.

Rule a: "control register" should be "4-bit shift register." The term "control register" is confusing. Same with Rule b. We should say "TBIC control register" or "control structure." However, these terms are not previously defined. Adam said it's a confusion issue here. Steve said the word "the" means it has already been mentioned. Adam suggested adding "TBIC" to "control register" in Fig. 13. Steve said let's leave it to Brian and C.J. to work this out off-line. We must move on.

P. 45: Ken said the Note underneath Table 3 "normal mission function as well as" is incorrect since there's no normal mission mode. Table 3 is not mandated, not part of standard, just examples. Dot-4 does not define those mode lines. According to the rules, you may have 3 mode lines if desired.

Adam Osseiran said Note 3 of Table 2 should be deleted. Brian said the code bits or mode lines must be defined but not necessarily exactly as shown in Table 3.

P. 47: John Andrews said items c and d should be deleted since it may result in a "very bad design." Brian said the reasons for the rules being there are as follows:

1. If differential input and differential output, then 4 lines would be required.

2. If differential input but no differential output, how are we going to mandate the required number of bus lines in there.

Ken said the fact that the pin is an input or output pin is immaterial. To be able to measure differentially off-chip, we need 2 buses. But how is this going to be mandated? The team will work on this topic tonight.

P. 48: Brian will check the "?" symbol.

P. 52: Steve said AT1 goes to the function pin and then to the chip. If there's a short circuit on the function pin, then there's no way to get the signal onto the chip. brian thinks the signal is applied to the fnction pin. Adam asked if the sentence is needed there. Under "Descriptions," Steve suggested the sentence "the boundary scan register allows signal to be applied to the function pins without having to pass through the core circuitry." Instead of "in this Standard," say "1149.4." The last sentence on P. 52 is misleading.

P. 53, Fig. 17: One rectangular box for the TBIC blocks (instead of 4 smaller ones).

P. 53, 7.2e: When in INTEST what happens?

John raised the Dot-1 compliant issue that prompted some debates.

The first 3 rules in Section 7.2: a and b seem to be saying the same things. Rule b is dependent on Permission d (labeled e in D16).

P. 54: Steve asked whether the designer forced to give up "INTEST of Dot-1" if he puts an ABM in there. This gets back to the Whet-cell which separates digital and analog functions. In theory, we get Dot-1 INTEST but with ABM, we are not sure if that is possible. Adam suggested taking out Permission e (which should be d). But Steve disagreed saying that is an important permission to have. A scenario may be that if a designer has a design that has lots of digital pins and subsequently wants to add the analog capability to them, then does he have to give up INTEST capability of Dot-1. However, INTEST is optional in Dot-1. An alternative is that we can put a note saying "INTEST is compromised if that is the case."

Section 7.3, Rule c: Change the word "output" to "function."

Steve said we should suggest a way to connect an ABM to a differential pin. He said this is confusing issue which can be clarified with a picture. Steve said he would be happy to draw such a diagram (action item for Steve; see end of these minutes).

P. 55: Steve said if we have differential pair, we must clearly spell out that the noninverting pin should be AB1, and the inverting pin will be AB1n, if it exists. Ken added that this prevents the user to hook up differential pins to any 2 lines which have no relation to each other (but if it is ruled in, then we are declaring these are differential pins which are defined in the software).

P. 55: Recommendation j is eliminated because of (c).

P. 56. Brian asked if Note 2 should be kept. Note 2: Get rid of the words "the input" before "circuitry," and Note 2 moved to c. Delete Note 1.

Steve said we use the output driver to do high and low testing. Steve recommended that in place of Recommendation j, the native driver should be used to deliver Vh and Vl.

John spotted an error: The comparator is backward in Fig. 18.

Same with Fig. 21.

P.57, Fig. 19:

P. 59, Table 5: The table starts with pattern 0. Before it was pattern 1 in Table 2.

P. 60, Note 3: A labeling issue. Ken said the labels Vg may be Vl, if both Vl and Vh are of reference quality. The Note is incorrect saying 4-7 may be omitted. So, it should be deleted since otherwise it would mess up Table 5. Fig. 19 is just showing an example of a simplified ABM structure. The software will make Vg, Vh or Vl if either is of high quality. Note 3 should not be eliminated altogether. Rather, it should say Vg can be Vh or Vl.

Brian openly questioned the merit of keeping the "Pin State" column. The WG decided to keep the column in the Table.

P. 61: The asterisks again mean "reserved." The "code" column and Note 3 refer to Fig. 22.

P. 63: If Vg is Vh or Vl, then the logic equations would be different (on the bottom of page). There should be a note saying that. The equations will be double checked.

HIGHZ instruction is an option but HIGHZ pin is needed by all users. Table 6 is fine but Note 2 needs to be modified. So does Table 7.

Keith did not include options in his simulations. Table 7 gets a new row for "HIGHZ". Ken said the TBIC section will need to be fixed the same way.

Ch. 8 hasn't been changed for many versions. We should add "ATAP pins" to the first paragraph, in addition to "analog and digital function pins."

P. 68, Figs. 23 and 24: We need to show conceptual switches that would have no labels. We also need to show a closed switch, not a straight through line as in Fig. 25, Mani said.

Second paragraph, second sentence: "S4 and S5" should be "SB1 and SB2." P. 68, Fig. 23, just replace the switches with closed switches.

Ch. 9, P. 72, Fig. 26: Steve said there is an error in this diagram. In the TBIC block, let's label the buffers S1, S4, S3, S2 from top to bottom. Convert S4 to an I buffer and S3 to a V buffer. Vh and Vl and Vg should be V buffers. Near the top of P. 72: say "a lower bound" instead of "the". Ken said the phrase "as small as possible" in paragraph below Fig. 26 suggests that designers should make the output impedance just that, but what we really mean is "as small as practically possible." Steve agreed.

P.73, Fig. 27: Rs is some series resistance. Second line of the second paragraph: Insert "labeled as Rs in Fig. 27" immediately after "ESD protection resistance..."

P. 74: The equation in Rule d is supposed to make sure enough drive is available. Need units in equation.

Brian said Rules a and b use the same notation (Rsw) as in Recommendation i. The Rsw's are the same, Steve said. Rsw's refer to AT1 and AT2 resistances and AB1 and AB2 resistances. We assume Vdd is greater than Vss.

Ken asked Keith as a designer if the rules in the Draft make sense in Ch. 9. We don't know if we are being overly restrictive or not. Keith thinks we should add more text. Steve said either 100 uA or 100mV is the absolute. ecided on 100uA. We need to be consistent with the units. Ken asked if Keith could make sure the rules make sense. Steve said this is the third revision of the specifications. The WG finally decided on the 1% accuracy as the basis. One should be able to measure with 1% accuracy. If the accuracy requirement cannot be met for a chip, then it is non-conformal to Dot-4 regardless of other factors.

P. 74: John McDermid asked if "native driver' term has been used before. It should be changed to "functional output driver."

P. 75, Recommendation k: What we really want to say is that between 10 and 10 kHz, a certain gain is required. A minimum bandwidth is guaranteed for this bus.

Recommendation i should say: Refer to Rules a and b.

P. 75: Descriptions are needed in 9.4. Need to reword and add documentation requirement in 9.4g.

P. 76, 9.5, first paragraph: Add this sentence to Rule 9.4g.

P. 80: "Figure DD" needs a number assigned. Steve said a graph of switch impedance vs. voltage will be shown. It exhibits a nonlinear behavior rather than a straight line. Also, 1/f noise should be mentioned. Another concern that will be addressed in this section is measurement duration. Integrating over a longer duration may result in a lower reading but the system may introduce other variables into the measurement. What about measurement duration for differential measurements? Obtain graphs on the web and add appropriate reference.

P. 82, 10.2e: Should reference rules.

*** Ken Parker would like these meeting minutes to reflect the gratitude the WG have for Brian's diligent work on the Draft. ***

Adjourn for Day

The WG adjourned for 6/2/97.

Arrival and Introductions

Meeting resumed the next day, 6/3/97:

Refer to Figure VG4 (Partitioned on-chip buses). After overnight deliberations, Ken and Steve drew on the board a possible scheme for extending the TBIC to n chips.

John Andrews had made a motion the day before for one and a half TBIC for the case of differential- input-single-ended output. On Viewgraph VG5, John depicted a possible scheme for a one-half TBIC. In light of this development, he initiated a motion to delete Rules c and d on P. 47. Ken seconded. John said we can do differential testing with only 2 wires. Differential testing in Dot-1 is performed without resources or instrumentation and was discussed somewhat but Dot-4 has done "a very good job" with the differential issue. Partial differentiality proposal has never been challenged before. Mani asked why we put them in the Draft in the first place. John replied saying there is a need to alleviate the burden of testing for the case where only the input or the output is differential. With the instrumentation resources of Dot-4, there is no need for Rules c and d.

MOTION: Delete Rules c and d as shown on Page 47 in Draft D16. Ken seconded. Unaminous approval.

Steve's presentation on the partitioning of buses. The purpose of the proposed bus structure is to keep things simple. If you have 10 partitions, you would need 19 more PAIRS of bits. This scheme allows AT1 to drive selected AB2's or AB1's (or more than one bus). Ken said within a domain, one can't mix AB1 of a TBIC and AB2 of another TBIC. John McDermid asked if we should say anything about combining multiple AT1's and AT2's. They will all eventually recombine into a set of AT1 and AT2. Adam Osseiran asked if it is useful to look at the first TBIC as two halves. He asked how we can turn the second core in a chain into a TBIC. Steve said we would address that issue later. As for BSDL, if there are two TAPs, the Dot-1 paradigm breaks down. At present, analog is ignored in Dot-1. One only needs two bits or switches to daisy chain multiple cores/chips.

Brian asked about the unused codes. There will be unused states with some being reserved for future Dot-4 development use and others for designers to use. Adam Cron pointed out that the designers also have the instruction space to use. That is, one may create brand new instructions to use bits in different ways.

Draft Review (continued).

Ch. 9: Mani asked if there will be lots of changes we need to wait for Brian to make. There are a few remaining issues that need to be resolved.

Ch. 10, P. 82. Ken said we need to recognize Ch. 10 will not be completed before the other nine are in a reasonable shape. "Table xxx" refers to Ch. 9.

Ch. 10: Brian wanted all the numbers and rules to be consistent. For example, we should eliminate contradictions. An example is you can't say 50 ohms is fine but somewhere else you say it is necessary to document the 50 ohm impedance. Steve said the rule is 1% accuracy. But if there is a parallel impedance, then it can be taken into account to achieve the 1% accuracy.

Section 9.5 will be absorbed into Rule g.

Ken said on the bottom of P. 82, Rule e only has 3 items; are there any others. John McDermid said we should say in Item iii that power/ground supply should be Vg. John what he interpreted we are saying in iii is that Vg is constrained to be either Vss or ground but we should not be constrained.

Steve said for a given function pin, we need to have 1% accuracy for any voltage between Vdd and Vss. If there are other impedances in the configuration that would make that 1% unachievable, then we need to document it. Ken said there is a difference between what we need to document for the user and what the manufacturer has to test. What we have here is documentation for the user. John thinks it's a little ambiguous the way it's written.

ACTION ITEM: John McDermid will help clarify what needs to be documented for the user and what the manufacturer has to test.

Brian will release D17 soon. We will want to wrap it up. Keith asked what do we mean by "value" in Ch. 10; does it mean 1% measurement accuracy? Adam said this falls into the unambiguous category and John McDermid will handle that.

Adam Cron asked if anybody has any idea to submit changes over the e-mail to make it quick and convenient. Do we have "change bars" to help the reader quickly and effortlessly identify what the changes are from the previous versions? Ken asked if we have a Draft close enough to ballot, and whether anybody in this room will vote no because of fundamental objections to this Draft. Ken asked C.J. if he has any objections? C.J. said the latest ballot invitations for Dot-1 already went out but only to people on the Dot-1 WG back in 1992 and 1993.

Ken said the IEEE has rules on the number of returned positive ballots (minimum of 75%). But among the negative ballots in the past for Dot-1, there were some great comments. So, he urged not to "stick to the minimum." Dot-1 could have stopped at 75% but didn't. Dot-1 took into account the negatives. He said to try to get into the high 90's and look at the legitimate complaints and suggestions. C.J. said a lot of the people in this WG are not designers except for Keith and who might have different views and perspectives. Adam said there are currently 61 eligible people in WG of which only 20 are active. Steve said he is concerned some of these people will object to Draft. Adam Cron said the ballot list is closed, in response to Keith's question about whether we need more press for the ballot. Keith said he would like to get other people from the outside to look at the Draft. John Andrews asked if anyone from LSI is here today. He said he sent copies of the Draft to these people on the condition that they provide comments. Ken said we hope people read the Draft. Keith said he hasn't attempted to urge more designers to read the Draft. Steve said right now it is an ad hoc world out there. But soon, people will want to work testability into their designs. Until they "get burned," they don't see the need to concern themselves with the Dot-4 Draft and Standard. Until they are "backed against the wall," why use it? Ken said the difference between Dot-1 and Dot-4 is that Dot-1 had to start the basic infrastructure. But Dot-4 is built on Dot-1, and users can use Dot-4 right away. In Japan, there is lots of publicity and interest which is a good thing for Dot-4. Let's not forget there are some good things here.

Tony Suto, having just arrived for the second day of the meeting, said he has comments on P. 1 where it says there are applications illustrated. But only a few are provided in the back of the document. Tony thinks this aspect of the Draft is weak. Somebody may say this is a good concept but then how do we test different situations. Tony thinks somebody needs to put more examples in the Draft. Steve's response to Tony's comments was that we are not training people on how to do measurements and that the application examples are really only there for reference. People can read the suggested references. Steve thinks we should draw a line somewhere. Besides, we don't want to bias people into a specific way to do measurements. Tony said he will take the action item to help Brian edit the Draft on this aspect. He maintained he wanted more application information.

ACTION ITEM: Tony Suto will help Brian find a way to work more application information into the Draft.

BSDL Consensus

There has been some debates over this issue, and we have decided to go to ballot without BSDL. Ken pointed out the Dot-1 capability of Dot-4 can be described in BSDL as it stands now. Keith and Mani asked if we could make that clear in the Draft somewhere Ken said maybe somewherein Ch. 10. The lack of BSDL is the key concern of Gordon Robinson who has said he would cast a negative vote on the Dot-4 Draft without BSDL come ballot time. Ken said ideally BSDL and hardware should be developed in parallel. But that is not how it is done practically. Adam said some people raised their concern about the BSDL issue but no one never stepped up to the plate. Keith said BSDL is an outgrowth of both hardware and VHDL. Mani will give the VHDL web site to Keith so he can read up on it. Ken said we will address Gordon's concern, saying we are well aware of his concern but we have to move on. The answer to Gordon is "we're working on it." Adam cited Tom Lankford and Gordon as the two notable people voicing their concern about BSDL but neither has offered to help because of work and personal commitments.

Brian again brought up the subject of whether we need to put into the Draft something on the Dot-4 EXTEST compatible to Dot-1 and that Dot-4 can be BSDL'ed, in response to Gordon's concern. Adam said we could put that on the cover letter saying "we can put the weasel words on a cover letter," because he is a significant player. However, Gordon represents only one vote. Ken said Dot-4 offers automation while Dot-1 is being revised to accommodate Dot-4. He hopes people will vote yes to Dot-4 and at the same time provide comments (apology to Brian in advance for potentially more work).

Floating ATn Pins

An issue for board manufacturer: Floating ATn pins. It should be communicated to users that the ATn pins should not be kept floating (we can jumper the pins but what if we need to go through the chip (jumpered) to test other chips). The pins may be jumpered only if it's not going to do anything, i.e., tied up or down to power supplies. We need to put some recommendations in the Draft somewhere. We just have to identify the issue and let people solve it as they see fit.

ACTION ITEM: Adam Cron will examine where in the Draft the issue of floating ATn pins should be discussed.

C.J. asked about balloting in Dot-1 - How many Dot-4 members are current Dot-1 members? Only a handful of people in Dot-4 are also Dot-1 members. C.J., John Andrews, Ken Parker, and Lee Whetsel. Steve said there's an e-mail invitation for ballot from the IEEE soliciting voters. That was the official invitation. If anyone is interested, reply to the e-mail and the IEEE will send the appropriate forms. C.J. thinks e-mail might not be the best idea. Keith said there are lots of people out there that do not participate. Steve said they don't necessarily have to participate, but they would rather us telling them what to do since most of them are too busy.

Patent Issues

Patent update. Steve said there are 2 patents that have surfaced over the past 2 years. They are as follows:

(1) Tektronix: Gaining access to points on a chip through a MUX. The key phrasing is "each point on the chip we want to access has a DEMUX. Now, if one just consider exactly one input and one output, then Tektronix's scheme would look like a Dot-4 output. The questions is whether one-input-one-output is still considered a MUX. The Dot-4 scheme was clearly documented in the meeting minutes dated 10/22/93. Therefore, the release date for this patent at the approximate time frame of ITC where Dot-4 meeting minutes were released means it might not be enforce-able.

(2) Lee Whetsel: Variable reference voltage for a comparator. Dot-4 permits an option of using AB2 as a variable reference which is useful for capturing high speed waveforms. However, it was taken out because it was ad hoc in Dot-4. But Lee Whetsel has a patent granted for this idea. The filing date is 12/2/95. Steve made a proposal for this in February, 1995 and also Keith had it on his test chip at the time. Besides, we have the meeting minutes to support it. Adam said he talked with Lee who said he'd make it available to Dot-4 and would not be aggressive in trying to protect his patent. Adam added that he talked to the IEEE and was told we should not go look for patents. But if you found them, don't mention it. We feel relatively comfortable about these two patents. So, if you found something, investigate it yourself. If it becomes a problem, then we will address them.

Verilog Models

Refer to Keith Lofstrom's viewgraphs.

Viewgraph VG6. The purpose is to simulate the tables and the logic equations in Draft D15, but not the bus extensions. This facilitates the testing of alternatives. The models are transportable. However,

Viewgraph VG7. Verilog doesn't do well for analog. Free Verilog simulators are similar in size.

Viewgraph VG8. The advantages of Verilog models: Small Verilog models are available (SILOS 3) free of charge. Verilog more directly expresses hardware behaviors than the programming language C but is as easy to learn as C.

Viewgraph VG9. Model implemented included

1. One single-ended TBIC.
2. One single-ended ABM.
3. Partition control: not yet.
4. Gate version, table version selectable by 'define statement.
   

The test code was divided into 3 segments so the demo version will work.

Viewgraph VG10. Switch models include unidirectional (for clamps) and bidirectional. We can also model using Saber, Analogy, etc.

Viewgraph VG11. See viewgraph for an example of a TBIC (test bus interface circuit).

Viewgraph VG12. A Table Driven TBIC. Keith said one can easily add/change states simulating what is in the Draft. He remarked on the surprising ease with ease he picked up on the Verilog model. This provides a check or verification of the Draft.

Viewgraph VG13. Equation driven TBIC. This provides a way to check the logic equations.

Viewgraph VG14. Test Segment. One can put in the desired input controls and simulate the results. The example is for a TBIC and ABM.

Viewgraph VG15. Conclusions. The equations in Draft can be simulated and were shown to work. One can play "what if" games with this sort of simulation which is very handy. Besides, Verilog is easy to run.

Viewgraph VG16. Verilog simulator available. Keith used a demo version found on the internet with the URL of www.simucad.com/demo. Among other available simulators is Crippleware with about 500 lines of active codes. Mani said Ken can use Keith's simulator to help with obtaining a revised TBIC table. Keith said he put the models out there to let people expand the models.

Ballot Status

The ballot list is closed. The deadline was already extended once. Mani asked if there is a deadline for response.

1149.1 Status

C.J. said he has a PAR and that Dot-1 is fairly behind. Adam Ley is probably down to the nitty-gritty by now. Nevertheless, here are some issues remained to be resolved. C.J. added that he was trying to shoot for the revised Dot-1 to be approved by the ITC time frame, but that may not be possible. So, Dot-1 is in the draft status. It might be necessary to have another Dot-1 meeting to provide incentive for completing the draft. A draft must be submitted by 9/15. Ballot resolution needs to be done by end of August. That works out to a 2 month time frame. Dot-4 wants to get the ballot out. We would want to say at the ITC we have so and so approval rate and that we are rapidly converging. Brian asked if the IEEE allows a draft in pdf format. Adam Cron said there is an article in the newsletter Standards Bearer that reported people are getting drafts they should not be getting. Adam said he "is as guilty as any." He needs to pare down the reflector membership. Steve asked would somebody do if he/she wants to get a copy of the Draft. Adam said they could call 1800-678-IEEE to obtain the information. We don't hand copies of the Draft out for free. Steve said when we whittle down the reflector audience and change the password, what do we do? Steve said he can give just anybody the password. But we make sure they "don't give out the password to just anybody."

ITC Papers

This year's ITC there are few things going for us.

(1) 1149 papers: Adam will present Dot-4 perspective and views.

(2) Adam will chair the Dot-4 session at ITC.

(3) Dot-4 related presentations at ITC include Ken and Matsushita's paper, Jose's paper, a paper from Taiwan (they are proposing a special unity gain buffer with a bit to grab the results and saying a buffer is needed to drive AT1 and AT2 buses). It is ad hoc, and anybody can come up with ad hoc implementations. We have always advocated putting a buffer on AT2. It is not additional to what we have, nor is it something new. Steve said there is a paper submitted referencing Draft D5. They are way behind us. Adam will change the password to the private access area on the Dot-4 internet home page and will instruct people to call IEEE to get a copy of the Draft.

Dot-4 panel discussion. Steve and Keith are two of the panelists. The third is Dave Rich of AT&T. The title is "Is Dot-4 useful in testing chips?" Steve said they are still looking for the fourth panelist. Is Gordon Robinson a possibility, Ken asked. Steve said maybe someone in the ATE equipment industry and/or somebody who is going to opposed to Dot-4. Nai-chi Lee? He was on the panel four years ago. Keith said maybe somebody from Europe. Franz de Jong or Phillips's Keith Baker? Basically, Steve Sunter and Keith Lofstrom will be on one side and Rich and possibly Keith Baker on the other side opposing to Dot-4. The panel will come up with top 10 unsolvable issues.

Next Meeting at ITC

Adam asked if anybody wanted to have meeting before then. No one was in favor. Ken asked if teleconference is necessary. Adam said e-mail is fine. Brian can then incorporate changes. The question is: When will D18 go out? Ch. 9 will be worked on for the next several days? The next revision should be ready in two weeks, Brian said.

Ken said there are 17 Dot-1 members in Dot-4. There are two new members: Adam Sheppard and Ted Eaton.

With no more meeting agenda items remaining, Tony Suto made a few comments on the Draft. On P. 75, the flatness specifications were mentioned but not the phase specifications. Recommendation k: It's a good point to include the phase limits. We need to calculate phase error limits.

ACTION ITEM: Tony Suto will work on phase error limits to be included in the Draft.

Relevant action items for Steve Sunter:

1. Add application notes, drawings, and rationale in Ch. 9 EXTEST.
2. Partitioned buses text and drawings.
3. Fix diagram in Fig. 30.
4. Differential TBIC and ABM diagrams.
   

Adjourn

John Andrews moved to adjourn meeting. Ken Parker seconded. Unaminous approval.

Access the Minutes of the November, 1997 Working Group Meeting.

To reach the Chair of the IEEE P1149.4 Working Group: