rom in vhdl

[Mohammed khader]

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.

 

[Neo]

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

 

[Ian Lang]

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.

 

[Jim Lewis]

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:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

 

[Mohammed khader]

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.

 

[rickman]

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

(e-mail address removed)
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