Utilizing Device Specific RAM

Discussion in 'VHDL' started by Shannon, Sep 13, 2007.

  1. Shannon

    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, Sep 13, 2007
    #1
    1. Advertising

  2. Shannon <> 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.)


    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

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.net/electronics.html
     
    Martin Thompson, Sep 13, 2007
    #2
    1. Advertising

  3. On Thu, 13 Sep 2007 06:22:36 -0000, Shannon <>
    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.

    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
     
    Brian Drummond, Sep 13, 2007
    #3
  4. Shannon

    Shannon Guest

    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
     
    Shannon, Sep 13, 2007
    #4
  5. Shannon

    Andy Guest

    On Sep 13, 7:05 am, Brian Drummond <>
    wrote:
    > On Thu, 13 Sep 2007 06:22:36 -0000, Shannon <>
    > 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.


    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.


    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
     
    Andy, Sep 13, 2007
    #5
  6. 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
     
    Mike Treseler, Sep 13, 2007
    #6
  7. Shannon

    Shannon Guest

    On Sep 13, 7:26 am, Mike Treseler <> 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


    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, Sep 13, 2007
    #7
  8. 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
     
    Mike Treseler, Sep 13, 2007
    #8
  9. Shannon

    Shannon Guest

    On Sep 13, 10:26 am, Mike Treseler <> 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


    Hmm guess I just don't know what the term "block RAM" means.
     
    Shannon, Sep 13, 2007
    #9
  10. Shannon wrote:

    > Hmm guess I just don't know what the term "block RAM" means.


    I think you defined it pretty well:
    "actual RAM and not a chunk of LEs"

    -- Mike Treseler
     
    Mike Treseler, Sep 13, 2007
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. TC
    Replies:
    5
    Views:
    7,728
    =?Utf-8?B?R2lyaXNoS3VtYXI=?=
    Sep 1, 2004
  2. Robert Posey
    Replies:
    0
    Views:
    679
    Robert Posey
    Nov 26, 2003
  3. ashu
    Replies:
    1
    Views:
    463
  4. ashu
    Replies:
    2
    Views:
    618
    mysticlol
    Nov 6, 2006
  5. Xin Xiao

    Block RAM Distributed RAM

    Xin Xiao, Jan 7, 2008, in forum: VHDL
    Replies:
    8
    Views:
    1,477
    Duane Clark
    Jan 7, 2008
Loading...

Share This Page