SBP-2 Data Buffer Alignment

Stephen_Finch at Stephen_Finch at
Fri Jul 11 06:39:06 PDT 1997

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* Stephen_Finch at

The possibility of odd byte addresses and odd byte transfer lengths have
always been in 1394.  Yes, some restrictions have been placed on some
structures for convenience and cost reduction of hardware.  Unfortunately,
there is a lot of software that has data buffers on arbitrary address
boundaries.  The PC arena is an excellant example of this.

For systems, performance is king.  Data transfers to/from a device want to
be directly from the applications space if possible.  And since this data
space has no byte/word/quadlet boundary, either the hardware must handle it
or the data must be buffered in an area that meets the address boundary
requirements.  Writes would require moving the data from application to the
buffer and then the command to the device could be issued.  Reads would
read the data into the buffer and then the data could be moved to the
application.  Moving data is expensive in time and processor resource

So, what is better?  Having hardware handle the odd bytes or having data
moved.  The various groups working on standards so far have said:  make the
hardware do it and avoid the manual moves.

Well, they did allow us to put all of the control structures on quadlet
boundaries (or larger) because the device drivers are all going to be new
and can be written with the boundary requirements met.  So some
specifications and standards (e.g., SBP-2) have their data structures
limited to quadlet or higher boundaries, but the data payload is still on
arbitrary byte boundaries.

Yes, it costs hardware to do it right and fast.  But, this is the direction
the industry is going....

A side note:  isoc transfers don't have addresses and, therefore, don't
have odd byte address problems...

steve finch

<peter's message>
In a message dated 97-07-10 11:50:24 EDT, packer at (John
Packer x2146) writes:

<<I assumed the purpose of quadlet alignment is due to the nature of 32 bit
computers ... they are quadlet aligned.  This even works with the 16 bit
machines.  Now you are saying allow the data buffers to be aligned to any
boundary.  The packets to fetch data are still quadlet aligned.  Are you
expecting the "host" to fetch 32 bits of data out of two 32 bit memory
addresses, then build the 1394 quadlet while saving some for the next 1394
quadlet?  Same is true for the store to memory.  I just want to make sure
that the target is not expected to align the 1394 quadlets to the system

The relationship between system memory addresses and the 1394 addresses
used to reference them is a matter for the adapter hardware / software and
not something that the target need worry about (with the exception of page
boundary information supplied in the ORB).

If a block read for 5 quadlets is received for a 1394 address such as
0x0001 and this requires the host adapter hardware / software to fetch two
different quadlets to assemble the single response packet, that's exactly
whats implied.

The target is not expected to split such a request into separate block read
requests that do not cross quadlet boundaries. The target doesn't even know
the relationship between system memory addresses and Serial Bus
addresses----except that page boundaries may occur if the ORB says so.


Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson at

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

More information about the T10 mailing list