How to implement a 32K lookup table in CPLD?

[Altera_Forum]

hello, 

I'm newbie in VHDL, FPGAs and CPLDs devices. I would like some help for implement a lookup table with 2048 words (2 bytes). The table should be: 2048x16bits (32K), I mean, 11 bits address (A10-A0) and 16 bits data (D15-D0). As soon as the address is placed on the bus, the fastest possible data should appear (no latch or enable is used).  Please, could somebody guide in the implementation? Can I use a CPLD (EPM240 o EPM570)? I need to use the fewest possible components, so I prefer a CPLD.  This the code I plan to use, but i think it will be very slow due to sequential process (assume that the latest addresses are used): ----------------------------------------------------------------------- LIBRARY ieee; USE ieee.std_logic_1164.all;  ENTITY lookuptable IS PORT (address : IN STD_LOGIC_VECTOR(10 DOWNTO 0); data : OUT STD_LOGIC_VECTOR(15 DOWNTO 0)  ) ; END lookuptable ;  ARCHITECTURE behavior OF lookuptable IS BEGIN PROCESS ( address ) BEGIN CASE address IS WHEN "00000000000" => data <= "1111111111111111"; -- example data, all "1s" WHEN "00000000001" => data <= "1111111111111111"; -- example data, all "1s" WHEN "00000000010" => data <= "1111111111111111"; -- example data, all "1s" WHEN "00000000011" => data <= "1111111111111111"; -- example data, all "1s" . . . WHEN "11111111101" => data <= "1111111111111111"; -- example data, all "1s" WHEN "11111111110" => data <= "1111111111111111"; -- example data, all "1s" WHEN "11111111111" => data <= "1111111111111111"; -- example data, all "1s" WHEN OTHERS => data <= "0000000000000000"; -- example data, all "0s" END CASE; END PROCESS; END behavior -----------------------------------------------------------------------  I know that altsyncram (with ROM, single-port) Megafunction option exist , but this will force to use a FPGA device (more expensive and need more electronics components around it). That is my last option.  Thank you !

[Altera_Forum]

I don't know if CPLDs contain rom blocks. but you can use their logic to serve your rom.  

Best thing try it on the compiler to se if it fits any cpld.  You might need some automation in generating 2048 data points such as C or matlab code.  Yoy will also need to look after timing issues to external device since you don't want clock (luckily for such large logic).  edit: read this  http://www.altera.co.uk/devices/cpld/max2/overview/features/mx2-flash_memory.html

[Altera_Forum]

MAX 10 CPLD (FPGA?) has embedded SRAM and larger capacity user-flash. I think you get the best of both worlds (single component, adequate RAM for your application).

[Altera_Forum]

Hello, 

Thank you for your reply. Well, the MAX II - EPM240 does not have enough capacity to support all the data (the code need 296 logic elements, and the EPM240 only have 240), so I changed it by EPM570, it have double of logic elements, now the compilation was successful (296/570 logic elements - 52% utilization).  Also, I have changed the code to be concurrent code, using WHEN-ELSE (data is an example, I will use correct data):  data <= "0000000000000000" WHEN address= "00000000000" ELSE  "0000000000000001" WHEN address= "00000000001" ELSE  "0000000000000010" WHEN address= "00000000010" ELSE  "0000000000000011" WHEN address= "00000000011" ELSE  .  .  .  .  "0000011111111101" WHEN address= "11111111101" ELSE  "0000011111111110" WHEN address= "11111111110" ELSE  "1111111111111111";  Those CPLDs have internal clock, so I have to check how to use it (I think they have 2 options, 3.3. o 5.5 MHz).  Best regards.

[Altera_Forum]

Hi! 

 Considering you *almost* managed to fit it in a 240LE MAX II, I'm guessing that there's a LOT of identical data in there. Trying to cram that much data into a CPLD is pushing it and I'd look at other angles, like what your data will contain and if you can (potentially) compress it or access it smarter. I.e. if half of your rom is all zeros then you can significantly reduce the combinatorial amount used.  With regards to the MAXII, it's got 8K(bits) of eprom IIRC but that's slow as hell, so that's probably not going to be of any use.  -Mux