Utilizing Device Specific RAM

S

Shannon

Guest
Again and again I've learned from this group that good VHDL code is
generic and portable. And this makes perfect sense to me.

I'm faced with my first opportunity to use the embedded RAM of a
device (Cyclone). It seems to me that for Quartus to recognize I want
to use the actual RAM and not a chunk of LEs, I MUST use one of their
"LPM Megafunctions" to instantiate a RAM block.

1) Do you guys know if that is true?
2) Is this one of the acceptable occasions to use device-specific
code blocks? (The idea seems distasteful to me.)

Shannon
 
Shannon <sgomes@sbcglobal.net> writes:

Again and again I've learned from this group that good VHDL code is
generic and portable. And this makes perfect sense to me.

I'm faced with my first opportunity to use the embedded RAM of a
device (Cyclone). It seems to me that for Quartus to recognize I want
to use the actual RAM and not a chunk of LEs, I MUST use one of their
"LPM Megafunctions" to instantiate a RAM block.

1) Do you guys know if that is true?
2) Is this one of the acceptable occasions to use device-specific
code blocks? (The idea seems distasteful to me.)
Click to expand...
I've always been able to infer RAMs from portable HDL code,
currently on Xilinx, but it used to work in Altera-land as well.
Googleing for "altera inferring RAM" leads you on to a "recommended
HDL coding styles" handbook, which has a big section on inferring
RAMs. The code in there looks just like the stuff I use, although I
tend to use variables for my memory array.

The times you need to use the vendor-specific stuff is when you want
different port-widths on each side of a dual port RAM. And you may
need to if you want to use different clocks on each port and write to
both ports.

Altera have the advantage that their RAM blocks (altsyncram etc) are
instantiatable in a fairly sane way, giving generics for width and
depth, whereas Xilinx force you build your RAM up out of whatever
primitive RAM blocks your device has, so it's not even necessarily
portable across Xilinx devices. Grrr. Sorry, do I sound bitter ;-)

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
 
On Thu, 13 Sep 2007 06:22:36 -0000, Shannon <sgomes@sbcglobal.net>
wrote:

Again and again I've learned from this group that good VHDL code is
generic and portable. And this makes perfect sense to me.

I'm faced with my first opportunity to use the embedded RAM of a
device (Cyclone). It seems to me that for Quartus to recognize I want
to use the actual RAM and not a chunk of LEs, I MUST use one of their
"LPM Megafunctions" to instantiate a RAM block.

1) Do you guys know if that is true?
2) Is this one of the acceptable occasions to use device-specific
code blocks? (The idea seems distasteful to me.)
Click to expand...
Inferring RAM is to be preferred, and simple templates ought to work.
But for specialised purposes, a more complex template may work with one
vendor but not another; this isn't any better than instantiating RAM
blocks directly.

I like to create and use a generic entity as a wrapper for the RAM,
whose architecture instantiates the device-specific block. Then you can
write an alternative architecture to do the same for another vendor, or
a (possibly non-synthesisable) generic description of the same block for
simulation.

If the entity and architecture are in separate files, you should only
need to recompile the architecture when changing vendors; the rest of
the design only sees the wrapper entity, so hopefully no recompilation
is necessary.

However I keep entity and architecture together in the same file.
IMO this is one case where instantiating the RAM as a component in my
design is preferable to direct entity instantiation; I can select Brand
X or Brand A components from different libraries via configuration
statements, without recompiling the design.

- Brian
 
Ok, that was scary simple. Plopped the VHDL template from Quartus
into a blank project, compiled, and tada! done and done.

Thanks you guys... AGAIN! I never even noticed Quartus had those
templates. Of course I'm going to modify it for my needs until it no
longer infers a ram but that will be left for another post. hehehe

Shannon
 
On Sep 13, 7:05 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
On Thu, 13 Sep 2007 06:22:36 -0000, Shannon <sgo...@sbcglobal.net
wrote:

Again and again I've learned from this group that good VHDL code is
generic and portable. And this makes perfect sense to me.

I'm faced with my first opportunity to use the embedded RAM of a
device (Cyclone). It seems to me that for Quartus to recognize I want
to use the actual RAM and not a chunk of LEs, I MUST use one of their
"LPM Megafunctions" to instantiate a RAM block.

1) Do you guys know if that is true?
2) Is this one of the acceptable occasions to use device-specific
code blocks? (The idea seems distasteful to me.)

Inferring RAM is to be preferred, and simple templates ought to work.
But for specialised purposes, a more complex template may work with one
vendor but not another; this isn't any better than instantiating RAM
blocks directly.
Click to expand...
Nope, inferring rams is still better. Instantiated rams cannot store
anything but std_logic[_vector]. Inferred rams can store integers,
booleans, enumerated types, arrays, records, and virtually any other
data type that can be synthesized. I've never encountered a situation
that required two different pieces of code to infer the same resource
in two different tools/architectures. It was always a case of dumbing
down the code so that the dumbest tool could handle it, and then the
smarter tools took it just fine. Aggravating as heck, but it worked.

That said, I have had to instantiate resources that could not be
inferred optimally in one architecture or another, like data bus width
translation HW built into some xilinx rams.

I like to create and use a generic entity as a wrapper for the RAM,
whose architecture instantiates the device-specific block. Then you can
write an alternative architecture to do the same for another vendor, or
a (possibly non-synthesisable) generic description of the same block for
simulation.

If the entity and architecture are in separate files, you should only
need to recompile the architecture when changing vendors; the rest of
the design only sees the wrapper entity, so hopefully no recompilation
is necessary.

However I keep entity and architecture together in the same file.
IMO this is one case where instantiating the RAM as a component in my
design is preferable to direct entity instantiation; I can select Brand
X or Brand A components from different libraries via configuration
statements, without recompiling the design.
Click to expand...
This is a good step, except I've gotten to the point where I'll use an
if-generate driven by a generic to instantiate the appropriate entity/
architecture, and pass the generic down from the top level, where it
can be overridden by the tool. Configurations and components have
their place, but it is getting smaller and smaller in my book.

Andy
 
Shannon wrote:

I'm faced with my first opportunity to use the embedded RAM of a
device (Cyclone). It seems to me that for Quartus to recognize I want
to use the actual RAM and not a chunk of LEs, I MUST use one of their
"LPM Megafunctions" to instantiate a RAM block.
Click to expand...
Here's a related example:
http://home.comcast.net/~mike_treseler/block_ram.vhd

-- Mike Treseler
 
On Sep 13, 7:26 am, Mike Treseler <mike_trese...@comcast.net> wrote:
Shannon wrote:
I'm faced with my first opportunity to use the embedded RAM of a
device (Cyclone). It seems to me that for Quartus to recognize I want
to use the actual RAM and not a chunk of LEs, I MUST use one of their
"LPM Megafunctions" to instantiate a RAM block.

Here's a related example:http://home.comcast.net/~mike_treseler/block_ram.vhd

-- Mike Treseler
Click to expand...
Good stuff everyone. Mike: The version I used is **almost**
identical to yours. One question though: You re-synch the address.
I assume this is just so that the address hold time of the "calling"
function is relaxed. Or maybe so that you can cross clock domains?

Shannon
 
Shannon wrote:

Mike: The version I used is **almost**
identical to yours. One question though: You re-synch the address.
I assume this is just so that the address hold time of the "calling"
function is relaxed. Or maybe so that you can cross clock domains?
Click to expand...
No. It's so the code will infer a block ram.
That's the way they are.

-- Mike Treseler
 
On Sep 13, 10:26 am, Mike Treseler <mike_trese...@comcast.net> wrote:
Shannon wrote:
Mike: The version I used is **almost**
identical to yours. One question though: You re-synch the address.
I assume this is just so that the address hold time of the "calling"
function is relaxed. Or maybe so that you can cross clock domains?

No. It's so the code will infer a block ram.
That's the way they are.

-- Mike Treseler
Click to expand...
Hmm guess I just don't know what the term "block RAM" means.
 
Shannon wrote:

Hmm guess I just don't know what the term "block RAM" means.
Click to expand...
I think you defined it pretty well:
"actual RAM and not a chunk of LEs"

-- Mike Treseler
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top