Closed mithro closed 4 years ago
https://github.com/enjoy-digital/litex/pull/399 has been merged and a first 2020.04
release has been created for this breaking change with https://github.com/enjoy-digital/litex/commit/56aa7897df99d7ad68ea537ab096c3abdc683666. There is a note in the README and Wiki for existing users explaining LiteX will have to be reinstalled. Thanks all for the discussions, ideas and work, i think we managed to find a good compromise.
With the increasing number of CPU cores supported by LiteX, cloning the LiteX repository means cloning a large number of submodules which can get very big.
I think we should convert each of the supported LiteX CPUs into their own Python packages.
litex/soc/cores/cpu
becomes a "namespace module" which other Python packages can provide modules under. See https://packaging.python.org/guides/packaging-namespace-packages/The CPUs can be split into;
litex-cpu-lm32
litex-cpu-mor1k
litex-cpu-vexriscv
litex-cpu-blackparrot
litex-cpu-microwatt
litex-cpu-chiselwatt
litex-cpu-rocket
litex-cpu-picorv32
litex-cpu-minerva
This allows projects which are only using a single CPU like VexRISCV to only pay the cost of that CPU.
The setup process then becomes;
People can also submodule the repository in using the normal method of;
Or specify a Python requirements file using;
We can easily set up Travis CI so that any push to the LiteX repository causes each of the CPU packages to be tested in combination with the based LiteX.
As VexRISCV is currently the most popular CPU to use with LiteX, we could also make VexRISCV the "default" CPU that is included with LiteX by default and just move the other CPU cores into their own modules. I personally don't think we should preference VexRISCV like that, but it could be a possible compromise?
Thoughts?