You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 20, 2024. It is now read-only.
In person discussion notes:
Yes this is a reasonable constraint that we probably haven't encountered before because most compilers support a more reasonable minimum size such that anything smaller should be in flops anyways.
We should add support for using the larger size and wasting the bits.
In addition we should add the ability for the compiler to upgrade the number of ports, and tie them off to obtain different sizes.
This would also require an update to the cost model such that the number of ports is reflected.
This would allow a 32x128 single port request to be mapped to either the minimum size single port library, for example 32x512, or at a cost of 1.X times per memory a smaller dual port library, for example 32x128.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
While compile to SRAMs for some technology, I believe I encountered a bug. Here is the test case:
-n <my conf file> -l <my sram-compiler.json> -u
(output options omitted)I'm unsure if this also affects >1-port memories because my technology has much smaller min depth for register files.
Possibly related to #44 and #47?
The text was updated successfully, but these errors were encountered: