On Wed, Jul 23, 2008 at 1:49 PM, Petter Urkedal <[EMAIL PROTECTED]> wrote: > 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?
When the address decode logic gets a write from PCI, first it gets the address and pushes that into the queue, with some flags indicating that this is an address, and along side are flags that indicate the target (engine, memory). The address is a byte address; only for I/O space will the lower two bits be non-zero. The next thing it does is push the data word onto the same queue, with some flags indicating that this is write data, along with the byte enables. Since 38 bits are required to make sense of the queue entry (for data: 32-bit data, 4-bit byte enable, 2-bit type), and HQ is 32-bit, either we need to expand HQ to more than 32-bit, or we throw more ports at it, with one port triggering a dequeue when accesses (probably the data/address portion). > >> 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. PCI allows per-word byte enables. The c/be signals are the command on an address cycle but the byte enables on a data cycle. > Assuming e.g. byte enable are encoded in the top of the address, the > code may look something like (omitting count logic) For the command queue, an address entry contains the following data: Address -- 30 bits Type -- 2 bits (indicating that it's an address) Target -- which memory space The following memory spaces are valid parameter TARGET_CFG=0; parameter TARGET_ENG=1; parameter TARGET_MEM=2; parameter TARGET_PROM=3; parameter TARGET_IO=4; HQ can't get CFG or PROM, but it can get any of the other three. (Actually, I think IO isn't connected right, but we can fix that easily.) > 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. Well, the port address should exist in any case. But it should be passed through to the bridge. The S3 may throw it away. In other words, don't pay it any special attention. >> * 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 I kinda like the second one better. -- 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)
