OpenCores

OpenCores

Generic Memories

no use

no use

1/1

no use

no use

Generic Memories by bporcella on Jul 13, 2004			bporcella Posts: 22 Joined: Jan 16, 2004 Last seen: Oct 2, 2007
All: In my mind a "generic" dual port memory is defined in verilog as: reg [dw-1 :0] mem [(1<<aw) -1:0]; // instantiate memory always @(clk) mem[wadr] <= data_in; // this is how you write data_out = mem[radr]; // this is how you read Specifically, the only registers associated with the "generic memory" are those that constitute the storage array. While I understand that to get maximum throughput from any such structure you want to register all I/O data as "closely as possible", - there are times maximum throughput is not needed. There are in fact design situation where multiplexors rather than registers might be more appropriate to place near the array for maximum SYSTEM throughput. I bring this up because Open Cores coding guidelines recommends using "generic" memories in designs - I suppose to minimize problems in porting between FPGA technologies. While I have no desire to cause myself extra grief, recent experience leads me to believe that most FPGA tools can deal very nicely with a simple dual port structure like that described above. 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.? bj Porcella <A HREF="http://pages.sbcglobal.net/bporcella/">http://pages.sbcglobal.net/bporcella/</A> -------------- next part -------------- An HTML attachment was scrubbed... URL: <A HREF="http://www.opencores.org/forums.cgi/cores/attachments/20040713/25bb0653/attachment.htm">http://www.opencores.org/forums.cgi/cores/attachments/20040713/25bb0653/attachment.htm</A> All: In my mind a "generic" dual port memory is defined in verilog as: reg [dw-1 :0] mem [(1http://pages.sbcglobal.net/bporcella/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20040713/25bb0653/attachment.htm

Generic Memories by Unknown on Jul 14, 2004			Not available!
bporcella wrote: [q] 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.? [/q] 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 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

Generic Memories by Unknown on Jul 14, 2004			Not available!
On Wed, 2004-07-14 at 04:56, bporcella wrote: [q] All: In my mind a "generic" dual port memory is defined in verilog as: reg [dw-1 :0] mem [(1<<aw) -1:0]; // instantiate memory always @(clk) mem[wadr] <= data_in; // this is how you write[/q] I hope this is just a typo and the actual source code is: always @(posedge clk) mem[wadr] <= data_in; [q] data_out = mem[radr]; // this is how you read[/q] This is slightly misleading, as the read address (radr) is actually registered. Some synthesis tools had problem correctly recognizing and instantiating memories if you write it as: "always @(posedge clk) data_out = mem[rad];" [q] Specifically, the only registers associated with the "generic memory" are those that constitute the storage array.[/q] The registers must be there where they are because this is how the memories in the FPGAs are constructed. Moving the registers will result in memories being implemented via LUTs, which is rather undesirable in most cases. [q] While I understand that to get maximum throughput from any such structure you want to register all I/O data as "closely as possible", - there are times maximum throughput is not needed. There are in fact design situation where multiplexors rather than registers might be more appropriate to place near the array for maximum SYSTEM throughput. I bring this up because Open Cores coding guidelines recommends using "generic" memories in designs - I suppose to minimize problems in porting between FPGA technologies. While I have no desire to cause myself extra grief, recent experience leads me to believe that most FPGA tools can deal very nicely with a simple dual port structure like that described above. 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. [/q] Thats because thats how the actual memories in the FPGA work. After they register the address they will drive the data. Trying to code the memories in any other way will result in memories being constructed from LUTs, instead of using BRAMs for example. If you can not work with the "registered output" memories, chances are you will have trouble with high speed ASIC memories as well. [q] 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?[/q] The idea here is portability. If your IP Core can work with generic_memories, it will be able to synthesize in to Altera and Xilinx and use the appropriate resources and be able use memories generated with various memory compilers for Full Custom ASICs. Using a FPGA memory compiler might be simple and straight forward for a particular project/implementation, but if your goal is a portable IP Core, it's the wrong approach. [q] 2) More importantly - do the "generic" memory files we have actually aid in FPGA synthesis - if so how.? [/q] Only in the sense that they help utilize the appropriate memory resources. [q] bj Porcella <A HREF="http://pages.sbcglobal.net/bporcella/">http://pages.sbcglobal.net/bporcella/</A>[/q] -- rudi ======================================================== ASICS.ws ::: Solutions for your ASIC/FPGA needs ::: ..............::: FPGAs * Full Custom ICs * IP Cores ::: FREE IP Cores -> <A HREF="http://www.asics.ws/">http://www.asics.ws/</A> <- FREE EDA Tools On Wed, 2004-07-14 at 04:56, bporcella wrote: All: In my mind a "generic" dual port memory is defined in verilog as: reg [dw-1 :0] mem [(1 always @(clk) mem[wadr] I hope this is just a typo and the actual source code is: always @(posedge clk) mem[wadr] data_out = mem[radr]; // this is how you read This is slightly misleading, as the read address (radr) is actually registered. Some synthesis tools had problem correctly recognizing and instantiating memories if you write it as: "always @(posedge clk) data_out = mem[rad];" Specifically, the only registers associated with the "generic memory" are those that constitute the storage array. The registers must be there where they are because this is how the memories in the FPGAs are constructed. Moving the registers will result in memories being implemented via LUTs, which is rather undesirable in most cases. While I understand that to get maximum throughput from any such structure you want to register all I/O data as "closely as possible", - there are times maximum throughput is not needed. There are in fact design situation where multiplexors rather than registers might be more appropriate to place near the array for maximum SYSTEM throughput. I bring this up because Open Cores coding guidelines recommends using "generic" memories in designs - I suppose to minimize problems in porting between FPGA technologies. While I have no desire to cause myself extra grief, recent experience leads me to believe that most FPGA tools can deal very nicely with a simple dual port structure like that described above. 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. Thats because thats how the actual memories in the FPGA work. After they register the address they will drive the data. Trying to code the memories in any other way will result in memories being constructed from LUTs, instead of using BRAMs for example. If you can not work with the "registered output" memories, chances are you will have trouble with high speed ASIC memories as well. 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? The idea here is portability. If your IP Core can work with generic_memories, it will be able to synthesize in to Altera and Xilinx and use the appropriate resources and be able use memories generated with various memory compilers for Full Custom ASICs. Using a FPGA memory compiler might be simple and straight forward for a particular project/implementation, but if your goal is a portable IP Core, it's the wrong approach. 2) More importantly - do the "generic" memory files we have actually aid in FPGA synthesis - if so how.? Only in the sense that they help utilize the appropriate memory resources. bj Porcella http://pages.sbcglobal.net/bporcella/ -- rudi ======================================================== ASICS.ws ::: Solutions for your ASIC/FPGA needs ::: ..............::: FPGAs * Full Custom ICs * IP Cores ::: FREE IP Cores -> http://www.asics.ws/

