On 1/1/08, Lourens Veen <[EMAIL PROTECTED]> wrote: > > Note that the decision as to which arbiter to talk to, when doing PCI > > writes, is being made at the top level. The amount of logic is > > trivial, but it's probably inappropriate to do it this way, from a > > logical standpoint. > > You mentioned this before in the context of the FIFOs, and talked about > having an extra wrapper around some modules that includes the FIFOs. > Perhaps a similar solution could work here, to wrap the four arbiters > together with the router into a single module (the memory manager?)?
Yes, probably. We can move the bridge-to-arbiter command fifo into there as well. I don't want to tackle that right now. It's too much code to move and reconnect. Too much opportunity to make mistakes. We can try it when Kenneth has his perl script done that checks connections and stuff. > > 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. > > 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. 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. -- 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)
