cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Contributor
Contributor
2,486 Views
Registered: ‎11-25-2013

Vivado 17.4, AXI 1G/2,6G Ethenet Subsystem and unlicensed eth_avb_endpoint creates critical warnining in bitstream generation

Jump to solution

I am receiving the following critical warning upon bitstream generation for a design that uses th AXI 1G/2.5G Ethernet Subsystem:

 

[Vivado 12-1790] Evaluation License Warning: This design contains one or more IP cores that use separately licensed features. If the design has been configured to make use of evaluation features, please note that these features will cease to function after a certain period of time. Please consult the core datasheet to determine whether the core which you have configured will be affected. Evaluation features should NOT be used in production systems.

Evaluation cores found in this design:
IP core 'KCU105_bd_axi_ethernet_0_0' (bd_979c) was generated with multiple features:
IP feature 'eth_avb_endpoint@2015.04' was enabled using a design_linking license.
IP feature 'tri_mode_eth_mac@2015.04' was enabled using a bought license.
IP core 'bd_979c_mac_0' (bd_979c_mac_0_block) was generated with multiple features:
IP feature 'eth_avb_endpoint@2015.04' was enabled using a design_linking license.
IP feature 'tri_mode_eth_mac@2015.04' was enabled using a bought license.

Resolution: If a new IP Core license was added, in order for the new license to be picked up, the current netlist needs to be updated by resetting and re-generating the IP output products before bitstream generation.

 

I have a purchased license for the ethernet subsystem:

ethernet_ip_status.JPG

I am not enabling the eth_avb_endpoint in the core configuration gui.

 

I have tried resetting all output products and regenerating/synthesising/implementing etc from scratch but the warning persists.

 

Can this either be safely ignored or is there some way to inform Vivado that I'm not actually using the eth_avb_endpoint core?

0 Kudos
Reply
1 Solution

Accepted Solutions
Moderator
Moderator
2,884 Views
Registered: ‎09-15-2016

Hi @rsclancy

 

Tool should not offer this Critical warning as you are using purchased license for ethernet subsystem. Discussion is already going on this and this issue is most likely to be addressed in Vivado 2018.1. I believe you can safely ignore this CW for now.

 

Regards

Rohit

Regards
Rohit
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

View solution in original post

18 Replies
Moderator
Moderator
2,885 Views
Registered: ‎09-15-2016

Hi @rsclancy

 

Tool should not offer this Critical warning as you are using purchased license for ethernet subsystem. Discussion is already going on this and this issue is most likely to be addressed in Vivado 2018.1. I believe you can safely ignore this CW for now.

 

Regards

Rohit

Regards
Rohit
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

View solution in original post

Moderator
Moderator
2,438 Views
Registered: ‎06-14-2010

Hello @rsclancy,

 

As correctly indicated by @thakurr, you can ignore this CW.

Here is some additional info/clarification on this matter:

 

Please note that prior 2017.1 version of Vivado, in Vivado you’d actually see a WARNING instead of a Critical Warning. However, from 2017.1 this was decided to be upgraded to a CW instead of WARNING (by the request of many other users).

 

As stated in the warning, an IP evaluation license can prevent the bitstream from working after the HW timeout. Therefore, in 2017.x a CRITICAL WARNING is now issued instead of a WARNING to prevent customer going to production with an eval license. 

 

In the IP catalogue, if you search for “Tri Mode Ethernet MAC” and then, right click on this core -> and then view “License Status”, you can see that this particular core has multiple feature controlled by separate license:

Forum_19.png

 

In relation to axi_ethernet, if AVB isn’t enabled, so no additional licenses are required, therefore this Critical WARNING can be safely ignored:

Forum_20.png

Therefore, as long as the TEMAC core is not generated with AVB enabled, then you only need a Tri-mode Ethernet MAC, which you do have and in this case, therefore you can either suppress the CW (i.e. in Vivado GUI, the ‘Messages’ section, you can just right-click on the message that you’d like to suppress and the option to suppress it is there as an option) or you can downgrade the CW to a WARNING/INFO, you can use the below Tcl command to do so, e.g.:

 

set_msg_config -id {Vivado 12-1790} -new_severity {INFO}

 

Hope this helps.

Kind Regards,
Anatoli Curran,
Xilinx Technical Support
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Observer
Observer
1,253 Views
Registered: ‎05-09-2017

