cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
patocarr
Teacher
Teacher
375 Views
Registered: ‎01-28-2008

10G/25G Ethernet license evaluation

Jump to solution

Hi folks,

  I have a design that is based on xapp1305 for the PL Ethernet 10GbE, that fails to generate the bitstream even after adding the proper evaluation licenses. The license was created as node locked and installed in a floating license server. The node is the license server's NIC ID. In the screenshot, the Vivado License Manager is running on a different host and reports all licenses are available in the license server. As you can see, there's two licenses for 10G/25G: xxv_eth_basekr and xxv_eth_mac_pcs. The IP is configured for 10G Base-KR (though I also tested with Base-R) as shown in screenshot below.

  Here's some things I've tried,

  • Resetting the block design's output products before each run.
  • Generating the block design's output products before each run.
  • Clearing the IP cache.
  • Removing the entire Ethernet subsystem from the BD and recreating it.
  • Configuring for Base-R or Base-KR.
  • Manually removing the cache directory under the Vivado project for the 10G/25G IP, i.e. <project>.cache/ip/2020.2/<hash-for-IP>

Is there any place where to check exactly which feature(s) are being requested from the license server and their response? How about requesting a license to the server as test?

The error message is always the same and doesn't vary before or after adding the license(s).

[Common 17-69] Command failed: This design contains one or more cells for which bitstream generation is not permitted:
i_ps_top/ps_top_i/pl_ethernet/xxv_ethernet_0/inst/i_ps_top_xxv_ethernet_0_1_top_0/i_ps_top_xxv_ethernet_0_1_CORE (<encrypted cellview>)
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 believe there's either a problem in the license server with the added Ethernet features, or somehow the netlist is stuck and regardless of regeneration, it still fails to request a fresh license from the server. However, I'm at a loss how to narrow it down.

Any help will be appreciated.

Thanks,

-Pat

 

License manager:

Screenshot 2021-05-26-23_35_26-Vivado License Manager 2020.2_01.png

10G/25G Ethernet IP configuration:

Screenshot 2021-05-26-23_43_17-Re-customize IP_01.png

Give kudos if helpful. Accept as solution if it solves your problem.
https://tuxengineering.com/blog

0 Kudos
1 Solution

Accepted Solutions
anatoli
Moderator
Moderator
336 Views
Registered: ‎06-14-2010

Hello @patocarr ,

The main issue here, you are treating your Node-Locked license as a floating license. You can't start the Floating license server with a Node-Locked (NL) lic file.

A node-locked license key is for use on one computer, and is tied to that computer. You do not need to run a license server if you are using a node-locked license.

Floating is a license that lives on a license server. Any computer can check out the license and use it, then check it back in when done and allow another computer to use it. Only one computer can use a license at a time.

Floating license keys contain the hostname and hostID of the that floating license server machine.

The license manager daemon and vendor daemon must be running on the license server whose hostname and hostID are specified in the license key.

When a user quits an application, all licenses used during that session are returned to the pool of available licenses.

 

Some additional info that may be useful:

Please note that the license is checked out at the beginning of each run (i.e. Synthesis, Implementation, bitstream generation) and Vivado will keep the entire license checked out and will only release the license file once Synthesis process completes in Vivado.

Basically, on the same machine, you can run multiple jobs locally on that single license. Once the process is started, the entire license is checked out on this particular machine, so you can run multiple jobs locally on that single license.

The situation is, 1 license checked out per user regardless of how many jobs or how many different machines they run on, only when using the load sharing facility (LSF) server farm to run additional jobs (e.g. multiple synthesis runs running in parallel in the server farm), i.e. spawn multiple jobs across network machines.

A single user will not need to have another floating license if he is running his designs on a single machine. However, if a single user is planning to run e.g. the same design on a machine A and simultaneously on a different machine (B), then in this situation he would need 2 floating licenses.

 

Which type of license if better?

You see, if you buy a FL license, you’d need to set it up on a network by starting license server etc.. Then the users just point their environment variable (XILINXD_LICENSE_FILE) to the that server and can then Check OUT and back IN their FL licenses.

