Virtex® Family FPGAs

[bonita.h]

Hello,

    I want to use a BRAM to implemente a logic block where only combinational logic (8 inputs and 32 outputs) exist.

    My question, how to know the proper values that I need to write to the BRAM?  I cannot infer the values by analyzing this combinational logic block becasue it's a laborious work. Can I directly map this combinational logic into this BRAM, and then it automatically write proper values into proper RAM address?

   Thanks very much !

   Eric,  

[bassman59]

---

bonita.h wrote:

Hello,

    I want to use a BRAM to implemente a logic block where only combinational logic (8 inputs and 32 outputs) exist.

    My question, how to know the proper values that I need to write to the BRAM?  I cannot infer the values by analyzing this combinational logic block becasue it's a laborious work. Can I directly map this combinational logic into this BRAM, and then it automatically write proper values into proper RAM address?

   Thanks very much !

   Eric,  

---

Time to review Karnaugh Maps.

[mcgett]

Block RAMs are synchronous and not combinatorial.

[bonita.h]

Hi,

   thanks for your suggestion. But it's not a simple function. if the there is only 1 output, Karnaugh map is OK. But it has 32 outputs. Can you give me more hints?

   I have a idea, that is to scan all the input combination and record the corresponding outputs. It seems ok, but I want to simplify this work, just want to know whether it's possible to directly map a combinational block into a BRAM (8-inputs, 32-output)

Thanks

[bonita.h]

Hi, mcgett,

    In my work, a clock signal controls the BRAM. in each clock cycle, 8 bit values are inputted to the BRAM and the corresponding 32 bit outputs are got from the output of this BRAM.

 Thanks ,

  Eric,

[avrumw]

The first question that comes to mind is "why?".

FPGAs are very efficient at implementing combinatorial logic in slice resources. Depending on how the tools choose to map these, they can be implemented in as little as 32 slices (one slice for each of the 32 outputs - the four 6-input LUTs and the wide MUXes in a slice can implement an arbitrary 8 input function). These will be naturally inferred from RTL code, and can probably be done in a couple of hundred picoseconds. If you need the output to be clocked (like the output of a BRAM would be), then one of the FFs in the slice would be used too.

This would generally be preferable to using a block RAM.

Avrum

[mcgett]

> In my work, a clock signal controls the BRAM. in each clock cycle

Ok, then you are implementing sequential logic, not combinatorial.

> But it has 32 outputs. Can you give me more hints?

The simple answer is 32 karnaugh maps, one for each output.

An 8 bit function is likely between 2-2.5 LUTs on average or less than 80 LUTs in total.  I would suggest that you just let the synthesizer do the work and if you really have a timing problem then to explore the use of a BlockRAM.

If creating the values by hand is too much work then just let the simulator do it for you by going through the 256 possible combinations.

[eteam00 · Accepted solution]

There are three problems to overcome:

• Deriving the 256x32 (8-input, 32-output) set of logic functions.  Up to the point of Boolean logic expressions, this cannot be automated, it resides in your head.

• Conversion from logic expressions to a syntax-correct memory .INIT text file.  As Ed McGett suggester, you can use the simulator to crank out the 32-bit memory words by stepping through the 256 input combinations.  Or you can use a spreadsheet to generate text output which can be readily re-formatted to proper source code form for synthesis.

• Because the end product of this tedium is completely unreadable by humans, you will have to endure another round of tedium to verify the work.

Sometimes your job requires tedious work.  If you dearly want to avoid this tedium, then delegate this job to a newly-hired junior engineer or an unpaid intern.  Or hire one of your kids to do this, for allowance money.

I agree with the others who have suggested using ordinary logic expressions and LUTs rather than a BRAM with a data table.  The logic expressions are human readable and convey meaning without much effort.  The data table is impossible to review (for anyone except Neo), and every update to the source logic means the table must be re-generated and re-verified.

-- Bob Elkind

[bonita.h]

Hi Bob,

   My work seems strange. Actually, I want to implemente the combinational part of a crypto-block by using BRAM in order to reduce the logic glich, routing length, which are possibly leak the confidentical infromation in their power or EM characteristics.

   I've understood, no shortcut exist. I will try to scan them.

   Thanks,

    Eric,

[avrumw]

If this is really something you need to do...

The generation of the lookup table is, of course, tedious - which makes it an ideal problem to solve using a computer program!

In this case, you could write a program in any language (and Verilog/VHDL would certainly be capable of it), which can generate the SOURCE code for your FPGA. This code would consist of a for loop to iterate through the 256 possible input values, use a behavioural description of the function to be implemented (and hence generate the 32 bit output required for each combination), and use $display (or equivalent) statements to generate the truth table in a format readable by the FPGA implementation tools.

If using XST, then the output of your verilog/vhdl program could be the case statement to put in an initial block to initialize the "ROM" - of the format  

$display("     %h:  out_val = %h", i, f(i));

where i is your loop variable (iterating over 0 to 255), and f is a function that describes the logic.

The output of this program (which would be run using a simulator - isim would be sufficient), would then be cut and pasted as the body of a case statement in your verilog source code for the FPGA.

Alternatively, you could use the same mechanism (a program generating output) to generate a .coe file for the block memory generator, which you can use to build this ROM including the initialization. Information on the .coe file is available in DS512.

Avrum