Continue to Site

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.

[SOLVED] how to store values in rom in sys gen and call when required?

Status
Not open for further replies.

sandy3129

Member level 3
Joined
Nov 7, 2014
Messages
56
Helped
1
Reputation
2
Reaction score
1
Trophy points
8
Activity points
445
im storing the values in sys gen rom using the initial value vector?,lets say(just an example) eg: 10 20 30 40 50. in the addresses 1, 2,3,4,5. when i have the inputs in the form of 45,55,65,75,85 it should call the stored values. if my input is 55, the rom should output 20 like that? how to implement it using sys gen?
 

What you are describing seems to indicate you want a CAM, not the most efficient thing to build in an FPGA (assuming you aren't just trying to simulate such a thing in sys gen and plan on building it in HW).

Are the inputs 8-bit or less or can they be bigger than the 85 you have listed as an example. Bit width is an important piece of information you left out. Every bit of width increase doubles the size of the array required to create the look up table to make a CAM, if you are okay with latency then a search algorithm to find the data can be used instead, i.e. two fields in a memory: 1 - the input data (45,..,85), 2 - the resulting output data (10,...,50). Though your question lacks enough detail to determine if this would even be feasible.
 
I am curious about your top-level ports. Can you give more info about them for your rom?

At a glance, looks like you need to implement an address decoder which will sit between your actual addresss_in port and the top-level address input port. If the ROM size is not huge, then implement this decoder using case statements.
e.g. - If top_level_i == 65, then address_in <= 3, so that data_out is 30.
 

Reminds to CAM, but the question isn't actually clear. A full specification would tell:
- input and output width (e.g. 7 bit)
- expected output for each input value in the given range (e.g. 0..127)

I guess, after structuring the problem quite a bit, the solution will be more or less obvious.
 
ya my input and output width is 7 bit (7 bit only). expected output for each input value is in the range of (0 to 127), now i have stored input values in the memory following like this [eg_mod] if 10 20 30 40 50 stored in 0, 1, 2, 3, 4 addreses, only four addresses i filled for scalability issue, when my input is 45 it should output 10 ,similarly 55=20,65=30,75=40,85=50.
 

Answered half the question. What's the expected output for input values like e.g. 0, 33, 84, 127?
 

Answered half the question. What's the expected output for input values like e.g. 0, 33, 84, 127?

since i didnt assign anything for those inputs, the output will be zero atleast i want it to be zero.
 

Seems to me the easiest way to implement this is a 128x7 (actually 128x8) RAM which is not even a full 16Kb BRAM or could even be done in distributed RAM.

So you would just connect the lower 7-bits of address to the input data and the upper 4-bits to the 0s. The RAM would be initialized with your output data. e.g.

Code:
0 => 0
1 => 0
2 => 0
...
9 => 0
10 => 45
11 => 0
...
20 => 55
21 => 0
...
 
k u mean to say , what ever the input im giving to the rom should represent the address ryt? hence respective output will come out of it., fine il use it, , if i have my inputs in decimals, lets say my input is 1)0.625 then my output is (just eg) 200. 2)0.865 my output is 300 then? should i convert the decimals into a natural number and make them as address and initialize those address with output data? or is there any other way ???
 

Well there aren't any decimals in hardware you either have 0s or 1s (binary) so you can represent a decimal fixed point number using the VHDL fixed package. If your decimal numbers are represented using a 7-bit value then just making the translation a look up table is probably the easiest thing to implement. If you can't afford to use a block ram for this then you'll probably want to go back to the other method of two look up tables: the first translates the input into an address (you can use a case statement as you seem to indicate only a small number of valid locations), then use the resulting address to index into a second lookup for the output (which with only 5 values would easily fit in distributed RAM).
 

im doing using system generator, ya true no decimal values so using decimal fixed number as an address is better, to values in the address, but while im converting my point values (0.2546) etc , some conversion is going upto the precision of 4063236 , that much memory is present in the rom???
 

im doing using system generator, ya true no decimal values so using decimal fixed number as an address is better, to values in the address, but while im converting my point values (0.2546) etc , some conversion is going upto the precision of 4063236 , that much memory is present in the rom???

No there isn't that much RAM/ROM in FPGAs unless you are planning on using the $1000+ Ultrascale or Ultrascale+ parts.

You originally stated your fixed point values were 7-bit now you are telling us that they are producing 22-bit values?

this is why I don't use things like system generator for generating control logic structures, it's too far removed from the actual hardware implementation details.
 

ok ok, true i said 7bit for understanding purpose. its actually 23bits binary point at 15. il show my actual values