Please note that Floating license is checked out for each "process (synthesis, implementation, etc)". Once the process is started, the entire license (i.e. 1 out of 5 seats of that license) is checked out for the duration of each process run. Even if you are running a Synthesis run, it will first check out the entire license file out of the floating license Server and will then use e.g. Synthesis licensing feature out of it. Once Synthesis completes, it then returns this Synthesis licensing feature back and once done, the entire license is Checked back in then to the floating license server.

Unlike with Node-Locked licenses, FL l can’t be just put into a folder and Vivado will start using this. As you can see, this requires maintenance from the network setup, debug etc.

With Node-Locked licenses, license is uncounted, means there are no seats attached to this license. However, this license will only work on that particular machine and nowhere else.

Therefore, please don't add any of the NL licenses into/with FL license file and then start the server, as this will make syntax of the entire FL license incorrect and the entire license will misbehave altogether then.

To begin, edit your FL license and remove any of the NL license out of this FL lic file.

With Node-Locked lic file, all you need is to create a folder on the machine that you've generated this license for (as you have generated this with Host Name and Host ID of this particular machine, so the license will only work on that particular machine and nowhere else (unless you are using a Dongle)), e.g. C:/Licenses, and just put this NL license into this folder. Then set your XILINXD_LICENSE_FILE env. variable to point to this folder (and not to the lic file itself, as Vivado just need to know where you keep all of your Node-Locked licenses. In this folder, just call all of your NL lic file differently, and Vivado will then be able to find this folder and scan and use the required NL licenses). 

Hope the above is clear and helps.

If you need any further assistance on this, please let me know.

Kind Regards,
Anatoli Curran,
Xilinx Technical Support
------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal, take a look at our Versal Design Process Hub and our
Versal Blogs

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

View solution in original post

4 Replies
anatoli
Moderator
Moderator
337 Views
Registered: ‎06-14-2010

Hello @patocarr ,

The main issue here, you are treating your Node-Locked license as a floating license. You can't start the Floating license server with a Node-Locked (NL) lic file.

A node-locked license key is for use on one computer, and is tied to that computer. You do not need to run a license server if you are using a node-locked license.

Floating is a license that lives on a license server. Any computer can check out the license and use it, then check it back in when done and allow another computer to use it. Only one computer can use a license at a time.

Floating license keys contain the hostname and hostID of the that floating license server machine.

The license manager daemon and vendor daemon must be running on the license server whose hostname and hostID are specified in the license key.

When a user quits an application, all licenses used during that session are returned to the pool of available licenses.

 

Some additional info that may be useful:

Please note that the license is checked out at the beginning of each run (i.e. Synthesis, Implementation, bitstream generation) and Vivado will keep the entire license checked out and will only release the license file once Synthesis process completes in Vivado.

Basically, on the same machine, you can run multiple jobs locally on that single license. Once the process is started, the entire license is checked out on this particular machine, so you can run multiple jobs locally on that single license.

The situation is, 1 license checked out per user regardless of how many jobs or how many different machines they run on, only when using the load sharing facility (LSF) server farm to run additional jobs (e.g. multiple synthesis runs running in parallel in the server farm), i.e. spawn multiple jobs across network machines.

A single user will not need to have another floating license if he is running his designs on a single machine. However, if a single user is planning to run e.g. the same design on a machine A and simultaneously on a different machine (B), then in this situation he would need 2 floating licenses.

 

Which type of license if better?

You see, if you buy a FL license, you’d need to set it up on a network by starting license server etc.. Then the users just point their environment variable (XILINXD_LICENSE_FILE) to the that server and can then Check OUT and back IN their FL licenses.

Please note that Floating license is checked out for each "process (synthesis, implementation, etc)". Once the process is started, the entire license (i.e. 1 out of 5 seats of that license) is checked out for the duration of each process run. Even if you are running a Synthesis run, it will first check out the entire license file out of the floating license Server and will then use e.g. Synthesis licensing feature out of it. Once Synthesis completes, it then returns this Synthesis licensing feature back and once done, the entire license is Checked back in then to the floating license server.

