rom in vhdl

Discussion in 'VHDL' started by Mohammed khader, Nov 23, 2004.

  1. HI Vhdl Floks,


    There are many ways to create a rom in vhdl.

    1) Can be created by declaring a constant of two dimensional array
    and
    2) As a function which has a simple case statement for all the index
    values .

    and many more...

    I would like to know if there is any other way and which is better
    for simulation & synthesis among all and why ?

    Thanks a lot.
    Mohammed khader, Nov 23, 2004
    #1
    1. Advertising

  2. Mohammed  khader

    Neo Guest

    I think multidimensional arrays are not supported in synthesis but can
    be used for simulation. Also I feel simulation will be much faster
    with arrays then case statements.

    Neo
    Neo, Nov 24, 2004
    #2
    1. Advertising

  3. Mohammed  khader

    Ian Lang Guest

    Neo wrote:
    > I think multidimensional arrays are not supported in synthesis but can
    > be used for simulation. Also I feel simulation will be much faster
    > with arrays then case statements.
    >
    > Neo


    Any decent synthesiser (synopsys, LeorardoSpectrum or Synplicity for
    example) will cope happily with multi-dimensional arrays and indeed
    records (Xilinx XST is not so good). Don't assume that the synthesiser
    won't cope; they're more capable than most engineers realise.
    Ian.
    Ian Lang, Nov 27, 2004
    #3
  4. Mohammed  khader

    Jim Lewis Guest

    Mohammed,
    Rather than a two dimensional array, you want an array of
    an array. It is in some ways similar to a multidimensional
    array. One problem with multidimensional arrays is that
    you cannot slice them. Format for array of array is:

    architecture RTL of ... is
    type RomType is array (natural range <>) of std_logic_vector(2 downto 0);
    signal ROM : RomType(0 to 7) := (
    "000", "001", "010", "011", "100", "101", "110", "111") ;

    begin
    Y <= ROM(to_integer(unsigned(addr(2 downto 0)))) ;
    end RTL ;

    Of course, when you mentioned two dimensional aray, this may
    been what you are thinking, however, a two dimensional array is
    different and in this case harder to use (as you have to iterate
    through each bit in the output assignment rather than assigning
    the entire array).

    By now, both coding styles you mentioned should be recognized
    by most synthesis tools. I would start with one of these two.
    If it did not meet the quality of results I expected, I would
    look into ROM parts in the technology (FPGA/ASIC) you are using.

    Cheers,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



    > There are many ways to create a rom in vhdl.
    >
    > 1) Can be created by declaring a constant of two dimensional array
    > and



    > 2) As a function which has a simple case statement for all the index
    > values .
    >
    > and many more...
    >
    > I would like to know if there is any other way and which is better
    > for simulation & synthesis among all and why ?
    >
    > Thanks a lot.
    Jim Lewis, Nov 28, 2004
    #4
  5. Thanks Jim,

    My main problem is here ……

    I am implementing sin & cos in hardware. After going through the
    literature I realised that best way to implement is by lookup table.
    My entity interface is …
    entity SinCos is
    port( angle_in: in Signed(SINCOS_ADDR_LENGTH-1 downto 0); -- angle
    in radians
    sincos_select: in Std_Logic; -- To select either sin function or
    cos
    sincos_value: out Signed(SINCOS_WORD_LENGTH-1 downto 0) –-
    sin(angle_in) or cos(angle_in)
    );
    end entity SinCos;

    SINCOS_ADDR_LENGTH is 12
    SINCOS_WORD_LENGTH is 16

    I am using rom to store first quadrant of sine wave.Rom stores the
    values from 0 to 1 in 1.15 fixed point format(Stictly saying 0 to
    ..999..). Hence least 10 bits are used as address to ROM and 12 and
    11 bit are used to encode the quadrant.

    I need to subtract angle_in from PI if angle belongs to 2nd or 4th
    quadrant for sine and I need to complement the data from rom if
    angle belongs to 3rd or 4th quadrant. ( Similarly for cosine similar
    computations are needed but for different quadrant)


    For this my architecture requires a Subtracter (for PI – angle_in
    ) before rom and a 2s complement ( for - rom_data_out) after rom.
    My problem is I cant afford such a long critical path in my main
    design. And I can keep only 1st quadrant of data to achieve desired
    precision.

    Is there any solution to optimise this critical path. Or any other
    architecture is appreciated.

    Thanks,
    Mohammed A Khader.
    Mohammed khader, Nov 28, 2004
    #5
  6. Mohammed  khader

    rickman Guest

    Mohammed khader wrote:
    >
    > Thanks Jim,
    >
    > My main problem is here ……
    >
    > I am implementing sin & cos in hardware. After going through the
    > literature I realised that best way to implement is by lookup table.
    > My entity interface is …
    > entity SinCos is
    > port( angle_in: in Signed(SINCOS_ADDR_LENGTH-1 downto 0); -- angle
    > in radians
    > sincos_select: in Std_Logic; -- To select either sin function or
    > cos
    > sincos_value: out Signed(SINCOS_WORD_LENGTH-1 downto 0) –-
    > sin(angle_in) or cos(angle_in)
    > );
    > end entity SinCos;
    >
    > SINCOS_ADDR_LENGTH is 12
    > SINCOS_WORD_LENGTH is 16
    >
    > I am using rom to store first quadrant of sine wave.Rom stores the
    > values from 0 to 1 in 1.15 fixed point format(Stictly saying 0 to
    > .999..). Hence least 10 bits are used as address to ROM and 12 and
    > 11 bit are used to encode the quadrant.
    >
    > I need to subtract angle_in from PI if angle belongs to 2nd or 4th
    > quadrant for sine and I need to complement the data from rom if
    > angle belongs to 3rd or 4th quadrant. ( Similarly for cosine similar
    > computations are needed but for different quadrant)
    >
    > For this my architecture requires a Subtracter (for PI – angle_in
    > ) before rom and a 2s complement ( for - rom_data_out) after rom.
    > My problem is I cant afford such a long critical path in my main
    > design. And I can keep only 1st quadrant of data to achieve desired
    > precision.
    >
    > Is there any solution to optimise this critical path. Or any other
    > architecture is appreciated.


    I am not sure what part of the critical path is too long. The input
    complementer is just one 10 bit adder/subtracter (0+-N). The output
    complementer is 16 bit with only the 10 msbs significant, so you could
    drop the extra 6 bits. How fast do you need to run this? Are you aware
    that the block rams in the newer parts are all synchronous? So the
    lookup operation will require two clock cycles anyway.

    --

    Rick "rickman" Collins


    Ignore the reply address. To email me use the above address with the XY
    removed.

    Arius - A Signal Processing Solutions Company
    Specializing in DSP and FPGA design URL http://www.arius.com
    4 King Ave 301-682-7772 Voice
    Frederick, MD 21701-3110 301-682-7666 FAX
    rickman, Nov 28, 2004
    #6
    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. rajan
    Replies:
    1
    Views:
    2,753
    Marcin
    Jul 29, 2003
  2. vhdl_rookie

    coding issues with vhdl and ROM

    vhdl_rookie, May 10, 2004, in forum: VHDL
    Replies:
    0
    Views:
    736
    vhdl_rookie
    May 10, 2004
  3. Inno_pf
    Replies:
    0
    Views:
    4,163
    Inno_pf
    May 25, 2006
  4. afd
    Replies:
    1
    Views:
    8,323
    Colin Paul Gloster
    Mar 23, 2007
  5. hangeonos
    Replies:
    0
    Views:
    765
    hangeonos
    May 24, 2009
Loading...

Share This Page