cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
dbscintera
Visitor
Visitor
18,169 Views
Registered: ‎05-17-2013

Vivado 2013.1 removing "unused" logic, need to understand why

I'm using Vivado 2013.1 on Linux and am having trouble with my design getting optimized away. The main IP block is still a work-in-progress but other people on my team are successfully running cycles on it using the NCV simulator.

 

When I include this IP block within a larger project, the surrounding logic is present and functional on a KC705 reference board. However, the main IP block is completely removed by synthesis.

 

When I set the IP block as "top", the IO ring from the IP is present in the synthesized design but there is NO logic within it. The Elaborated Design Schematic looks great, but the Synthesized Design has only the Nets and Leaf Cells for the IP ports.

 

Everything looks good until "Start Cross Boundary Optimization" where thousands of these messages appear:

"WARNING: [Synth 8-3332] Sequential element ( ... ) is unused and will be removed"

 

This seems like it should be a simple thing to debug but we've reviewed it multiple times and can't find the source of the problem. Are there any options within Vivado to help find the source of the error?

 

Thank you!

Dave

0 Kudos
16 Replies
bassman59
Historian
Historian
18,150 Views
Registered: ‎02-25-2008


@dbscintera wrote:

I'm using Vivado 2013.1 on Linux and am having trouble with my design getting optimized away. The main IP block is still a work-in-progress but other people on my team are successfully running cycles on it using the NCV simulator.

 

When I include this IP block within a larger project, the surrounding logic is present and functional on a KC705 reference board. However, the main IP block is completely removed by synthesis.


In general, the simulator tool won't optimize away blocks whose outputs drive no loads (generally the main reason for optmizing away logic).

 

Naturally the synthesizer does, since it's the easiest optimization to do.

 

So running it on a simulatpr doesn't help you here.

----------------------------Yes, I do this for a living.
0 Kudos
dbscintera
Visitor
Visitor
18,144 Views
Registered: ‎05-17-2013

I agree, the simulator and synthesizer work differently. It is strange though that in simulation it is possible to write and read from embedded memories, so there IS an observable output change.

 

Are you saying that the answer is NO, there is nothing Vivado can do to help me find the source of the problem? 

 

0 Kudos
bassman59
Historian
Historian
18,109 Views
Registered: ‎02-25-2008


@dbscintera wrote:

I agree, the simulator and synthesizer work differently. It is strange though that in simulation it is possible to write and read from embedded memories, so there IS an observable output change.

 

Are you saying that the answer is NO, there is nothing Vivado can do to help me find the source of the problem? 

 


I don't understand your problem.

 

it seems like the "main" IP block has something missing, most likely outputs which aren't connected to anything. As such, the synthesis rips it all away. That's totally separate from simulation.

----------------------------Yes, I do this for a living.
0 Kudos
dbscintera
Visitor
Visitor
18,107 Views
Registered: ‎05-17-2013

The problem statement is the subject of this thread -- Vivado is making the logic go away and I need to find out why. I'm not blaming the tool in any way, it is almost certainly a bug in our RTL. I was simply hoping that there would be a way to get more information out of Vivado to help find and fix the problem. 

 

0 Kudos
bassman59
Historian
Historian
18,090 Views
Registered: ‎02-25-2008


@dbscintera wrote:

The problem statement is the subject of this thread -- Vivado is making the logic go away and I need to find out why. I'm not blaming the tool in any way, it is almost certainly a bug in our RTL. I was simply hoping that there would be a way to get more information out of Vivado to help find and fix the problem. 

 


Again: "unused logic" is that which has no load. I don't use Vivado, but XST will spit out tons of infos/warnings about logic removal. Make sure none of the messages are filtered, and go through the reports and look for those warnings/infos.

----------------------------Yes, I do this for a living.
0 Kudos
pascaldel
Visitor
Visitor
17,955 Views
Registered: ‎08-02-2013

I got the same issue with a design which writes its results only in an internal memory, without  top level output: the synthesis is removing a lot of logic, including the memory.

I simply fixed the problem by creating a top level output for the Read data bus memory.

 

0 Kudos
zefir
Visitor
Visitor
17,942 Views
Registered: ‎07-26-2013

