2007/3/19, Timothy Normand Miller <[EMAIL PROTECTED]>:
On 3/18/07, Petter Urkedal <[EMAIL PROTECTED]> wrote:
> On 2007-03-18, Timothy Normand Miller wrote:
...
> So it's possible to move a value from one address to another in the same
> instruction within the same block RAM? Do we need it?
The objective is to be able to move data at 66.6 million words per
second. I would be amazed if our processor could exceed 100MHz. That
means if we required one IN and one OUT for each word to be moved from
the master state machine's fifo into the memory write fifo, we
couldn't keep up.
In fact, that makes me realize something I don't have a solution for.
When writing, we need to push two words: data and its address. If
that takes two cycles, we're already screwed.
I think someone suggested the idea of setting up background moves.
I suggest this. A kind of memcpy instruction. Complex op are the
better way to have performance, because you don't have the performance
penalty of using a DMA(or a specific core)+a cpu (you avoid a lot of
data move).
If you use 2 pipelines, you could synchronises every fetch to 2
different register set. Each pipeline are in order but one pipe is
multicycle. The order are done by the write on each register set.
But to know each specific instruction you need, you must do a study
about the exact use of the core.
That is, we don't move the words. We tell some other logic to do some
number of words. This also frees us from having to deal with pipeline
stalls, because we can just request to move N words (more than are
perhaps available at the time), and it takes an unknown amount of
time, and we pick it up later by checking status.
Checking status could also be slow :)
We're going to end up with an intricate network of queues. Read
request queues, read return queues, write queues, and queues into
which we put requests to do reads and writes. :)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
