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?
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)