I'm having the same problem in Vivado 2013.2, Here's a straightforward question for xilinx, Is there a list of all the Synth 8-****  messages and their explanations?

 

Synth 8-3295 tying undriven pin module_nam:port_name to constant 0

 

I have gone so far as to simply drive the port with a constant nonzero value ala assign Port_x = 8'hAB; only to have the synthesizer come back with the above message. How can the port be undriven? As with the other customer the problem probably lies with mysource code but how do we debug the synthesis?

 

Shiny new tool, same old problems.

0 Kudos
bernief
Participant
Participant
17,891 Views
Registered: ‎07-30-2012

I having same problem with 2013.2 as well.  The difference with my issue is that the design was synthesizing correctly until I made one a change to one of the blocks. Boom all surrounding logic removed.  Even after backing out that change I simply cannot get it to synthesize the logic again...  Guessing the problems lies with my source but no way to narrow it down!!

 

Any help Xilinx

0 Kudos
elphel
Observer
Observer
17,055 Views
Registered: ‎08-09-2013

Is this issue resolved?

 

I made a simple test for Zynq  with BRAM connected to PS7 AXI PS Master GP0. And tried the same design with both ISE 14.7 and Vivado 2013.4. ISE outputs a lot and goes through to the very end (bitfile generation)

Device Utilization Summary:
   Number of PS7s                            1 out of 1     100%
   Number of RAMB36E1s                       1 out of 265     1%
   Number of Slices                        133 out of 19650   1%
   Number of Slice Registers               350 out of 157200  1%
      Number used as Flip Flops            350
      Number used as Latches                 0
      Number used as LatchThrus              0
   Number of Slice LUTS                    364 out of 78600   1%
   Number of Slice LUT-Flip Flop pairs     383 out of 78600   1%

The same files in Vivado :

---------------------------------------------------------------------------------
Start Area Optimization
---------------------------------------------------------------------------------
WARNING: [Synth 8-3332] Sequential element (\inreg_reg[29] ) is unused and will be removed from module fifo_reg_W_D.
WARNING: [Synth 8-3332] Sequential element (\inreg_reg[28] ) is unused and will be removed from module fifo_reg_W_D.
WARNING: [Synth 8-3332] Sequential element (\inreg_reg[27] ) is unused and will be removed from module fifo_reg_W_D.
WARNING: [Synth 8-3332] Sequential element (\inreg_reg[26] ) is unused and will be removed from module fifo_reg_W_D.
...

 

Report BlackBoxes:
+-+--------------+----------+
| |BlackBox name |Instances |
+-+--------------+----------+
+-+--------------+----------+

Report Cell Usage:
+-+-----+------+
| |Cell |Count |
+-+-----+------+
+-+-----+------+

Report Instance Areas:
+------+---------+-------+------+
|      |Instance |Module |Cells |
+------+---------+-------+------+
|1     |top      |       |     0|
+------+---------+-------+------+

How can I find the source of the problem? Or should I add dummy outputs? Which ones?

0 Kudos
benzao
Observer
Observer
8,815 Views
Registered: ‎02-04-2014

i have same problem in vivado 2013.4, maybe it's a bug of vivado.

 

 

Synthesis[Synth 8-3332] Sequential element (\flag_reg[3] ) is unused and will be removed from module tt.
[Synth 8-3332] Sequential element (\flag_reg[2] ) is unused and will be removed from module tt.
[Synth 8-3332] Sequential element (\flag_reg[1] ) is unused and will be removed from module tt.
[Synth 8-3332] Sequential element (\flag_reg[0] ) is unused and will be removed from module tt.

0 Kudos
driesd
Xilinx Employee
Xilinx Employee
8,811 Views
Registered: ‎11-28-2007

Just to be clear: this is not a bug or problem of Vivado!

 

As the initial writers wrote: these are problems with your design and that's why everything gets optimized away.

You need to find the undriven inputs, floating outputs (sometimes caused by missing module ports) in your code that cause this optimization of your design.

 

There are a few options:

- analyze your code manually, focus on any recent changes if it previously worked

- analyze the RTL schematic in Vivado (this basically just runs elaboration of synthesis)

- run synth_design in verbose mode (synth_design -verbose or via other options) to disable message limits and show all optimized elements to help debug the issue

