-
Notifications
You must be signed in to change notification settings - Fork 552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to connect the SRAM generated by the memory compiler to the Ibex core and verify its functionality? #2197
Comments
The running log and the trace_core are attached as follows. |
I have used a memory compiler to generate an SRAM with a width of 32 and a depth of 8192. I have instantiated one in prim_generic_ram_2p. Since the memory compiler cannot generate dual-port SRAM, I directly used port A for data RAM. The code is shown as follows. Afterwards, I used VCS to simulate the simple system with the hello_test binary and encountered the following error: Check the trace_core_00000000.log file and find that it gets stuck at instruction 177, then an error is reported, as shown in the figure below. Instruction 174 seems to be incorrect. I don't understand why x15=0x000000xx; it should be x15=0x00000048. I have attached both the correct log and the incorrect log below. |
Hi there, Thank you for the detailed description of what you're trying to do, and what's not working. I think I understand you, and I'm pretty optimistic that we can get things working for you. My first note is about the assertions. These are basically saying that some control structures are trying to make decisions based on uninitialised data. Practically speaking, this will mean that you've fetched some instruction words from uninitialised memory and are now trying to decode and execute them. As you might expect, this isn't going to work :-) This matches your description of the log file. If you look closely, notice that the (also) instruction after the lbu On the plus side, I suspect the root cause is the same in both cases: the fetched instruction data contains When you say that " For details of the exact timing, I'm going to forward this to @GregAC (who implemented most of the code in question). I can try to work it out by squinting at the implementation, but I'm probably not the best person to answer! |
Thank you very much for your quick response. I found part of the reason: as you mentioned, I did not read in data during the SRAM initialization. This was my mistake; I assumed that memory initialization only applied to the Instruction memory and not to the data memory. It turns out both parts need to be initialized. I only ported the data memory, keeping the data memory part as the original code. Now that I have initialized the data memory, I can continue to make progress (I simply added the $readmemh statement in the Verilog code for the data memory; I wonder if there is a more convenient way to modify this). Additionally, after initializing the data memory, although the system can continue running, there are still other errors. I am currently debugging and hope to resolve them. If I am unable to fix them, I will post the issues here and hope to receive your assistance. |
By the way, may I ask if the default RAM size for the simple system is 1MB? I want to modify it to 32KB (because the memory compiler can only generate a maximum of 32KB RAM). Is this sufficient for the simple system to run? If so, which files should be modified? From my preliminary review, it seems necessary to modify the Device address mapping section in ibex_simple_system.sv. Do the base addresses and masks for RAM, SimCtrl, and Timer all need to be modified? Besides this, which other files need to be changed? |
I am currently aiming to tape out a chip using SMIC's 180nm process. I am keeping the ibex core unchanged, but I need to embed SRAM on the chip. I use SMIC's memory compiler to generate the RAM's Verilog and liberty files, but I need to verify whether this SRAM can connect well with the ibex core and function properly. This is because the read/write timing of the SRAM generated by the memory compiler is different from that of prim_ram_2p. The prim_ram_2p can read out data in the current cycle, while the SRAM generated by the memory compiler requires a delay of one cycle to read out data. Therefore, I need to verify whether this SRAM works well; otherwise, I will need to design additional timing control logic.
I want to use the Ibex Simple System for verification. My steps are as follows:
However, the simulation reports errors. It seems that the vmem is not read into the SRAM, and the instructions in the trace_core_00000000.log file are empty, showing INVALID. Is it possible that the SRAM cannot use the $readmemh command to load data? How should I proceed to verify it?
The text was updated successfully, but these errors were encountered: