Raito_Bezarius has quit [Ping timeout: 255 seconds]
Raito_Bezarius has joined #yosys
nelgau has joined #yosys
oldtopman has quit [Quit: *poof*]
nelgau has quit [Read error: Connection reset by peer]
nelgau has joined #yosys
oldtopman has joined #yosys
<cr1901>
TIL that yosys will turn large case statements into block RAM. This is a great idea and normally desirable. If I want to check resource usage where a block RAM is NOT used, is there an attribute or something I can use to suppress block RAM inference?
<cr1901>
nevermind I got it; case with Default for vast majority suppressed the transformation
ec has quit [Ping timeout: 256 seconds]
ec has joined #yosys
charlottia has joined #yosys
<charlottia>
<cr1901> "TIL that yosys will turn large..." <- yes. set e.g. `ram_style` to `logic`.
<charlottia>
(see memory_libmap.cc around lines 493-531)
<cr1901>
Noted for the future, thanks!
nelgau_ has joined #yosys
nelgau has quit [Ping timeout: 258 seconds]
indy has joined #yosys
FabM has joined #yosys
FabM has joined #yosys
smkz has quit [Ping timeout: 240 seconds]
smkz has joined #yosys
nelgau_ has quit [Read error: Connection reset by peer]
nelgau has joined #yosys
nelgau has quit [Read error: Connection reset by peer]
nelgau_ has joined #yosys
nelgau_ has quit [Ping timeout: 255 seconds]
nelgau has joined #yosys
<jix>
IIRC the `-norom` option to `proc` should prevent it from creating memory cells in the first place which might be closer to what you're asking for than mapping the rom back to logic?
kristianpaul has joined #yosys
nelgau has quit [Read error: Connection reset by peer]
nelgau has joined #yosys
FabM has quit [Ping timeout: 240 seconds]
<cr1901>
jix: Cool, I will have to try that when I have a chance to change the script. I was looking for source-level suggestions b/c they were easy :P
<jix>
I wonder if it makes sense for proc_rom (which does the initial transformation from case statement to ROM) to check if `ram_style` is `logic` and omit it
<jix>
or alternatively a different attribute or a special `ram_style` option ... I can see use cases for both, not creating a ROM in the first place and mapping the ROM back to logic
<jix>
although the difference between those two ways to end up with logic probably doesn't matter much most of the time
<cr1901>
Yea, I can imagine they could end up w/ different results, but not significantly. In any case, I decided to eat the cost of an additional block RAM for now. But being able to check to see if a sparse case can be optimized well in logic with an attribute would be cool
<jix>
If it's sufficiently sparse (less than a quarter of the values are non-default) it shouldn't end up being a rom in the first place
<jix>
and in the case where it's sparse in some other way I think it'd mostly be abc that might be able to optimize it and that runs after it would be mapped back to logic if you use ram_style logic, so that should work the same for both approaches
<cr1901>
I would say about 1/10 of the values are non-default, but the default is 2'b1, and the values don't follow a nice pattern for which is default or not. In this case, the block RAM approach is better. 1/2
<cr1901>
Additionally, all 1024 cases are written out via a Python for-loop (Amaranth-generated Verilog). I don't have code to share right now.
<jix>
cr1901: with 1/10 cases being non-default you end up with a ROM?
<cr1901>
yes
<jix>
hmm maybe that's ambiguous ... with do you have cases for 1/10 of the input values and the rest is handled by a default case or do you have cases for all input values of which 9/10 have the same value?
<cr1901>
latter
<cr1901>
Why? I generated a memory init list in Python initially. I changed from an explicit ROM/Memory to a case/(Switch/Case) in Amaranth. This saved a few resources, _even when proc_rom inferred a BRAM_.
<jix>
ok, in the former case you shouldn't get a ROM, the current heuristic only looks at the number of cases / number of possible values
<cr1901>
FWIW, When I convert to the former case, I don't get a ROM.
<cr1901>
Tbh, I'm a bit surprised that a BRAM is best (in logic, the switch/case takes like 60 SB_LUT4s for some reason I can't be arsed to debug right now). Maybe I'll try minimizing manually.
<jix>
I'm not too familiar with the part that generates logic for case statements, so I might be wrong, but I think it will always generate a comparison for each case and then build a mux tree using those comparisons as selects ... which can handle the general case but is not the best way to implement a rom