Initial values, memories, and Yosys

Hi all,

First off, thanks for creating and sustaining MyHDL! It is a fantastic tool, and I have thoroughly enjoyed using it.

I have a question, and I suspect that as I am new to MyHDL and FPGA development, the error may lie in my use of the tools as opposed to a bug. The issue is the following:

  1. I believe it is often the case that we want to pre-initialize BRAMs with some predetermined values. This is generally done with the initial syntax in Verilog, and via toVerilog.initial_values = True support in MyHDL.
  2. When I enable initial value support on MyHDL, it wants to initialize the output of the data register for the BRAM.
  3. Yosys then decides that since the output of the RAM has an initial value that it is incompatible with the BRAM model, and pushes the entire memory out of BRAMs.

Here is a sample test case:

def case_for_test(clock, reset, values):
    addr = Signal(intbv(0)[4:])
    data = Signal(intbv(0)[8:])
    ram = [Signal(intbv(x)[8:]) for x in range(16)]
    cnt = Signal(modbv(0, min=0, max=16))
    we = Signal(bool(0))

    def rom():
        if we:
            ram[addr].next = 0
   = ram[addr]

    @always_seq(clock.posedge, reset=reset)
    def cycle(): = cnt + 1 = cnt = data

    return instances()

I had to add the unused we line to convince MyHDL that the memory was driven (so that initial values made it to the output). Here is the generated Verilog

// File: ../gen/case_for_test.v
// Generated by MyHDL 0.11
// Date: Mon Oct 14 11:43:58 2019

`timescale 1ns/10ps

module case_for_test (

input clock;
input reset;
output [7:0] values;
reg [7:0] values;

reg [3:0] addr = 0;
reg [3:0] cnt = 0;
reg [7:0] data = 0;
wire we;
reg [7:0] ram [0:16-1];
initial begin
    ram[0] <= 0;
    ram[1] <= 1;
    ram[2] <= 2;
    ram[3] <= 3;
    ram[4] <= 4;
    ram[5] <= 5;
    ram[6] <= 6;
    ram[7] <= 7;
    ram[8] <= 8;
    ram[9] <= 9;
    ram[10] <= 10;
    ram[11] <= 11;
    ram[12] <= 12;
    ram[13] <= 13;
    ram[14] <= 14;
    ram[15] <= 15;

assign we = 1'd0;

always @(posedge clock) begin: CASE_FOR_TEST_ROM
    if (we) begin
        ram[addr] <= 0;
    else begin
        data <= ram[addr];

always @(posedge clock, negedge reset) begin: CASE_FOR_TEST_CYCLE
    if (reset == 0) begin
        cnt <= 0;
        addr <= 0;
        values <= 0;
    else begin
        cnt <= (cnt + 1);
        addr <= cnt;
        values <= data;


The heartburn is from this line:

reg [7:0] data = 0;

The Yosys synthesis pass claims:

Checking rule #1 for bram type __ICE40_RAM4K_M0 (variant 1): Bram geometry: abits=8 dbits=16 wports=0 rports=0 Estimated number of duplicates for more read ports: dups=1 Metrics for __ICE40_RAM4K_M0: awaste=240 dwaste=8 bwaste=3968 waste=3968 efficiency=3
Rule #1 for bram type __ICE40_RAM4K_M0 (variant 1) accepted. Mapping to bram type __ICE40_RAM4K_M0 (variant 1):
Read port #0 is in clock domain !~async~.
Bram port A1.1 has incompatible clock type.
Failed to map read port #0.
Mapping to bram type $__ICE40_RAM4K_M0 failed.

And the complaint about the read port being in the async clock domain appears linked to its initial value. If I remove that initial value, I get the following:

Number of cells: 24
SB_RAM40_4K 1

And the BRAM is correctly synthesized.

Any suggestions/advice on how to proceed? I can’t imagine I’m the first one to encounter this issue, but searching has so far been unhelpful.



Synthesis tools require specific coding to detect RAM, ROM, dual RAM…
You have to refer to the synthesis documentation and code accordingly.
The we signal might be required by your tool to instantiate BRAM correctly.


Is it a really small BRAM? It strikes me that initialised values for BRAM is a slightly strange concept. That said, I can see when it might be useful when the RAM is really just a small holding area, in which case a solution is to use a block to load the RAM from a ROM - it can be an initial state which just loads RAM and then permanently exits.

It’s rather application specific as to what the best strategy might be.