Sorry to reopen this 2 year old thread, but this problem still persists for me in Vivado 2018, and this thread already contains a lot of relevant information.

I am using the Tri Mode Ethernet MAC IP,  but not the eth_avb_endpoint, but get the following error when generating the bitstream:

 

ERROR: [Vivado 12-1790] Evaluation License Warning: This design contains one or more IP cores that use separately licensed features. If the design has been configured to make use of evaluation features, please note that these features will cease to function after a certain period of time. Please consult the core datasheet to determine whether the core which you have configured will be affected. Evaluation features should NOT be used in production systems.

Evaluation cores found in this design:
    IP core 'eth_mac' (eth_mac_block) was generated with multiple features:
        IP feature 'eth_avb_endpoint@2015.04' was enabled using a design_linking license.
        IP feature 'tri_mode_eth_mac@2015.04' was enabled using a bought license.

Resolution: If a new IP Core license was added, in order for the new license to be picked up, the current netlist needs to be updated by resetting and re-generating the IP output products before bitstream generation.

Depsite the comment from @thakurr that this should be addressed in Vivado 2018, I see the problem in 2018.1 and 2018.3, but not in Vivado 2015.

Unfortunately the suggested workaround, to demote the severity of the message, does not work in 2018.3, as this is now an error message:

INFO: [Common 17-239] ERROR Messages are prohibited to be downgraded. Message 'Vivado 12-1790' is not downgraded.

Does anyone know of a solution fo this? I do not want to get a licence for a component which I am not using. In fact, according to the product page for the eth_avb_endpoint IP, the licence is bundled with Vivado. Does this mean it should already be included with built-in licences?

https://www.xilinx.com/products/intellectual-property/do-di-eavb-ept.html

Many thanks,

Glenn.

0 Kudos
Reply
Moderator
Moderator
1,219 Views
Registered: ‎06-14-2010

Hello @glennchid ,

This reporting issue isn't yet addressed, so that is why you are still seeing this behaviour.

If you are not using this additional IP AVB feature of this particular core, you can safely ignore these Evaluation License WARNINGs.
image.png

Please note that there are many IP Cores that come with multiple additional licensed features, and as the flow cannot tell if that feature is in use or not, hence the safety Evaluation License Critical Warning is issued. Please note a CR is filed on this, as these warnings are indeed confusing users when they actually have full valid licenses and no evaluation licenses were used at all, but still, Vivado incorrectly issues this Evaluation License Critical Warning.

I hope the above is clear.

Kind Regards,
Anatoli Curran,
Xilinx Technical Support
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Reply
Observer
Observer
1,199 Views
Registered: ‎05-09-2017

Hi @anatoli,

Thank you for the reply.

>>>If you are not using this additional IP AVB feature of this particular core, you can safely ignore these Evaluation License WARNINGs.

Unfortunately I can not just ignore this in Vivado 2018 as this WARNING message has been upgraded to an ERROR, and can not be downgraded - so I am unable to produce a bitstream for the device. I have been unable to find a workaround for this. Could this somehow be a artefact of upgrading the TEMAC IP from Vivado 2015? I am just surprised that other people are not experiencing problems with the TEMAC IP core in Vivado 2018.

Many thanks,

Glenn.

0 Kudos
Reply
Moderator
Moderator
1,117 Views
Registered: ‎06-14-2010

Hello @glennchid ,

Apologies for the late reply, as I only noticed your response now.

Indeed, if there is an error at the bistream generation and not just a Warning, that is an indication of a licensing issue at your end.
As you have confirmed, if you did this upgrade from Vivado 2015 to 2018, then you'd need to reset and then regenerate your output products for this IP, as your netlist would need to be updated after the upgrade of the IP was done.

Perhaps your current TEMAC lic is valid for the previous version of this IP however, is not valid for the updated version and in this case, if you wish to design with an updated IP Core version, a new/updated TEMAC license is needed in this case.

Therefore, can you please open your Vivado 2018.x and do report_ip_status and then see if a valid license is listed for this TEMAC IP core in the list?

You should see Purchased and not e.g. Design Entry (see my example screenshot below for one of the Video IP Core). Please attache a similar screenshot that you see at your end.

