Greg Shue said that he made a proposal to the January PWG that would
extend SBP-2 so that it was symmetrical (at least that is what I
understand--I may be way off here). If so, that would be great. I have
not been able to find any minutes from the PWG since Dec 97 (anyone got
some?).
1394 could really use a commonly accepted symmetrical transport layer.
If that's 1284.4, great. If that's a modified SBP-2, great. If that's
TCP/IP, great. If that's DPP's Thin Protocol, great.
Personally, I am biased towards IP or 1284.4 (if you couldn't tell).
Stephen Holmstead
> -----Original Message-----
> From: Toru Ueda [SMTP:ueda@slab.tnr.sharp.co.jp]
> Sent: Friday, February 13, 1998 5:45 AM
> To: Turner, Randy
> Cc: 'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
> Subject: Re[2]: P1394> Rough SBP-2 & IP1394 core component ROM
> sizes
>
>
> 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" <rturner@sharplabs.com> wrote:
>
> >
> >
> > 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 Homestead [SMTP:stephen@hpb16977.boi.hp.com]
> > Sent: Wednesday, February 11, 1998 8:30 AM
> > To: 'Turner, Randy'; 'Brian Batchelder'; p1394@pwg.org
> > 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:rturner@sharplabs.com]
> > > Sent: Monday, February 09, 1998 1:03 PM
> > > To: 'Brian Batchelder'; p1394@pwg.org
> > > 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:brianb@vcd.hp.com]
> > > Sent: Monday, February 09, 1998 9:37 AM
> > > To: p1394@pwg.org
> > > 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:brianb@vcd.hp.com
> > > Connectivity Futurist | 1115 SE 164th Ave. | Phone:
> > (360)
> > > 212-4107
> > > DeskJet Printers | Vancouver, WA 98684 | Fax:
> > (360)
> > > 212-4227
> >