search

ucb-bar / chipyard

An Agile RISC-V SoC Design Framework with in-order cores, out-of-order cores, accelerators, and more
https://chipyard.readthedocs.io/en/stable/
BSD 3-Clause "New" or "Revised" License
1.56k stars 618 forks source link

Problems with the vlsi-flow of sky130-Tutorial #1363

Closed zqj2333 closed 1 year ago

zqj2333 commented 1 year ago

Background Work

Chipyard Version and Hash

Release: 1.8.1

OS Setup

CentOS Linux release 7.9.2009 conda 22.11.1

Other Setup

Set up the prerequisites described in the document

Current Behavior

I run "make buildfile tutorial=sky130-commercial" and then "make sim-rtl tutorial=sky130-commercial BINARY=$RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv64ui-p-simple", but the simulation couldn't finish. It seems that there has been some people who occurred this (https://github.com/ucb-bar/chipyard/issues/1211#issue-1349624534) and there has been some improvement. But I still occur this problem, I was wondering if I could do something to correct this.

Expected Behavior

The simulation could finish.

Other Information

No response

harrisonliew commented 1 year ago

This X-propagation is due to the fact that OpenRAM memories do not have a method of register initialization via an environment variable or similar. For VCS simulation, you will be required to pass the +vcs+initreg+random compile-time option and one of vcs+initreg+<0,1,random> runtime options when using OpenRAM macros.

FYI, we are migrating away from OpenRAM in favor of https://github.com/rahulk29/sram22 by the next Chipyard release (in a couple of weeks). This SRAM generator will not have X-propagation issues.

zqj2333 commented 1 year ago

This X-propagation is due to the fact that OpenRAM memories do not have a method of register initialization via an environment variable or similar. For VCS simulation, you will be required to pass the +vcs+initreg+random compile-time option and one of vcs+initreg+<0,1,random> runtime options when using OpenRAM macros.

FYI, we are migrating away from OpenRAM in favor of https://github.com/rahulk29/sram22 by the next Chipyard release (in a couple of weeks). This SRAM generator will not have X-propagation issues.

