UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor drwmj12
Visitor
312 Views
Registered: ‎06-14-2018

Problem with Vivado HLS 2018.3

I recently installed Vivado 2018.3 and have a problem that hasn't occurred on any previous HLS version (back to 2016.4).  All other versions synthesize and pass a verification testbench.

When I try to synthesize with 2018.3, I get the following error message three times, and then synthesis stops because of a "broken module" :

PHINode should have one entry for each predecessor of its parent basic block!

There isn't much diagnostic information for this, but my best guess is that it has to do with a switch statement that has multiple case statements assigned to the same code (that is, fewer basic blocks in the switch statement than there are cases).  This is very common and allowed in C++, so I'm not sure why this problem was introduced in this version.

I can provide the source code outside of this forum.

0 Kudos
5 Replies
Voyager
Voyager
213 Views
Registered: ‎10-23-2018

Re: Problem with Vivado HLS 2018.3

@drwmj12

Your case statement theory sounds correct.

https://github.com/NETMF/llilum/issues/76

Please mark solution accepted to close this thread.

0 Kudos
Visitor drwmj12
Visitor
178 Views
Registered: ‎06-14-2018

Re: Problem with Vivado HLS 2018.3

This doesn't really address the issue - I found the same comments with the same search.  It doesn't address why this source, which has been synthesized starting with Vivado 2016.4 through 2018.2, is completely unusable with 2018.3.  It appears to be related to a configuration of LLVM, not fundamental.  It also isn't the only case that triggers the problem.  I fixed one source file to fully elaborate the switch cases - causing significant code growth because the switch statement was being used to unroll a while loop (which can't be unrolled by HLS because the number of iterations is run-time dependent).  I also had a similar problem in another source which doesn't use switch statements, so apparently there are other cases.  There is absolutely no information where the problem is - it just gives the error message and stops.

This actually raises a more general issue.  Normally new releases would be expected to resolve bugs and/or improve functionality.  Every single new release I try to use introduces significant new problems, and stops working on cases that worked previously.  After this experience with 2018.3, I reverted to 2018.2 - which I haven't used through the whole design flow before.  It synthesizes code, but the Verilog fails a testbench that passes perfectly fine with 2017.4-generated RTL.  This is with identical settings, source code, and directives.  On the other hand, 2017.4 synthesizes another source file into Verilog that won't elaborate.

When VivadoHLS works, it seems to work fine, but I'm close to concluding that it isn't stable enough to be usable.  I'm using, or trying to use, three different releases in different areas of the design flow, and still don't have a combination that will accept all of the source files and pass end-to-end.

Voyager
Voyager
149 Views
Registered: ‎08-16-2018

Re: Problem with Vivado HLS 2018.3

My piece of advice: don't rush to upgrade, let others crash first to show the bumps and holes. Was there anything you couldn't do with 2018.2? Probably not, so actually no reason at all to upgrade, besides the myth of "it's newer, must be better, they say so...". The seducing power of "new" over human reasoning is amazing.

0 Kudos
Moderator
Moderator
142 Views
Registered: ‎06-24-2015

Re: Problem with Vivado HLS 2018.3

@drwmj12

I have sent you an EZMove package. Please upload the HLS project so that we can reproduce the issue at our end.

Thanks,
Nupur
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (click on the 'thumbs-up' button).
0 Kudos
Visitor drwmj12
Visitor
128 Views
Registered: ‎06-14-2018

Re: Problem with Vivado HLS 2018.3

Generally good advice.  However, there was one source that never worked in any version - it generates Verilog but the Verilog hangs in elaboration, so I can't run a testbench against it.  I filed testcases (2017.4) early last year, and was working on other development hoping this issue could be resolved, which is why I tried 2018.3.  It failed for another reason - the one I'm discussing here.

I reverted to 2018.2 (which I hadn't used before), and it did generate Verilog on the source that was a problem in 2017.4, but I didn't get to the point of seeing whether it would elaborate.  Before I did this, I decided to rerun the testbench I was using in 2017.4 against Verilog that ran sucessfully in 2017.4, but using 2018.2 for the entire flow.  No luck - the simplest source that synthesized and ran the testbench displayed completely different behavior (in correct behavior) with exactly the same source, settings, and directives.  So far different combinations of settings result in different behavior, but they're all incorrect.

By the way, this "simplest source" needs significant rewrite for 2018.3 or HLS throws up its hands with the error message that I mentioned at the start of this thread.

0 Kudos