On 2008-07-23, Timothy Normand Miller wrote:
> ;; Target Write
> let PCI_T_WRITE_COUNT = _PCI_B + 0x08 ; in - number of words in write queue
> let PCI_T_WRITE_ADDR_FL = _PCI_B + 0x09 ; in - address and flags for a
> write
> let PCI_T_WRITE_DATA = _PCI_B + 0x0a ; in - data of write word
>
> * The way we queue writes for the bridge is that there's an address
> followed by data. But since HQ is 32-bit, there aren't enough bits to
> detect that.
I don't quite follow, but I think this is because I don't know
PCI_T_WRITE_ADDR_FL is encoded. Is it a byte or word address, and where
are the byte-enables encoded? Are there other flags that will not be
naturally integrated in the address?
> But maybe we should think about that. It would be nice
> if the protocol to fetch PCI writes were more similar to the protocol
> to push them on to the bridge.
I tentatively agree, but maybe they are naturally different as PCI uses
the same byte-enables for a whole stream, whereas our bridge allows
per-data enables.
Assuming e.g. byte enable are encoded in the top of the address, the
code may look something like (omitting count logic)
move [PCI_T_WRITE_ADDR_FL], r0
shiftu r0, -28, r1 ; r1 = byte-enables
and 0xfffffff, r0, r0 ; r0 = start address
move r0, [MEM_WRITE_ADDR]
... ; begin test and loop
move [PCI_T_WRITE_DATA], r2
move r2, [add MEM_WRITE_DATA_0000, r1]
... ; end test and loop
So it need not be too difficult, if I understand this right.
> ;; Memory Ports
> ;; ============
>
> let _MEM_B = -0x40 ; base address for memory ports
>
> let MEM_READREQ_FREE = _MEM_B + 0x00 ; in - Free slots in command pipe.
> let MEM_READREQ_ADDR_TRIG=_MEM_B + 0x01 ; out - First address to read.
> let MEM_READREQ_COUNT = _MEM_B + 0x02 ; out - Number of words to read.
> let MEM_READREPLY_DATA = _MEM_B + 0x03 ; in - Data stream from memory.
> let MEM_READREPLY_AVAIL = _MEM_B + 0x04 ; in - Number of words in FIFO.
>
> let MEM_WRITE_ADDR = _MEM_B + 0x05 ; out - Start address.
> let MEM_WRITE_FREE = _MEM_B + 0x06 ; in - Free slots in output FIFO.
> let MEM_WRITE_DATA_0000 = _MEM_B + 0x10 ; out - 16 ports for data
> stream, where
> ; lower 4 address bits are enables.
> let MEM_WRITE_DATA_1111 = MEM_WRITE_DATA_0000 + 15 ; for convenience
>
>
> * All write addresses, read addresses, read counts, and write data go
> into one queue. Obviously, they need different ports in order to set
> the other flags in the command word, but since there's only one queue,
> then there should be only one "free" port. I've also been thinking
> about the 0000 write. At first, I thought it should be there but do
> nothing. Now, I think it's a good way to insert a "dead" write into
> the stream, like a convenient way to skip a word or two while
> advancing the auto-increment, although issuing an address command
> doesn't really waste any time by comparison.
Gate-wise, the 0000-writes are for free, aren't they? It usually takes
logic to deal with special cases, so can't we just omit that logic? I
think 0000-writes could be useful in cases where we don't know the
byte-enables while writing the code, if such cases exists.
> * There are three bus commands. They are:
> parameter b_addr = 1;
> parameter b_rcount = 2;
> parameter b_write = 3;
>
> So, you can set addresses all you want. They take up queue space, but
> all they do is set the address in the S3. rcount triggers a read, and
> write issues a write word (and we can think of it as generally
> stateless except that we have to make sure the address is right). If
> you know what rcount and write commands are going to do to the address
> counter in the S3, there may be circumstances where you can skip the
> address command, although I wouldn't generally recommend certain
> combinations simply because it's more of a pain sometimes to keep
> track than to just issue another address.
So, to mirror the bridge commands, it would be sufficient with
MEM_CMD_FREE
MEM_CMD_ADDR
MEM_CMD_READ_COUNT
MEM_READ_AVAIL
MEM_READ_DATA
MEM_WRITE_DATA_0000
MEM_WRITE_DATA_1111
where MEM_WRITE_DATA_xxxx are really commands. Yet another naming
scheme:
MEM_CMDQ_FREE
MEM_SEND_ADDR
MEM_SEND_READ_COUNT
MEM_SEND_DATA_0000
MEM_SEND_DATA_1111
MEM_READQ_AVAIL
MEM_READQ_DATA
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
