cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
1,398 Views
Registered: ‎05-07-2019

Vivado 2018.x and Verilog case statements - looks like an errata

The attached testcase, trial.v, is a simple state machine, based on a state machine in the some ARM IP for the cortex M7. Perfectly valid and legal Verilog.

Vivado 2017.4 synthesis correctly produces the correct number of states and logic - see attached log, synth_2017_4.log

Vivado 2018.3 (or any 2018.x) synthesis makes a complete has of it, resulting in a single state - see attached log, synth_2018_3.log
Looks like a bug in Vivado 2018.x

The "fix" is to simply change:-
ST7, ST0: nxt_state = ip0 ? ST1 : ST0;
to
ST0, ST7: nxt_state = ip0 ? ST1 : ST0;
However, this identical situation happens with ARM IP (which is where I started investigating this issue), which we don't tend to touch.

Anyone from Xilinx care to comment?

Thanks, DaveW

15 Replies
Highlighted
Scholar
Scholar
1,372 Views
Registered: ‎09-16-2009

Re: Vivado 2018.x and Verilog case statements - looks like an errata

Dave,

Does the resulting netlist match the RTL in the 2018.3 version?

I've noticed that many of the Vivado tools releases don't properly recognize my state machines.  So FSM optimizations are NOT done.  But the netlists matches the RTL, so I don't really care.  FSM optimization is overrated, IMHO.

Regards,

Mark

0 Kudos
Highlighted
Contributor
Contributor
1,363 Views
Registered: ‎10-25-2018

Re: Vivado 2018.x and Verilog case statements - looks like an errata

Another "fix".

 

ST7, ST0: begin
     if (state == ST0) begin
          nxt_state = ip0 ? ST1 : ST0;
     end
     else if (state == ST7) begin
         nxt_state = ip0 ? ST1 : ST0;
      end       
end

It's worth noting that with respect to states and transitions, ST7 is redundant and essentially an alias for ST0, so the optimizer would probably try and remove it.

 

 

0 Kudos
Highlighted
1,334 Views
Registered: ‎05-07-2019

Re: Vivado 2018.x and Verilog case statements - looks like an errata

No it doesn't - ends up with one single state (you can see it in the log files), and the resulting system is broken, which is why I investigated this in the first place!

0 Kudos
Highlighted
1,332 Views
Registered: ‎05-07-2019

Re: Vivado 2018.x and Verilog case statements - looks like an errata

Agree, but shouldn't then end up with just one state!

0 Kudos
Highlighted
1,330 Views
Registered: ‎05-07-2019

Re: Vivado 2018.x and Verilog case statements - looks like an errata

I should re-iterate - this is based on a state machine within the ARM Cortex M7 IP - I've simply stripped it out, and created a testcase to show the issue.

Given this is ARM IP, patching it is not the answer. It's clearly a Vivado problem, more so since 2017.4 handles it just fine.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
1,304 Views
Registered: ‎05-14-2008

Re: Vivado 2018.x and Verilog case statements - looks like an errata

You can use this workaround:

set_property BLOCK_SYNTH.FSM_EXTRACTION {OFF} [get_cells <instance name of this IP in your design>]

This constraint adding to your XDC is to disable fsm_extraction for this specific IP instance and this can resolve the issue.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
1,295 Views
Registered: ‎07-21-2014

Re: Vivado 2018.x and Verilog case statements - looks like an errata

Hi,

 

This is a regression from 2017.4 which is fixed in 2019.1

For 2018.x you can use disabling the fsm extraction as pointed by Vivian.

 

-Shreyas

----------------------------------------------------------------------------------------------
Try to search answer for your issue in forums or xilinx user guides before you post a new thread.

Kindly note- Please mark the Answer as "Accept as solution" if information provided solves your query.
Give Kudos (star provided in right) to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Scholar
Scholar
1,280 Views
Registered: ‎09-16-2009

Re: Vivado 2018.x and Verilog case statements - looks like an errata

Vivian/Shreyas

I've not tried Dave's testcase.  I'm still not clear if this is just a FSM optimization problem, or in fact a simulation/synthesis mismatch.  But if the behavior is in fact as he states, then this is a very significant Vivado bug. Simulation/Synthesis mismatches are fatal errors, and should never occur.