If you see Purchased and no Design Linking, then right click on the IP Core and selected “reset output products” and then “Regenerate output products” and then re-run synth, Implementation and generate bitstream. Then see if this time your bitstream still fails with the same error message or not?


image.png

Hope this helps.

Kind Regards,
Anatoli Curran,
Xilinx Technical Support
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Reply
Visitor
Visitor
935 Views
Registered: ‎10-31-2016

I can't believe that this inaccurate CRITICAL warning message is still being generated in 2019.1.

The message specifically states "IP core 'MicroBlaze_axi_ethernet_0_0' (bd_7d9e) was generated with multiple features: IP feature 'eth_avb_endpoint@2015.04' was enabled using a design_linking license."

The core was NOT generated with these features.

This led me on a wild goose chase to figure out whether I had inadvertently enabled this feature. Isn't Vivado smart enough to know that this feature wasn't actually enabled? Bad move Xilinx. Software should not say that a core was generated with an unlicensed feature unless it actually was generated with that feature.

0 Kudos
Reply
Explorer
Explorer
542 Views
Registered: ‎11-22-2016

Oh, this is as confusing as hell.

First the necessary context.  I am running Vivado 2019.2 and have used the IP Integrator Block Design to instantiate an AXI Ethernet Controller thus:

 

  # Create instance: axi_ethernet_0, and set properties
  set axi_ethernet_0 [ create_bd_cell -type ip -vlnv xilinx.com:ip:axi_ethernet:7.1 axi_ethernet_0 ]
  set_property -dict [ list \
   CONFIG.Frame_Filter {false} \
   CONFIG.PHY_TYPE {1000BaseX} \
   CONFIG.RXCSUM {Full} \
   CONFIG.SupportLevel {1} \
   CONFIG.TXCSUM {Full} \
   CONFIG.TransceiverControl {false} \
   CONFIG.axiliteclkrate {250} \
   CONFIG.axisclkrate {250} \
 ] $axi_ethernet_0

 

As is familiar in this thread, despite having a Purchased Tri Mode Ethernet MAC license, and the IP Status Report shows all components correctly licensed, with no mention of the AVB component, I get ERROR {Vivado 12-1790}:

[Vivado 12-1790] Evaluation License Warning: This design contains one or more IP cores that use separately licensed features. If the design has been configured to make use of evaluation features, please note that these features will cease to function after a certain period of time. Please consult the core datasheet to determine whether the core which you have configured will be affected. Evaluation features should NOT be used in production systems.

Evaluation cores found in this design:
IP core 'interconnect_axi_ethernet_0_0' (bd_7d6a) was generated with multiple features:
IP feature 'eth_avb_endpoint@2015.04' was enabled using a design_linking license.
IP feature 'tri_mode_eth_mac@2015.04' was enabled using a bought license.
IP core 'bd_7d6a_mac_0' (bd_7d6a_mac_0_block) was generated with multiple features:
IP feature 'eth_avb_endpoint@2015.04' was enabled using a design_linking license.
IP feature 'tri_mode_eth_mac@2015.04' was enabled using a bought license.

Resolution: If a new IP Core license was added, in order for the new license to be picked up, the current netlist needs to be updated by resetting and re-generating the IP output products before bitstream generation.

Here is what Report IP Status shows:

ip_status.png

Note that there is no mention of AVB.

Note that the error message describes itself as a Warning, but in fact it is flagged and treated as an ERROR.  In particular, running

set_msg_config -id {Vivado 12-1790} -new_severity {INFO}

does not work.  Indeed, UG835 says this:

IMPORTANT: You cannot downgrade a Vivado Design System ERROR message to make it less than an error

My colleagues and I have spent considerable effort chasing this.

However, and rather unexpectedly, it turns out that suppressing this message does work:

set_msg_config -id {Vivado 12-1790} -suppress

and I now appear to have a valid bitstream!

 

@anatoli, I know that you did suggest this (and it was your suggestion that finally put me on the right path), but given that everything else is so confused I think there are a lot of points that Xilinx could usefully pick up here.

  • First of all, error {Vivado 12-1790} cannot be downgraded to a warning ... but it can be suppressed.  This is particularly confusing.
  • Secondly, there is a mismatch between the configuration reported by this error and the configuration reported by Report IP Status.  This is extremely hard to interpret.
0 Kudos
Reply
Moderator
Moderator
536 Views
Registered: ‎06-14-2010

Hello @araneidae,

