Timothy Normand Miller wrote:
On 3/16/07, Daniel Rozsnyó <[EMAIL PROTECTED]> wrote:
Timothy Normand Miller wrote:
> It won't be long before we'll have to design a nanocontroller for OGD1
> to manage VGA and DMA. I may be able to just go off and design one
> myself, but I think that many of you would fancy observing and
> participating in the design process, and with more brains on it, we'd
> do a better job.
...
...
Ok, I've read your whole idea.. and I have a question regarding the
memory access:
- is the DMA "hw accelerated", so that this new core will set only
addresses for fragments and the transfer is done automatically, you only
do the calculation of sizes because of interrupted pci tranfers?
This one. I thought about and thought about it, and I decided that
making the CPU baby-sit the DMA would require way too much overhead.
One of my original ideas was to have the PCI master handle individual
transactions, but if the target (the host chipset in this case) were
to terminate the transaction, then our CPU would have to catch it,
recompute the address, and restart. But I decided that a relatively
small enhancement to the state machine for the master would save a
huge amount of trouble in the end.
My plan, at this point, is to decide on some boundary that the CPU is
not allowed to ask the master to cross. Let's say it's 256-byte
boundaries (which is the case for the target at the moment). This
way, we can limit the number of bits in the address counter in the
master, keeping the clock rate up. If something needs to cross the
boundary, then the CPU will just have to issue more requests.
With this approach, the CPU can just toss sets of requests into a
queue and trust that they'll happen (short or something catastrophic).
Then, it can use what limited processing power it has to do useful
things like unpack engine command packets into register writes, etc.
Are you going to have an interrupt or use a WAIT instruction?
--
JRT
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
