12-09-2019 07:24 AM
Create a new Vivado project, add the 3 attached files (top.v, success.v and failure.v), run synthesis and look at the schematic. Modules "success" and "failure" are logically equivalent; however, since 2018.3, Vivado has incorrectly synthesised module "failure".
The problem did not occur in 2018.2, was introduced with 2018.3 and is still present in 2019.2
Target FPGA is xcvu440-flga2892-1-c but that seems not critical.
12-09-2019 09:48 AM
You don't need a testbench to see the problem. The schematic shows the failing module is not sensitive to all the inputs as it should be. See attached png. And BTW - in case you haven't looked - the code is trivial.
12-09-2019 10:06 AM
12-09-2019 10:21 AM
Hello, I have been able to reproduce the problem and verify that the logic is incorrect using formal verification. The problem does appear to be that the "finished" and "list_valid" inputs are not driving the "failure" module any longer. I have filed a CR for this and assigned to development.
I see if I can find any workarounds for this next.
12-09-2019 11:12 AM
Thank you Manusha and aschule. Module "success" is the workaround we are using. Please find attached an updated version of the demo, including a testbench. I have also fixed the SystemVerilog-style implicit port connections in top. If you run a behavioral simulation, it passes. If you run a post-synthesis functional simulation, it fails.
12-09-2019 11:30 AM
I tried a few different workarounds none of them worked. The next thing I was going to try was to break up next and next into different always blocks, but I can see that is what the module success already does. I have let the developer know that this is the problem.
12-09-2019 12:12 PM
Could this be related to the state machine problem here?:
That thread discusses another RTL/netlist mismatch related to the Vivado State Machine optimizer. An AR was published as well:
This was supposed to be fixed in Vivado 2019.1, but I've not yet verified this.
We've globally turned off FSM optimizations in our Vivado designs because of this bug. I'm wondering if this new bug @aholme has posted here is related.
Can someone try the testcase with FSM optimization turned off, and see if the mismatch still persists?
12-09-2019 12:22 PM
Turning off the state machine was one of the expirements that I tried and it did not fix the issue. The problem seems to be how the next signal is being assigned.