A fast CI is what we need

[ClSlaid]

Though running simulations in hardware development is relatively slow compared to software developments, a faster CI could surely save time and encourage more people to contribute and to contribute more to the XiangShan project.

For example, my PR (#850 ) merely made some typo fixes, but it still consumed almost 1 hour to run and rerun (CI may fail unexpectedly even the code is actually correct).

Taking a look into tests, a time-consuming operation build EMU ran twice in different tests, if the simulator could be reused, it'll save some time for us.

Improve could be made by:

1. better machine running tests, even better than GitHub Actions, this might cost lots of money and power.
2. adapt the way how CI runs, maybe like what I said above.

Though hard making improvement might be, once it being made, there'll be a leap in contributing experience.

considering how much people might come here to contribute, better come along with more marketing works.

[poemonsense]

Thanks for the feedback on CI.

Currently we are using five self-hosted servers for CI (AMD EPYC 7742). We did consider Travis-CI or other public platforms. But none of us has actually tried to do that. We are also considering migrating our repo to gitee, which uses a different CI framework. Hopefully we will build a better CI before September.

For the second question, these two EMUs are not the same. The latter one uses DRAMsim but not the former one. GitHub has a limitation on CI running time (6 hours). If we combine them into a single job, it cannot finish within 6 hours.

We are much appreciated if someone in the community could help us build the CI platform. Actually we don’t know much yet.

[ClSlaid]

Thanks for the feedback on CI.

Currently we are using five self-hosted servers for CI (AMD EPYC 7742). We did consider Travis-CI or other public platforms. But none of us has actually tried to do that. We are also considering migrating our repo to gitee, which uses a different CI framework. Hopefully we will build a better CI before September.

For the second question, these two EMUs are not the same. The latter one uses DRAMsim but not the former one. GitHub has a limitation on CI running time (6 hours). If we combine them into a single job, it cannot finish within 6 hours.

We are much appreciated if someone in the community could help us build the CI platform. Actually we don’t know much yet.

I don't know much about CI, either. After questioning my senior, who's also a chisel user, he considered your CI to be fast enough. Maybe this is what hardware development like I think. 🤣

BTW, I've tried developing a very naive pipeline CPU in verilog last year, which did give me a bad impression about hardware development for writing annoying test benches For example, the compiler just lets go those bad codes that will stuck the whole simulator like modelsim or vivado. Such as

// this is a test bench
always sig_trig=2'b01;
// should be "assign sig_trig=2'b1;"
// no warnings will be given out

Can Chisel avoid such a situation? Are there any recommendations on books or videos about ChiselHDL?

[AugustusWillisWang]

Information for those who are interested in enhancing XiangShan CI:

Currently, XiangShan CI does 3 jobs in parallel:

1. Generate Verilog code (not for simulation) from Chisel source code
2. Use Verilator to run simulation without DRAMsim for basic inst tests and embedded benchmarks
3. Use Verilator to run simulation with DRAMsim for spec SimPoints

Verilator simulation consists of 3 stages:

1. We need to convert Chisel to Verilog before running Verilator simulation. It can only be done with a single thread.
2. Compiling Verilator emulator. This can be done in parallel.
3. After Verilator emulator compiling, run benchmarks and inst tests. They can run in parallel.

Currently, we use a python script https://github.com/OpenXiangShan/XiangShan/blob/master/scripts/xiangshan.py to deal with environmental things.

[poemonsense]

Chisel generates synthesizable verilog. It cannot be used to write testbench.

Recommend resources: https://www.chisel-lang.org/chisel3/docs/resources/resources.html.

[xied75]

I can help on the CI front if that's needed. We can also try Azure DevOps if there is no policy against using these big clouds.