<d1b2>
<garbile> Came across this comment in a guide from June 2020. Anyone know the current state of this? > There also isn’t much RAM available, because the yosys tooling is currently unable to use the 128KB of “single-port RAM” in an iCE40UP5K. That will probably be addressed in future versions, but at the time of writing, I think that a vanilla nMigen design can only use the smaller “block RAMs” for Memory objects.
<cr1901>
You can use the 128kB of single-port RAM, but you have to instantiate it yourself manually using a "SB_SP128K" )(sp?) primitive
<cr1901>
SB_SPRAM256KA*
<d1b2>
<garbile> any examples of that? I don't see anything after a quick search
<d1b2>
<garbile> I've done it in Verilog, but I don't know the syntax in nmigen
<whitequark>
garbile: the Yosys tooling should be able to use SPRAM soon-ish
<whitequark>
not in the sense of any specific timescale, but in the sense that that part of Yosys is being actively worked on
<mwk>
hmm
<mwk>
there is one potential problem here
<mwk>
whitequark: how many SPRAMs are there per chip?
<mwk>
if it's something like "zero or one", we'd also need some infrastructure for resource limits to reasonably use it
<mwk>
and that's not yet on the agenda
<mwk>
though I suppose a Memory with a custom manual attribute that says "map this as SPRAM" could be a useful solution in the meantime that is better than "use Instance"
<mwk>
and that *is* on the agenda
<d1b2>
<bob_twinkles> there's 4 SPRAMs on the UP5k
<mwk>
and on other chips?
<mwk>
4 is... little, would still need to be carful with infering them without resource limit information
<d1b2>
<bob_twinkles> none in the ultralite devices, 4 in all the ultrapluses assuming I can read datasheets
<d1b2>
<bob_twinkles> ECP5s seem to have only blockrams as well?
<mwk>
... also I should probably actually take a look at the SPRAM, I didn't take it into account when designing the whole thing, should probably make sure it matches the architecture
<mwk>
wtf, they have two different primitives with different port names for icecube2 vs radiant? hilarious
<d1b2>
<bob_twinkles> oh huh, didn't notice that when I was working with these. I think yosys/icestorm uses icecube2 names
<mwk>
and there's also "hw port name" in the document, which is DIFFERENT FROM BOTH
<d1b2>
<bob_twinkles> yeah there's some fixed logic in front of the actual memory block and for some reason they felt the need to explain in detail what that logic does?
<mwk>
"the hardware port WEM allows write mask for individual bits of DATAIN; for external user primitive level, this mask is available for each nibble (4-bits)" WHAT
<d1b2>
<bob_twinkles> ¯_(ツ)_/¯
<mwk>
does this mean the hw actually has independent bits, but the primitives don't expose them for some reason? or is it really describing some fixed in-hw wrapper that cannot just be removed?
<d1b2>
<bob_twinkles> AFAIK the latter, this was confusing someone in #icebreaker on the 1b2 discord a day or two ago
<d1b2>
<bob_twinkles> why they felt the need to describe that in detail rather than just declare it a 4 bit wide port I'm not sure
<mwk>
... okay this documentation is absolutely terrible
<mwk>
it doesn't explain how the read data latch works, for one
<sorear>
what I've heard is that it's a poorly abstracted and whitelabeled synopsys ram macro
<mwk>
... it's one of those "your documentation sucks, please give me a sim model instead" days
<mwk>
I'd have to download icecube2/radiant for that, wouldn't I
<mwk>
I mean, that thing looks dead simple; whatever the read semantics are, it sounds like something that the upcoming memory inference pass will be able to handle
<mwk>
I'm just not sure *which* kind of dead simple it is
<d1b2>
<bob_twinkles> you gotta be careful with the sim model too, as there are some particular requirements around deasserting ~POWERON until you can release the reset/operate with it
<d1b2>
<bob_twinkles> and those aren't captured by the logic sim
<mwk>
... what reset, this thing doesn't *have* a reset
<d1b2>
<bob_twinkles> STANDBY/SLEEP sorry
<mwk>
right, of course
<mwk>
whitequark: oh, one problem with this primitive is that it doesn't seem to have initialization capabilities; isn't that something that nMigen doesn't support?
<mwk>
as in, if the yosys mem inference pass gets a memory where initial contents is not all-x, it'll definitely have to reject the SPRAM as a possible match
<whitequark>
mwk: yes, and that's something that there is an open nmigen issue for
<whitequark>
in the meantime you could fix this with a... synthesis override command, i think