Why has it been stopped in this place? [UART] UART0 is here (stdin/stdout).

[llhe110]

When I run the following simulation command, it stops all the time.

 ./scripts/run-verilator.sh --debug  mobilenet
This emulator compiled with JTAG Remote Bitbang client. To enable, use +jtag_rbb_enable=1.
Listening on port 44019
[UART] UART0 is here (stdin/stdout).

[Srangrang]

hi,did you solve this problem? I think verilator is not suitable for running mobilenet.

https://groups.google.com/g/chipyard/c/gxeuKCxkmmk/m/EQYfQUWEEAAJ

[llhe110]

hi,did you solve this problem? I think verilator is not suitable for running mobilenet.

https://groups.google.com/g/chipyard/c/gxeuKCxkmmk/m/EQYfQUWEEAAJ

I don't know how to deal with it

[bysg]

maybe is to slow to run?

[hinata9276]

When I build with GemminiRocketConfig, it runs with verilator. Under the chipyard/sim/verilator/, I overwrite the verilator threads (to speed up the simulation) and timeout limit (to prevent timeout error). The culprit is the slow memory loading, so I overwrite to load the built binary into SimDRAM.

make CONFIG=GemminiRocketConfig VERILATOR_THREADS=4 TIMEOUT_CYCLES=10000000000 run-binary-fast BINARY=../../generators/gemmini/software/gemmini-rocc-tests/build/imagenet/mobilenet-baremetal LOADMEM=1

It is documented in the Chipyard repo but used for RISCV simulation, the same applied to Gemmini too. I tried and it no longer stuck on "[UART] UART0 is here (stdin/stdout)" printout.

It managed to complete the verilator simulation, taking 4 hours. However, the mobilenet code failed the classification task in Verilator and Spike simulations.

[bysg]

what test case do you run，in most testcase，uart will stay for a long times-------- 原始邮件 --------发件人： hinata9276 @.>日期： 2025年10月4日周六 中午12:50收件人： ucb-bar/gemmini @.>抄送： bysg @.>, Comment @.>主 题： Re: [ucb-bar/gemmini] Why has it been stopped in this place? [UART] UART0 is here (stdin/stdout). (Issue #332)hinata9276 left a comment (ucb-bar/gemmini#332) When I build with GemminiRocketConfig, it runs with verilator. Under the chipyard/sim/verilator/, I overwrite the verilator threads (to speed up the simulation) and timeout limit (to prevent timeout error). The culprit is the slow memory loading, so I overwrite to load the built binary into SimDRAM. make CONFIG=GemminiRocketConfig VERILATOR_THREADS=4 TIMEOUT_CYCLES=10000000000 run-binary-fast BINARY=../../generators/gemmini/software/gemmini-rocc-tests/build/imagenet/mobilenet-baremetal LOADMEM=1 It is documented in the Chipyard repo but used for RISCV simulation, the same applied to Gemmini too. I tired and it no longer stuck on "[UART] UART0 is here (stdin/stdout)" printout. It managed to complete the verilator simulation, taking 4 hours. However, the mobilenet code failed the classification task in Verilator and Spike simulations. mobilenetVerilatorError.png (view on web)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[hinata9276]

I ran the default test cases from gemmini-rocc-tests. Yes, before I modify the command, uart stayed for a long time. After I adapted the chipyard tutorial here, it ran instantly after the uart printout. It worked on most gemmini-rocc-tests build. Nevertheless, mobilenet and resnet50 have wrong outputs. Now turning on gemmini check flag for particular layer to check with CPU output, but it is taking very long time. CPU cross check for mlps and baremetalC have no issue (except tiled_matmul_ws_softmax-baremetal build).

Edit: the test failed because I accidentally removed the mvin_scale_args in the configs. Both mobilenet and resnet50 passed the test after restoring the mvin_scale_args. My bad.