-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
enable inference for RAMB36E1 #31
Conversation
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
LUT6 is actually two LUT5s and a MUX. Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Working 7-series carry chains on VPR
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Changes to support 7-series VPR flow
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Correct map entries for some FF's
…f the "synth_xilinx" macro. Updated manual accordingly. Signed-off-by: Maciej Kurc <mkurc@antmicro.com>
…inx" flow accordingly. Signed-off-by: Maciej Kurc <mkurc@antmicro.com>
Signed-off-by: Maciej Kurc <mkurc@antmicro.com>
Signed-off-by: Maciej Kurc <mkurc@antmicro.com>
Signed-off-by: Maciej Kurc <mkurc@antmicro.com>
Signed-off-by: Maciej Kurc <mkurc@antmicro.com>
Update yosys with setundef
Signed-off-by: Maciej Kurc <mkurc@antmicro.com>
Merge WREDUCE fix to Symbiflow branch
Signed-off-by: Maciej Kurc <mkurc@antmicro.com>
…backend Signed-off-by: Maciej Kurc <mkurc@antmicro.com>
Signed-off-by: Maciej Kurc <mkurc@antmicro.com>
…erilog frontend/backend Signed-off-by: Maciej Kurc <mkurc@antmicro.com>
…e JSON backend Signed-off-by: Maciej Kurc <mkurc@antmicro.com>
Signed-off-by: Maciej Kurc <mkurc@antmicro.com>
Support for attributes on parameters in Verilog
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Previous logic was using CO[Y_WIDTH], which is downstream of another MUXCY. Rather than using CO[Y_WIDTH], O[Y_WIDTH] with S[Y_WIDTH] = 0 works just as well. For reference: O[N] = CO[N-1] ^ S[N] So if S[N] = 0, O[N] === CO[N-1], which is the desired state. Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
Update CARRY4 sim model to handle disconnected CIN signal.
Dedicated top of carry pin is sourced from O[Y_WIDTH].
techlibs/xilinx/brams.txt
Outdated
# or_next_if_better | ||
#endmatch | ||
match $__XILINX_RAMB36_TDP | ||
min bits 4096 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should RAMB36 and RAMB18 have the same min bits?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how this value is calculated. Why shouldn't there be less than 4k bits used, if it is otherwise the best match?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to assign a weight or polynomial, or some soft limit, rather than just hard limits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that is what "efficiency" is for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, but it's just the percentage of used bits. For example, may some types of memory use less power or have less delay, or maybe it's better to fill one RAM 90% than use two at 95% efficiency, or one at 100% and one at 50% for a greedy algorithm. I guess you can prioritize them by changing the order, but then they would have to have the same exact efficiency for it to matter.
Anyway, I don't know where the 4k bit minimum comes from, so I didn't modify it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another thing, the 8/16/32 bit modes are weird in that you can waste e.g. 1/9th of the memory and yet have an efficiency of 100% because it's 100% of the available capacity in that mode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another thing, the 8/16/32 bit modes are weird in that you can waste e.g. 1/9th of the memory and yet have an efficiency of 100% because it's 100% of the available capacity in that mode.
A narrower mode is deeper, so efficiency is non-linear.
Signed-off-by: Dusty DeWeese <dustin.deweese@gmail.com>
I'm going to put off adding support for 8/16/32-bit widths for later, since it's not trivial and not needed right now. @litghost What value do you suggest for |
Let's leave it alone. |
Have you tested the relevant circuits in symbiflow? E.g. murax, picosoc and scalable proc? Which of these now instance the larger primitive? |
@HackerFoo Please report hardware testing status for:
|
|
|
Does |
|
No description provided.