[dv] Backdoor loading of scrambled memories from a Verilator simulation

I'm in the process of adding scrambling to the OTBN memories and started looking at how to support backdoor memory loading. We already have support for backdoor loading with scrambling via mem_blkdir_if (https://github.com/lowRISC/opentitan/tree/master/hw/dv/sv/mem_bkdr_if) however it's been written to work with the DV UVM environment and can't be directly used by Verilator simulations.

The OTBN UVM testbench could use mem_blkdir_if though it's currently using memutil (https://github.com/lowRISC/opentitan/tree/master/hw/dv/verilator) to do backdoor loading which supports ELF loading and provides some consistency between the verilator and UVM testbenches as they can both use the same code.

We could just not scramble memories in the OTBN verilator or UVM testbench or switch the UVM one to use mem_blkdir_if but then we need a new elf loading solution. Plus our top-level earlgrey verilator will also need a way to load scrambled memories. So I think we need a Verilator solution for backdoor loading of scrambled memories.

We do have a C implementation of the PRINCE primitive, but we need a few extra bits on top of it, specifically the extra diffusion layers that do some substitutions and permutations. This is all available in sram_scrambler_pkg which doesn't include extra DV/UVM environment stuff so could be built in a Verilator sim using DPI to export the top level encrypt/decrypt methods though sadly Verilator doesn't build it, there's some internal issues around the use of dynamic arrays.

What's the best way forward?

• Submit a Verilator bug report to get issues fixed
  • I will do this whatever, it's more a question of whether we'll get a fix that works for our purposes in good time
  • Have yet to look into it in detail, these are certainly the kinds of features Verilator doesn't claim to have great support for so a fix could take a while or they'll be unwilling to fix in the short term if it's complex and eventually getting dealt with by the extra support Verilator is getting to allow use of UVM
• Rewrite sram_scrambler_pkg to build with Verilator (probably dropping all use of dynamic arrays)
• Implement functionality from sram_scrambler_pkg in C
  • Could drop sram_scrambler_pkg in SV form altogether and have both mem_blkdir_if and memutil use it
• Drop backdoor loading support from Verilator sims
  • Not a big deal for the OTBN testbench, more problematic for the top-level earlgrey simulation

I might tend towards an implementation of sram_scrambler_pkg in C that everything uses. Otherwise it's a bit messy from the verilator side, DPI call to SV which in turn DPI calls into another C library.