Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes

From: "Turner, Randy" <[email-masked]>
Date: Wed, 11 Feb 1998 08:35:10 -0800

I didn't know chip sets offered "explicit" support for SBP-2. OHCI
maybe, but I hadn't seen the chip set feature in the brochure for
"chip-level SBP-2 support".

Also, since 1394 is a peer-to-peer interface, anyone developing a
peer-to-peer device (like the majority of the Japanese electronics
industry), would have to essentially duplicate the functionality of
SBP-2 initiator and target, whether they actually use SBP-2 to do this,
or some other (potentially proprietary) method for implementing
peer-to-peer functionality.

Randy

	-----Original Message-----
	From:	Stephen Holmstead [SMTP:[email-masked]]
	Sent:	Wednesday, February 11, 1998 8:30 AM
	To:	'Turner, Randy'; 'Brian Batchelder'; [email-masked]
	Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes

	My experiences in the past is that combining target AND
initiator
	functions into a single device is VERY difficult.  The
complexity of the
	state tables and ambiguities that can arise make it very
difficult.
	Also, I don't believe any of the chip manufacturers support
SBP-2 for
	both target and initiator.  In my opinion, it's NOT just a
matter of
	adding the 15K for the target and 15K for the initiator.  The
target and
	initiator have vastly different functions.   Designing a model
that did
	both (well) would be a challenge.  It was problems like this
that fueled
	many of the AEN (asynchronous event notification) debates.

	Stephen

	> -----Original Message-----
	> From:	Turner, Randy [SMTP:[email-masked]]
	> Sent:	Monday, February 09, 1998 1:03 PM
	> To:	'Brian Batchelder'; [email-masked]
	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
	> 
	> 
	> I am very interested in the combined target/initiator
footprint as
	> well.
	> 
	> Thx
	> 
	> Randy
	> 
	> 
	> 	-----Original Message-----
	> 	From:	Brian Batchelder [SMTP:[email-masked]]
	> 	Sent:	Monday, February 09, 1998 9:37 AM
	> 	To:	[email-masked]
	> 	Subject:	Re: P1394> Rough SBP-2 & IP1394 core
component
	> ROM sizes
	> 
	> 	At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
	> 
	> 	[snip]
	> 
	> 	>I approached them about sharing some rough estimates of
code
	> size
	> 	>for the IP1394 glue, SBP-2 target and initiator, and
1394 bus
	> 	>manager modules to get a feel for how "heavy" the
protocol
	> 	>implementations really are.  They graciously shared the
flowing
	> 	>estimates with us, and certainly deserve our thanks.
Since the
	> 	>technology is still being developed, these
implementations are
	> 	>certainly going to be tuned and the numbers will change
a
	> little
	> 	>bit.
	> 	>
	> 	>  Component                Rough ROM size (KBytes)
	> 	>  ---------                -----------------------
	> 	>  SBP-2 initiator core     15 +/- 5
	> 	>  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch
agent,
	> no exec agent)
	> 
	> 	Any idea how big a combined SBP-2 target/initiator would
be?
	> 15-30K? ;-)
	> 	[snip]
	> 	Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	> ~
	> 	Brian Batchelder      | Hewlett-Packard      |
	> mailto:[email-masked]  
	> 	Connectivity Futurist | 1115 SE 164th Ave.   | Phone:
(360)
	> 212-4107  
	> 	DeskJet Printers      | Vancouver, WA  98684 | Fax:
(360)
	> 212-4227

---

From: Greg Shue <[email-masked]>
Date: Wed, 11 Feb 1998 08:59:39 -0800 (PST)

Some chipsets offer HW assist for portions of the SBP-2 target
protocol.  Others offer HW support for DMA to map device memory
to Serial Bus memory, which significantly improves SBP-2 intiator
performance (e.g.  OHCI).  This does _not_ mean that the chips
are protocol-specific.

I definitely agree that initiator and target functionality are
vastly different.  In my mind, the represent opposite ends of a
client-server model.  I think it would be extremely difficult to
write a single application that could, in a single instance (or
through a single interface) be both a controller and a controlled
function.  (Note, I did not call this a Module, a Node, or a
device.  :-) I could very easily see a protocol stack for a node
having both target and initiator support.  Any server-type
services would use the target support.  Any client-type
applications would use the initiator support.  Because there is
so little that is shared, I see the size of the stacks as being
(roughly) the sum of the individual solutions, no matter how many
applications or services my node has.

