[t10] 13 cases in bus annex why how

Pat LaVarre LAVARRE at iomega.com
Mon Mar 17 19:06:27 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
Here we have 241 lines.  Can this be helpful?

> Why does T10 want to know more of the 13 cases and
> what is it that we want to know?

Offline kindly I'm informed "why 13" is at least of
idle interest here.  Here's a try at answering that,
on the chance that that is the question intended.

Somebody please tell me how clear I now am or am not?

The short answer is we say 13 because 13 works.  We
haven't worked too hard on explaining why 13 works. We
just see that 13 does work.

I imagine why 13 works is hard to understand because
13 is a rhetorical & political choice.  It's a
technical choice only by way of being an expository
choice.  You could explain this same stuff in any of a
thousand ways.  But as steep as this learning curve
is, seemingly it is the flattest of the learning
curves yet discovered near here.

Saying 13 can deeply annoy people who want to be
persuaded a case matters before they willingly allow
the case to appear in an outline.  Saying 13 is a way
of covering all the possibilities up front and
deferring the discover of  which matter til later,
deeper in.

Saying 13 can also annoy people who build improperly
layered devices - because they often get many of the
13 cases wrong, differently at least by op, if not
indeed differently by Cdb.

But if you really want the long answer ...

> ...

All of us commonly say a host passes thru the CDB to
the device and asks to copy bytes.  A host asks to
copy In Hi bytes, or to copy Out Ho bytes, or copy no
(Hn) bytes.

So far we have 3 cases, not 13.

So far so good, right?

> ...

"The Thirteen Cases" is an arbitrary convention for
the next level of that same outline.  We go on to say,
in reply, the device asks to copy In Di bytes, to copy
Out Do bytes, or to copy no (Dn) bytes.

Two parties each independently making a choice among
three options gives us 3 x 3 = 9 cases.  But then when
the host and the device happen to agree over which way
to copy data (In, Out, or Not), then still they may
disagree over how many bytes of data to copy.  Adding
Di < Hi, Do < Ho, Hi < Di, Ho < Do gives us 4 more
cases, for a total of 13 = 9 + 4.

Clear, so far?  Arbitrary, maybe, but clear, right?

> ...

Having hit upon an outline of 13 sections, we stuck to
our outline of "The Thirteen Cases" purely for
expository reasons.

First, thirteen cases is enough to persuade managers
etc. to delegate the understanding of this detail to
those folk who happily involve themselves in the
grungiest of technical details.  Less is not better.
If you force us back to say, just three cases, we'll
end up including in our discussion people unwilling to
invest the considerable time it takes to understand
these real interoperability issues properly.  That
won't help.

Second, the number thirteen connotes evil in American
English, which fits for anything outside of the "thin
diagonal" cases of (Dn = Hn, Di = Hi, Do = Ho). The
phrase "thin diagonal" makes visual sense if you draw
the H vs. D matrix conventionally.

"Evil" well describes the "positive residue" cases of
(Dn < Hi, Di < Hi, Dn < Ho, Do < Ho): these cases
often hang DMA engines.

"Evil" even more faithfully describes all the
remaining cases i.e. the "phase error" cases.  For
those cases, all we ask is that timeout & reset &
retry work as well as they ever do.

Note we propose T10 not try to stray from the D = H
thin diagonal.

Ok, ok, maybe more often acknowledging this limited
scope explicitly could help people properly apply our
intentionally incomplete T10 specifications. But
that's a worry for T10 folk.

The issue here now is that T10 folk are asking USB DWG
folk to explain something of USB to T10, not to grow
the scope of T10.  Clearly the scope of USB DWG is
more narrow: it is just USB.  Yet the scope of USB DWG
is more broad: it covers the 13 cases, not just the 3
of the thin diagonal popularly assumed in misreadings
of T10 paper.

How we quickly say only the significant bits of all
this in a T10 appendix is the issue, right?

> > less cases

People do commonly write the first level of the
outline by dividing the thirteen cases into just the
three columns: Hn, Hi, and Ho.

