[hw] Split DV and DD for lowRISC vendored IPs

[martin-velay]

This would allow us to pull in the upstream DV files while maintmaining the DD files in the same state as before. This is needed as some RTL changes are not desired while we need to get latest DV changes from upstream. This will work until the DV diverge from the DD. Then, another solution will be needed to keep the DV and DD in sync (maybe cherry- picking individual changes in an OpenTitan fork dedicated to Mocha which will be manually maintained for Mocha needs).

[martin-velay]

All looks good now:

dvsim hw/top_chip/dv/mocha_sim_cfgs.hjson -i smoke --reseed 1
...
|                                              Name                                               |  Passing  |  Total  |  Pass Rate  |  Coverage  |
|:-----------------------------------------------------------------------------------------------:|:---------:|:-------:|:-----------:|:----------:|
|                     [UART](scratch/split_dd_dv_opentitan/reports/uart.html)                     |     3     |    3    |  100.00 %   |     --     |
|            [SPI_DEVICE_2P](scratch/split_dd_dv_opentitan/reports/spi_device_2p.html)            |     3     |    3    |  100.00 %   |     --     |
|                 [SPI_HOST](scratch/split_dd_dv_opentitan/reports/spi_host.html)                 |     3     |    3    |  100.00 %   |     --     |
|                 [RV_TIMER](scratch/split_dd_dv_opentitan/reports/rv_timer.html)                 |     3     |    3    |  100.00 %   |     --     |
|               [PRIM_ALERT](scratch/split_dd_dv_opentitan/reports/prim_alert.html)               |     2     |    2    |  100.00 %   |     --     |
|                 [PRIM_ESC](scratch/split_dd_dv_opentitan/reports/prim_esc.html)                 |     1     |    1    |  100.00 %   |     --     |
|                [PRIM_LFSR](scratch/split_dd_dv_opentitan/reports/prim_lfsr.html)                |     2     |    2    |  100.00 %   |     --     |
|   [ENTROPY_SRC_RNG_16BITS](scratch/split_dd_dv_opentitan/reports/entropy_src_rng_16bits.html)   |     3     |    3    |  100.00 %   |     --     |
|                      [I2C](scratch/split_dd_dv_opentitan/reports/i2c.html)                      |     3     |    3    |  100.00 %   |     --     |
|            [KMAC_UNMASKED](scratch/split_dd_dv_opentitan/reports/kmac_unmasked.html)            |     3     |    3    |  100.00 %   |     --     |
|                [XBAR_PERI](scratch/split_dd_dv_opentitan/reports/xbar_peri.html)                |     1     |    1    |  100.00 %   |     --     |
|                     [GPIO](scratch/split_dd_dv_opentitan/reports/gpio.html)                     |     4     |    4    |  100.00 %   |     --     |
|                   [PWRMGR](scratch/split_dd_dv_opentitan/reports/pwrmgr.html)                   |     3     |    3    |  100.00 %   |     --     |
|                   [RSTMGR](scratch/split_dd_dv_opentitan/reports/rstmgr.html)                   |     3     |    3    |  100.00 %   |     --     |
|            [ROM_CTRL_32KB](scratch/split_dd_dv_opentitan/reports/rom_ctrl_32kb.html)            |     3     |    3    |  100.00 %   |     --     |
| [RV_DM_USE_JTAG_INTERFACE](scratch/split_dd_dv_opentitan/reports/rv_dm_use_jtag_interface.html) |     0     |    7    |   0.00 %    |     --     |
|            [TOP_MOCHA_SIM](scratch/split_dd_dv_opentitan/reports/top_mocha_sim.html)            |    30     |   34    |   88.24 %   |     --     |

[tchilikov-semify]

Regarding the ordering of dependencies: I checked this with Claude and I think now if we vendor the DD enviornment alone, it will remove the dv vendor. Is this constraint acceptable here, or should we add some glue logic to the scripts?

[martin-velay]

I think we could still re-run the DV vendor script even if we don't update the Git hash version, just to get the files back. WDYT? Maybe you have a cleaner solution in mind?

[tchilikov-semify]

I think that's fine. We could technically exclude the the DD script from touching the DV directories on deletion, but this would be extra effort for limited returns. Maybe better to stay pragmatic.