Open ClSlaid opened 3 years ago
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.
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
?
Information for those who are interested in enhancing XiangShan CI:
Currently, XiangShan CI does 3 jobs in parallel:
Verilator simulation consists of 3 stages:
Currently, we use a python script https://github.com/OpenXiangShan/XiangShan/blob/master/scripts/xiangshan.py to deal with environmental things.
Chisel generates synthesizable verilog. It cannot be used to write testbench.
Recommend resources: https://www.chisel-lang.org/chisel3/docs/resources/resources.html.
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.
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:
Though hard making improvement might be, once it being made, there'll be a leap in contributing experience.