Indeed, sometimes all we say for Hn is how to copy CDB
Out and Status In, so that in Hi and Ho we can take
those as given and focus on Data In and Data Out.

Surely you've seen pr*prietary chipset doc written
this way?  First an Hn example, then an Hi example,
then an Ho example?  Me, I've never seen chipset doc
written any other way.

> > more cases

We could add the fourteenth case of Do = Ho = 1.  Its
evil is well known: seen broken in chipsets, in Win
Ioctl, etc. etc.

But back in the real world, in practice, thirteen
cases works.  If we divide the discussion into
thirteen cases, we get true answers.  By
distinguishing Dn and Hn, by acknowledging the
inconvenience of D != H, by making the horror of H < D
and Di != Ho and Do != Hi explicit, we give those
cases proper attention.

Within a section like Do = Ho, we can manageably
subdivide the discussion.  Maybe we talk about Do = Ho
= 1.  Maybe we talk about Do <= Ho when Do isn't a
multiple of 8.  Whatever.  That's the third level of
the outline - as yet, we have no expository
conventions there.

For transports that choke over such wildly creative
approaches as not always copying multiples of 8, often
in the Ho third of the document we just refer back to
Hi. But sometimes only Ho is broken, as in Do = Ho = 1
being broken while yet Di = Hi = 1 works.

> ...

Want to see four strawpeople go down in flames?

1) Yes, in theory, on paper, in merely public
specifications, the H and D choices are not
independent.  In theory, the mutual observation of the
sequence of CDB's leading up to a CDB gets the host
and the device into agreement over which way to copy
data and a max count of bytes to copy.

Meanwhile, back in the real world, we have two state
machines, one in the host, one in the device, so by
definition they fall out of sync now and then, of
course.  The question is not why do they fall out of
sync.  The question is why don't they fall out of sync
more often.

For example, we get hosts that implement SFF/ ANSI MMC
connected to devices that implement ANSI SPC, whoops.

2) Yes, often the protocol for Hn is an extreme case
of Hi or Ho, but sometimes it's not.

For example, in ATA PIO, Hn is the extreme case of Ho,
which differs from the unused extreme case of Hi.

3) Yes, in theory, the host and device choose just as
independently how many CDB and Status bytes to copy.

Back in the real world, i.e. in actual bus traces of
Microsoft Windows, the host & the device don't fall
out of sync often enough on those for us to bother
specifying a fix.

Mind you, as we speak, the Usb Mass CWG is touching on
the CDB length issue, with the latest proposal being
to allow the host to round up to 12 from 6 or 10 at
will.

4) Yes, in theory, hosts other than Microsoft Windows
matter ... but on this issue they agree.

Linux, Mac OS X, other free BSD, BIOS, etc. etc. i.e.
all the actual host source code seen by Us all solve
this same problem this same way.

The app on the host that authors the CDB passes the
CDB thru together with a guessed length and a max
length and a direction of how many data bytes to copy.

Hosts vary in how distinct this info is e.g. some say
guessed = max and some let a lower layer guess
direction from op, but in the end at the bottom some
piece of host code gets told max length and direction,
separately from the CDB and independently of how the
device parses the CDB.

> the H vs. D matrix conventionally

We never really figured out whether to write H then D
or D then H.  Nowadays maybe I incline towards writing
D then H, by the idea that H is expected and D is
actual that drives the source code convention of
writing the actual on the left e.g. { if (x == 42) ...
} rather than { if (42 == x) ... }.

> ...

Anybody read this far?

I trust we agree we don't want to put all this into a
T10 appendix.

Anybody know what we do want to say?

If we think we're going to relate T10 to Usb Mass, I
figure we have to mention "The Thirteen Cases".  That
second-level outline is the core of the chapter 6 of
Usb Mass that details the protocol. If you don't
understand the outline, you won't properly understand
the spec.

Cluelessly, curiously, thankfully yours, Pat LaVarre

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list