Greg Shue wrote:
> > 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.
>
Actually a single ORB can point to a data buffer which is larger than the
maximumlegal 1394 packet transfer size. Therefore multiple data packet
transfers can be
caused by one ORB.
> 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
> ----------------------------------------------------------------
Jack Hollins
ASIC Architect
Adaptec