Oh, yeah, that’s a bit closer to what I had in mind … :). Thanks for the pointer! (and thanks Clifford!)
You have an awful lot of blocking assignments (=) in your code. I suspect a lot of them should be non-blocking assignments (<=). I suspect this is what is causing you to use so many resources, and arachne-pnr to take so long.
Nice tune, though.
I’ve just been looking into it a bit now - it seems like it’s the “flanger” effect that’s taking the lions share of the resources, and that, in turn, seems to be because its delay-line storage is not being inferred as a block RAM (I’m sure there’s a good reason for that, but I don’t know it at this point)…
I’ve just started trying to rewrite the flanger around a SB_RAM256x16 RAM block - ie. from the SiliconBlue library (the dual-port nature makes it ideal - It allows me to have separate read/write pointers), but it seems like yosys is unable to recognise it:
\SB_RAM256x16' referenced in module\flanger’ in cell `\delay_buffer’ is not part of the design.
After looking at the code here: https://github.com/YosysHQ/yosys/blob/master/techlibs/ice40/cells_sim.v. I wonder whether I need to use a SB_RAM40_4K block instead, and pass in READ_MODE and WRITE_MODE parameters.
Duly noted re: the blocking assignments too. I’m learning more about this as I go, and I’ll probably do an optimisation pass at some point to fix some of the atrocities I’ve been creating.
Yes, I get an explosion of resource usage, when BRAM is not used for memory. At least one case of that was caused by typo where I used a blocking assignment instead of a non-blocking one.
You should not need to use SB_RAM… block. Just put your RAM in a separate module, make sure it uses non-blocking assignments, has inputs for addresses, enable flags and data in, and an output for data out. It sometimes gets turned into registers if one a tiny amount of memory is accessed. It also must only have one write to memory.
There is quite a bit of code that I wrote a few months ago that I need to rewrite. I have been doing this since February when I got my myStorm board.
Hmm… that’s all interesting… I’m sure that I was breaking all of the rules, and I imagine yosys would have had a hell of a time unpicking what I was trying to do.
I’ve just added a commit which uses the SB_RAM block explicitly, and it seems to work okay for me locally… compile times have come way down, and from what I can see it now uses about 4,000 fewer cells, and 4,000 fewer wire-bits… It’s actually very impressive how much stuff you can fit in one of these devices - especially when you don’t abuse the hell out of it
That version builds much much faster.
In my tests I use the schemes suggested in appendix A of this document:
I did not have to instantiate the SB_RAM blocks,
yosys infers under this scheme that BRAM must be used.