cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
wfjmueller
Explorer
Explorer
17,500 Views
Registered: ‎11-23-2009

Many spurious "[Synth 8-6014] Unused sequential element ... was removed" warnings in vivado 2017.1

Jump to solution

Hi,

 

after I changed to vivado 2017.1 I get a large number of apparently spurious warnings of type

  WARNING: [Synth 8-6014] Unused sequential element r_reg[ucnt] was removed.
...
WARNING: [Synth 8-6014] Unused sequential element n_reg[msec] was removed.

Closer inspection shows that nothing is actually removed, the cell usage under 2016.4 and 2017.1 is very similar, and the designs are fully functional. I often use a vhdl coding style I picked up from the LEON project. I collect all registers in a record, and write combinatorial processes like

  proc_next: process (R_REGS)

    variable r : regs_type := regs_init;
    variable n : regs_type := regs_init;

  begin

    r := R_REGS;
    n := R_REGS;

    n.usec := '0';
    n.msec := '0';

    n.ucnt := slv(unsigned(r.ucnt) - 1);
    if unsigned(r.ucnt) = 0 then
      n.usec := '1';
      n.ucnt := slv(to_unsigned(USECDIV-1,CDUWIDTH));
      n.mcnt := slv(unsigned(r.mcnt) - 1);
      if unsigned(r.mcnt) = 0 then
        n.msec := '1';
        n.mcnt := slv(to_unsigned(MSECDIV-1,10));
      end if;
    end if;
    
    N_REGS <= n;

    CE_USEC <= r.usec;
    CE_MSEC <= r.msec;
    
  end process proc_next;

 

 [Synth 8-6014] messages are apparently created for each record field for the two lines

    r := R_REGS;
    n := R_REGS;

The variables 'n' and 'r' certainly do not create a sequential element (aka register).

 

It looks like 2017.1 synthesis gets confused by this coding style. ISE for many years and Vivado up to 2016.4 had no problems with this. 2017.1 creates the correct logic, but the warnings are truly distracting from real issues.

 

I've attached a tarball with a small example design with about 100 [Synth 8-6014] messages.

 

I hope that future vivado releases are less noisy.

 

With best regards,   Walter

 

1 Solution

Accepted Solutions
prathikm
Moderator
Moderator
12,477 Views
Registered: ‎09-15-2016

>> We have tested your design and can see when g_lfsr is set to false, false message for r_cnt_reg is seen.
>> Also, for the test-case shared by @wfjmueller looks true as tool issue (R_BREGS_reg[cnt]).
>> We have passed both test-cases to factory to look into to be fixed in future release.

The factory have fixed this issue in Vivado 2018.1 build.

 

Regards,
Prathik
-----------------------------------------------------------------------------------------------
Please mark the appropriate post as an answer "Accept as solution" in case it helps to resolve your query.
Give Kudos to a post which you think is helpful and reply oriented.
-----------------------------------------------------------------------------------------------

View solution in original post

21 Replies
julian3
Observer
Observer
17,347 Views
Registered: ‎07-14-2016

I am having the same issue since downloading 2017.1 . Certainly an annoying issue with this release.

0 Kudos
anusheel
Moderator
Moderator
17,322 Views
Registered: ‎07-21-2014

@wfjmueller and @julian3,

 

This is a known issue and we already have CRs on this issue, we are expecting that future releases(may be 2017.3) will report better logs.

 

Thanks,
Anusheel
-----------------------------------------------------------------------------------------------
Search for documents/answer records related to your device and tool before posting query on forums.
Search related forums and make sure your query is not repeated.

Please mark the post as an answer "Accept as solution" in case it helps to resolve your query.
Helpful answer -> Give Kudos
-----------------------------------------------------------------------------------------------

asharapov
Visitor
Visitor
16,966 Views
Registered: ‎01-31-2013

Same problem.

 

Thank you for the info.

0 Kudos
zyxer
Visitor
Visitor
16,948 Views
Registered: ‎11-30-2016
Our project is very involved in terms of testing the design, so we depend on the synthesis/implementation reports up to the final stage of porting to a new tool version. And we had to waste couple of hours in figuring out this issue. Certainly, a frustrating thing given that the problem did not exist with earlier versions. One great customer centric approach that Xilinx can take is to release only one version per year (and maybe one patch) instead of 3 versions with issues and one relatively better one. In general I have seen .4's to be relatively more stable and less buggy than .1, .2 and .3.
0 Kudos
sathishsn
Visitor
Visitor
16,822 Views
Registered: ‎07-17-2017

