Hi. I'm having trouble when I run the ./generate_bench command in the minsoc/sim/run directory.

jb@ubuntu:~/minsoc/sim/run$ ./generate_bench
../../bench/verilog/minsoc_bench.v:590: error: Could not find variable ``minsoc_top_0.or1200_top.or1200_cpu.or1200_rf.rf_a.ramb16_s36_s36.mem'' in ``minsoc_bench.init_fpga_memory''
../../bench/verilog/minsoc_bench.v:591: error: Could not find variable ``minsoc_top_0.or1200_top.or1200_cpu.or1200_rf.rf_b.ramb16_s36_s36.mem'' in ``minsoc_bench.init_fpga_memory''
2 error(s) during elaboration.
jb@ubuntu:~/minsoc/sim/run$

I'm trying to use the Xilinx RAM, by uncommenting the 'define OR1200_XILINX_RAMB16 in the minsoc/rtl/verilog/or1200/rtl/verilog/or1200_defines.v file.

Help me!

Jim

Hi Jim,

on or1200_r3 the register file, or1200_rf.v, always instantiates a generic memory for DUAL PORT RAM. Previously it instantiated a target specific or generic memory depending on your sets of or1200_defines.v.

Since the CPU does not work if the registers aren't set to zero previous to simulation start, my testbench especifically set the memory content of the registers to zero, before simulation start. I didn't try to find out why this is like that, I only noticed it was that way.

First, I commented out the initialization for dual port RAM to test if the new memory would work. The simulation failed as it did before.

I could include a new initialization for the new memory. Because the new memory is generic and I believe target specific memory should be used whenever possible, I'd recommend you to switch it back to the way it was before and not to touch the memory initializations:

On or1200_rf.v: lines 304 and 280 edit this way:
304:
or1200_dpram_32x32
rf_b
(
.rst_a(rst),
.rst_b(rst),
.oe_a(1'b1),
// Port A
.clk_a(clk),
.ce_a(rf_enb),
...
280:
/* or1200_dpram #
(
.aw(5),
.dw(32)
)*/
or1200_dpram_32x32
rf_a
(
.rst_a(rst),
.rst_b(rst),
.oe_a(1'b1),
// Port A
.clk_a(clk),
.ce_a(rf_ena),
...

This might be a typo or maybe a work around for something else. That's something the OpenRISC developers have to tell us. It is remarkable that both, OR1200_RFRAM_GENERIC and OR1200_TWOPORT are exactly the way there were before. However, the OR1200_RFRAM_DUALPORT uses now a new module, which is basically an adaptation of the OR1200_RFRAM_GENERIC one, but with DUALPORT, of course.

We are still in an adaptation phase of the 3rd release of or1200. The boot address was previously changed on standard and now changed back. So other changes might come until it stabilizes. When I think it will not change so often anymore I will adapt code and documentation.

So, good luck and have fun,
Raul