Am I missing something here?

Greg Shue

---

From: Toru Ueda <[email-masked]>
Date: Fri, 13 Feb 98 21:44:35 JST

I don't want to make any confusion about PC printing protocol. This is
only for your information.

>From consumer device point of view, "symmetrical" is the essential
feature of the protocol.
For example, a digital still camera wants to send its image data to
printers.  Also the same camera wants to receive image data from the 
other still cameras. We want to use the same protocol for both use.

These are three essential features for consumer device.

1) Bi-directional
  Each side can send and receive data.
  SBP2 supports bi-directional feature.
  
2) "True" bi-directional
  Each side can send and receive data at any time.
  Alan's architecture supports "true" bi-directional feature by using
  transmit buffer, receive buffer and unsolicited status.
  
3) Symmetrical
  Each side has the same architecture.
  This is completely different from bi-directional issue.
  
Consumer device needs these three features and the protocol must be
simple.

If SBP2 implementation needs 30K for initiator and target, it might be
difficult to use it for consumer device.

Toru Ueda
Software labs.
Sharp Corp.

On Wed, 11 Feb 1998 08:35:10 -0800
"Turner, Randy" <[email-masked]> wrote:

> 	From:	Stephen Homestead [SMTP:[email-masked]]

---

From: Brian Batchelder <[email-masked]>
Date: Tue, 17 Feb 1998 00:30:23 -0800

Time to put in my $0.02-worth.  I apologize if any of this is redundant.  I
wrote it a few days ago, but only now have been able to send it.

1394 was designed for, and will be used as a symmetric, peer-to-peer bus.
The majority of devices will benefit from being able to communicate with
every other device, which includes both initiating that communication and
sending and receiving data.  Other devices that don't need peer-to-peer
functionality will also move to 1394 for other factors, e.g. throughput,
installed base, etc.

IMHO, SBP-2 was designed to provide for those non peer-to-peer devices by
emulating old master-slave busses on top of this inherently peer-to-peer
bus.  (Flame away!)  This works well for mass storage devices, for example.
 The initiator always initiates (sorry) communication.  The target never
initiates communication.  The initiator knows the sequence and quantity of
data to be transferred.  The target paces and executes the transfer of that
data.  

Unfortunately, this doesn't map well to true "peers".  As I indicated
earlier, each peer wants to initiate communication with other peers, in
addition to being the target of other peers.  You can think of this from
the application point of view.  Applications that operate as clients want
to initiate communication with applications that operate as servers.  Most
devices will have both types of applications.  Printers have print engines
(servers) and status engines (clients).  Scanners have control engines
(servers) and scan engines (clients).  Multi-function peripherals have all
of that plus maybe FAX engines, which might act as servers and clients.

In the past, we have made clients look like servers and vice-versa, because
of the limitation of our busses.  Fine.  I can see SBP-2 as a mechanism to
bring those old implementations to 1394.  We have also figured out ways to
allow clients and servers over master/slave busses by hiding the
"master/slaveness" in the transport layer (1284.4 is an example of this).
To make SBP-2 work AS IS for us, we would have to choose one of those two
paths, and we still have to add some other functionality.

Actually, I am currently leaning towards SBP-2, but we must use it in a way
that allows clients to be clients, servers to be servers, and both to exist
on every device.  This probably means implementing both target and
initiator (targiator) functionality on each device.  If the chip
implementations available today don't optimally support targiators, well,
we won't be optimal until they are fixed.  However, I was pleased to read
Michael Teener's message in which he indicated that targiators should be
quite possible.

If, however, targiators CAN'T be supported, I believe we will have to look
elsewhere for a solution.  I like Ats' idea of 1284.4 over something else
(DFA?).  I agree that 1284.4+SBP-2 does feel quite redundant.  I know that
we chose SBP-2 largely because it was an existing standard with support
from both Microsoft and the mass-storage industry.  One thing this long
discussion has DEFINITELY taught me is that SBP-2 is not unanimously
believed to be the obvious solution.

Remember, we are specifying a protocol that we must assume will be used for
at least the next 10 years.  Can we afford to limit the functionality of
our implementations?

Brian

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:[email-masked]  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227