what causes this huge over load of gates

[pm100]

I keep hitting this and make random changes until things go back to normal (my design actually uses 20% of the ice408k). I see other posting bug reports.

after thinking for a long time yosys says

Info:            ICESTORM_LC: 30718/ 7680   399%
Info:           ICESTORM_RAM:     0/   32     0%
Info:                  SB_IO:    24/  256     9%
Info:                  SB_GB:     7/    8    87%
Info:           ICESTORM_PLL:     0/    2     0%
Info:            SB_WARMBOOT:     0/    1     0%
Info: Placed 24 cells based on constraints.
ERROR: Unable to place cell 'hack.ROM[432]_SB_DFFE_Q_DFFLC', no BELs remaining to implement cell type 'ICESTORM_LC'
0 warnings, 1 error
scons: *** [hardware.asc] Error 4294967295

I feel it is something not initialized correctly, or maybe a logic loop. But iverilog usually picks these things up if yosys does not and iverilog doesnt complain at all when I do a sim.

[pm100]

Icecube2 compiles the code fine once I had fixed its complaints about wire and registers being used before they are declared. It reports 10% lut usage.

[nakengelhardt]

Can you share the code? Without any information it's impossible to say what's happening...

[pm100]

I was looking for generl guidance about what might cause it, but sure here is the code https://github.com/pm100/alchrity_cu. its the hack subdir. you will need a submodule update too to pick up m y library

[pm100]

if i comment out shell.v:197 r_Bus_Rd_Data <= w_o_ROM_data; it compiles fine

[KrystalDelusion]

Based just on this I would guess that it is a problem with trying to map the ROM to LUTs. You mentioned that Icecube2 reports 10% lut usage, but what about the other resources?

[pm100]

here is what icecube says

Final Design Statistics
    Number of LUTs      	:	673
    Number of DFFs      	:	334
    Number of DFFs packed to IO	:	0
    Number of Carrys    	:	35
    Number of RAMs      	:	4
    Number of ROMs      	:	0
    Number of IOs       	:	23
    Number of GBIOs     	:	1
    Number of GBs       	:	3
    Number of WarmBoot  	:	0
    Number of PLLs      	:	0
Device Utilization Summary
    LogicCells                  :	673/7680
    PLBs                        :	125/960
    BRAMs                       :	4/32
    IOs and GBIOs               :	24/95
    PLLs                        :	0/2

[KrystalDelusion]

That does indeed look like it is failing to map to the BRAM. Have a look at the documentation for supported memory patterns, there is also a note just above that section on enabling debug outputs and checking what memory_libmap is doing.

[pm100]

Thank you for helping. Still stuck (total noob here so thank you for your patience, I dont even know what sync bs async memory access means - I assume in a clocked always block vs a simple assign?).

Anyway I added

  (* ram_style = "block" *)
  reg [15:0] ROM[0:1000];

fatals -> ERROR: no valid mapping found for memory Shell.hack.ROM

the debug output says

found attribute 'ram_style = block' on memory Shell.hack.ROM, forced mapping to block RAM
Memory Shell.hack.ROM mapping candidates (post-geometry):
Memory Shell.hack.ROM mapping candidates (after post-geometry prune):
Rejected candidates for mapping memory Shell.hack.ROM:
can't map to logic: RAM kind conflicts with attribute
can't map to to $__ICE40_SPRAM_: RAM kind conflicts with attribute
Assigning write ports... (candidate configs: 2)
can't map to option selection [] of port group [R] of $__ICE40_RAM4K_: not a write port
can't map to option selection [] of port group [R] of $__ICE40_RAM4K_: not a write port
Assigning read ports... (candidate configs: 2)
can't map to port group [W] of $__ICE40_RAM4K_: not enough unassigned ports remaining
can't map to option selection [] of port group [R] of $__ICE40_RAM4K_: not an asynchronous read port
can't share write port 0: not a read-write port
can't map to port group [W] of $__ICE40_RAM4K_: not enough unassigned ports remaining
can't map to option selection [] of port group [R] of $__ICE40_RAM4K_: not an asynchronous read port
can't share write port 0: not a read-write port
Handling transparency... (candidate configs: 0)
ERROR: no valid mapping found for memory Shell.hack.ROM

I have no idea what any of that means.

[KrystalDelusion]

I found the issue using this script:

read_verilog system.v cpu.v alu.v
hierarchy -top System
proc
opt
memory -nomap
debug memory_libmap -lib +/ice40/brams.txt -lib +/ice40/spram.txt
techmap -map +/ice40/brams_map.v -map +/ice40/spram_map.v
ice40_braminit
stat System

Saving the script as system.ys and then calling yosys system.ys -l system.log to save the log for inspection. In the MEMORY_DFF section there is a message about no output FF found, which suggests a problem with the way you are trying to read the ROM. Indeed, looking at the code further you have two asynchronous reads in system.v lines 64 and 65, and then a synchronous read on line 101. I believe trying to satisfy both of those cases is what leads to the mapping to logic.

On the memory handling page I linked earlier, I would suggest either following the "Synchronous SDP with clock domain crossing" pattern (which most closely maps to the ICE40, the same clock can be used for both) or the "Asynchronous-read SDP" pattern. As a quick test, I commented out lines 63-65 and changed line 101 to o_bus_ROM_data <= ROM[w_CPU_ROM_addr];, which roughly follows the "Synchronous SDP with clock domain crossing" pattern and the script above reported SB_RAM40_4K 4.

Also as a quick aside, ROM means read-only-memory, so strictly speaking you shouldn't be trying to write to a ROM :)

[pm100]

Thank you , yes I have delved a whole lot deeper, and am now using the ice40 native primitive SB_RAM40_4K. Learning fast but I have a long way to go. Now understanding the whole process of high level verilog getting turned into device/vendor specific stuff etc.

Re writing to ROM. FYI this is an implementation of the Hack system built in the excellent 'the elements of computing systems' aka 'from nand to tetris'. The simple CPU built there has RAM and ROM. But you need to be able to load the ROM. The cpu only runs code from the ROM but has no way of writing to it. My 'shell' is like a mini gdb, read / write ROM, go, will add read/write RAM, single step etc.

This is my first non trivial fpga project (and I know its trivial in real life, but compared to the tutorials noobs get its fairly large)

My main frustration is that I know so little (very very experienced sw dev) and its hard to find resources beyond the simple things. Even your few small pointers helped a lot, pointed me in the right direction.