Hi,

I added the minsoc to a ModelSim project. and also I added all necessary files.
When I run ModelSim, the Memory is initialized correctly but other sections don´t work.
I attach a section of signal waves of ModelSim. I think the problem is that wishbone does not work correctly. Could anybody help me to solve this problem?
Also there are multiple timescales for multiple modules in the minsoc. Should I make all of them equal or each module should have its own timescale?

Thank you,
Mehdi

The X's on your read data suggest that something else is also trying to drive the bus to all 0's and you see an X for every 1 bit that is read.

Even when I simulate with GENERIC_FPGA definition, I have this problem again.

Check the signals req_i and req_won plus i5_wb_adr_i and t0_addr of module tc_mi_to_st::t0_ch from minsoc_tc_top::tc_top.

By the way, did you change any definition on minsoc_bench_defines.v ? Or in minsoc_defines.v or or1200_defines.v ?

the signals have the following values: (also I attach the signals waves)
req_i 00x00000
req_won x0x
i5_wb_adr_i 100000000

My only change is in the minsoc_defines.v, I uncommented Virtex5. (also overall of my project directory is available in the attachment)

Dehbasi,

it seems you have included too many files and are having some conflicts therefore. Not completely sure.

For a list of the files to include for simulation use this: minsoc/sim/bin/minsoc_model.txt

Update your project accordingly and tell me if it works.

I hope that helps,
Raul

For sure you have to:

-remove minsoc_onchip_ram_top.v
-remove minsoc_tc_top_B3.v
-edit minsoc_bench.v the way it was, comment 110-113 and uncomment 114-117
-copy tap_defines.v and tap_top.v plus compiled jp-io-vpi.vpi from adv_debug_sys directory

Then inlude everything else in the project and run again.

-As you recommended, I started to update my project. During update, I just understood the problem: When I have the following definition, there is no problem.

`define GENERIC_TAP
//`define FPGA_TAP

But when I have the following definition:

//`define GENERIC_TAP
`define FPGA_TAP

ModelSim reports some errors like this:

# ** Error: (vsim-3389) C:/Modeltech_pe_edu_10.0a/examples/minsoc_bench.v(228): Port 'jtag_tdi' not found in the connected module (3rd connection).
# Region: /minsoc_bench/minsoc_top_0

(also similar errors for 'jtag_tms', 'jtag_tck', 'jtag_tdo', 'jtag_vref', 'jtag_gnd')

This is related to lines 188-195 :

//JTAG ports
`ifdef GENERIC_TAP
, .jtag_tdi(dbg_tdi_i),
.jtag_tms(dbg_tms_i),
.jtag_tck(dbg_tck_i),
.jtag_tdo(dbg_tdo_o),
.jtag_vref(jtag_vref),
.jtag_gnd(jtag_gnd)
`endif

I thought because now I don't use GENERIC_TAP, I can comment this section for escaping the errors. After commenting this section, the previous problem occurs and some signals have X values. Do you know why ModelSim reports the above mentioned error? (# ** Error: (vsim-3389)) . I use Modelsim PE Student Edition 10.0a. In this situation how I can use FPGA_TAP?


-Also there are some warnings like:

# ** Warning: (vsim-3015) C:/Modeltech_pe_edu_10.0a/examples/minsoc_onchip_ram.v(414): [PCDPC] - Port size (11 or 11) does not match connection size (13) for port 'ADDR'. The port definition is at: C:/Modeltech_pe_edu_10.0a/examples/fpga_memory_primitives.v(206).
# Region: /minsoc_bench/minsoc_top_0/onchip_ram_top/block_ram_3/ramb16_s9

This occurs while I use the following definition:

`define MEMORY_ADR_WIDTH 13

And it is solved only by changing aw parameter in the module RAMB16_S9.


-There is another warning for $jp_init', $jp_in', $jp_out', $jp_wait_time':

# ** Warning: (vsim-PLI-3003) C:/Modeltech_pe_edu_10.0a/examples/dbg_comm_vpi.v(118): [TOFD] - System task or function '$jp_init' is not defined.
# Region: /minsoc_bench/dbg_if

How can I resolve this warning?


-Another matter, when I use FPGA memory the following memory initialization doesn't work:

minsoc_top_0.onchip_ram_top.block_ram_3.mem[initialize/4]

(It works only by using GENERIC_MEMORY definition.)

Because there is another module ramb16_s9 in the path:

# ** Error: (vsim-3043) C:/Modeltech_pe_edu_10.0a/examples/minsoc_bench.v(110): Unresolved reference to 'mem' in minsoc_top_0.onchip_ram_top.block_ram_3.mem.

