Hi folks, sorry if it has been discussed already, ...
# openram
t
Hi folks, sorry if it has been discussed already, but may I ask, if it planned to have smaller SRAMs as well for processor register files for instance ? If so, will they have most likely the same 1.5 cycle latency as well, or is there a chance to build faster ones ? Thanks for your answer in advance. Cheers Tobias
m
The current memories have 1 cycle latency...
t
Thanks for your reply, but is it planned to have smaller SRAMs as well ?
m
It is a compiler, so we can make almost any size (given some restrictions). What size are you thinking? Too small and it may be more efficient to use flip flops
t
Sure, its a compiler, but integrating the reference SRAMs worked like a charm. Guess I have to try the compiler. It’ll be a bloody Christmas. Regarding size, I guess it has been discussed here on slack quite a bit already, since many user implement a processor. The register file (e.g. 32x32) is always a classical example for a FF-macro trade-off. But thinking of it again I guess there are also other arguments. I understand that the flow still has issues with SDFs from macros (e.g. SRAMs) and paths to/from macros are probably (therefore) not considered during timing optimizations, I guess it is fair to say, that you are better off with FF for processor register files at the moment. At least that would save my Cristmas. It would probably be nice to have a pre-qualified RF size SRAM with 0.5 cycle latency in the future #JustSayingForAFriend. Thanks a lot, Cheers, Tobias
m
@User we will add a 32x32 dual port. I'm not aware of all the discussions... Making a half cycle access will require a different circuit and won't be possible with the current compiler, however. Your best alternative would be to halve the clock and double clock the SRAM.
t
Sounds awesome, is 1w2r possible on this technology ?
m
No that's not possible at this time.
That is getting into register file territory and needs more work.