> In the project Milkymist, they use a nice trick to have a tiny but
> really fast DRAM controller (
http://opencores.org/project,hpdmc),
> they put an hardware interface only for the common use, and use
> register and bit bangingt with a lattice cpu for the init part.
>
> I like the idea to have a cpu using register (connected to signals)
> for the complex part, and a ultra fast hardware for the common case
> (only).
>
> Regards,
> Nicolas Boulay
>
> 2010/10/25 Timothy Normand Miller <theosib@gmail.com>:
>> On Mon, Oct 25, 2010 at 7:20 AM, Mark Marshall <mark.marshall@csr.com> wrote:
>>
>>> I agree with the other comments here though. A video-mem to video-mem copy
>>> should be done in the S3, as should block fills. If we are copying
>>> video-mem to system-mem then I think we really need to bus master to get
>>> this "fast". The trick (I guess) will be to free up the PCI bus and the
>>> host CPU while we are reading from RAM to S3 and then from S3 to XP10. Only
>>> when the data is in the XP10 do we want to use the PCI bus, and then we
>>> still don't want to bother the CPU.
>>
>> How about we drop _another_ HQ into the S3, just as a quick hack for
>> starters. We need a real blt engine, but until we run out of space
>> for something else, there's no harm in having a microcontroller
>> sitting in the S3.
>>
>>>
>>> I'd really like for someone to be working on PCI bus master, as I think
>>> that's the one feature that's really going to make things faster.
>>>
>>
>> To do the PCI target, I first designed a simulation-only model that I
>> debugged, and then I converted it to a synthesizable form (and in the
>> process found some bugs and such). As a test harness for this, I also
>> developed a simulation version of a master. This master is designed
>> to be as aggressive as possible with the protocol so as to test the
>> target. Some of these things need to be relaxed a bit, and some
>> changes need to be made regarding how it handles transaction
>> termination and such. And then it can be converted to a synthesizable
>> form. Finally, we need to make some decisions on how the thing is
>> controlled. And I don't remember enough about it to talk further
>> about this, although we did already discuss this at length on the list
>> in the past. Basically, HQ drops commands into a queue, which the
>> master processes in sequence, and the commands are things like "read X
>> pci words from address Y and send them to address Z in graphics
>> memory". So the master would be connected to like three fifos.
>>
>> Oh, and then there's the matter of integrating the two to use the same
>> set of pins. We play a trick in the master to allow MUXes to be as
>> close to the pins as possible. For a handful of signals, we'll have
>> to pull that logic out into a master-target wrapper. And then
>> anything that is registered will have to be pulled out into the
>> wrapper, because there will be more than one piece of logic that might
>> require an input be registered in or an output registered out.
>>
>> Let's not worry about this too much for now. For the short term,
>> let's drop an HQ into the S3. We'll have to give it its own read and
>> write ports on the arbiter and make its program memory available in
>> the register space. Then following that, we can put in a real blt
>> engine.
>>
>> --
>> Timothy Normand Miller
>>
http://www.cse.ohio-state.edu/~millerti
>> Open Graphics Project
>> _______________________________________________
>> Open-graphics mailing list
>>
Open-graphics@duskglow.com
>>
http://lists.duskglow.com/mailman/listinfo/open-graphics
>> List service provided by Duskglow Consulting, LLC (
www.duskglow.com)
>>
>