Thanks for your reply. To pass the +vcs+initreg+random compile-time option, I ran make sim-rtl-debug tutorial=sky130-commercial to get the original vcs instruction, and then add the +vcs+initreg+random to the instruction, which becomes /usr/eelocal/synopsys/vcs-vt2022.06/bin/vcs -full64 -lca -debug_access+all -timescale=1ns/10ps -CC -I/usr/eelocal/synopsys/vcs-vt2022.06/include -CFLAGS -O3 -CFLAGS -std=c++11 -CFLAGS -I/local/home/coguest/chipyard/.conda-env/riscv-tools/include -CFLAGS -I/local/home/coguest/chipyard/tools/DRAMSim2 -CFLAGS -I/local/home/coguest/chipyard/vlsi/generated-src/chipyard.TestHarness.TinyRocketConfig -LDFLAGS -L/local/home/coguest/chipyard/.conda-env/riscv-tools/lib -LDFLAGS -Wl,-rpath,/local/home/coguest/chipyard/.conda-env/riscv-tools/lib -LDFLAGS -L/local/home/coguest/chipyard/vlsi -LDFLAGS -L/local/home/coguest/chipyard/tools/DRAMSim2 -lfesvr -ldramsim -kdb -notice -line +lint=all,noVCDE,noONGS,noUI -error=PCWM-L -error=noZMMCM -timescale=1ns/10ps -quiet -q +rad +vcs+lic+wait +vc+list -f /local/home/coguest/chipyard/vlsi/generated-src/chipyard.TestHarness.TinyRocketConfig/sim_files.common.f -sverilog +systemverilogext+.sv+.svi+.svh+.svt -assert svaext +libext+.sv +v2k +verilog2001ext+.v95+.vt+.vp +libext+.v -debug_pp +incdir+/local/home/coguest/chipyard/vlsi/generated-src/chipyard.TestHarness.TinyRocketConfig /local/home/coguest/chipyard/vlsi/generated-src/chipyard.TestHarness.TinyRocketConfig/chipyard.TestHarness.TinyRocketConfig.top.v /local/home/coguest/chipyard/vlsi/generated-src/chipyard.TestHarness.TinyRocketConfig/chipyard.TestHarness.TinyRocketConfig.harness.v /local/home/coguest/chipyard/vlsi/generated-src/chipyard.TestHarness.TinyRocketConfig/chipyard.TestHarness.TinyRocketConfig.top.mems.v /local/home/coguest/chipyard/vlsi/generated-src/chipyard.TestHarness.TinyRocketConfig/chipyard.TestHarness.TinyRocketConfig.harness.mems.v /local/home/coguest/chipyard/vlsi/generated-src/chipyard.TestHarness.TinyRocketConfig/chipyard.TestHarness.TinyRocketConfig.top.v /local/home/coguest/chipyard/vlsi/generated-src/chipyard.TestHarness.TinyRocketConfig/chipyard.TestHarness.TinyRocketConfig.top.mems.v /local/home/coguest/chipyard/vlsi/generated-src/chipyard.TestHarness.TinyRocketConfig/EICG_wrapper.v /local/home/coguest/chipyard/vlsi/generated-src/chipyard.TestHarness.TinyRocketConfig/chipyard.TestHarness.TinyRocketConfig.harness.v /local/home/coguest/chipyard/vlsi/generated-src/chipyard.TestHarness.TinyRocketConfig/chipyard.TestHarness.TinyRocketConfig.harness.mems.v /local/home/coguest/chipyard/vlsi/build-sky130-commercial/chipyard.TestHarness.TinyRocketConfig-ChipTop/tech-sky130-cache/primitives.v /local/home/coguest/chipyard/vlsi/build-sky130-commercial/chipyard.TestHarness.TinyRocketConfig-ChipTop/tech-sky130-cache/sky130_fd_sc_hd.v /home/coguest/sky130root/sky130_sram_macros/sky130_sram_2kbyte_1rw1r_32x512_8/sky130_sram_2kbyte_1rw1r_32x512_8.v /home/coguest/sky130root/sky130_sram_macros/sky130_sram_1kbyte_1rw1r_32x256_8/sky130_sram_1kbyte_1rw1r_32x256_8.v /home/coguest/sky130root/sky130_sram_macros/sky130_sram_1kbyte_1rw1r_8x1024_8/sky130_sram_1kbyte_1rw1r_8x1024_8.v +define+DEBUG +define+VCS +define+CLOCK_PERIOD=1.0 +define+RESET_DELAY=777.7 +define+PRINTF_COND=TestDriver.printf_cond +define+STOP_COND=!TestDriver.reset +define+MODEL=TestHarness +define+RANDOMIZE_MEM_INIT +define+RANDOMIZE_REG_INIT +define+RANDOMIZE_GARBAGE_ASSIGN +define+RANDOMIZE_INVALID_ASSIGN +define+FSDB +notimingcheck +delay_mode_zero +vcs+initreg+random -top TestDriver -o /local/home/coguest/chipyard/vlsi/build-sky130-commercial/chipyard.TestHarness.TinyRocketConfig-ChipTop/sim-rtl-rundir/simv. I ran this new vcs instruction to generate a new simv, and ran the simv with ./simv +vcs+initreg+0 $RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv64ui-p-simple, but there was some errors. The end of the information is

............   749 Reading TestDriver.testHarness.chiptop.system.tile_prci_domain.tile_reset_domain.tile.frontend.icache.data_arrays_0.data_arrays_0_0_ext.mem_0_0 addr0=000010000 dout0=00000000000000000000000000000000
                 750 Reading TestDriver.testHarness.chiptop.system.tile_prci_domain.tile_reset_domain.tile.frontend.icache.tag_array.tag_array_ext.mem_0_0 addr0=00000001 dout0=00000000000000000000000000000000

terminate called after throwing an instance of 'std::runtime_error'
  what():  could not open +vcs+initreg+0 (did you misspell it? If VCS, did you forget +permissive/+permissive-off?)

Error-[DPI-UED] C++ Exception detected
  Import DPI routine invoked at file 
  '/local/home/coguest/chipyard/vlsi/generated-src/chipyard.TestHarness.TinyRocketConfig/SimSerial.v'(line
  53) has C++ exceptions not caught. C++ exceptions shall not propagate out of
  any imported subroutine.
  Fix it in DPI-C code before running simulation.
