This message is from the T13 list server.
Pat,
Do We Get Odd byte Transfers?
Pat, can you clarify something for me - who is sending these
commands for 5 bytes of returned INQUIRY data? Since 1993 with SCSI-2, the
standard INQUIRY data length has been 36 bytes. Indeed, I don't know of any
case since SCSI-2 where you need to allow for an odd number of returned
bytes (except possibly unblocked data in tapes (I'm not an expert there) -
certainly no control information). This change happened when SCSI first
introduced wide SCSI, which meant that in wide SCSI mode (a purely physical
mode invisible to the upper layers of software) you can only transfer an
even number of bytes. SCSI did allow for an odd byte indicator (IGNORE WIDE
RESIDUE message), but I personally have never seen it being used (it is a
performance disaster).
And is this 5 byte issue one of the host not having enough buffer
space (hard to believe they would not have allocated at least 8 bytes
anyway)? Or it is a worry about the host interpreting the possible "bad"
last byte? In the later case, I'm not sure there is a possible issue (for
instance, in INQUIRY the 5th byte is the number of bytes left in the Inquiry
data, so if that were 0 the last odd byte would be ignored anyway).
Perhaps it would help if you had some more data on the cases where
the system was failing for this reason (i.e. hardware, software running,
device, ...)? If you are worried about 8 year old SCSI software, then I
think you'll need a beefier bridge implementation anyway (see "How to Handle
Bad Implementations").
Impact of changes to the ATA Standard
The reason why it takes so long to change some things is that they
affect hardware design in programs with long lead times for hardware
development. For instance, for HDDs the ASIC we use typically has to be
defined 12 to 18 months before the product hits mass production. Add to
that the time to actually stabilize the definition of new stuff, and you get
around two years.
The 48 bit addressing is a good example - the first revision of the
proposal was offered to T13 in January of 2000, and that was proceeded by
months of email conversation on the topic (there were initially alternative
approaches offered). Call it two years ago (fall 1999). Guess what? The
first HDDs to implement this feature (from Maxtor BTW) have just started
shipping - a bit more than 2 years from when the conversation was started.
And this was a very simple change as these things go.
Making available a transfer count register for UDMA would require
the same amount of time to market since you have to alter ASICs (i.e. the
register cannot be updated by firmware, otherwise you have to sit around so
long that you might as well have transferred the data at PIO mode 0 speeds).
And you would still have to handle older devices for at least 3 more years -
a total of 5 years before you could really take advantage of the feature for
all products. So it is actually HARDER than the 48 bit addressing (by
definition you do not care about older devices, since they never needed the
48 bit addressing anyway due to their limited capacity, while here you
really do need it on all devices to take advantage of it in your bridge
design).
It seems that the underlying issue here is the ability to implement
a bridge without a uP to parse the commands. Assuming for the moment that
this is desirable, other changes would have to be made as well (as Hale
pointed out). So just making this one change would introduce problems (i.e.
instability for a lot of designers) but not really solve them. If a more
comprehensive package of changes were developed....
BTW - I would not employ a transfer counter anyway, since that would
require a real reworking of UDMA. Instead, for devices that support odd
byte residues, just implement the counterpart to the IGNORE WIDE RESIDUE
message in SCSI - a register you can read at the END of the command that
tells you whether the last byte was valid of not (e.g. 0 for valid, 1 for
invalid). Not great, but simpler to implement and if done right only
devices that can have odd residues need ever to change.
Bridge Implementations
From my perspective, I'm not sure the changes are desirable anyway.
The bridges I've designed and work with have generally all had embedded uPs
to parse commands - this just makes life so much easier. Today an embedded
8031 class uP running at a high clock rate (say 48 MHz) is cheap and can do
the job quite well. It usually requires just 4 Kbytes of memory to hold the
code (I'd allocate 8Kbytes to be sure), which again can be internal. You
can embed that code in ROM, and supply an external EEPROM capability for
updates. Given the pin counts you need anyway for the interfaces, the
resulting die is not the limiting factor that drives bridge cost - instead
it is the IO ring.
I admit that an FPGA implementation wants to use a uP simpler than
an 8031, but there are a lot of 8 bit uP cores out there that are low in
gate count (say 3000 gates). And most FPGAs today want to give you some
memory anyway - enough for this application.
If you do want a simple state machine in the hardware, then you can
accomplish this today. You might even be able to make it work with
"compliant ATAPI devices" (as per your earlier email). The only issue I've
seen identified is the issue of the odd byte residue on transfers (which
occurs in PIO or DMA, but DMA has no indication of it like PIO). Note BTW
that this is NOT a byte count issue - in a transparent bridge you don't care
about the byte count (or you can count it yourself). It is just an issue of
the last byte's validity.
But that will not save you from bad implementation (see next item).
How to Handle Bad Implementations
Bad implementations will always be with us. If you need to design
something that can work "in the real world," then you really do need a uP
based implementation with a lot of smart code to handle a lot of different
screwy implementations. If you were selecting all parts yourself, then in
theory you could avoid this. But even then unanticipated bugs and future
(needed) enhancements make a flexible design so much better.
Rather than focusing on the standard, the better approach here is to
focus on compliance testing and certification. Microsoft may not do an
adequate job here today, but that could be improved (or another party take
over that exacting task). This will not eliminate bad implementations, but
will allow you to label a lot of them as such and thus have a legitimate
reason to ignore them in your design.
Personally I'd just accept that badness happens, and make my design
flexible and customizable enough to handle it. But in that case we are back
to something like the embedded uP, and the issues so far identified appear
to go away.
Standards and Tutorials
Given all of this, I still think the standard could use some fresh
wording in some areas. As Hale points out, some of the exception cases are
not well documented, even when there exists a body of "standard practice."
And there are areas (like DMA for the PACKET command) that have not been
widely implemented, where I'm sure some elaboration would be good.
Of course, even with some updating, a standard will never be a
tutorial. It is fundamentally a legal (compliance) document, not an
educational one. To my knowledge no such tutorial exists today in the
market (although there are classes and consultants you can hire - in my
opinion well worth the price for people serious about developing a product).
Jim
-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 05, 2001 10:26 PM
To: [EMAIL PROTECTED]
Subject: [t13] to Dma from Pio - can this committee help?
This message is from the T13 list server.
> > UDma ... If M more clocks arrive,
> > then a sender that guesses the receiver
> > willingly requested D = N * 2 bytes
> > can be wrong by anywhere from 0 to M * 2 + 1 bytes.
> I'm not saying that changing protocols
> could not improve them. But it takes
> two years to get those changes to market,
Yes but.
Teaching an Atapi device to report accurate residue (the count of bytes
clocked that were not willingly requested) is fast & good & cheap, as
protocol changes go. Changing to report accurate residue comes a lot
easier, for example, than to learn to support 48 rather than 28 bit Lba's in
Ata.
I'm thinking people who control both bridge and device can turn this
quickly, to fix the first plug 'n play horror that goes away with this fix.
I'm now hoping to see this change roll in across our product line as a
metal-mask firmware change only, no real silicon change.
I'll have to go reread the relevant portions of the Atapi standard more
carefully, but I'm thinking I remember that standard leaves us lots of room
in the task file of the final INTRQ of a command to change an Atapi device
to accurately report residue at will.
> and you will always have to contend
> with older designs without the "fix."
Aye.
I can get competitive plug 'n play time-to-market edge and some price break
if just one if my partners makes for me a bridge fully transparent merely
across my own product line. But I can ask for a better break if my chosen
partner can find a lot of other customers to share the cost.
I'm not at all clear on what the least wrong heuristic is for guessing what
residue is.
I imagine the final choice of a heuristic might end up a tightly guarded
trade s*cret that gives people competitive edge. That is, this heuristic
will become a "secret sauce", like how creatively boot Bios interpret our
quasi-public Ansi Ide standards. Secret sauce gets purchased expensively by
paying people to isolate the root evil in a series of plug 'n play troubles
over time.
If so, then standardising a way for Atapi devices to report accurate residue
will be the only low-cost-of-entry route for latecomers to enter the market.
Pat LaVarre
Subscribe/Unsubscribe instructions can be found at www.t13.org.
Subscribe/Unsubscribe instructions can be found at www.t13.org.
