OPENCORES.ORG

-----Original Message-----

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
> 