Including automatic svh generation in build

[timsaxe]

utils/ioscript does multiple things:

1. reads rtl/../data/*.csv and produces .md files for documentation -- this is accessed with a 'make' in docs/
2. reads rtl/../data/*.csv and produces .h files for software -- I think there should be a sw/ folder parallel to /docs with a make for this
3. read rtl/../data/*.csv and produces .svh files for simulation/emulation/synthesis -- ???
4. reads pintable.csv and produces .sv and .svh files for simulation/emulation/synthesis -- ???

My question is how we want to handle the last two cases. If we used make, then that would handle running ioscript if the pintable or pulp_soc_defines.sv were updated. But the current scheme uses ./generate_scripts instead of make.

One option would be to modify the generated scripts to invoke ioscript so that there is no issue of stale files. ioscript is pretty fast, so I don't think this would be onerous. The drawback to this approach is that the changes have to be introduced into each script -- verilator/questa/xilinx/synopsys etc.

Another option is to incorporate this in the top-level make. A drawback to this is that the current methodology doesn't recommend using the top-level make.

A final question is what happens if we switch to fusesoc, and therefore what would be most compatible.

[timsaxe]

@zarubaf @gmartin102 Can I get your suggestions on the above? If I get some free time I will explore the script option today.

[zarubaf]

In fusesoc we would already have a solution for this, it supports generate targets and it generates the files into a build dir which is unique for the given target, but we are not there yet, unfortunately (especially for synthesis) and I think we shouldn't create a dependency on this feature.

Would it be a viable path to switch to make for the moment? We could call the io script and the ./generate_scipts within the make target for the specific target. I think it would still be a stop-gap solution as I can see it going wrong in a number of places :-/ I am not really attached to the current flow :-)

[MikeOpenHWGroup]

Hi @timsaxe, what is the status of this issue?