Based on what you've shown, all I see is a CRITICAL WARNING and not and ERROR.

Secondary, if you'd receive a licensing error at bitstream generation, you should not suppress this to a warning and MUST to resolved at this stage.

More info can be found here: https://www.xilinx.com/support/answers/75352.html

There is a report_ip_status -license_status command that should list all the IPs in the project, the license level that was used to generate the output products and the currently available license level, e.g.:

report_ip_status -license_status

Copyright 1986-2020 Xilinx, Inc. All Rights Reserved.

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

| Tool Version : Vivado v.2020.2.0 (win64) Build 0 Sat Jun 13 19:39:12 GMTDT 2020

| Date         : Tue Jun 16 17:06:10 2020

| Host         : XDCBENC33 running 64-bit major release  (build 9200)

| Command      : report_ip_status - license_status

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

 

IP License Status Summary

 

  1. Project IP License Status

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

 

Project IP Instances

+---------------+------------------------+------------------+-------------------------+-------------------------+

| Instance Name | Target                 | Required License | Generated License Level | Available License Level |

+---------------+------------------------+------------------+-------------------------+-------------------------+

| c_addsub_0    | Any                    | N/A              | N/A                     | Included                |

+---------------+------------------------+------------------+-------------------------+-------------------------+

| cpri_0        | Simulation             | cpri@2019.10     | Bought                  | Bought                  |

+---------------+------------------------+------------------+-------------------------+-------------------------+

|               | Synthesis              | cpri@2019.10     | Bought                  | Bought                  |

+---------------+------------------------+------------------+-------------------------+-------------------------+

|               | Change Log             | cpri@2019.10     | Bought                  | Bought                  |

+---------------+------------------------+------------------+-------------------------+-------------------------+

|               | Instantiation Template | cpri@2019.10     | Bought                  | Bought                  |

+---------------+------------------------+------------------+-------------------------+-------------------------+

Please check this and see what you'd see in your case?

Kind Regards,
Anatoli Curran,
Xilinx Technical Support
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Reply
Explorer
Explorer
533 Views
Registered: ‎11-22-2016

@anatoli wrote:

Hello @araneidae,

Based on what you've shown, all I see is a CRITICAL WARNING and not and ERROR.

What can I say.  It is flagged as an error in the messages pane and was followed by a second ERROR message to the effect that write_bitstream failed.


Secondary, if you'd receive a licensing error at bitstream generation, you should not suppress this to a warning and MUST to resolved at this stage.

In truth, I'd be surprised if a true ERROR can be suppressed, but Xilinx tools never cease to surprise.


There is a report_ip_status -license_status command that should list all the IPs in the project, the license level that was used to generate the output products and the currently available license level, e.g.:

report_ip_status -license_status

report_ip_status -license_status
Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
-----------------------------------------------------------------------------------------------------------------
| Tool Version : Vivado v.2019.2 (lin64) Build 2708876 Wed Nov  6 21:39:14 MST 2019
| Date         : Tue Nov 17 14:31:02 2020
| Host         : pc0073.cs.diamond.ac.uk running 64-bit Red Hat Enterprise Linux Workstation release 7.9 (Maipo)
| Command      : report_ip_status - license_status
-----------------------------------------------------------------------------------------------------------------

IP License Status Summary

1. Project IP License Status
----------------------------

Project IP Instances
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| Instance Name                        | Target     | Required License         | Generated License Level | Available License Level |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_axi_bram_ctrl_0_0       | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_axi_cdma_0_0            | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_axi_ethernet_0_0        | Simulation | tri_mode_eth_mac@2015.04 | Bought                  | Bought                  |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
|                                      |            | eth_avb_endpoint@2015.04 | Design_Linking          | Design_Linking          |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
|                                      | Synthesis  | tri_mode_eth_mac@2015.04 | Bought                  | Bought                  |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
|                                      |            | eth_avb_endpoint@2015.04 | Design_Linking          | Design_Linking          |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_axi_intc_0              | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_axi_lite_interconnect_0 | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_axi_pcie3_bridge_0      | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_axi_register_slice_0_0  | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_axi_register_slice_1_0  | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_blk_mem_gen_0_0         | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_ddr0_buf_0              | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_ddr0_crossbar_0         | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_ddr0_us_0               | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_ddr1_buf_0              | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_ddr1_crossbar_0         | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_dma_buf_0               | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_dma_ddr0_cc_0           | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_dma_ddr1_cc_0           | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_dma_ddr1_ds_0           | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_dma_xbar_0              | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_dsp_ddr1_buf_0          | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_dsp_ddr1_cc_0           | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_dsp_ddr1_pc_0           | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_mig_7series_0_0         | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_util_reduced_logic_0_0  | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_util_reduced_logic_1_0  | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_util_vector_logic_0_0   | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_util_vector_logic_1_0   | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_xlconcat_0              | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+
| interconnect_xlconstant_0_0          | Any        | N/A                      | N/A                     | Included                |
+--------------------------------------+------------+--------------------------+-------------------------+-------------------------+

