How to initial onchip_memory in modelsim post-simulation?

So, if i put the onchip_memory.hex file created by NiosII IDE in QuartusII project directory, then QuartusII software will use it directly to initial The mem_init<num> generics of ligical RAM, am I right?

I have another question:

how to ensure that onchip_memory has been initialed correctly during modelsim post-simulation?

The following is my idea:

In NiosII IDE, I set code/data... memory to onchip_memory, so I hope to observe the CPU signals to ensure that CPU is excuting my code.

In modelsim Pre-simulation, it's easy to implement, because SOPC Builder has bring these signals into modelsim wave window for observing, as the following shows:

# Display signals from module cpu

add wave -noupdate -divider {cpu}

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/i_readdata

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/i_readdatavalid

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/i_waitrequest

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/i_address

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/i_read

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_dataa

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_datab

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_ipending

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_status

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_estatus

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_n

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_a

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_b

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_c

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_readra

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_readrb

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_writerc

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_result

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_clk_en

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_start

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/A_ci_multi_done

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/clk

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/reset_n

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/d_readdata

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/d_waitrequest

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/d_irq

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/d_address

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/d_byteenable

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/d_read

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/d_write

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/d_writedata

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/d_readdatavalid

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/the_cpu_test_bench/W_pcb

add wave -noupdate -format Logic -radix ascii /test_bench/DUT/the_cpu/the_cpu_test_bench/W_vinst

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/the_cpu_test_bench/W_valid

add wave -noupdate -format Logic -radix hexadecimal /test_bench/DUT/the_cpu/the_cpu_test_bench/W_iw

But in modelsim Post-Simulation, I can't find the signals listed above. May be after fitting, their names have been changed(Is there any rule or datasheet can explain how name change before and after QuartusII Fitting operation?) or some of them have been optimized.

BTW. how could SOPC Builder bring the signals listed above into modelsim wave window automatically?

Could you also guide me how to decide the time resolution during modelsim Post-simulation? In modelsim handbook, it says that: "Choosing the resolution

You should choose the coarsest resolution limit possible that does not result in undesired

rounding of your delays. The time precision should not be unnecessarily small because it will limit the maximum simulation time limit, and it will degrade performance in some

cases." As I know, the unit of *.sdf file created by QuartusII is 'ps', base on the words "You should choose the coarsest resolution limit possible that does not result in undesired rounding of your delays." Does it mean that I should choose 'ps' for modelsim simulator resolution limit?

Sorry for so many questions...

P.S. : the red color of word represents my questions. :)

Wish you a happy Christmas!!

Thanks again!

Yes, the Quartus II software will initialize the memory with your HEX file. If you change the HEX file, remember to run Update Memory Initialization File and re-run the Assembler to generate a new programming file (or re-run the EDA Netlist Writer to generate your VHO) . The ATOM models initialize from the mem_init parameters in order to mimic this behavior - if you don't Update Memory Initialization File, then you won't get updated initial contents in your memories.

Now for your questions:

How to ensure that onchip_memory has been initialed correctly during modelsim post-simulation?

Do you have a specific concern that the on-chip memory isn't initialized correctly? That would be a fairly significant bug in the software itself. In general, I give software the benefit of the doubt until there's no other explanation. If you're just being cautious or curious, I can understand. Even so, your time might be spent elsewhere, I think.

Is there any rule or datasheet can explain how name change before and after QuartusII Fitting operation?

Nope. Pin names are generally sacred, for obvious reasons. Register names often survive without transformation, unless packed into a macro block (RAM, DSP, I/O), merged with a duplicate, or retimed. RAM outputs are particularly troublesome because the actual names attached to the physical RAM blocks come from the inferred megafunctions and not the user source, and Quartus II has many different ways to implement a large RAM into the available RAM blocks. I would normally route the RAM output to a debug port on my design or make sure it fed a set of well-named registers with a Preserve attribute to prevent any compiler optimizations. You can also preserve combinational nets with the Keep attribute. Essentially, you tell the software that you care about a select number of names and it keeps them around for you.

BTW. how could SOPC Builder bring the signals listed above into modelsim wave window automatically?

That's a novel idea but I doubt enough users will ever clamor for this feature to make it a priority. I feel your pain. I've debugged plenty of post-fitting simulations in Modelsim and finding the signals you want can be a challenge. The astute use of Preserve and Keep are the best solutions in my toolbox.

