Open leviathanch opened 2 months ago
I think adding a
override def desiredName = "RocketALU"
To the module definition of ALU would be sufficient.
If you open a PR with this to the dev branch, I'd be happy to accept it.
I just realized the folks from Litex are still on a super old version, which is 4f197707eb07d833131395a839974c186069930b... I'd first have to bring their dependencies up to speed and get the upgrades accepted there first...
Here you go, now I bring the rest of the stuff up to speed and will make some more PRs for better integration of Litex
Type of issue: bug report
Impact: API modification
Development Phase: request
Other information When running
it turns out that Yosys and Gowin already have an ALU module which collides with the Rocket Chip ALU moving the file from src/main/scala/rocket/ALU.scala to src/main/scala/rocket/RocketALU.scala and renaming all it's occurrences makes Yosys finally run through and arrive at nextpnr-himbaechel
If the current behavior is a bug, please provide the steps to reproduce the problem:
Running litex-boards/litex_boards/targets/sipeed_tang_primer_20k.py --build --cpu-type rocket --cpu-variant linux --cpu-num-cores 1 --cpu-mem-width 2 --sys-clk-freq 50e6 --with-ethernet --with-sdcard --toolchain=apicula
What is the current behavior?
Synthesis for Gowin boards with Yosys fails
What is the expected behavior?
That the synthesis runs through and the follow up tools like nextpnr can generate a bitstream and I can run a RISC-V SoC on my FPGA
Please tell us about your environment:
openSUSE Tumbleweed
What is the use case for changing the behavior?
Using Rocket Chip with Litex on my Sipeed FPGA from Taobao