Oh dear.  I see AVB flagged as "Design Linked".

So now what do I do?

0 Kudos
Reply
Moderator
Moderator
527 Views
Registered: ‎06-14-2010

Thanks @araneidae ,

Yes, indeed, based on the report you've generated, you have AVB enabled in the design.

Do you need this AVB or was it enabled by mistake?

If this is not needed, you can just re-generat this IP core and have this AVB unselected, and then reset and regenerate the output products and you should not see an error this time but a CRITICAL WARNING (as per earlier AR) and your bitstream can be successfully generated then.

Hope this helps.

Kind Regards,
Anatoli Curran,
Xilinx Technical Support
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Reply
Explorer
Explorer
526 Views
Registered: ‎11-22-2016

Oh oh oh oh.

My bad.

set_msg_config -severity "CRITICAL WARNING" -new_severity ERROR

I have this set at the top of my project build.

Generally quite a good idea ... but not so clever if you go and forget about it (that's been in this project and its ancestor for years).

Explorer
Explorer
522 Views
Registered: ‎11-22-2016

@anatoli wrote:

Thanks @araneidae ,

Yes, indeed, based on the report you've generated, you have AVB enabled in the design.

Do you need this AVB or was it enabled by mistake?

If this is not needed, you can just re-generat this IP core and have this AVB unselected, and then reset and regenerate the output products and you should not see an error this time but a CRITICAL WARNING (as per earlier AR) and your bitstream can be successfully generated then.

Hope this helps.


Well, this is what's confusing me immensely.  I have not enabled AVB, and I am regenerating the IP from the TCL script which I quoted in my posting earlier, I'll repeat it here:

  # Create instance: axi_ethernet_0, and set properties
  set axi_ethernet_0 [ create_bd_cell -type ip -vlnv xilinx.com:ip:axi_ethernet:7.1 axi_ethernet_0 ]
  set_property -dict [ list \
   CONFIG.Frame_Filter {false} \
   CONFIG.PHY_TYPE {1000BaseX} \
   CONFIG.RXCSUM {Full} \
   CONFIG.SupportLevel {1} \
   CONFIG.TXCSUM {Full} \
   CONFIG.TransceiverControl {false} \
   CONFIG.axiliteclkrate {250} \
   CONFIG.axisclkrate {250} \
 ] $axi_ethernet_0

As far as I can tell that's the complete instantiation of the entity and Enable AVB is definitely NOT checked when viewed from within the IP Integrator tool.

0 Kudos
Reply
Moderator
Moderator
509 Views
Registered: ‎06-14-2010

Hello @araneidae ,

I see, this make sense now.

This CW was updated to an ERROR, that makes sense now why you saw this error. However, bitstream generates a CRITICAL WARNING, and this again, due to the explanation in the AR that i've shared earlier.

And based on the reporting part, looks like avb is just reported, as the tool can't detect if this sub-option of this IP was enabled or not.

AFAIK, there isn’t a command to report the license status of IP within a netlist (so after bitstream was generated)

Normally, if you do a View Licensing info for this IP, this would list all of the licensing features of this IP (like in the example screenshot below). And this is what is reported in your case.

As you were mentioning an ERROR, i assumed that you have this AVB enabled, as otherwise it doesn't make sense why you'd see an ERROR and not a CW.

Anyhow, again, as you've shown here and AVB isn't enabled, and the CW is seen and not an ERROR, in this case please ignore this CW as per AR.

Hope this helps. 

image.png

Kind Regards,
Anatoli Curran,
Xilinx Technical Support
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Reply
Explorer
Explorer
470 Views
Registered: ‎11-22-2016

@anatoli, thank you for the help.

I think this leaves us with a couple of opportunities for Xilinx to improve the user experience:

  1. As discussed elsewhere in this thread, it's extremely confusing and quite unnecessary for Vivado to raise any kind of warning, let alone a critical warning, about the licensing of unused IP.
  2. More generally, it would be nice if the warning messages generated by Vivado were helpful and capable of being suppressed when not.  My project generates thousands of warnings, most of which come from Xilinx IP, and none of which are useful.  When doing software development in C I strive to get the compiler to generate as many warnings as possible, treat all warnings as errors, and eliminate them all.  VHDL development with Vivado seems to require exactly the opposite approach!
Observer
Observer
451 Views
Registered: ‎05-09-2017

@anatoli just a curiosity really, but I had thought that Critical Warnings were supposed to prohibit bitstream generation in a design. This is stated in UG911, and I assume this was the motivation for upgrading this particular message {12-1790} to a CW from a warning in 2017.1. I am finding though that my bitstream still builds okay with this CW in both 2018.3 and 2020.1 - is that the expected behaviour for this CW?

0 Kudos
Reply
Moderator
Moderator
433 Views
Registered: ‎06-14-2010

Hello @glennchid ,

Please note that prior 2017.1 version of Vivado, in Vivado you’d actually see a WARNING instead of a Critical Warning (CW). However, from 2017.1 this was decided to be upgraded to a CW instead of WARNING (by the request of other users). 

As stated in the warning, an IP evaluation license can prevent the bitstream from working after the HW timeout. Therefore, in 2017.1 a CRITICAL WARNING is now issued instead of a WARNING to prevent customer going to production with an eval license. 

As an example, if you look at the PG210: https://www.xilinx.com/support/documentation/ip_documentation/xxv_ethernet/v2_4/pg210-25g-ethernet.pdf, on page 9 you can see the below table.

image.png

Here you can see that if you are using this particular IP Core and also BASEKR is not used, then the only license that is required is the license that has the “xxv_eth_mac_pcs” and “x_eth_mac” features and from your own message in this Forum thread I can see this core was generated with a full/bought license file.
image.png

So, a valid license was found and used and you can successfully generate bitstream. Therefore, your license is working fine.

The reason for this CW is that the IP has multiple additional 'features' that are licensed (e.g.AVB or BASE-KR). However, the flow cannot tell if these additional features are in use or not and hence the safety warning is issued (well, in 2017.x, this was upgraded to a CW instead of a Warning).

 Also, if you can successfully generate your bitfile and just getting a CW message, then it shows that you have a valid license for this, as otherwise this (i.e. your bitstream generation) would error out instead, if you for example were using AVB, but had no valid license for this feature. No CW would be issued in this case but an error instead and bitstream will fail then.

In your case, this CW just to indicate that an IP core, Tri Mode Ethernet MAC, comes with multiple features that use separately licensed features. And if you were using these and in your design (like AVB additional feature/option), e.g. …

image.png

….before you'd be able to put this into production, you’d then need to obtain a separate full license for this AVB too. However, in your situation that is not the case as you are not using this (i.e. AVB) but just 'tri_mode_eth_mac' core on its own, and therefore you can safely ignore this CW (or downgrade this to a Warning instead, if you wish).

Unfortunately, there is no way to avoid this CW when dealing with the IP Core that come with these additional features that are not even in use in the design. All you can do here is to downgrade the CW to a WARNING/INFO, and to do this you can use the below Tcl command, e.g.:

 set_msg_config -id {Vivado 12-1790} -new_severity {INFO}

I hope the above is clear. 

Hope this helps.

Kind Regards,
Anatoli Curran,
Xilinx Technical Support
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Reply
Observer
Observer
386 Views
Registered: ‎05-09-2017

Hi @anatoli,

Many thanks for your quick reply. I think I understand the situation.

My question was about Critical Warnings in general - just whether they are supposed to inhibit bitstream generation or not. The only documentation I could find on this was UG911 which states that "Critical Warnings in the design are upgraded to Error at the bitstream generation (write_bitstream) stage, which stops the design process." This does not appear to be the case, at least with {Vivado 12-1790}, where I am able to successfully generate a bitstream in 2018.3 and 2020.1 despite the CW. I am not too concerned about this, but just wanted to understand.