[Open-graphics] Re: Nascent XP10 bridge (new)

[Petter Urkedal]

On 2007-12-10, Timothy Normand Miller wrote:
> Here's a new XP10 bridge design.  This one expects fifos to be
> attached to it, one for commands (address, write data, read count),
> and the other for returning read data.  This doesn't account for HQ,
> but logically, HQ goes between this and the physical bridge.  We'll
> have to work that out.

I'm thinking about how to integrate the HQ I/O into your xp10_bridge,
and I think its fairly straight forward except for how HQ deals with
return data from across the bridge.

The idea is to have a writable port with two mode bits.

  * HQ can at any time read FIFO counts and a status register composed
    of selected internal signals from the bridge, as long as no side
    effect (queuing) is involved.

  * One bit decides whether HQ intercepts data_in/deq_in and
    bridge_ad_out.  In that case HQ can dequeue the read end of the
    command FIFO and write to bridge_ad_out and bridge_cmd, where
    bridge_cmd is decided by the port address.

  * The other bit decides whether HQ intercepts bridge_ad_in and
    data_out/enq_out, in a similar fashion, except:

One issue remaining is that HQ cannot accept data from across the bridge
on every cycle.  Solutions I can think of are a) add a new FIFO, b)
reuse the return FIFO if possible, c) let the I/O unit override memory
operations in HQ and write directly to its BRAM, or d) only allow HQ to
do short reads using a tiny return FIFO.

Ad c.  HQ will still be able to use registers and access I/O ports.  In
the worst case, it will just run in a loop polling the status register
until the BRAM is available again.

Ad d.  Single-word reads would be easy to implement, but only feasible
if this are really unimportant.

That was my thoughts, I might have missed a more compelling solution.
Also, I haven't considered how this will work with PCI master/target
modes.  Can we get away with only the two FIFOs connecting the bridge/HQ
to the PCI controller?