And the following initialization works:

minsoc_top_0.onchip_ram_top.block_ram_3.ramb16_s9.mem[initialize/4]

You are trying to use FPGA specific modules on simulation. To do so, you either need behavioral models from the manufacturer or home made behavioral models.

Fortunately, I created home made behavioral models for the memories used on OpenRISC. But not for the JTAG taps or memory divisor.

Actually, I only created those memory behavioral models to support changes to or1200_defines.v. Changes made to minsoc_defines.v are rolled back by the simulation with the definition `define GENERIC_FPGA of minsoc_bench_defines.v . This is the code which does that on minsoc_defines.v:
//
// Set-up GENERIC_TAP, GENERIC_MEMORY if GENERIC_FPGA was chosen
// and GENERIC_CLOCK_DIVISION if NO_CLOCK_DIVISION was not set
//
`ifdef GENERIC_FPGA
`define GENERIC_TAP
`define GENERIC_MEMORY
`ifndef NO_CLOCK_DIVISION
`define GENERIC_CLOCK_DIVISION
`endif
`endif

Finally, you will not be able to initialize memory so easily if using FPGA memory blocks (specific FPGA memory modules). The reason is simple, minsoc uses a generate assignment to instantiate an arbitrary number of memory blocks based on the MEMORYADRWIDTH configuration.

On simulation, every single block would have to be filled with memory previous to simulation time to upload the firmware efficiently. However, you cannot access generated instances using variables and therefore, you cannot access these instances in a loop. This is impracticable.

My way out was to create a memory model which uses generic memory instead and thus, only instantiates 4 memory blocks, which are then filled with the firmware data prior to simulation time.

Now, if you want to use the memories, you could comment `define INITIALIZE_MEMORY_MODEL and uncomment `define START_UP on minsoc_bench_defines.v. This will use the START_UP module to fill the memory during simulation from an modeled external SPI memory. Moreover, you have to put minsoc_onchip_ram_top.v back in and remove minsoc_memory_model.v .

At last, to avoid the $jp-init problems and so on, comment `define VPI_DEBUG on minsoc_bench_defines.v. It instantiates the module correspondent to the tasks created in C which have to be linked to the simulation environment (don't ask me how to do that in Modelsim).

I still advice you to go for the generic stuff and comment VPI_DEBUG. If you still prefer doing it the way you are now, you might end-up still having problems with the clock divisor.

Lastly, I don't quite get why you changed so many configurations before trying to make it run for the first time. You are already experimenting with another simulator, it would be a lot easier if you run the configuration which is known to run. After it runs, you can start tweaking things step by step and make sure where problems arose. Just my thought.

I hope that helps,
Raul

ramb16_s9 are memory blocks for Xilinx FPGAs. They have address ports with fixed width, therefore minsoc uses a generate assignment to instantiates more of them in order to fill the whole amount of memory expected by MEMORY_ADR_WIDTH.

If you change the aw value of the behavioral model of ramb16_s9, you might have problems with it while OpenRISC uses it. The best approach would be to use GENERIC_MEMORY definition. This uses generic memory instead, which basically simply has a settable address width and memory depth. On top of it you avoid the mismatches occurred by changing a module which is used elsewhere.

I don't know why you get the X values. But, the jtag controls the debug module which has access the OpenRISC. It is never a good idea to simply remove inputs or modules of a simulation, the signals of the removed module are then floating and being fed to other system parts. Mostly, the simulator assumes these port values to be uninitialized X and any access to these values propagates to anyone who depends on them. To avoid that, the testbench initializes the aforementioned ports to safe values, resulting in no interaction between the debugging system and OpenRISC (i.e. no Xs propagating through the system).

`ifdef VPI_DEBUG
dbg_comm_vpi dbg_if(
.SYS_CLK(clock),
.P_TMS(dbg_tms_i),
.P_TCK(dbg_tck_i),
.P_TRST(),
.P_TDI(dbg_tdi_i),
.P_TDO(dbg_tdo_o)
);
`else
assign dbg_tdi_i = 1;
assign dbg_tck_i = 0;
assign dbg_tms_i = 1;
`endif

Hello Raul,
I actually posted in the forum but got no response, therefore decided to write here.
I also want to do simulation for Virtex5 configuration.I also have modifications on or1200 rtl files. I do the necessary steps explained in "debugging the simu" at FAQ however after I start the bridge I cannot "si" or "continue". It just gets stuck at 0x100 address. Could it be absence of a memory model or what?
Thanks in advance