iob-lib/python-setup: copies software of modules that are only for simulation porpoise.

[PedroAntunes178]

Currently, in IOb-SoC-opencryptolinux in the Setup phase the software of the iob-uart is copied. The iob-uart is only used in simulation, therefor the software is not required. It causes conflicts with the iob-uart16550 software. Even after renaming all the iob-uart16550 functions so that these have a different name from the iob-uart functions.

[jjts]

What conflicts? Can you paste the errors here?

[PedroAntunes178]

Renaming the functions so that there is no conflict between the iob-uart and the iob-uart16550 software solves the most relevant problem.
However, since the iob-uart software is included in the sources for compilation, the bootloader.bin is bigger than the default BOOTROM_ADDR_W. That can also be solved by redefining BOOTROM_ADDR_W. Nevertheless, it would be nice if unused software was not present in the build directory.

Could the software sources stop being copied by altering the flow variable of a module? Is there any way to alter a submodule flow variable?

[arturum1]

Currently, it is possible to change the flows attribute of a module, but I don´t think we should do that.
I think most class attributes (including flows) of the modules should be read-only because otherwise it can cause issues with multiple setups. This is because the attributes are only initialized once for each class.
So, if we change the iob-uart attributes when setting up that core for the iob-soc-opencryptolinux system, then that change would persist even if we set up for any other system.

For example, imagine we use this iob-soc-opencryptolinux system as a Tester for the IOb-SoC-SUT system.
This Tester would use the iob-uart16550 and the SUT would use the iob-uart. The SUT needs the iob-uart software sources.
Therefore, if the Tester somehow disabled the emb flow of the flows in the iob-uart, it would also not copy the software sources needed by the SUT.

On the other hand, if the Tester somehow managed to disable the copy of sources for itself and still allowed the SUT to copy from the UART, we would still have this BOOTROM_ADDR_W problem, because the sources would be on the build dir.

[arturum1]

I think the best solution is to prevent the iob-uart software from being included in the sources for compilation.
To do this, we need to create a sw_build.mk file for this system, similar to the one in IOb-SoC, but with an extra filter to filter out the iob-uart sources.

The disadvantage of this is having to maintain this new sw_build.mk file.

[arturum1]

I think the best solution is to prevent the iob-uart software from being included in the sources for compilation. To do this, we need to create a sw_build.mk file for this system, similar to the one in IOb-SoC, but with an extra filter to filter out the iob-uart sources.

The disadvantage of this is having to maintain this new sw_build.mk file.

Another solution, similar to this, would be to create a python script that inserted that filter into the sw_build.mk of the build directory.
With this, we would not have to maintain a new sw_build.mk file in this repository.