-
Notifications
You must be signed in to change notification settings - Fork 762
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
[verilator] Load elf instead of vmem #3
Comments
@towoe please assign this to yourself if you want to give it a try, and let me know if you have any questions. |
Thanks @imphil for putting this down. I will give it a try! |
I've created a small sample Verilator example which uses libelf to access the data, same as your previous work @imphil, and So do we want to load ROM and Flash with this method? Do we load the first segment of each file into the memory? |
Replace -O2 in the fusesoc file with -O0 to get faster test builds.
We already hardcode a hierarchical path to each memory, you can use this path for this work as well.
That won't be possible. You need to start writing at address 0 of the respective memory. Ultimately, you need to write the memory with the same data that objdump creates when transforming an elf file into a bin file. The code in Open SoC Debug should do that. |
Thanks for the tip!
Rephrasing this, what should we do with the RAM section? There is currently a method to load data into RAM but maybe we will get rid of this?
True. My current approach will reuse the scope method and use a function on the SV side in order to make it more obvious how the memory is updated.
Will write to address 0 of the memory. But my idea, which I still think will not work, would be to select the appropriate memory based on the address in the elf file.
I am assuming you meant |
Treat them all the same: you have a binary and want to load it into a memory space. From the view of Verilator, it doesn't make a difference if that memory is called ROM, RAM, or flash. We (most likely likely) won't have a single elf file that needs to be split between the three. |
This commit replaces long ternary expressions by a combination of `if/else` and `unique case` statements.
Supported by #1091 |
Execution wrapper
According to top_earlgrey.v, hmac's alert should be a fatal alert. However, while implementing phase lowRISC#3 of chip_sw_alert_handler_lpg_clkoff test, I noticed it misbehaves. This commit provides the C and SV files to reproduce the behavior: - Drive u_hmac.gen_alert_tx[0].u_prim_alert_sender.alert_req_i to 1 for 200ns. - Put the hmac into clock-gating mode - Clear the hmac_alert_cause register (cause_reg_44) of the alert handler - Wait for 100us - Enable the clock again Expected behavior: alert_req_trigger to be 1 after re-enabling the clock Observed behavior: alert_req_trigger is 0 after re-enabling the clock Signed-off-by: Bilgiday Yuce <bilgiday@google.com>
According to top_earlgrey.v, hmac's alert should be a fatal alert. However, while implementing phase lowRISC#3 of chip_sw_alert_handler_lpg_clkoff test, I noticed it misbehaves. This commit provides the C and SV files to reproduce the behavior: - Drive u_hmac.gen_alert_tx[0].u_prim_alert_sender.alert_req_i to 1 for 200ns. - Put the hmac into clock-gating mode - Clear the hmac_alert_cause register (cause_reg_44) of the alert handler - Wait for 100us - Enable the clock again Expected behavior: alert_req_trigger to be 1 after re-enabling the clock Observed behavior: alert_req_trigger is 0 after re-enabling the clock Signed-off-by: Bilgiday Yuce <bilgiday@google.com>
Currently we need to pre-process elf files into vmem files to load them into a Verilator simulation (through
$readmemh()
). It would be nice if we can improve Verilator to directly load elf files.Steps towards that:
$readmemh()
mem
variable in theprim_generic_ram_1p.sv
& Co. through Verilator. Either by making it/* verilator public*/
or through a task/function in the SV code, similar to thesimutil_verilator_memload
function in prim_generic_ram_1p.sv & Co.There might be existing code out in the internet that does that, it might be worth googling first :-)
The text was updated successfully, but these errors were encountered: