On Tuesday 01 January 2008 23:40:30 Timothy Normand Miller wrote: > On 1/1/08, Lourens Veen <[EMAIL PROTECTED]> wrote: > > > > I'm not sure what you're looking at. See > > > mem_ctl/tims/memctl_syn_top.v and > > > mem_ctl/tims/memctl_fsm_200712.v. (There are two other files in > > > there, but they're not so important.) > > > > Oh. I was looking at the pni version, this one does have a 64-bit > > interface. I'll have to look at it in more detail. I'm going to try > > and make a big map of all the modules and how they connect > > together, as a starting point for the documentation. It might take > > me a while though, as that's quite a hefty job. > > At the moment, there are some scripts that are used to compile (for > sanity check) the source files together using Icarus. That might be > a place for you to start. > > We also need to put those README (or whatever) files into these rtl > directories to tell people which modules are the ones currently being > used so as to avoid things like you thinking that the pni version was > the one being used in OGD1 right now.
Or have a good explanation on the wiki of what is what. > > > Yes and no. Different memory sizes have different numbers of > > > rows and columns. How the address gets broken up into > > > column/row, etc. needs to be made configurable in the arbiter. > > > > So that we can have the same set arbiter/memory controller pairs > > work with different memory configurations, or in other words, have > > a single TRV10 that can deal with different memory configurations, > > right? > > I wouldn't try connecting different memory types to the same TRV10 at > the same time. Plus, there's only one set of config registers. We > could split them up, but it would be very odd to have different > memories with different timing characteristics. > > But for a given set of eight RAM chips of whatever type, we should be > able to get TRV10 to talk to them. That's what I meant, that we don't have to produce a different version of TRV10 for every memory configuration that customers want. > Interestingly, all the best-priced DDR RAM chips seem to have a CAS > latency of 3. Certainly, nothing has anything longer. And for us, > we'd get no benefit from 2.5. Right now, the controller is > hard-coded to only do 3. I think we'll be forced to move to DDR3 > chips before this becomes a problem. > > One thing pops into mind. We should look into making this memory > manager able to use only 2 or only 1 of the memory chip pairs. This > way, we can deploy a TRV10 with only two memory chips. It'll be > slower, but it's a way to save on board space and money for an > embedded system. At the moment, everything assumes that there are > four 64-bit-wide memory controllers. That's not an assumption we > should really be making. That would just be a change to the routing logic right? It would have to be able to select using 0, 1 or 2 LSBs, and then chop off the corresponding amount (2, 1 or 0) of bits at the top to make a 25-bit address to pass into the arbiters. Or am I missing something? Lourens
pgp05NQ6UGFJv.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