Unlike with Node-Locked licenses, FL l can’t be just put into a folder and Vivado will start using this. As you can see, this requires maintenance from the network setup, debug etc.

With Node-Locked licenses, license is uncounted, means there are no seats attached to this license. However, this license will only work on that particular machine and nowhere else.

Therefore, please don't add any of the NL licenses into/with FL license file and then start the server, as this will make syntax of the entire FL license incorrect and the entire license will misbehave altogether then.

To begin, edit your FL license and remove any of the NL license out of this FL lic file.

With Node-Locked lic file, all you need is to create a folder on the machine that you've generated this license for (as you have generated this with Host Name and Host ID of this particular machine, so the license will only work on that particular machine and nowhere else (unless you are using a Dongle)), e.g. C:/Licenses, and just put this NL license into this folder. Then set your XILINXD_LICENSE_FILE env. variable to point to this folder (and not to the lic file itself, as Vivado just need to know where you keep all of your Node-Locked licenses. In this folder, just call all of your NL lic file differently, and Vivado will then be able to find this folder and scan and use the required NL licenses). 

Hope the above is clear and helps.

If you need any further assistance on this, please let me know.

Kind Regards,
Anatoli Curran,
Xilinx Technical Support
------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal, take a look at our Versal Design Process Hub and our
Versal Blogs

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

View solution in original post

patocarr
Teacher
Teacher
321 Views
Registered: ‎01-28-2008

Hi @anatoli 

Thank you for your insightful response and explanation. Mixing the NL license into the FL license file was admittedly a Bad Idea™. I've gone back to the licensing site and added the Ethernet evaluation licenses to our current floating license file. Now it's one license file to download with all the needed FL licenses, no mixing. Then restarted the license server processes (lmgrd & xilinxd) through systemd, ensuring these processes were stopped and then started. At this point, the license server should be fixed.

However, after resetting & regenerating the block design output products, the bitstream generation failed yet again. Please note the IP within the block design can not be reset individually, at least I haven't found a way to do it. The entire block design must be reset. This is a very time consuming procedure that's taken the best of two days to debug. Is there a faster way to test whether the license will be accepted, rejected or otherwise fail to be found, before doing a 2 hour build each time? How about looking which license feature was "locked" in the netlist, in order to know whether regeneration is necessary?

 

Thanks again for your insight, Anatoli.

-Pat

 

Give kudos if helpful. Accept as solution if it solves your problem.
https://tuxengineering.com/blog

0 Kudos
patocarr
Teacher
Teacher
308 Views
Registered: ‎01-28-2008

Hi,

  Somehow after resetting the output products, Vivado would still remember the old setting in the netlist, but restarting Vivado and then doing the implementation this time the bitstream was generated correctly.

Thanks again, Anatoli.

-Pat

 

Give kudos if helpful. Accept as solution if it solves your problem.
https://tuxengineering.com/blog

anatoli
Moderator
Moderator
220 Views
Registered: ‎06-14-2010

Hello @patocarr ,

Thanks for the info.

Just to add to your details that you've provided, in case anyone else sees or comes across this post, you can also run report_ip_status -license_status, this will show and display all the IPs found in your design and the license level that was used when these IPs were generated
image.png

You can also directly query an individual IP:

e.g.:

get_property used_license_keys [get_ips cpri_0]

{{simulation {cpri@2019.10 bought}} {synthesis {cpri@2019.10 bought}} {changelog {cpri@2019.10 bought}} {instantiation_template {cpri@2019.10 bought}}}

IPs generate what we call “output products” which are the files that get passed on to synthesis and simulation. They have a concept of “stale”. So, for example, if a parameter changes on the IP but the output products aren’t re-generated, they will become “stale”. Therefore, you can check if an IPs outputs are stale using the report_property [get_ips <xyz>] command and look for “stale_targets”. We added the concept that an IPs output products would go stale if they were previously generated using a “lower” license than is currently available.

Hope this helps.

Kind Regards,
Anatoli Curran,
Xilinx Technical Support
------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal, take a look at our Versal Design Process Hub and our
Versal Blogs

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