Unless we have details, users should globally disabled fsm extraction TODAY.  I'm going to discuss with our team, and likely do so immediately for all our FPGAs.  

Can Xilinx provide any more insight?  What are the conditions that cause the bug?

Regards,

Mark

0 Kudos
Highlighted
1,222 Views
Registered: ‎05-07-2019

Re: Vivado 2018.x and Verilog case statements - looks like an errata

Couldn't make that work :(

For the testcase, trial, I added a constraint file with:-
set_property BLOCK_SYNTH.FSM_EXTRACTION {OFF} [get_cells trial]

That gives the synth error:-
Processing XDC Constraints
Initializing timing engine
Parsing XDC File [/projects/kleinmatterhorn/dwri/icm/trial/trial.xdc]
WARNING: [Vivado 12-180] No cells matched 'trial'. [/projects/kleinmatterhorn/dwri/icm/trial/trial.xdc:1]
CRITICAL WARNING: [Common 17-55] 'set_property' expects at least one object. [/projects/kleinmatterhorn/dwri/icm/trial/trial.xdc:1]

Also tried:-
set_property BLOCK_SYNTH.FSM_EXTRACTION {OFF} [get_cells *state*]

Giving:-
WARNING: [Synth 8-6072] Ignoring block_synth property 'fsm_extraction' applied to non-module instance 'state_reg'
Applied set_property BLOCK_SYNTH.FSM_EXTRACTION = OFF for state_reg. (constraint file /projects/kleinmatterhorn/dwri/icm/trial/trial.xdc, line 1).
etc

I applied the same constraint to the ARM IP module (using module name) where the original problem was found.
Constraint was accepted, but state machine was still trashed.

Any other suggestions?
Currrently looks like patching the ARM IP RTL is the only fix, which is not ideal.

0 Kudos
Highlighted
Teacher
Teacher
1,216 Views
Registered: ‎07-09-2009

Re: Vivado 2018.x and Verilog case statements - looks like an errata

@aher

by regresion do you mean bug fomr 2017 that was fixed and came back in 2018 ?

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Scholar
Scholar
1,203 Views
Registered: ‎09-16-2009

Re: Vivado 2018.x and Verilog case statements - looks like an errata

The workaround listed tries to selectively turn off state machine optimizations.  I'd suggest just turning it off globally instead:

Change/add your synth_design command line to include:

synth_design -fsm_extraction off //...rest of options...

I've still not taken the time too look at your testcase myself.  I'm very concerned there's a signficant bug in the Vivado 2018.* releases.  

Regards,

Mark

0 Kudos
Highlighted
1,194 Views
Registered: ‎05-07-2019

Re: Vivado 2018.x and Verilog case statements - looks like an errata

Aher (Xilinx employee) above, has confirmed the bug is present for 2018.x. Would be nice to know the details.
For now, I will not be moving over to 2018.x with such a fundamental bug present.

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
1,176 Views
Registered: ‎05-14-2008

Re: Vivado 2018.x and Verilog case statements - looks like an errata

@dppwright-ublox 

The cell name used in get_cells in the BLOCK_SYNTH.FSM_EXTRACTION constraint, is the instance name of the module, not the module name.

For example, if you have a module instantiated in the top level like below

trial my_trial(
.a (a),
.b (b),
......
);

Then the constraint is like this: set_property BLOCK_SYNTH.FSM_EXTRACTION {OFF} [get_cells my_trial]

This constraint disables fsm extraction only for the specific hierarchical instance.

 

As of whether you're going to disable the fsm extraction globally or on a block level, that's up to the designer to evaluate the benefits.

The issue has been fixed in 2019.1. You can stay with 2017.4 now and wait for 2019.1 which will be released soon.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
1,137 Views
Registered: ‎07-31-2014

Re: Vivado 2018.x and Verilog case statements - looks like an errata

@viviany  If this is a known issue, you really need an AR detailing what versions of the tools are affected and any other pertinent information ASAP.

0 Kudos
Highlighted
967 Views
Registered: ‎05-07-2019

Re: Vivado 2018.x and Verilog case statements - looks like an errata

Ive just tested with release 2019.1 and it appears to fix this issue. Lets hope it stays fixed...

0 Kudos