12-29-2018 11:03 AM
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.
01-04-2019 01:40 PM
01-07-2019 09:42 AM
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.
01-09-2019 01:36 AM
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.
01-09-2019 03:19 AM
I have sent you an EZMove package. Please upload the HLS project so that we can reproduce the issue at our end.
01-09-2019 06:23 AM
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.