Too bad the S3 doesn't have a built-in microcontroller. :) One of the ideas I had proposed for our memory controller was similar. Instead of a general purpose CPU, the idea was more like our video controller. The memory controller is basically a state machine, so the idea was to encode all state transitions in a block RAM. I decided against it because I thought I could get more speed out of dedicated logic (I still think that), but I think someone else went ahead and implemented something based on the BRAM idea. The reason I did use that idea for the video controller is because it needs to be reprogrammable, while the memory controller behavior is mostly fixed. Also, I wanted to avoid using too many BRAMs, because I want to use them for other things like FIFOs and program memory for shaders, etc.
On Mon, Oct 25, 2010 at 1:47 PM, Nicolas Boulay <[email protected]> wrote: > 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 <[email protected]>: >> On Mon, Oct 25, 2010 at 7:20 AM, Mark Marshall <[email protected]> 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 >> [email protected] >> http://lists.duskglow.com/mailman/listinfo/open-graphics >> List service provided by Duskglow Consulting, LLC (www.duskglow.com) >> > -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