V C S   S i m u l a t i o n   R e p o r t 
Time: 779500 ps
CPU Time:      0.440 seconds;       Data structure size:   4.0Mb
Fri Feb 24 11:49:52 2023

I was wondering if there is something wrong in my action. Thank you very much.

harrisonliew commented 1 year ago

When you run ./simv, you must place plusargs in between +permissive and +permissive-off.

By the way, you should append these initreg plusargs using sim.inputs.options for the compile-time one and sim.inputs.execution_flags for the runtime one, then you won't miss these permissive plusargs.

zqj2333 commented 1 year ago

When you run ./simv, you must place plusargs in between +permissive and +permissive-off.

By the way, you should append these initreg plusargs using sim.inputs.options for the compile-time one and sim.inputs.execution_flags for the runtime one, then you won't miss these permissive plusargs.

Thanks for your reply. I change the instruction to run simv to /local/home/coguest/chipyard/vlsi/build-sky130-commercial/chipyard.TestHarness.TinyRocketConfig-ChipTop/sim-rtl-rundir/simv +permissive +verbose +vcs+initreg+0 +fsdbfile=/local/home/coguest/chipyard/vlsi/output/chipyard.TestHarness.TinyRocketConfig/.fsdb +dramsim +dramsim_ini_dir=/local/home/coguest/chipyard/generators/testchipip/src/main/resources/dramsim2_ini +max-cycles=10000000 -saif_opt+toggle_start_at_set_region+toggle_stop_at_toggle_report -ucli2Proc -ucli -do /local/home/coguest/chipyard/vlsi/build-sky130-commercial/chipyard.TestHarness.TinyRocketConfig-ChipTop/sim-rtl-rundir/run.tcl +permissive-off $RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv32ui-p-simple, which is the original instruction with "+vcs+initreg+0". But I found that the simulation still couldn't finish after a few minutes. (For the same workload, the ASAP-tutorial could finish within 10 seconds) I found that it seems that it has been in an endless loop, for example, this is some information when running: N`F(~I@{R@3R0BKGO 8XEZ8 What's more, I found that there are still some X in the process:

AM6OW$D(X$X0N_)$RE41Q{7

nayiri-k commented 1 year ago

We are in the process of modifying the sky130 tutorial substantially, to include new SRAMs designed by a student in our lab. RTL simulation with VCS easily passes with these new SRAMs (and they work better for P&R and pass DRC/LVS as well). The tutorial should be out within a week, my best advice would be to wait and try out the new tutorial. Sorry you experienced these issues.

zqj2333 commented 1 year ago

We are in the process of modifying the sky130 tutorial substantially, to include new SRAMs designed by a student in our lab. RTL simulation with VCS easily passes with these new SRAMs (and they work better for P&R and pass DRC/LVS as well). The tutorial should be out within a week, my best advice would be to wait and try out the new tutorial. Sorry you experienced these issues.

Thanks for your information. I was wondering if the new sram would have information about the power? and how about dynamic power?

nayiri-k commented 1 year ago

I have not done much power analysis with these SRAMs but the LIB files were generated with Cadence Liberate so they should be accurate. That being said, for a small chipyard design (TinyRocket SoC) with 3 SRAM macros (4096x32, 1024x32, 64x32) at 67MHz, the Innovus post-PnR power report for Macros is as follows (in mW):

Group                           Internal   Switching     Leakage       Total  Percentage 
                                Power      Power         Power         Power  (%)        
-----------------------------------------------------------------------------------------
Macro                              1.139     0.01103   0.0004367       1.151       4.009
zqj2333 commented 1 year ago

I have not done much power analysis with these SRAMs but the LIB files were generated with Cadence Liberate so they should be accurate. That being said, for a small chipyard design (TinyRocket SoC) with 3 SRAM macros (4096x32, 1024x32, 64x32) at 67MHz, the Innovus post-PnR power report for Macros is as follows (in mW):

Group                           Internal   Switching     Leakage       Total  Percentage 
                                Power      Power         Power         Power  (%)        
-----------------------------------------------------------------------------------------
Macro                              1.139     0.01103   0.0004367       1.151       4.009

Hello, thanks for your information. It seems that this could give some information for power analysis.