Colliding module name: ALU

[leviathanch]

Type of issue: bug report

Impact: API modification

Development Phase: request

Other information
When 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

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

[jerryz123]

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.

[leviathanch]

I just realized the folks from Litex are still on a super old version, which is 4f19770... I'd first have to bring their dependencies up to speed and get the upgrades accepted there first...

https://github.com/litex-hub/pythondata-cpu-rocket/blob/master/pythondata_cpu_rocket/verilog/update.sh

[leviathanch]

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

#3673