> > > "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.
>
> Ah, another case of overloaded terms. Yes, an ORB can refer to
> a much larger data buffer than the maximum possible MTU of the bus.
> This results in many MTU transfers per ORB. Thanks for keeping me
> honest and consistent.
>
> I was using "packet" with respect to the transaction layer.
> I was thinking of the case where a 10 MByte print job is consumed by
> a device with 1 MByte of buffer space, and the flow of data into the
> 1 MByte buffer space must be controlled. In this case I was thinking
> that ORBs with 0.5 MByte to 1 MByte data blocks would be reasonable.
>
Actually the initiator does not need to be aware of buffer limitations of the
targetin regards to the initiator sizing the data buffers associated with an
ORB. A target
is under complete control of the consumption rate once an ORB has been put in
the
initiator's linked list (assuming linked lists are used) or if the ORB pointer
CSR is
written in the non-linked list case. This allows different target
architecture
performance/cost tradeoffs to be made without impacting an initiator. A more
cost
sensitive target might have a smaller buffer space than a higher performance
target.
> > Jack Hollins
> > ASIC Architect
> > Adaptec
>
> --
> Greg Shue
> Hewlett-Packard Company
> Office Products Division gregs@sdd.hp.com
> ----------------------------------------------------------------
Jack Hollins
ASIC Architect
Adaptec