Block ram reads within ~36 cycles of device reset always return 0, but only on the first reset after device reconfiguration.

[aappleby]

This repros on an ICE40-HX8K breakout board using Icestorm tools built from head as of a week or so ago. The board is in "sram" mode, and I'm flashing it using "iceprog -S ..."

To repro -

1. Flash the board with some placeholder config, I use this one -

module placeholder(input clk_in, output reg [7:0] out_debug, output reg out_trap);
assign out_debug = 8'b10101010;
endmodule

2. Flash the board with this config, which reads from a blockram shortly after device reset and displays the result of the read on the board's LEDs -

module blockram_bug(input clk, output reg [7:0] out_debug);

reg [31:0] memory[0:127];
initial begin
  memory[0] = 32'hFFFFFFFF;
  memory[1] = 32'hFFFFFFFF;
  memory[2] = 32'hFFFFFFFF;
  memory[3] = 32'hFFFFFFFF;
  memory[4] = 32'hFFFFFFFF;
  memory[5] = 32'hFFFFFFFF;
  memory[6] = 32'hFFFFFFFF;
  memory[7] = 32'hFFFFFFFF;
end

reg [25:0] count = 0;
reg [31:0] mem_raddr = 32'hFFFFFFFF;

always @(posedge clk) begin
  if (count == 0) begin
    mem_raddr <= 7;
    out_debug <= 32'hFFFFFFFF;
  end

  if (count == 36) begin
    out_debug <= memory[mem_raddr];
  end

  count <= count + 1;
end

endmodule

If the bug does not repro, the LEDs will light up immediately. If the bug does repro, the LEDs should be off for ~5 seconds until the counter rolls over, then they should light up. Changing the "if (count == 36)" to 37 or higher will cause the bug to not repro.

3. Flash the board a second time with the same .bin from step 2. The bug should not repro (LEDs light up immediately).

4. Flash the board with the placeholder again, then flash with blockram_bug. The bug should repro again.

[aappleby]

Forgot the relevant .pcf that maps out_debug to the LEDs on the breakout board -

set_io clk_in J3
set_io --warn-no-port out_debug[0] B5
set_io --warn-no-port out_debug[1] B4
set_io --warn-no-port out_debug[2] A2
set_io --warn-no-port out_debug[3] A1
set_io --warn-no-port out_debug[4] C5
set_io --warn-no-port out_debug[5] C4
set_io --warn-no-port out_debug[6] B3
set_io --warn-no-port out_debug[7] C3

[cliffordwolf]

This is a hardware issue with iCE40 block rams. There is nothing the software tool-chain can do about it. You simply have to take this into consideration when creating your HDL designs.

Here is another demo for this issue:
http://svn.clifford.at/handicraft/2017/ice40bramdelay

You can synthesize this demo with Lattice iCEcube2 as well and you will observe the same issue. (But you will have to use LSE and set the "Propagate Constants" option to False, otherwise it will incorrectly optimize away the entire design. This is because the Lattice tools don't not really understand register initialization, so they think everything is undefined if there is no external reset signal.)