Generic Memories by Unknown on Jul 14, 2004			Not available!
Aloha! bporcella wrote: [q] 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. [/q] I would at least update the link chapter about memories (chapter 3.6.1) in the opencores_design_guidelines.pdf to point to the common/generic_memories/ section (not just common/) for easier findability. -- Med vÃ¤nlig hÃ¤lsning, Yours Joachim StrÃ¶mbergson - Alltid i harmonisk svÃ¤ngning. VP, Research & Development ---------------------------------------------------------------------- InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÃ–TEBORG / Sweden Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02 E-mail: <A HREF="http://www.opencores.org/mailman/listinfo/cores">joachim.strombergson at informasic.com</A> Home: www.informasic.com ---------------------------------------------------------------------- Aloha! bporcella wrote: 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. I would at least update the link chapter about memories (chapter 3.6.1) in the opencores_design_guidelines.pdf to point to the common/generic_memories/ section (not just common/) for easier findability. -- Med vÃ¤nlig hÃ¤lsning, Yours Joachim StrÃ¶mbergson - Alltid i harmonisk svÃ¤ngning. VP, Research & Development ---------------------------------------------------------------------- InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÃ–TEBORG / Sweden Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02 E-mail: joachim.strombergson at informasic.com Home: www.informasic.com ----------------------------------------------------------------------

Generic Memories by bporcella on Jul 16, 2004			bporcella Posts: 22 Joined: Jan 16, 2004 Last seen: Oct 2, 2007
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 <A HREF="http://pages.sbcglobal.net/bporcella/">http://pages.sbcglobal.net/bporcella/</A> ----- Original Message ----- From: "H. Peter Anvin" <<A HREF="http://www.opencores.org/mailman/listinfo/cores">hpa at zytor.com</A>> To: "Discussion list about free open source IP cores" <<A HREF="http://www.opencores.org/mailman/listinfo/cores">cores at opencores.org</A>> Sent: Tuesday, July 13, 2004 5:07 PM Subject: Re: [oc] Generic Memories [q] bporcella wrote: [q]> > 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.? >[/q] 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 _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A>[/q] 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 at zytor.com> To: "Discussion list about free open source IP cores" cores at opencores.org> 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

Generic Memories by Unknown on Jul 17, 2004			Not available!
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 [q] -----Original Message----- From: <A HREF="http://www.opencores.org/mailman/listinfo/cores">cores-bounces at opencores.org</A> [mailto:<A HREF="http://www.opencores.org/mailman/listinfo/cores">cores-bounces at opencores.org</A>] 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 <A HREF="http://pages.sbcglobal.net/bporcella/">http://pages.sbcglobal.net/bporcella/</A> ----- Original Message ----- From: "H. Peter Anvin" <<A HREF="http://www.opencores.org/mailman/listinfo/cores">hpa at zytor.com</A>> To: "Discussion list about free open source IP cores" <<A HREF="http://www.opencores.org/mailman/listinfo/cores">cores at opencores.org</A>> Sent: Tuesday, July 13, 2004 5:07 PM Subject: Re: [oc] Generic Memories [q]> bporcella wrote: [q] > > On the other hand, my attempts to use "generic" memory [/q] in Open Cores [q] > CVS have been frustrating -- what are > described as "generic dual port rams" turn out to be [/q] "generic dual port [q] > 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 [/q] CVS are not [q] > 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 [/q] think about this a [q] > few minutes. > > TWO QUESTIONS > 1) Are we perhaps better off using FPGA tools to instantiate > memories from standard descriptions (updated often by [/q] vendors) or should [q] > we continue to try to maintain generic files that "aid" [/q] in syntheses? [q] > 2) More importantly - do the "generic" memory files we [/q] have actually [q] > aid in FPGA synthesis - if so how.? >[/q] > > Most FPGAs available today have RAMs which required address [/q] registering. [q]> Thus, you generally can't use the RAM structures in FPGAs [/q] unless you use [q]> registered addresses/write data, and preferrably registered [/q] read data as well. [q]> > What I generally do is put RAM instantiations in separate [/q] files; that way I [q]> can use either vendor-specific files or generic files -- [/q] after all, you need [q]> generic files e.g. when running simulations, and frequently [/q] the FPGA tools can [q]> figure out what you want from the generic files, so you [/q] don't need to muck [q]> with vendor-specific stuff at all. For initialized [/q] memories, though, you [q]> generally do need vendor-specific stuff :( > > -hpa > _______________________________________________ > <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A>[/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A> [/q] 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 at opencores.org [mailto:cores-bounces at opencores.org] 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 at zytor.com> To: "Discussion list about free open source IP cores" cores at opencores.org> 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

Generic Memories by bporcella on Jul 17, 2004			bporcella Posts: 22 Joined: Jan 16, 2004 Last seen: Oct 2, 2007
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 <A HREF="http://pages.sbcglobal.net/bporcella/">http://pages.sbcglobal.net/bporcella/</A> ----- Original Message ----- From: "Richard Herveille" <<A HREF="http://www.opencores.org/mailman/listinfo/cores">richard at herveille.net</A>> To: "'Discussion list about free open source IP cores'" <<A HREF="http://www.opencores.org/mailman/listinfo/cores">cores at opencores.org</A>> Sent: Friday, July 16, 2004 10:11 PM Subject: RE: [oc] Generic Memories [q] 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 [q]> -----Original Message----- > From: <A HREF="http://www.opencores.org/mailman/listinfo/cores">cores-bounces at opencores.org</A> > [mailto:<A HREF="http://www.opencores.org/mailman/listinfo/cores">cores-bounces at opencores.org</A>] 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 > <A HREF="http://pages.sbcglobal.net/bporcella/">http://pages.sbcglobal.net/bporcella/</A> > ----- Original Message ----- > From: "H. Peter Anvin" <<A HREF="http://www.opencores.org/mailman/listinfo/cores">hpa at zytor.com</A>> > To: "Discussion list about free open source IP cores" > <<A HREF="http://www.opencores.org/mailman/listinfo/cores">cores at opencores.org</A>> > Sent: Tuesday, July 13, 2004 5:07 PM > Subject: Re: [oc] Generic Memories > > [q] > bporcella wrote: [q]> > > > On the other hand, my attempts to use "generic" memory [/q] > in Open Cores [q]> > CVS have been frustrating -- what are > > described as "generic dual port rams" turn out to be [/q] > "generic dual port [q]> > 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 [/q] > CVS are not [q]> > 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 [/q] > think about this a [q]> > few minutes. > > > > TWO QUESTIONS > > 1) Are we perhaps better off using FPGA tools to instantiate > > memories from standard descriptions (updated often by [/q] > vendors) or should [q]> > we continue to try to maintain generic files that "aid" [/q] > in syntheses? [q]> > 2) More importantly - do the "generic" memory files we [/q] > have actually [q]> > aid in FPGA synthesis - if so how.? > >[/q] > > Most FPGAs available today have RAMs which required address [/q] > registering. [q] > Thus, you generally can't use the RAM structures in FPGAs [/q] > unless you use [q] > registered addresses/write data, and preferrably registered [/q] > read data as well. [q] > > What I generally do is put RAM instantiations in separate [/q] > files; that way I [q] > can use either vendor-specific files or generic files -- [/q] > after all, you need [q] > generic files e.g. when running simulations, and frequently [/q] > the FPGA tools can [q] > figure out what you want from the generic files, so you [/q] > don't need to muck [q] > with vendor-specific stuff at all. For initialized [/q] > memories, though, you [q] > generally do need vendor-specific stuff :( > > -hpa > _______________________________________________ > <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A>[/q] > > _______________________________________________ > <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A> > [/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A>[/q] 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 at herveille.net> To: "'Discussion list about free open source IP cores'" cores at opencores.org> 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 at opencores.org > [mailto:cores-bounces at opencores.org] 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 at zytor.com> > To: "Discussion list about free open source IP cores" > cores at opencores.org> > 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

no use

no use

1/1

no use

no use

© copyright 1999-2025 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.