[Open-graphics] HQ stub in place

[Petter Urkedal]

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.