Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

how to implement look-up table in RTL?

Status
Not open for further replies.

xldu

Junior Member level 1
Joined
Apr 3, 2005
Messages
15
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,430
lookup table with dff

If a table have variable length value, how to look up the table in RTL fast ?
what about using CAM?
can anyone introduce some methods to implementing looking up table in RTL level?
thanks!
 

xldu

Junior Member level 1
Joined
Apr 3, 2005
Messages
15
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,430
on one answer me?
when decoding bitstream, i should look up a decoding-table. the table is large and has
varible length content, so i don't know how to implement it in RTL. the table can be saved in ram but how to save it? someone say dividing the table into several segments is good, but how to dividing it?
anyone can help me?
 

archillios

Full Member level 1
Joined
Jun 29, 2005
Messages
97
Helped
5
Reputation
10
Reaction score
1
Trophy points
1,288
Activity points
1,910
hi,
1.
some vendor provide CAM core ,and you can get CAM simulation lib ,then use it in your RTL.
2.
if not ,use verilog reg array to build a lookup table,using the max length as the array width .
this way may lead to large die area consumed if the look-up table is big.

3.
if your target is FPGA,then using CAM or LUT or something in FPGA.
 

xldu

Junior Member level 1
Joined
Apr 3, 2005
Messages
15
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,430
thank you!
our target is ASIC, and the size can't be too big.
so the regsiter array is not good.
we want to save the table in the RAM, but the critical problem is how to look up the content?
for example:
when received one bitstream, i should compare the bitstream and the table in the RAM, output the result of looking-up. otherwise, the bitstream is not fixed-length.
do you have any advices for it?
 

vlsi_whiz

Full Member level 4
Joined
Nov 12, 2005
Messages
216
Helped
49
Reputation
98
Reaction score
24
Trophy points
1,298
Location
Penang
Activity points
3,139
You've mentioned that you need a dynamic look-up table whose contents/size can be modified and thatn you are targetting ASIC. There's a contradiction here... First, hardware structure or size cannot be modified/changed dynamically.

What you can do, is to design a ROM of fixed size by first deciding on an upper memory limit and the number of data that are going to be stored in the ROM table. Then hardcode the ROM with the values of the table. This way you have created a lookup table. The only drawback here is that you cannot modify the contents of the ROM later. This is the method followed in storing the instructions in processors.

If you implemet this table in RAM, you will loose all the data when the chip looses power and to overcome this you will have to use a external ROM to load the data back in.
 

funster

Full Member level 4
Joined
Jun 30, 2005
Messages
233
Helped
19
Reputation
38
Reaction score
4
Trophy points
1,298
Activity points
2,742
for lookup table, if you use DFF to construct it,

you can use CASE struct directly. if you

use ram, you should prepare a file to programmble

ram.

best regards







xldu said:
If a table have variable length value, how to look up the table in RTL fast ?
what about using CAM?
can anyone introduce some methods to implementing looking up table in RTL level?
thanks!
 

AlexWan

Full Member level 5
Joined
Dec 26, 2003
Messages
304
Helped
8
Reputation
16
Reaction score
2
Trophy points
1,298
Activity points
2,692
Register file can be to create the look-up table.
 

ami

Member level 3
Joined
Apr 28, 2005
Messages
62
Helped
4
Reputation
8
Reaction score
0
Trophy points
1,286
Location
VN
Activity points
1,952
hi,
I think how to design a look-up table depends much on the requirements of your design.
1. if your input value for look-up varies in its bit-length, try to define the min & max length
----> the min length will be the depth of your unit table.
----> The max leng will define how many unit tables that you need
2.ex: you need to look up this [a2a1a0][b4b3b2b1b0] for a data of 16 bits
----> divide the look up table in to ([a2a1a0]max)=8 unit table
-----> ([b4b3b2b1b0])max = 32 ----> unit table size = 32x16
so you can look-up in parallel on 8 unit-table --> decode --> your desire lookup value

Hope this help.
 

avimit

Banned
Joined
Nov 16, 2005
Messages
413
Helped
91
Reputation
182
Reaction score
23
Trophy points
1,298
Location
Fleet, UK
Activity points
0
you may use a case statement i.e combinational logic

Example:

cosout_p : PROCESS(index_in)
BEGIN
CASE index_in IS
WHEN "000000" => cosout <= "11111111111111111111111";
WHEN "000001" => cosout <= "11111111101100010000111";
WHEN "000010" => cosout <= "11111110110001000110110";
WHEN "000011" => cosout <= "11111101001110101010101";
WHEN "000100" => cosout <= "11111011000101001011111";
WHEN "000101" => cosout <= "11111000010100111111011";
WHEN "000110" => cosout <= "11110100111110100000101";
WHEN "000111" => cosout <= "11110001000010010000100";
WHEN "001000" => cosout <= "11101100100000110101111";
WHEN "001001" => cosout <= "11100111011010111101011";
WHEN "001010" => cosout <= "11100001110001011001011";
WHEN "001011" => cosout <= "11011011100101000001101";
WHEN "001100" => cosout <= "11010100110110110011000";
WHEN "001101" => cosout <= "11001101100111110000001";
WHEN "001110" => cosout <= "11000101111001000000001";
WHEN "001111" => cosout <= "10111101101011101111100";
WHEN "010000" => cosout <= "10110101000001001111001";
WHEN "010001" => cosout <= "10101011111010110100100";
WHEN "010010" => cosout <= "10100010011001111001100";
WHEN "010011" => cosout <= "10011000011111111011111";
WHEN "010100" => cosout <= "10001110001110011101100";
WHEN "010101" => cosout <= "10000011100111000011110";
WHEN "010110" => cosout <= "01111000101011010111010";
WHEN "010111" => cosout <= "01101101011101000100000";
WHEN "011000" => cosout <= "01100001111101111000101";
WHEN "011001" => cosout <= "01010110001111100110100";
WHEN "011010" => cosout <= "01001010010100000001100";
WHEN "011011" => cosout <= "00111110001100111111001";
WHEN "011100" => cosout <= "00110001111100010111000";
WHEN "011101" => cosout <= "00100101100100000010000";
WHEN "011110" => cosout <= "00011001000101111010011";
WHEN "011111" => cosout <= "00001100100011111011001";
WHEN "100000" => cosout <= "00000000000000000000000";
WHEN OTHERS => cosout <= (others => '0');
END CASE;
END PROCESS cosout_p;
 

xldu

Junior Member level 1
Joined
Apr 3, 2005
Messages
15
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,430
thanks all!

using CAM will result in large size, sequential looking-up a table will result in a waste of time. i must balance the size and time. does anyone more advise?


to ami,
your solution for table structure is good for me, can you explain more? because
how to look-up the table is critical!

to avimit,
using case structure (DFF) will result in huge size, as the table is very large!
 

avimit

Banned
Joined
Nov 16, 2005
Messages
413
Helped
91
Reputation
182
Reaction score
23
Trophy points
1,298
Location
Fleet, UK
Activity points
0
hello xldu,
tell me what exactly you want to implement, and then I may be able to give you a better edvice.
In some applications, only a few values are stored in a lookup table at regular intervals, while the others may be calculated using the stored values and linear interpolation.
Kr,
Aviral Mittal
 

ami

Member level 3
Joined
Apr 28, 2005
Messages
62
Helped
4
Reputation
8
Reaction score
0
Trophy points
1,286
Location
VN
Activity points
1,952
Hi,
this is the heart code of my CAM (search unit table),

Code:
reg [W-1:0] cam_reg [D-1:0];
reg [D-1:0] match;
integer i;
always @ (posedge clock or negedge reset)
    if (!reset)
    begin
    match <= {D{1'b0}};
    end
    else
        begin
        for (i=0;i<D;i=i+1) match[i] <= (search_data == cam_reg[i]);
        end

----> then, simply decode the "match" register ----> search result

this code works well with D=8 (256 locations), W=32 @155MHz

* Hope this help
Regards

Added after 33 minutes:

xldu said:
to avimit,
using case structure (DFF) will result in huge size, as the table is very large!
yes, building the CAM with DFF cost much area, but you must accept that if the time for search result is important.
The CAM I give you above (4 unit of 256x32) cost 112422 area (a DFF with drive strength =1 cost 30 area).

Regards

Added after 11 minutes:

Another experience in this: if you use RAM for search, you must use many design tricks. Then, it will make your design more complex and hard to change afterward.
Using logic cell in such design like this cost area but it worth its weight in gold. If you use RAMs, there will many small RAMs in your design----> cost area in total too and you will face the difficult in P&R later.
It's my experience and I have paid for it :)
Regards[/b]
 

    xldu

    Points: 2
    Helpful Answer Positive Rating

jackson_peng

Full Member level 2
Joined
Apr 11, 2005
Messages
141
Helped
24
Reputation
48
Reaction score
9
Trophy points
1,298
Location
Shanghai, China
Activity points
2,380
the verilog HDL can't just discribe the CAM structure perporly, use the comercial CAM model to bulid your Lookup table
 

ami

Member level 3
Joined
Apr 28, 2005
Messages
62
Helped
4
Reputation
8
Reaction score
0
Trophy points
1,286
Location
VN
Activity points
1,952
jackson_peng said:
the verilog HDL can't just discribe the CAM structure perporly, use the comercial CAM model to bulid your Lookup table
Yes,
But we can use HDL to build something which functions like the comercial CAM, OK?
(self-bulding one will not be optimization like comercial CAM, but it still function well in many case)
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top