OPENCORES.ORG

Richard:
Sure..   Seems fair that those who complain about documentation should be willing to do some work to help.
I'll add some words about basic architecture  - an explanation of why along lines of Peter's paragraph - and delete 
the offending verilog description.  ( will look at all files in common/generic_memories ). 

bj Porcella
http://pages.sbcglobal.net/bporcella/
----- Original Message ----- 
From: "Richard Herveille" <richard@h...>
To: "'Discussion list about free open source IP cores'" <cores@o...>
Sent: Friday, July 16, 2004 10:11 PM
Subject: RE: [oc] Generic Memories

> 
> Do you volunteer to go over the file and update it?
> Keep in mind that the address-registered version is directly synthesizable
> to FPGAs.
> 
> Cheers,
> Richard
>  
> 
> > -----Original Message-----
> > From: cores-bounces@o... 
> > [mailto:cores-bounces@o...] On Behalf Of bporcella
> > Sent: Friday, July 16, 2004 4:50 PM
> > To: Discussion list about free open source IP cores
> > Subject: Re: [oc] Generic Memories
> > 
> > Peter:
> > 
> > Thanks for the reply.  I've confirmed the accuracy of your 
> > answer, and will follow your advice.
> > 
> > I will not however, use the generic_memory files found in 
> > Open Cores CVS.
> > 
> > While I suspect that there is a lot of good and useful work 
> > behind them,   The lack of basic architectural description,
> > and the inconsistencies in the selectable verilog 
> > descriptions  ( generic_dpram.v)  don't inspire confidence.
> > 
> > For the benefit of those who seem to be missing the point, 
> > perhaps I should dwell on the above statement.   The subject
> > file contains
> > two selectable verilog descriptions, one of which describes a 
> > dual port memory with address register, the other describes a dual
> > port memory with data register.   While these two structures 
> > may simulate in roughly the same way, they have different
> > timing characteristics
> > in any target technology and are not used interchangeably by 
> > knowledgeable designers.
> > 
> > bj Porcella
> > http://pages.sbcglobal.net/bporcella/
> > ----- Original Message -----
> > From: "H. Peter Anvin" <hpa@z...>
> > To: "Discussion list about free open source IP cores" 
> > <cores@o...>
> > Sent: Tuesday, July 13, 2004 5:07 PM
> > Subject: Re: [oc] Generic Memories
> > 
> > 
> > > bporcella wrote:
> > > >
> > > > On the other hand,  my attempts to use "generic" memory 
> > in Open Cores
> > > > CVS have been frustrating -- what are
> > > > described as "generic dual port rams"  turn out to be 
> > "generic dual port
> > > > rams with read output registers"
> > > > or "generic dual port rams with read address registers"   -- or
> > > > sometimes both.
> > > >
> > > > I strongly suspect that most of the "generic" memories in 
> > CVS are not
> > > > fully "up to date".
> > > > They are (at minimum) not well described - in my humble opinion.
> > > > Perhaps some of you who have been around awhile could 
> > think about this a
> > > > few minutes.
> > > >
> > > > TWO QUESTIONS
> > > > 1) Are we perhaps better off using FPGA tools to instantiate
> > > > memories from standard descriptions (updated often by 
> > vendors) or should
> > > > we continue to try to maintain generic files that "aid" 
> > in syntheses?
> > > > 2)  More importantly - do the "generic" memory files we 
> > have actually
> > > > aid in FPGA synthesis  - if so how.?
> > > >
> > >
> > > Most FPGAs available today have RAMs which required address 
> > registering.
> > > Thus, you generally can't use the RAM structures in FPGAs 
> > unless you use
> > > registered addresses/write data, and preferrably registered 
> > read data as well.
> > >
> > > What I generally do is put RAM instantiations in separate 
> > files; that way I
> > > can use either vendor-specific files or generic files -- 
> > after all, you need
> > > generic files e.g. when running simulations, and frequently 
> > the FPGA tools can
> > > figure out what you want from the generic files, so you 
> > don't need to muck
> > > with vendor-specific stuff at all.  For *initialized* 
> > memories, though, you
> > > generally do need vendor-specific stuff :(
> > >
> > > -hpa
> > > _______________________________________________
> > > http://www.opencores.org/mailman/listinfo/cores
> > 
> > _______________________________________________
> > http://www.opencores.org/mailman/listinfo/cores
> > 
> 
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/cores