On 9/8/07, Petter Urkedal <[EMAIL PROTECTED]> wrote:
> On 2007-09-08, Timothy Normand Miller wrote:
> > No.  Memory too, although the master controls would look almost identical.
>
> Are we not going to use the same FIFO for streaming write and single
> writes?  If we are, then I suggest unifying at least some of the ports.
> In the simplest case we have just
>         WRITE_ADDR
>         WRITE_DATA
>         WRITE_COMMAND_FREE

Yes, we want to use the same fifo.  The DMA controller wants an
address followed by a block of data words without addresses.
Similarly, the bridge isn't wide enough to quickly carry both an
address and data so we submit an address, followed by a block of data
words.

In both cases, it's actually a flag bit in the fifo that indicates
whether we're setting the address or transferring data (for a write).
We use different I/O ports because, well, that totals more than 32
bits of data to be enqueued.

>
> On each write to WRITE_DATA, WRITE_ADDR is incremented (modulus 2^6 if
> necessary).  If the hardware needs to know the number of writes before
> submitting, we'd also need a WRITE_COUNT which is be reset to 1 on each
> write to WRITE_ADDR.

The memory system won't care.  We will probably have the modulo
counter, but otherwise, it doesn't need to know in advance when to
stop.  On the other hand, the DMA controller needs an explicit
termination flag.  I'm pretty sure that's actually a flag on the last
write data word, because IIRC, PCI protocol won't allow us to end a
transaction without actually transferring a data word.  (One
alternative to that is to deassert all byte flags and "transfer" an
empty word.  But that's kinda dumb.)

BTW, the DMA controller has only two fifos.  One fifo accepts read
commands (with count), write commands, write data, and write
termination.  The other fifo is for read data.  We'll need to make the
crossbar smart enough to know when to indicate termination for writes
(which is at the end or at every 64th word).

-- 
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to