cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Teacher
Teacher
7,985 Views
Registered: ‎07-09-2009

warnings in Xilinx IP

Jump to solution

I have a design, that has a bunch of Xilinx IP in it

 

I'm getting 581 synthesis warnings in Vivado 2015.4

 

So I waded through them, to check I had not made a mistake some where, took quiet a while. 

 

turns out most of the warnings wer on the lines of this 

 

[Synth 8-312] ignoring unsynthesizable construct: assertion statement ["c:/cvs/my_vivado.srcs/ip/fifo_32x512_fwft/blk_mem_gen_v8_3_1/hdl/blk_mem_gen_v8_3_vhsyn_rfs.vhd":4803]

 

This particular one is a block memory , that is in the xilinx fifo generator 

 

How do I get rid of these Xilinx warnings so I can see any useful ones as these are all in encrypted xilinx IP.

 

 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Reply
1 Solution

Accepted Solutions
Scholar
Scholar
14,916 Views
Registered: ‎04-26-2012

@drjohnsmith "turns out most of the warnings wer on the lines of this  [Synth 8-312] ignoring unsynthesizable construct: assertion statement "

 

Synthesis assertions can be turned on again in 2015.3 and 2015.4 if you set an obscure tcl parameter before running synthesis:

set_param synth.elaboration.rodinMoreOptions {rt::set_parameter ignoreVhdlAssertStmts false}

See the following AR:

http://www.xilinx.com/support/answers/65415.html

 

-Brian

View solution in original post

5 Replies
Scholar
Scholar
14,917 Views
Registered: ‎04-26-2012

@drjohnsmith "turns out most of the warnings wer on the lines of this  [Synth 8-312] ignoring unsynthesizable construct: assertion statement "

 

Synthesis assertions can be turned on again in 2015.3 and 2015.4 if you set an obscure tcl parameter before running synthesis:

set_param synth.elaboration.rodinMoreOptions {rt::set_parameter ignoreVhdlAssertStmts false}

See the following AR:

http://www.xilinx.com/support/answers/65415.html

 

-Brian

View solution in original post

Scholar
Scholar
7,941 Views
Registered: ‎09-16-2009

Brian,

 

But there needs to be a more granular approach than "this check globally off or on".

 

I fight^H ahem, negotiate with our own team enough on cleaning up our own warnings. My idea -  fix it once, is better than trying to ignore it a thousand times.  We're mostly successful. However Xilinx' latest IP is spewing LOTS more warnings out of the tools that in the past.  I'm not sure this is because more of the Xilinx IP is verilog rather than VHDL (Verilog allows more slack in things leading up to these warnings.)  Or if we're just using more Xilinx IP.  But the amount of warnings has greatly gone up.  I've not given up asking for these to be fixed - but in the interim, it sure would be nice to have a way to "Turn off this check for this IP file".

 

Globally turning off assertion checking and warnings isn't a very useful suggestion  - there's real data in those messages hidden amoung the chaff.

 

Regards,

 

Mark

0 Kudos
Reply
Scholar
Scholar
7,930 Views
Registered: ‎04-26-2012

@markcurry "Globally turning off assertion checking and warnings isn't a very useful suggestion "

 

You are barking up the wrong tree, as I have suggested no such thing.

 

Quoting my previous post, with highlighting:

>

> Synthesis assertions can be turned on again in 2015.3 and 2015.4 if you set an obscure tcl parameter

>

 

( Also note the double negative within ignoreVhdlAssertStmts false )

 


 Back story:

 

Xilinx internally uses ***VHDL*** synthesis assertions within their IP code, particularly the memory generator, to sanity check internal widths and such.

 

Around 2015.1 or so, Xilinx ***intentionally*** disabled VHDL assertions (which had worked in XST for years, and previously worked in Vivado); any use within VHDL code now produces this #$%^&! warning message- hundreds or thousands of them in large systems with many block memories and FIFOs.

 

The tcl command that I posted turns VHDL assertions back ***ON*** again for synthesis.

 

Which is useful not only in that it cuts down on the spurious warning messages, but also lets one use assert statements in one's own code again.

 

-Brian

0 Kudos
Reply
Scholar
Scholar
7,926 Views
Registered: ‎09-16-2009

Brian,

 

My intention was to reinterate John's original assertion - Xilinx IP is too darned noisy with warnings.

 

You're right in that I missed the double negative of your suggestion, and what it was exactly doing.

 

I'd just like the IP to be cleaner, and failing that, better tools to turn off warnings for specific blocks.

 

An example from my last run:

 

grep "WARNING.*fifo_generator" foo_synth.log | wc -l
   3303

 

That 3k WARNINGS from the Xilinx Fifos (and we don't explicitly use ANY Xilinx FIFOs - there are all indirectly called from their IP).  Some warning are noteworthy - undriven net's and the like. 

 

 

Regards,

Mark

 

0 Kudos
Reply
Teacher
Teacher
7,899 Views
Registered: ‎07-09-2009

I must just come in here

 

I used to teach my students always to check the warnings,,,,

 

Used to be fine in ISE, 

   

but vivado, the one warning that they coudl find usefull was drowned

 

I'm relived that the problem is fixed again in 2016.1 , 

   with its windws 10 support it can't come to quickly for my clients as well as my students.

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Reply