On Wed, Jul 30, 2008 at 3:34 PM, Petter Urkedal <[EMAIL PROTECTED]> wrote: > I had a look at the IO unit in HQ and your wrapper. If you're already > on track to integrate the HQ, you may ignore this, but my idea and > questions of how to this is,
Alas, I spent most of the day beating my head against some image processing stuff that is necessary for but sadly not the focus of my research. > * Do we keep the val_or_addr[0] indicator for inport vs outport? I > see no reason not to, we'll just revise hqio.asm at the end. You're using bit zero of the I/O space address to select direction? I see no problem with that. I think we have plenty of "space", and if having this extra indicator (besides the fact that the CPU knows whether it's reading or writing) yields a way to save logic or make it faster, then go for it. What happens if you do a reads on a write address or a write on a read address? (Not that we really have to worry about the consequences.) > > * We route out the port address and data i/o from HQ, something like > > module oga1hq( > ... > output [8:0] io_addr, IIUC, this can be [7:0], since the high bit is for scratch space and the low bit is direction. > output io_enable, // read or write depending on io_addr[0] > output [31:0] io_write_data, > input [31:0] io_read_data); > > * We instantiate oga1hq inside hq_wrapper. Yes, and a means to access the program file from the outside. This will be implemented by two registers in the lower 1K words of the engine address space. One register is the file address, and the other is the data. We may or may not implement auto-increment. Also, if we can, we should run this in the PCI clock domain so we don't need a fifo and we don't have to worry about meeting timing constraints. > * We implement a port address decoder inside hq_wrapper. Yes. > One thing which is not clear to me is what to register at what needs to > be combinatorial. I think the critical part is reads. The input ports > needs to be decoded from the port address (val_or_addr) and fed back to > HQ and multiplexed into wb_val_o in one cycle, or is there another way? Well, can we get the address any earlier? If we could get a cycle early, we could pipeline the read MUX. However, if the read address is registered, and the read data gets registered, then all we have between registers is some MUXing, which probably won't be too bad, especially considering how few ports we're implementing right now. Right now, the version if HQ I have doesn't implement an externally accessible I/O address, so I can't tell. -- 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)
