On 2008-07-30, Timothy Normand Miller wrote: > > * 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.
I though you had put that in. On second though I don't think a direction bit in the address has any purpose. We could just consider input and output ports to be distinct address spaces, so that reading and writing to -0x20 are two different functions. > 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.) Right, I think we'd just have to throw away the lower bit if we went with this scheme, since the authoritative source must be the instruction. > > * 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. Yes, I picked 8 out of the air. I would also suggest changing the bit 9 test on val_or_addr to bit 31, cf bottom of http://readlist.com/lists/duskglow.com/open-graphics/1/5851.html unless you've changed your mind. Then we don't have a predefined limit on the range, and we can adjust the io_addr width as needed. > > 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. I don't think we can. val_or_addr comes directly from res_o of the ALU, which by the way already is MUXed after registration. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
