-
Notifications
You must be signed in to change notification settings - Fork 78
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
Symbiflow-classroom:Reset of BRAM Output Register #277
Comments
It seems that Yosys expects the attribute to be |
@mkurc-ant I have attached the synth_log as well as the original .sv file (part of a bigger project). It looks like yosys is not inferring a bram for the inst_memory. As I said in the meeting, our class is stalled due to this bug. If a fix could be found quickly (within a few days) we can get the rest of the clas's riscv processor variations tested through the toolchain before the semester ends in a couple of weeks. If not, we will miss out until next year. So, if there is a way to address it quickly it could help a lot with the testing project. |
@nelsobe Thank you, I'll take a look on that today. |
@nelsobe Let me share my findings: First of all it looks like you are using an outdated Yosys version ( Unfortunately the memory inference does not work with the version currently supposed to be used in symbiflow / f4pga which is Another thing is the attribute. As I mentioned before Yosys expects the So my suggestion is to try the upstream Yosys (there should be a conda package for the latest version available). I'll create a PR which bumps the version in the |
@mkurc-ant - Why is our version of Yosys so old? Isn't it suppose to be auto-updating? |
@mithro I need to confirm that but it may be that the dependabot creates a PR for each new Yosys package and it just can't keep up with the pace they are added. |
@mkurc-ant @tmichalak But, as @mithro pointed out in our meeting last week, in our role as users of the tools (instead of developers) my students (and me) are not privy to the inner details of what pieces/plugins/tarFiles go together to make a full toolchain. As such, our model is to simply reinstall when we are told something has been fixed. To help so we can more intelligently communicate with you on these issues could you quickly answer a couple of questions:
Thanks much! |
@mkurc-ant @tmichalak @mithro |
@mkurc-ant @tmichalak Have confirmed the error has to do with the reset clause, NOT the conditional read clause. Assume, but don't know for sure, that this is a synthesis problem and not a parsing problem and therefore the surelog plugin will not solve this. |
@mkurc-ant @tmichalak Any word on this one? As mentioned above, I have confirmed the error has to do with the reset clause in the code. |
@nelsobe We have checked the issue against Yosys and it looks like the problem is in the memory inference mechanism in Yosys itself. In your design you are using the specific Xilinx feature where the output register of a BRAM can be externally reset to all-zeros. However, memory inference in Yosys is generic, it can infer a BRAM with output register but it is completely unaware of the possibility of resetting that register. This shortcoming results in Yosys not inferring a BRAM in your case because the register following the memory cell is incompatible (has a reset). |
SYMBIFLOW-CLASSROOM-PROJECT
Below is a snippet of code from a riscv design used in our junior level course.
As can be seen, the reading from the BRAM includes a reset condition as well as a conditional read.
When processed by the standard Yosys front end, the inst_memory is not mapped to a BRAM but it seems is mapped to FF's, resulting in a non-functional design (curiously, this seems to cause other sections of the design to simply be optimized away). Removing the conditional read clauses in the code does result in mapping it to a BRAM.
I am guessing this is a BRAM mode not yet supported by Yosys?
The text was updated successfully, but these errors were encountered: