|
Message
From: Rudolf Usselmann<rudi@a...>
Date: Wed Jul 14 05:50:38 CEST 2004
Subject: [oc] Generic Memories
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<<aw) -1:0]; // instantiate memory
>
> always @(clk) mem[wadr] <= data_in; // this is how you write
I hope this is just a typo and the actual source code is:
always @(posedge clk) mem[wadr] <= data_in;
> 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/ <- FREE EDA Tools
|
 |
Browse