Thank you for the post. I was facing the same issue and now little relaxed after seeing this post and the reply by the xilinx moderator.

You are right, the logic blocks are present in the elaborated design but we get weird synthesis warnings

 

Best regards

Sathish

0 Kudos
brentm
Newbie
Newbie
16,805 Views
Registered: ‎07-17-2017

Seeing the same problem on 2017.2

 

I just spent a lot of time migrating my project from ISE (was using an old board) to Vivado 2017.2. Is this version backwards compatible with Vivado 2016.4? I'd like to switch to something that doesn't exhibit this problem.

 

Thanks,

0 Kudos
brians2
Newbie
Newbie
15,812 Views
Registered: ‎09-26-2017

While this won't solve the problem, you can at least double check that the registers you want are still in the design through the Tcl console:

 

get_cells -hier {instance_name_from_warning_msg*}

 

prowell
Visitor
Visitor
14,758 Views
Registered: ‎11-30-2017

Nope... In Vivado 2017.3 the bug still exists... :-(

0 Kudos
anusheel
Moderator
Moderator
14,734 Views
Registered: ‎07-21-2014

@prowell

 

Can you please share your RTL/design which is failing in 2017.3?

 

Thanks

Anusheel

0 Kudos
prowell
Visitor
Visitor
11,859 Views
Registered: ‎11-30-2017

Hi @anusheel,

Thank you for your quick response. Please find the requested design in attachment. Here you have the details:

Software (under Ubuntu):
Vivado v2017.3 (64-bit)
SW Build: 2018833 on Wed Oct 4 19:58:07 MDT 2017
IP Build: 2016188 on Wed Oct 4 21:52:56 MDT 2017

Chip used: xc7a200tffv1156-3

Synthesis strategy: Vivado Synthesis Defaults (without any user modifications)

The design is a counter, which can operate using a natural binary counter (NBC) or LFSR. The warning appears when the generic g_lfsr is set to false, so the NBC is used. Interestingly, the warning disappears if the LFSR is used (g_lfsr = true).


In both cases the result of the synthesis (when viewed in Schematics) is correct. However, the warning in question appears only in NBC mode in the synthesis messages (lfsr_counter_up.vhd:35). The design I provided in the attachment is the simplest one I can provide, but I can offer more examples if needed.

Using the same setup described above:
- I have checked Vivado 2017.1 - the warning exists.
- I have also checked older version of Vivado (2016.3). The warning hasn't occured then.

Thanks for your time.

0 Kudos
prathikm
Moderator
Moderator
11,823 Views
Registered: ‎09-15-2016

Hi @prowell,

 

There is a CR-988379 for which the factory is actively working on to resolve a similar issue (Link).

We have tested your design and can see when g_lfsr is set to false, false message for r_cnt_reg is seen.

Also, for the test-case shared by @wfjmueller looks true as tool issue (R_BREGS_reg[cnt]).

 

We have passed both test-cases to factory to look into to be fixed in future release.

 

Thanks a lot.
--------------------------------------------------------------
Please mark the appropriate answer as "Accept as solution" if information provided is helpful.
Give 'Kudos' to a post which you think is useful and reply oriented.
--------------------------------------------------------------

0 Kudos
prowell
Visitor
Visitor
11,462 Views
Registered: ‎11-30-2017

Nope... In Vivado 2017.4 the bug still exists...

0 Kudos
zyxer
Visitor
Visitor
11,339 Views
Registered: ‎11-30-2016
Xilinx, can you tell me when will there be a vivado /Petaling version with no bugs? We don't want all the fancy features, we just want something which works without any issues. On behalf of all the tool fighters, can I request you to stop further development of any new features and address ALL the existing issues. I have been using the tools since ISE 3.1 days and I rarely see a stable version. The best I have used is ISE7.2. Nowadays it looks like you take the users for granted and release 4 versions each year with 1-2 patches and none of them are bug free. Please release only one version in 2018 with maybe only one patch so that it is good enough for 2-3 years.
zyxer
Visitor
Visitor
11,338 Views
Registered: ‎11-30-2016
Read "Petalinux"
0 Kudos
prathikm
Moderator
Moderator
12,478 Views
Registered: ‎09-15-2016

>> We have tested your design and can see when g_lfsr is set to false, false message for r_cnt_reg is seen.
>> Also, for the test-case shared by @wfjmueller looks true as tool issue (R_BREGS_reg[cnt]).
>> We have passed both test-cases to factory to look into to be fixed in future release.

The factory have fixed this issue in Vivado 2018.1 build.

 

Regards,
Prathik
-----------------------------------------------------------------------------------------------
Please mark the appropriate post as an answer "Accept as solution" in case it helps to resolve your query.
Give Kudos to a post which you think is helpful and reply oriented.
-----------------------------------------------------------------------------------------------

View solution in original post

prowell
Visitor
Visitor
11,213 Views
Registered: ‎11-30-2017

Excellent. Great news. When will it be out? I assume not too soon as the latest version was released just a month ago.

0 Kudos
mve.recalm
Observer
Observer
9,642 Views
Registered: ‎01-09-2018

Unfortunately I am still facing this issue under vivado 2018.2. I have a code snipped that was generated with HDL coder in matlab 2018a. Vivado removes this architecture completely because it deletes the Delay_out1 operation. I have several other examples in my design. In Vivado 2016.2 however it works just smooth.

 

ARCHITECTURE rtl OF src_RisingEdgeTerm IS

  -- Signals
  SIGNAL Delay_out1                       : std_logic;
  SIGNAL Logical_Operator1_out1           : std_logic;
  SIGNAL Logical_Operator_out1            : std_logic;

BEGIN
  Delay_process : PROCESS (clk)
  BEGIN
    IF clk'EVENT AND clk = '1' THEN
      IF reset = '1' THEN
        Delay_out1 <= '0';
      ELSIF enb = '1' THEN
        Delay_out1 <= In1;
      END IF;
    END IF;
  END PROCESS Delay_process;


  Logical_Operator1_out1 <=  NOT Delay_out1;

  Logical_Operator_out1 <= Logical_Operator1_out1 AND In1;

  Out1 <= Logical_Operator_out1;

END rtl;

the error message is:

 

[Synth 8-6014] Unused sequential element ../u_RisingEdgeTerm/Delay_out1_reg was removed.  ../CORE_RAM_src_RisingEdgeTerm.vhd":44]

Do I have to change the synthesis settings? Is there any other workaround? I faced the problem in vivado 2017.4 and vivado 2018.2.

0 Kudos
viviany
Xilinx Employee
Xilinx Employee
9,615 Views
Registered: ‎05-14-2008

Although you have the same message as the others had in this thread, the problem you encountered is not the same one.

Please start a new post for your problem.

 

And for an initial investigation of your issue, have you tried applying a dont_touch attribut to the Delay_out1 register in your VHDL and see if that helps?

 

-vivian

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

I am also seeing this issue with the spurious warnings in 2018.1 as well.  (I am seeing it when I embed a simple 3 stage asynchronous signal edge detector in my design).  But when I look at the schematics (both synthesis and implementation) the sequential blocks are there as intended.  But man, when I design is done there will be *hundreds* of these warning messages...

0 Kudos
wfjmueller
Explorer
Explorer
8,622 Views
Registered: ‎11-23-2009

@prathikmwrote

>> The factory have fixed this issue in Vivado 2018.1 build.

 

I re-tested a design very similar to the posted example and got

  • 2017.1:   >100 times Synth 8-6014
  • 2017.2:   >100 times Synth 8-6014
  • 2017.4:        77 times Synth 8-6014
  • 2018.1:        37 times Synth 8-6014
  • 2018.2:        37 times Synth 8-6014

Apparently things changed as announced with 2017.3 and 2018.1, and changed to the better !

No longer a flood of [Synth 8-6014] which essentially hit each flip-flop coded in a certain style.

There are some remaining [Synth 8-6014] which I have to analyze closer, but the old issue seems closed.

0 Kudos
prathikm
Moderator
Moderator
8,604 Views
Registered: ‎09-15-2016

Hi @wfjmueller,

 

Thank you for the update. But note if you still see a test-case which shows [Synth 8-6014] which is unwanted, I can definitely have a look at it for further analysis.

 

Thanks again.

 

Prathik

-----------------------------------------------------------------------------------

Don't forget to reply, kudo, and mark the appropriate post as 'accept as solution'.

-----------------------------------------------------------------------------------

0 Kudos