Could you also guide me how to decide the time resolution during modelsim Post-simulation?

I think 1ps will be more than adequate. I believe some of the ATOM models use (or used) a 1ps delay to resolve race conditions that normally shouldn't occur if you simulate WITH delays. I imagine most delays in the SDF are more several hundred ps. Still, better to aim for a slower simulation that works than a faster simulation that doesn't. :)

Happy Simulating!

Wow...I don't know how to express my appreciation! Thanks very very very much for all you replies.

I'm a newer in QuartusII & Modelsim! I have lots of question need answer. :(

Today, I got another question:

How to write testbench so that I can observe signals of sub-module during modelsim post-simulation?

My system is NiosII system, and I integreted a custom IP into the NiosII system.

In modelsim, I create a testbench for top-level module automatically. Then I add stimulus in the testbench. But I hope to observe my custom IP signals to check if it's correct.

How could I do?

My idea is that:

Create another testbench for custom IP and check the signals.

But is doing this way, another two problems come up:

1. Due to modelsim post-simulation, so the custom IP testbench is based on post-fitting netlist file, the signals become hard to observe and check.

2. In modelsim, as I know, if I want to apply '*.sdo' during simulation, I have to select the design entity(means top-level entity, right?) the corresponds to the standard delay format output file.

which means that if I want to apply '*.sdo', I could only simulate top-level entity, am I right??

If yes, how could I integreted testbench files while applying '*.sdo' in modelsim post-simulation.

If no, could you kindly figure out where I understand wrong.

Happy Christmas and Thanks again.

I'm still a bit perplexed that you want to debug the post-fitting netlists in Modelsim. It's like debugging a C++ after its been compiled to heavily optimized machine code. I'm all for simulating a post-fitting netlists, but I generally dread tracing into the netlist to isolate a testbench failure. You should verify your RTL in Modelsim, where you can work out any functional kinks in your design. The post-fitting simulation should be a sanity check. If it fails, any number of issues could be at fault. For example, you may need to add/modify timing constraints, or you may need to review the Quartus II warning messages for any design issues. Look especially close at any critical warning messages. I'd explore all these avenues before I ever start probing internal signals in the post-fitting simulation. Sometimes it's almost easier to route those signals to top-level debug pins rather than make sense of the compiler-generated names.

Regarding your custom IP: I suggest you verify it separately, then integrate it into your full system. If something doesn't work, then follow the steps out lined about - check your timing constraints, look for suspicious warnings.

Great answer... You correct my direction:)

BTW, I have found the methods to allows access to any signal from any other hierarchical block without having to route it via the interface in modelsim.

The answer locates in Chapter 9 signal spy in Modelsim User's Manual.

The following is the introduction of this chapter, FYI.

The Verilog language allows access to any signal from any other hierarchical block without

having to route it via the interface. This means you can use hierarchical notation to either

assign or determine the value of a signal in the design hierarchy from a testbench. This

capability fails when a Verilog testbench attempts to reference a signal in a VHDL block

or reference a signal in a Verilog block through a VHDL level of hierarchy.

This limitation exists because VHDL does not allow hierarchical notation. In order to

reference internal hierarchical signals, you have to resort to defining signals in a global

package and then utilize those signals in the hierarchical blocks in question. But, this

requires that you keep making changes depending on the signals that you want to reference.

The Signal Spy procedures and system tasks overcome the aforementioned limitations.

They allow you to monitor (spy), drive, force, or release hierarchical objects in a VHDL or

mixed design.

Well, routing debug signals to your top-level interface is a way to debug internal points in your post-fit netlist without hunting for and grouping together the individual nodes that comprise your "point of interest", which can be damn near impossible without inside knowledge about the way the compiler optimizes a design. An arbitrary hierarchical reference into your original RTL will be most likely be invalid after compilation. Still, you've hit upon a good technique for debugging your RTL more deeply within your Verilog testbench itself. In VHDL, you're simply stuck with adding internal nodes to the waveform viewer or manually routing them to the design boundary, even when debugging just the RTL.

It sounds like you're making good progress!

With Modelsim SIGNAL SPY LIBRARY, you can also access to any signal from any other hierarchical block without having to route it via the interface in a VHDL or

mixed design.

Just to comfirm whether you have gotten my information.