June 2-3, 1997
|11:30am||Lunch - Thank you University of Washington|
|12:00pm||Arrival and Introductions||Adam Cron|
|12:15pm||Approval of March, 1997 Minutes||Adam Cron|
|12:30pm||New TBIC Architecture and MEASURE Ramification||Ken Parker|
|1:00pm||Draft Review||Brian Wilkins|
|3:00pm||Break - Thank you UW|
|3:30pm||Draft Review - Continued|
|6:00pm||Adjourn for Day||Adam Cron|
|7:30am||Continental Breakfast - Thank you UW|
|8:00am||Arrival and Introductions||Adam Cron|
|8:15am||Draft Review - Continued|
|10:00am||Break - Thank you UW|
|10:15am||BSDL Consensus||Adam Cron|
|10:30am||Floating ATn Pins||Adam Cron|
|10:45am||Patent Updates||Mani Soma|
|11:00am||Verilog Models||Keith Lofstrom|
|11:15am||Ballot Status||Adam Cron|
|11:30am||1149.1 Status||Ken Parker|
|11:40am||ITC Papers||Adam Cron|
|11:50am||Next Meeting at ITC||Adam Cron|
|Working Group Members||34|
|Total Subscribers on "esd" reflector||313|
|Companies and Other Institutions Participating||~241|
|John Andrews||National Semiconductor|
|Lori Hamoline||Newbridge Networks|
|Katsuhiro Hirayama||Panasonic Semiconductor|
|Elbert Nhan||Johns Hopkins University|
|Adam Osseiran||Ecole D'Ingenieurs de Geneve|
|Adam Sheppard||ASSET InterTech|
|Paul Spitalny||Crimble Micro Test|
|Mani Soma||University of Washington|
|Martin Snowden||Crimble Micro Test|
|Brian Wilkins||Southampton University|
|Dan Dandapani||University of Colorado|
|Lee Whetsel||Texas Instruments|
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.
Ken Parker moved to approve the minutes. Seconded. Unanimous approval.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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. ***
The WG adjourned for 6/2/97.
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
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
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.
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
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).
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
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.
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
Viewgraph VG9. Model implemented included
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
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
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 ballot list is closed. The deadline was already extended once. Mani
asked if there is a deadline for response.
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."
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.
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:
John Andrews moved to adjourn meeting. Ken Parker seconded. Unaminous