P1394 Mail Archive: Re: P1394> Print Protocols

Re: P1394> Print Protocols

Greg Shue (gregs@sdd.hp.com)
Thu, 19 Feb 1998 11:44:22 -0800 (PST)

> At 3:11 PM -0800 2/17/98, Eric Anderson wrote:
> >I
> >would suggest that generally whatever device has initiated the
> >operation is the initiator (simple, huh?). In the scanner-printer
> >case, probably we pressed a button on the scanner to cause it to
> >print the image. So the scanner is the initiator in this case.
>
> Actually, I think it is a bit more complicated.
>
> 1) In SBP-2, most of the pacing (flow control) is done by the target (it's
> the target that fetches the ORBs and decides exactly when to do the data
> transfer), it is best for the device that has the most constraints on
> timing to be the target. It's a toss-up between a scanner and a printer,
> but between a CPU and a printer *or* a scanner, it's the CPU that has the
> most relaxed timing, so it should be the initiator.

"Actually, I think it is a bit more complicated."

Flow control:
If "flow control" refers to the scheduling of bus transactions to
process a task, then I agree it is done by the (target's) fetch
agent.

If "flow control" refers to the presentation of the task requests
(ORBs) and shared memory space then it is managed the initiator,
since we're talking about one task request (ORB) referring to one
"packet" transfer.

If "flow control" refers to the policy for availability of the
shared memory space for doing transactions, then it's shared between
the target and the initiator (depending on the direction of data flow).

I still prefer Eric's proposal that whatever device has initiated
the operation is the initiator. It avoids having to have the
connected-to devices from polling the want-to-connect devices to
figure out when the connection needs to happen. That's much more
wasteful of processing power and bus bandwidth than providing
target functionality on a PC and using it only when appropriate.

Besides, who said we had to use the same SBP-2 device profile
for PC printing and "peer-to-peer" printing?

> 2) Devices that have a natural memory model (CPUs come to mind) should be
> initiators, since that allows them to implement a simple bus bridge
> function to support the target read and write operations directly, without
> software intervention.

"Silly me, I thought that any device driven by a CPU (whether a PC
or embedded device) has a natural memory model."

I guess that you mean devices which effeciently support memory
accesses from other 1394 notes should be initiators. No, that
doesn't sound quite right either. How about:

Devices which cannot provide timely scheduling of 1394 transactions
should not be driving fetch agents?

> ===========================================================================
> Michael D. Johas Teener, Chief Technical Officer & Chairman of the Board
> Zayante, Inc., 269 Mt. Hermon Rd. #111, Scotts Valley, CA 95066-4000, USA
> email: mike@zayante.com voice: +1-408-461-4901 fax: +1-408-461-1394
> ======================== http://www.zayante.com ===========================

-- 
Greg Shue
Hewlett-Packard Company
Office Products Division			gregs@sdd.hp.com
----------------------------------------------------------------