Functional Simulation of Virtex-4 Block Memory

If you already have a behavioral VHDL model of the ROM, why did you generate a core? Why not just synthesize the model you have? You just need to stick a register between the address generation and the ROM. Check the log file from your synthesis tool, and verify that block memory was used.

When I started with ROMs circa ISE 6.2 the COE thing wasn't working past some small number of values. Someone prompty directed me to infer the ROM and not use the core generator at all.

The VHDL looks something like this:

type i2c_array_type is array(natural range ) of natural; constant i2c_data_array : i2c_array_type :=(

0,0,0 -- put your constants here ); signal i2c_bit_index0 : unsigned(2 downto 0); begin i2c_data1

Thanks for the replies. I don't need help with the code for the ROM. No problem with my writing the code and letting ISE infer the ROM, however what if I wanted to use block memory for a dual-port memory. This is a non-trivial coding effort. I am wondering what use are the memory cores if I am better off writing the code myself? I thought the purpose of the cores is not only to help the user by having the code pre-written by Xilinx's experts, but also to ensure that the design is optimal for fitting into the the FPGA. I used a core adder/ subtractor and comparator with no problems. The trick with the memory seems to be simulating the memory with the contents loaded. so maybe the dual-port memory would work OK.

Thanks,

Charles

Inferring a dual port memory is just as easy as a single port memory:

constant AWIDTH : integer := 8; type drngs_array is array(0 to 2**AWIDTH-1) of std_logic_vector(31 downto 0); signal drngs_ram : drngs_array; signal rd_addr_drngs : unsigned(AWIDTH-1 downto 0);

drngs_wr_p: process(CLK) begin if rising_edge(CLK) then if DRNGS_WE = '1' then drngs_ram(to_integer(DRNGS_WADR))

You mention ROM in your original post. That's what I answered.

I haven't done any elaborate dual port BRAMs because everthing I have done fits into a single or maybe two BRAMs. Yeah, I suppose spreading init data among several BRAMs is not trivial and the combining of addresses and outputs. So maybe you should spill your requirements and see if someone can help?

That maybe true.

And did the core work better than an inferred adder/subtractor?

Thanks,

Charles

The whole point of inferring BRAMs is that the synthesis tool figures that out for you. You infer a single memory of whatever size you need, with whatever init data you need, and the synthesis tool figures out how to divide it up among primitives and wire them up, adding any necessary miscellaneous logic. And the synthesis tool does this just as well as coregen.

Well, I have certainly got the message that those who have replied to this post think that inferred units work as well as the cores (except for certain applications such as FFTs). I don't know whether the core comparator and adder work any better than inferred modules. I haven't run any tests, nor do I intend to. My thinking is that the cores for those modules are likely to work at least as well as inferred modules and since they are already incorporated into the design, I will let well enough alone. I come to sites like this to learn from others who have more experience than I in certain areas, and I am learning. I am not a champion of cores--I don't know enough about them to be either an advocate or a detractor.

In the case of the dual-port memory, I have no current application for it -- I just gave that as an example. I have used dual-port memory in other designs, but these were commercially available units not internal to an FPGA.

Thanks for all of the replies; even the snippy ones are helpful.

Charles

This thread has not yet covered your original concern:

The big advantage of using hdl templates to infer special features is that simulation is simple. The synthesis code and the simulation model are the same thing.

-- Mike Treseler

I apologize if I came off as snippy. Tone is hard to convey in postings, and I'll definitely try to work on that.

No reason to apologize. Your posting was professional, and not "snippity". Peter Alfke

I'll make one additional comment about inferring versus core generation or instantiation. The cores and instantiated models tend to simulate very slow in comparison to inferred models. I don't know whether it will be significant for comparators and adders, but inferred memory simulates much faster. And while having complex cores like FFTs available is a nice thing, the model for the FFT simulates *extremely* slowly. It is enough to make me want to write my own, if I can just get enough free time ;)

Is it still true that BRAM arrays with different width ports cannot be inferred?

Also, are the BRAM parity bits usable with inference, i.e. can you infer a 36 bit wide memory into a single BRAM?

Coregen left a bad taste in my mouth last time I tried to use it for BRAM. Instead I find directly instantiating BRAM instances with use of the VHDL generate statement to be fairly powerful and flexible.

-Jeff

That is true, as far as I know. But in that case I like to infer multiple BRAMs, and then wire them up (with multiplexers) to handle the different port widths.

I don't know for sure, but I would be surprised if the synthesis tools did that incorrectly.

That is how I did it for several years, but once I made that change to inferring memory, I'll never go back.

I guess if the performance and resource hit of the external muxes is not too bad that could be appealing.

Do you know if giving the bram initial values is handled properly when inferring?

-Jeff

Try it and see. I have had good luck varying the generics on this example:

-- Mike Treseler

I believe so. I made my own dual port ram component that looks at the data and address port widths on both ports to figure out the construction of the composite memory. It is limited in depth to the BRAM depths (up to 16K), as it doesn't use any multiplexers. It also accepts initial ram values as an array of integers and takes care of splitting those up among parallelled BRAMs as needed. It took a while to develop and test the component, but since I do as many designs as I do, it has more than paid for itself in time saved on subsequent designs.