On 2008-07-24, Timothy Normand Miller wrote:
> That's the issue.  If there were ever a side-effect on a read, we
> would need to put the address decode in single-word mode.  I think
> there may be side effects for VGA graphics.

Okay.

> What were you not satisfied?  Previous version of what?

That would be my own hqio.asm attachment from yesterday.

> Also, I'm not thinking much about PCI master right now, but I was
> thinking we should have three queues.  Command, read data, and write
> data.  The main reason to separate write data from commands is that we
> can now somewhat independently control write data generation and write
> address generation.  We'll have a short counter for the address, and
> we need to track the address so the master can restart on terminate.
> There's also a lot of latency between issuing a write command (with
> count known in advance) and the data actually being consumed.  The
> thing about the PCI master is that the writes aren't "reliable" in
> that we can just issue them and forget.  The bus protocol allows the
> other target a lot of control.  This is in contract to our bridge
> which is entirely a slave device, so there's no need for the extra
> flexibility.  If this doesn't make sense, ask, and I'll try to explain
> better.

I see the point, thanks.  I may ask about details later, but this should
suffice for the port definitions.  So, I reverted the _FREE port
unifications for the master and some of naming.  Should I commit
hqio.asm, or do you prefer to wait till nail down the port numbers
(i.e. after the Verilog is written)?
;; PCI Target Numbers
let PCI_TARGET_CFG = 0  ; (not seed by HQ) configuration
let PCI_TARGET_ENG = 1  ; engine
let PCI_TARGET_MEM = 2  ; memory
let PCI_TARGET_PROM = 3 ; (not seen by HQ)
let PCI_TARGET_IO = 4   ; IO


;; PCI Ports
;; =========

let _PCI_B = -0x20 ; base address for PCI ports

;; Master Command
let PCI_M_CMD_FREE      = _PCI_B + 0x00 ; in - number of commands we can write
let PCI_M_CMD           = _PCI_B + 0x01 ; enq - direction and count

;; Master Write
let PCI_MW_FREE         = _PCI_B + 0x02 ; in - how many data words we can write
let PCI_MW_DATA_0000    = _PCI_B + 0x10 ; enq - 16 ports for data word, where
                                        ; lower 4 address bits are byte enables
let PCI_MW_DATA_1111    = PCI_MWR_DATA_0000 + 15 ; for convenience

;; Master Read
let PCI_MR_COUNT        = _PCI_B + 0x04 ; in - number of words available to read
let PCI_MR_DATA         = _PCI_B + 0x05 ; deq - data word

;; Target Write
let PCI_TW_COUNT        = _PCI_B + 0x08 ; in - number of words in write queue
let PCI_TW_INFO         = _PCI_B + 0x0a ; in - type, target, byte-enables
let   PCI_TW_INFO_TARGET_SHIFT  = 29
let   PCI_TW_INFO_TARGET_MASK   = 0xe0000000
let   PCI_TW_INFO_TYPE_MASK     = 0x03000000
let     PCI_TW_INFO_TYPE_ADDR   = 0x00000000
let     PCI_TW_INFO_TYPE_RCOUNT = 0x01000000
let     PCI_TW_INFO_TYPE_WDATA  = 0x02000000
let   PCI_TW_INFO_ENABLE_MASK   = 0x0000000f
let PCI_TW_DATA         = _PCI_B + 0x0b ; deq - address or written data

;; Target Read
let PCI_TR_PENDING      = _PCI_B + 0x0c ; in - nonzero if pending read
let PCI_TR_ADDR         = _PCI_B + 0x0d ; deq - the one address that is pending
let PCI_TR_DATA         = _PCI_B + 0x0e ; enq - where we write the one word


;; Memory Ports
;; ============

let _MEM_B = -0x40 ; base address for memory ports

let MEM_CMDQ_FREE       = _MEM_B + 0x00 ; in - free slots in command pipe
let MEM_SEND_ADDR_MEM   = _MEM_B + 0x08 ; enq - address for memory read or write
let MEM_SEND_ADDR_ENG   = _MEM_B + 0x09 ; enq - address for engine read or write
let MEM_SEND_READ_COUNT = _MEM_B + 0x0f ; enq - do a read of given word count
let MEM_SEND_DATA_0000  = _MEM_B + 0x10 ; enq - 16 ports for data stream, where
                                        ; lower 4 address bits are enables
let MEM_SEND_DATA_1111  = MEM_SEND_DATA_0000 + 15
let MEM_READQ_AVAIL     = _MEM_B + 0x02 ; in - number of words in FIFO
let MEM_READQ_DATA      = _MEM_B + 0x03 ; deq - data stream from memory

;; [1] http://readlist.com/lists/duskglow.com/open-graphics/1/6252.html.
_______________________________________________
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