The FlexLM™ product is the most commonly used License Manager system for EDA software, and a product of the Globetrotter Division of the Macrovision Corporation.

While many engineers are familiar with the floating license concepts provided by FlexLM, very few companies that I've worked with have it configured efficiently and robustly. Their licensing implementation becomes problematic as they grow to multiple geographic locations and start to deploy batch queuing and resource management systems on their networks.

Background
FlexLM is implemented as a client-server architecture, with your EDA application acting as a client that talks to a license server in order to obtain the license required to run your EDA application. The license server usually runs as a daemon process, which is composed of LMGRD (License ManaGeR Daemon) coupled with an application specific daemon known as the Vendor Daemon. The Vendor Daemon understands the particular licensing scheme for that vendors application, which is expressed as one or more "FEATURE" lines in the vendor license file, usually called the "license.dat" file.

Most of my customers utilize a common directory tree on one of their fileservers to hold the executable files for the application, as well as the application license files (the license.dat files), and the Vendor Daemons. They export that directory tree (via NFS) to each of the individual computers that need to be able to execute that licensed application. A user who wishes to execute a licensed application will set an environment variable to point to the exported license.dat file as follows :

setenv LM_LICENSE_FILE /tools/vendorA/license/license.dat:/tools/vendorB/license/license.dat

The above example demonstrates two different vendors (A & B), each providing a unique license file for their applications. Let us take a brief look at what happens when you execute a licensed application for Vendor B :

1. The EDA application begins to execute and calls the client license module, which has been built into the application by vendor B.
2. The client license module examines the user environment (the LM_LICENSE_FILE list) to determine the location of the license file.
3. The client license module performs an NFS read of the first license file in the LM_LICENSE_FILE list.
4. The client license module parses the first license file, looking for the VENDOR name.
5. When it is not found, the client license module performs an NFS read of the next license file in the LM_LICENSE_FILE list.
6. When the correct VENDOR name (vendor B) is found, the client license module then parses the host name of the license server node.
7. The client license module performs a scan of the TCP/IP ports on the license server node to to locate the port number that the license manager daemon (LMGRD) is listening to.
8. The license module establishes a connection with the license manager daemon (lmgrd) and tells it what vendor daemon it needs to talk to.
9. The license manager daemon (lmgrd) determines which machine and port correspond to the vendor daemon and sends that information back to the client license module.
10. The client license module establishes a connection with the specified vendor daemon and sends a request for a specific licensed "feature".
11. The vendor daemon checks to see if any licenses of that "feature" are available and sends a grant or denial back to the client license module.
12. The client license module in the EDA application grants or denies the use of that "feature".
13. That "feature" of the EDA application begins executing, if a grant occurred. Otherwise the application usually quits, often ungracefully...

Combining License Files:
So right away, you can see that combining the two license files into one file will usually provide some efficiency. However, you need to use the most recent LMGRD version for this to work (and sometimes it still won't work). In addition, if your license file gets very large, if can also increase the time required to parse it. I usually combine only those license files that are used in the same workflow. In other words, your engineers usually don't require an accounting application, and the accounting staff usually don't require EDA applications. Only combine license files for similar work flows and the license.dat file size won't get unwieldy.

Using Port Numbers:
The second way to streamline this process is to provide the client application with the port number of the licensing daemon to begin with, instead of requiring it to parse the license file for that information.

setenv LM_LICENSE_FILE license_manager_nodename@license_manager_port_number

And a specific example:

setenv LM_LICENSE_FILE snoopy@27000;snoopy@27001

Where "snoopy" is the computer that is running the LMGRD and Vendor daemons. While this was not recommended with LMGRD version 5.0 and earlier, most current EDA applications use LMGRD version 7.1 or later and this is preferred.

In addition, you do not need to export the license.dat file when using port addressing like this. By placing the license file (license.dat) on the local file system of the license server, you usually eliminate one point of failure, namely the NFS read of the license file from the fileserver.

While this may only shave a second or so from your application startup time, if you are running many small jobs (i.e. cell library characterization) the time savings will quickly become significant.

Robustness:
I usually like to configure a second or backup license server if you have a large number of licenses. This provides some fail over capability and load distribution. If you have say, twenty (20) licenses for a particular application, then request two (2) license files of ten (10) licenses each from each of your vendors. Place these two (2) license files on separate license servers and have half of your engineers use :

setenv LM_LICENSE_FILE snoopy@27000;linus@27000

while the other half use :

setenv LM_LICENSE_FILE linus@27000;snoopy@27000

That way, if either license server goes down, you still have half of your licenses available for use. One word or caution here though, usually subsequent feature requests go to the same license server that the client license module originally connected with. If you have a small number of licenses this may cause a subsequent feature request to fail on one server, when there are still licenses available on the second server.

Links:
Macrovision Corporation
Globetrotter Division
FlexLM Product

Note Bene:
Moxon Design does not support or condone software theft, piracy, or violation of your End User Licensing Agreements (EULA). The tips and tricks presented here are intended to assist honest customers achieve the best utilization of their purchased software resources.