prjxray
prjxray copied to clipboard
f4pga
MUXF8 vivado compatibility
A number of fuzzers (and associated minitests) work on Vivado 2017.2 but are broken on Vivado 2017.3. A quick analysis shows its related to MUXF8.
Added some additional info to a minitest: https://github.com/SymbiFlow/prjxray/pull/19
The fundamental issue is likely that I'm abusing LUT6_2 in a way that worked in Vivado 2017.2 but not later. MUXF7 and MUXF8 are intended to be used to create very large LUTs by combining multiple LUT6s. Theoretically you could use this to create LUT6 or LUT7 from a LUT5 of a LUT6_2, but its of questionable merit and likely untested. So the fuzzers should be rewritten to switch between LUT6 and LUT6_2 as needed instead of using LUT6_2 exclusively. The current strategy was chosen as it nearly fully populates the CLB and only tweaks things were needed. So if this is changed it may lead to some aliasing, but this should be solvable.
More recent Vivado versions have more severe issues like renaming ports on LUT6_2. Given this and other minor changes that will cause a lot of maintenance issues without a huge impact on the success of this project, I'm going to declare this "won't fix" until we have a more specific reason to fix this.
@JohnDMcMaster We should have a more generic issue about making the fuzzers work with newer versions of Vivado?
I'm saying that I don't think its worth the effort. The return on investment is not good
Just if anyone looks at this in the future. It also looks like the newest Vivado (2018.02) doesn't like some of the things we are doing with LUTs.
ERROR: [Opt 31-67] Problem: A LUT6 cell in the design is missing a connection on input pin I0, which is used by the LUT equation. This pin has either been left unconnected in the design or the connection was removed due to the trimming of unused logic. The LUT cell name is: roi/dos[0].lut.
Resolution: Please review the preceding OPT INFO messages that detail what has been trimmed in the design to determine if the removal of unused logic is causing this error. If opt_design is being specified directly, it will need to be rerun with opt_design -verbose to generate detailed INFO messages about trimming.
Right. Before it was a recommendation now it's a requirement. We should fail maybe during settings.sh if a non complaint version is tried
On Fri, Jan 4, 2019, 9:21 AM Tim Ansell <[email protected] wrote:
Just if anyone looks at this in the future. It also looks like the newest Vivado (2018.02) doesn't like some of the things we are doing with LUTs.
ERROR: [Opt 31-67] Problem: A LUT6 cell in the design is missing a connection on input pin I0, which is used by the LUT equation. This pin has either been left unconnected in the design or the connection was removed due to the trimming of unused logic. The LUT cell name is: roi/dos[0].lut. Resolution: Please review the preceding OPT INFO messages that detail what has been trimmed in the design to determine if the removal of unused logic is causing this error. If opt_design is being specified directly, it will need to be rerun with opt_design -verbose to generate detailed INFO messages about trimming.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SymbiFlow/prjxray/issues/14#issuecomment-451381414, or mute the thread https://github.com/notifications/unsubscribe-auth/AANj21bpiMQlOhH1wOW0LPwnbJjORgV1ks5u_w8JgaJpZM4RLVMT .
Vivado 2017.2 is no longer even available for download. Could you please reconsider planning a fix for this issue? Especially with @daveshah1 's nextpnr-xilinx dependence on prjxray (which probably should not even be affected by the MUXF8 compatibility?)
@kammoh 2017.2 is available in the archive @ https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/vivado-design-tools/archive.html
Vivado HLx 2017.2: WebPACK and Editions - Windows Self Extracting Web Installer Vivado HLx 2017.2: WebPACK and Editions - Windows Self Extracting Web Installer (EXE - 51.59 MB)
MD5 SUM Value : c0f1f42b33a39957d85b0d4548717f80
Vivado HLx 2017.2: WebPACK and Editions - Linux Self Extracting Web Installer (BIN - 85.24 MB)
MD5 SUM Value : eaee62b9dd33d97955dd77694ed1ba20
Vivado HLx 2017.2: All OS installer Single-File Download (TAR/GZIP - 22.13 GB)
MD5 SUM Value : 958f190a089ad3f39d327d972c7dcf35
We would welcome someone fixing the problem but it isn't a high priority for the current contributors.
Vivado - Embedded Development - SDx Development Environments - ISE - Device Models - CAE Vendor Libraries
Also, there is pre-built output from this repo at https://github.com/SymbiFlow/prjxray-db
GitHub
Project X-Ray Database: XC7 Series. Contribute to SymbiFlow/prjxray-db development by creating an account on GitHub.
Just curious, can we delete the following instructions on the quick start page now? It appears to me that this issue has been addressed.
Why 2017.2? Currently the fuzzers only work on 2017.2, see Issue #14 on prjxray.
Is 2017.2 really required? Yes, only 2017.2 works. Until Issue #14 is solved, only 2017.2 works and will be supported.
@nalzok -- I'm not sure why this issue ended up getting closed -- I don't believe the MUXF8 issue has been solved in the latest Vivado versions?
why not define a custom LUT6_2 module that overrides the vivado module.
the problem seems to originate in the unisim transformations that automatically create a LUT5 and LUT6 for the LUT6_2 during synthesis. do this mapping manually and there is no problem with placement of the muxf8.
Hi,
There are several concerns about sticking to Vivado 2017.2:
- availability of that particular release
- impact on system libs necessary to have it still running in near future
- support of newer fpga references Willingly or not, support of Vivado > 2017.2 will have to come.
For the sake of adding support of new chips references, it should be better to fuzz based on a slightly reduced set slice configs, than to forbid even trying that for reasons that are after all relatively tiny.
Three issues have been mentioned in this discussion. Can I propose some candidate solutions and workarounds ?
- The original muxf8 issue: Would it be acceptable to add a small check in the fuzzers ? Only used for Vivado version > 2017.2, it would just check if muxf8 usage is acceptable for Vivado, and reject the generated design if not acceptable. Or, more generic behavior even though it would waste more computer time : in case Vivado crashes with error, just disregard that generated design and continue fuzzing.
- The LUT input reordering : Vivado can be prevented to do that with an attribute on the LUT, such as DONT_TOUCH
- The LUT input optimization when constant-driven : Similarly, attributes DONT_TOUCH should fix that behavior, but just in case I would recommend placing KEEP and DONT_TOUCH attribute on all primitives generated by the fuzzers. Just to keep in control of the design structure between before and after Vivado.
@marzoul - Someone needs to do the work to make sure that a stable prjxray-db can be produced on a newer version. If someone does that we can probably move everything to use a newer version.
@mithro - What is the indication of muxf8 failure? Is there a specific error expected?
Just if anyone looks at this in the future. It also looks like the newest Vivado (2018.02) doesn't like some of the things we are doing with LUTs.
ERROR: [Opt 31-67] Problem: A LUT6 cell in the design is missing a connection on input pin I0, which is used by the LUT equation. This pin has either been left unconnected in the design or the connection was removed due to the trimming of unused logic. The LUT cell name is: roi/dos[0].lut.
I was recently doing some testing related to #1794 using Vivado 2021.1 (running only fuzzers for xc7k325) and I did not observe any errors similar to what is shown above. What other clues might exist for the muxf8 issue or could it not appear until very late in the fuzzing process?
why not define a custom LUT6_2 module that overrides the vivado module.
the problem seems to originate in the unisim transformations that automatically create a LUT5 and LUT6 for the LUT6_2 during synthesis. do this mapping manually and there is no problem with placement of the muxf8.
This seems like a clever / clean solution @bunker-bunk567 , any chance you can elaborate a bit more on how to do this?
i am backpaddling on that statement. i looked at the problem a bit longer and ran into obstacles. my memory is fading, but i think i came to the conclusion that it might be best to not have a test that requires 6 inputs and 2 outputs at the same time. a 5-input/2-output and a 6-input/1-output set of separate tests should have identical coverage.
maybe there is a way to work around it, but vivado was stubborn with great endurance about this. i threw maybe half a dozen tricks at the problem and all failed.