Code:
124	640
84.5000000000000	645
55.3333337455988	650
27.1666662618518	655
23.9999998211861	660
16.5000002458692	665
15.0909095406532	670
12.7692312449217	675
10.8000005632639	680
9.64705824851990	685
8.63157901167870	690
8.24999950826168	695
7.21739082038403	700
6.95833291858435	705
6.14814819395542	710
5.89285679161549	715
5.54838693141937	720
5.21875000000000	725
4.74285686016083	730
4.37837818264961	735
4.39473625272512	740
3.99999985098839	745
3.88095214962959	750
3.59999978542328	755
3.50000036507845	760
3.39583373814821	765
3.26000053435564	770
3.17647039890289	775
3.05555496364832	780
2.98181778192520	785
2.84482788294554	790
2.81355963647366	795
2.49999992549419	800
2.66666650772095	805
2.50000007450581	810
2.47761234641075	815
2.38571414351463	820
2.36619776487350	825
2.29166653007269	830
2.21333369612694	835
2.14473716169596	840
2.12658280134201	845
2.06250049173832	850
1.97590354084969	855
1.94047607481480	860
1.92771077156067	865
1.89285703003407	870
1.87951800227165	875
1.68478220701218	880
1.73863584548235	885
1.71590857952833	890
1.65555545687675	895
1.59782570600510	900
1.61111101508141	905
1.52688132226467	910
1.46874964982271	915
1.51086920499802	920
1.48913007974625	925
1.43617004156113	930
1.38541633635759	935
1.33333370089531	940
1.34374967962503	945
1.31958770751953	950
1.24999973922968	955
1.02479299902916	960
1.20999974757433	965
1.18811845779419	970
1.12499993294477	975
1.10476183891296	980
0.941666610538960	985
1.04672873020172	990
1.02803714573383	995
1.00934556126595	1000
0.954955175518990	1005
0.936937153339386	1010
0.886956766247749	1015
0.884956121444702	1020

- - - Updated - - -

the decimal values are my input going into the ram it should out those frequencies. one way of implementing is converting decimal to hexadecimal , then from hex to unsigned fixed point. so that i can get addresses il store freq in rom at those particular address., but converting from decimal to hex is not working using in sys gen via mcode blocks.
 

Are these all the values (77 of them in the list)?
Are the values constant, or are there other values that map to the same values in the second column?

What I'm trying to determine is how many entries in the first column need to be mapped to the second column. As this is a true CAM operation.

As these are decimal numbers they won't necessarily convert to an exact binary fixed point value and if these values can vary from the values in the table above that will require ranges of values mapping to the same value (which might be fixed by rounding to less bits).

The other option is to perform a search operation through a memory that contains the values you have or a range of values e.g.

Code:
line 3:
55.3333337455988	650
suppose we have in the CAM memory: 44, 69, 650
so the input between 44 and 69 will map to 650, when you perform a search of all the values in the memory. The latency will vary according to where the range or single values are located in the memory being searched.

- - - Updated - - -

Regardless you probably don't want to do this as a direct lookup table as there is going to be a huge amount of empty space in the table. You might be able to do some tricks with the 23-bit fixed point data by using specific bits of the 23-bit data as the index depending on the value of the data (i.e. scaling the data by powers of 2), but you would have to look at the data in the fixed point binary representation to see if it is possible to reduce the number of bits to something reasonable (i.e. 77 out of 128 locations for a 7-bit address) that can easily fit in a less costly FPGA.
 
"Are these all the values (77 of them in the list)?
Are the values constant, or are there other values that map to the same values in the second column?" ya there are the only values NOTHING ELSE , im only worried about only these values, no the values are not constant, there are in decreasing order for sure from 640 to 1020.
 

"Are these all the values (77 of them in the list)?
Are the values constant, or are there other values that map to the same values in the second column?" ya there are the only values NOTHING ELSE , im only worried about only these values, no the values are not constant, there are in decreasing order for sure from 640 to 1020.

I meant are the values like 2.06250049173832 exactly that value and not something like 2.06250049173827 sometimes. If those input values can vary some number of bits then you'll have to account for that. But if they are constants then you can round them to say 8-bits or 9-bits (which can still fit in a single BRAM)
 
all those decimal values are represented via 23 bit binary point at 15. and there is no CAM in system generator.

- - - Updated - - -

I meant are the values like 2.06250049173832 exactly that value and not something like 2.06250049173827 sometimes. If those input values can vary some number of bits then you'll have to account for that. But if they are constants then you can round them to say 8-bits or 9-bits (which can still fit in a single BRAM)

ohkk ya only upto 5 decimal points it matters,else it wont matter
 

I'd say the quickest way to determine how many bits you'll need is to put the values in a spreadsheet and multiply them by increasing powers of 2 until the integer portion of all the values are mutually exclusive.

Looks like you need at least 8-bits extra to make them distinguishable i.e. the 7-bit of (124) integer plus an additional 8-bits to distinguish those values near each other later in the table.

- - - Updated - - -

That equates to 15-bit address and in Xilinx 7-series it would require 10 36K BRAMs to implement the lookup table out of which only 77 locations have data.

I think the search method would be much more efficient as long as the latency between results is not an issue. If you can't afford the latency then you'll likely need to create a multi-cycle lookup table using a case statement with the only the range of values you are interested.

I can also see a two tiered approach with the integer portion above 8 being a separate lookup (less bits required, 7-bit) and only if the lookup requires an input of < 8 will it scale with the extra 8-bits (11-bits). That would require only 2 BRAMs to implement along with some selection logic for checking if the input was >=8 or <8.

- - - Updated - - -

I can also see a two tiered approach with the integer portion above 8 being a separate lookup (less bits required, 7-bit)
Oops you need 8-bits as you can't distinguish between 8.63157901167870 and 8.24999950826168, without an extra bit in the fractional part.
 
Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top