OpenCores
no use no use 1/1 no use no use
Sim: More DDR2
by firefalcon on Nov 28, 2011
firefalcon
Posts: 99
Joined: Jan 10, 2011
Last seen: Mar 26, 2024
I have a hardware bug that Linux exposes only when I boot on real hardware using DDR2, not when I boot inside of ModelSim using on-chip RAM. How can I increase the size of the DDR2 used for simulation? I know how to edit ddr2_model_preload.v to initialize the DRR2, but not add more modules to the design correctly.
RE: Sim: More DDR2
by firefalcon on Nov 29, 2011
firefalcon
Posts: 99
Joined: Jan 10, 2011
Last seen: Mar 26, 2024
Paging Julius...
RE: Sim: More DDR2
by julius on Dec 1, 2011
julius
Posts: 363
Joined: Jul 1, 2008
Last seen: May 17, 2021
I have a hardware bug that Linux exposes only when I boot on real hardware using DDR2, not when I boot inside of ModelSim using on-chip RAM. How can I increase the size of the DDR2 used for simulation? I know how to edit ddr2_model_preload.v to initialize the DRR2, but not add more modules to the design correctly.

Just out of interest, I'd like a description of the bug you're seeing.

But in regard to increasing the size of the DDR2 model, I think you'll find the issue is that the amount of the image that is loaded into the DDR RAM models isn't as much as they can take. This is done in the testbench, where it includes the bench/verilog/ddr2_model_preload.v file. Have you looked at this? This loads the model with the data in the annoying way it must be arranged in the memories. To get more into the model, you'll want to increase the size of that loop (the ml501 shows it goes for 4096 loops of 128 bits, which is 64KB - increase that to whatever you need.)

You'll also need to make sure the array that we $readmemh() the .vmem file into is big enough. This is done in the orpsoc_testbench verilog. Right now it's 1M words (4MB) which might not be enough for your kernel image. So to increase it change the NUM_PROGRAM_WORDS parameter.

I never made the loading loop the full 4MB because we didn't need it, and it takes a long time as it is, for some reason.

But in regards to simulating the kernel bug you're seeing good luck - I hope you track it down and let us know what it is.
RE: Sim: More DDR2
by firefalcon on Dec 2, 2011
firefalcon
Posts: 99
Joined: Jan 10, 2011
Last seen: Mar 26, 2024
Just out of interest, I'd like a description of the bug you're seeing.


I am creating an illegal instruction exception after every 3 executed instructions. I have so far fixed several issues with exception processing that allow me to almost boot linux on hardware and boot completely using block-ram in rtl simulation. Right after the kernel frees memory it get and error that sends me to address 0.

But in regard to increasing the size of the DDR2 model, I think you'll find the issue is that the amount of the image that is loaded into the DDR RAM models isn't as much as they can take.


As I said in the original post, I have edited the preload file in a way that could load the entire kernel and my handler in a timely fashion. The problem is that this data is greater than 4MB, so I need to model much more DDR2 memory.
RE: Sim: More DDR2
by firefalcon on Dec 10, 2011
firefalcon
Posts: 99
Joined: Jan 10, 2011
Last seen: Mar 26, 2024
I have fixed the problem and will be submitting some fixes to the dev. lists. Here is an overview of whats I ended-up doing:

1. I defined MAX_MEM in ddr2_model_parameters.v
2. I changed ddr2_model_preload.v so it was much clearer to understand and edit and properly included banks as part of the address.
3. I made sure the ddr2 parameters matched those of my board's ddr2 chips

As a result of these changes, I can access the entire 256 MB range of DDR2 and loading a kernel image is practically instantaneous. Read and write accesses to the DDR2 also take less time for the simulator. The trade-off is a larger memory footprint by the simulator, but simulation times are no slower than with just 4 MB of DDR2.
no use no use 1/1 no use no use
© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.