- temporarily set DONT_TOUCH constraints in your HDL code to prevent optimization

- temporarily use these synthesis options:

-flatten_hierarchy none
-keep_equivalent_registers
-resource_sharing off

 

 

Good luck!

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
bassman59
Historian
Historian
8,801 Views
Registered: ‎02-25-2008


@benzao wrote:

i have same problem in vivado 2013.4, maybe it's a bug of vivado.

 

 

Synthesis[Synth 8-3332] Sequential element (\flag_reg[3] ) is unused and will be removed from module tt.
[Synth 8-3332] Sequential element (\flag_reg[2] ) is unused and will be removed from module tt.
[Synth 8-3332] Sequential element (\flag_reg[1] ) is unused and will be removed from module tt.
[Synth 8-3332] Sequential element (\flag_reg[0] ) is unused and will be removed from module tt.


How is this a bug?

 

If you assign something to a flip-flop, and you never use that flip-flop's Q output, the tools quite reasonably say "You aren't using this so we will remove it so you can save resources and maybe make your design go faster."

 

If there's a bug, it's in your design, not in the tools.

----------------------------Yes, I do this for a living.
0 Kudos
elphel
Observer
Observer
8,761 Views
Registered: ‎08-09-2013

I still consider it as a bug, because while the design does not have any I/O ports, it has connections to the PS. And PS7 is not just a module in PL, it provides connections to the "outside world".

I resolved my problem by adding keep attgribute to the first wire connected to the PS7 module:

  (* keep = "true" *) wire [ 3:0] FCLKCLK;
But it would be nice to have PS7 kept automatically if it is instantiated in the design (how it seems to be done in ISE where this problem did not appear for the same source files).

Andrey Filippov

Elphel, Inc.

0 Kudos
sandeepsathe
Newbie
Newbie
7,911 Views
Registered: ‎09-19-2014

Hi,

 

I got the very same error in Vivado 2014.2 tool. 

 

Problem I had was one signal was initialized at reset in two different always blocks.

 

Although I agree that this "IS" an RTL problem. But it is "very cruel" on part of Vivado to optimize this variable and the domino effect optimizations of subsequent signals, practically entire module.

 

Expect better from Xilinx.

 

Regards

Sandeep Sathe

0 Kudos
markcurry
Scholar
Scholar
7,907 Views
Registered: ‎09-16-2009

 

"very cruel"?  Not at all.  The tool's doing exactly what a synthesis tool should do.  It's optimizing constants, and removing unused logic.  That's the very reason for part of the optimization stage.

 

Now Andrey implied that there was some sort of bug in vivado, where it was optimizing logic away because it was ONLY used by the Zynq hard core.  I'm suspect of this, but it could be a true bug.  It was never confirmed in this thread.

 

There's little reason for a synthesis tool to NOT optimize unused logic.  Most of the time people are trying to do it is because they're adding debug logic (i.e. chipscope) POST synthesis. 

 

In any other case, the tools doing exactly what it was designed to do.

 

Regards,

 

Mark

 

 

jmhbfe
Visitor
Visitor
2,610 Views
Registered: ‎05-24-2018

I know this thread is very old but I'll chime in anyway for other latecomers.

If sequential logic doesn't have a clock or a live input, it's dead and gets optimized away.

Why doesn't it have a clock?  Maybe you changed "clk" to "sysclk" but forgot to change it in module instantiation.  Maybe you instantiated a block with "cllk".  Synthesis happily assumes it's a wire, creates it for you--maybe with an info or a warning--and just as happily optimizes it away.  Maybe somewhere you forced a clock manager into reset.  Or you ran the clock through a mux with a forced select line to a constant. No clock, no sequential logic.  Maybe the input way up is forced to a constant, or mis-spelled, or had a name change.  If the input doesn't change, there's no sequential logic.

 

Imagine the problem from the synthesizers point of view (or, equivalently, the software engineer[s] who wrote the synthesizer.)  Here's a flip-flop without a clock, or with a constant input.  Why, if the output can't change, it's as good as a constant, too.  And if it's as good as a constant, why, it is a constant.  And if it is a constant, why not say so?  And on to the next flip-flop, and the next, etc.

(Apologies to Gilbert & Sullivan....)

0 Kudos