-
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
tests: add murax test #17
Conversation
I'll look at the Murax issue, that PR significantly improved performance for Nexus and I suspect the increase for interchange is a latent issue of some kind (probably very poor lookahead). |
With @gatecat's fix to the bounding box (YosysHQ/nextpnr#702) and the workarounds listed below we got to a Murax design working on HW. Remaining workarounds to solve:
|
tests/murax/run.tcl
Outdated
read_verilog $src | ||
} | ||
|
||
synth_xilinx -flatten -nolutram -nowidelut -nosrl -nocarry -nodsp |
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.
Perhaps these flags should be located somewhere other than the individual tests? So that as we support more features, we don't have to update all the tests.
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.
Yes, definetely, I'd actually say that the whole run.tcl
file might end up in the common
directory
As you mentioned in the other issue, supporting carry chains will also make a big impact on Fmax, possibly almost as significant as adding proper timing data. |
Signed-off-by: Alessandro Comodi <[email protected]>
Also add synth and pnr logs Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
This PR requires a new conda package with the fixes for the illegal tile PIPs. The murax design was locally tested and pushed to work at 50MHz. |
tests/murax/Murax.v
Outdated
@@ -1,7 +1,14 @@ | |||
// Copyright (C) 2021 The Symbiflow Authors. |
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.
ianal, but I'm not convinced this copyright header is correct - any copyright applying to this would be a derivative of VexRiscv/Murax's copyright. But probably the license checker should just have a way of skipping generated files, so we don't have to remember to patch on a copyright header if updating 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.
Yeah, this was not intended to get checked in, but to get CI past the error. Actually, given that kokoro does not perform the license checking, I can just remove this commit, as I wanted to double-check that everything is all right in CI as well. But yeah, the license checker should avoid generated files to get checked.
the Murax design was successful, with no errors generated during bitstream generation. The bitstream runs on HW@50MHz. There is a known issue though on the FASM generation which affects the |
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
@mithro Given that the actions check fix might take a while to land, I opted to get to use the same strategy as in tool perf to check-in generated data. Does this look good? |
@acomodi All third_party code should be under the third_party directory, no exceptions.... |
Signed-off-by: Alessandro Comodi [email protected]
This adds the Murax test design.
TODO:
cc @gatecat: for the routing run-time increase (which is pretty substantial) I have isolated the problem being in the changes added with this PR: YosysHQ/nextpnr#697. It is still unclear to me what might have caused a spike in the murax routing times, but reverting those changes resulted in router time to go back to "normal"