[Open-graphics] OGA1 mad dash: What's left

[Lourens Veen]

On Tuesday 01 January 2008 23:40:30 Timothy Normand Miller wrote:
> On 1/1/08, Lourens Veen <lourens at rainbowdesert.net> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.duskglow.com/open-graphics/attachments/20080102/c38e2e7e/attachment.bin