Memory initializers are ignored when synthesizing with Diamond

[whitequark]

The memories end up initialized to zero. Diamond complains:

@N:[CG364](https://github.com/amaranth-lang/amaranth/issues/@N:CG364:@XP_HELP) : [top.v(1686)](https://github.com/home/whitequark/Projects/luna/build/top.v:1686:7:1686:15:@N:CG364:@XP_MSG) | Synthesizing module U$$1$31 in library work.
@W:[CG532](https://github.com/amaranth-lang/amaranth/issues/@W:CG532:@XP_HELP) : [top.v(1780)](https://github.com/home/whitequark/Projects/luna/build/top.v:1780:2:1780:9:@W:CG532:@XP_MSG) | Within an initial block, only Verilog force statements and memory $readmemh/$readmemb initialization statements are recognized, and all other content is ignored. Simulation mismatch may occur

[Lunaphied]

This isn't a valid behavior in Verilog correct? So Yosys isn't doing anything wrong by assuming that this is a valid way to initialize memories when translating the RTLIL into Verilog to feed to Diamond for synthesis?

I know that something similar happens with the MLABs on Cyclone devices and that support for $readmem[hb] was needed to support initialized memories on those. I know there was some work on the MLAB support recently so I want to take a look and see of that's been addressed at all.

In the short term this seems annoying to work around at the level that Amaranth works, just out of curiosity can you even directly specify something like $readmem[hb] from the RTLIL level?

[whitequark]

So Yosys isn't doing anything wrong by assuming that this is a valid way to initialize memories when translating the RTLIL into Verilog to feed to Diamond for synthesis?

It's explicitly allowed per IEEE 1364.1:

In the short term this seems annoying to work around at the level that Amaranth works

Yes, though I've done some preparatory work on it in the Yosys Verilog backend already.

just out of curiosity can you even directly specify something like $readmem[hb] from the RTLIL level?

No.