-
Notifications
You must be signed in to change notification settings - Fork 11
Use URAMs on F1 #230
Comments
A single SRAM may take more than 1 URAM, but other than that yep this should work. Are there any downsides to using a URAM over an SRAM (e.g. not dual ported, higher latency, etc.)? |
Latency should be the same (1-cycle), and URAMs are dual ported. However, the width of URAM ports is twice the width of BRAMs (72 bits), and this cannot be configured to operate as a smaller width. In other words, we do not get more depth with URAM if we use a narrower width, unlike BRAMs. This means that without fixing #231 , URAM usage will be quite inefficient for narrower data types. |
Also David, the case of 1 SRAM being >1 URAM may be a bit complicated since URAMs can be cascaded to implement bigger URAMs. However, enabling cascading reduces the number of URAMs available: If cascading is not enabled, and something > 4096 words is given a uram directive, I'm not sure if this will:
If case 1 or 2 it should be ok but if 3 then we might want to omit SRAMs > 4096 from this URAM list. But I think for now we can just assume 1 SRAM per URAM and handle this more complicated case later? Also, as Raghu said 4096 is the depth without packing into the 72-bit word width (#231), so it might actually be 8k or 16k words. This might be larger than anything we ever need so cascading may not be necessary. |
Ah interesting, thanks for pointing this out. In that case, if I see a bank larger than 4096 words I won't include it in the URAM candidate list for now. This doesn't happen extremely often in practice, so this simple solution should work ok for now. |
Do we have the metadata yet that tells me if I should uramify a memory? |
Not yet - will be adding it today |
The F1 has UltraRAMs which can be used for larger SRAMs. However, SRAMs need to be explicitly assigned to URAMs using the following syntax:
(* ram_style = "ultra" *) reg [DWIDTH-1:0] mem [0:WORDS-1];
One way to do this is to have an analysis pass which:
E.g. this can be done by storing the size of the 800th largest SRAM and then in code generation using a different template for SRAMs larger than that.
The text was updated successfully, but these errors were encountered: