How Many Licenses Do You Buy?

An informal survey of RTDA customers reveals that larger companies tend to buy licenses based on peak usage while smaller companies do not have that luxury and have to settle for fewer licenses than they would ideally have and optimize the mix of licenses that they can afford given their budget. Larger companies get better prices (higher volume) but the reality is that often they still have fewer than they would like. Or at least fewer than the engineers who have to use the licenses would like.

Licenses are expensive so obviously having too many of them is costly. But having too few is costly in its own way: schedules slip, expensive engineers are waiting for cheap machines, and so on. Of course licenses are not fungible, in the sense that you can use a simulation license for synthesis, so the tradeoff is further complicated by getting the mix of licenses right for a given budget.

There are two normal ways to change the mix of licenses for a typical EDA multi-year contract. One is at contract renewal to change the mixture from the previous contract. But large EDA companies often also have some sort of remix rights, which lets the customer exchange lightly (or never) used licenses for ones which are in short supply. There are even more flexible schemes for handling some peak usage, such as Cadence’s EDAcard.

Another key piece of technology is to have a fast scheduler which can move jobs from submission to execution faster. When one job finishes and gives up its license, that license is not generating value until it is picked up by the next job. Jobs are not independent (in the sense that the input to one job is often the output from another). The complexity of this can be staggering. One RTDA user has a task that requires close to a million jobs and involves 8 million files. As we need to analyze at more and more process corners, these numbers are only going to go up. Efficiently scheduling this can make a huge difference to the license efficiency and to the time that the entire task takes.

There are a number of different ways of investigating whether the number of licenses is adequate and deciding what changes to make.

• Oil the squeaky wheel: some engineers complain loudly enough and the only way to shut them up is to get more licenses.
• Peak demand planning: plan for peak needs. This is clearly costly and results in relatively low average license use for most licenses
• Denials: look at logs from the license server. But if using a good scheduler like NetworkComputer there may be no denials at all but that is still not a sign that the licenses are adequate
• Average utilization: this works well for heavily used tools/features whereas for a feature that is only used occasionally the average isn’t very revealing and can mask that more licenses would actually increase throughput
• Vendor queueing: this is when instead of getting a license denial the request is queued by the license server. A good scheduler can take advantage of this by starting a limited number of jobs in the knowledge that a license is not yet available but should soon be. It is a way of “pushing the envelope” on license usage since the queued job has already done some preliminary work and is ready to go the moment a license is available. But as with license denial, vendor queuing may not be very revealing since the job scheduler will ensure that there is only a small amount.
• Unmet demand analysis: this relies on information kept by the job scheduler. It is important to take care to distinguish jobs that are delayed waiting for a license versus jobs that are delayed waiting for some other resource, such as a server. Elevated levels of unmet demand are a strong indicator of the need for more licenses.

A more formal approach can be taken with plots showing various aspects of license use. The precise process will depend on the company, but the types of reports that are required are:

• Feature efficiency report: the number of licenses required to fulfill requests of specific software 95%, 99% and 99.9% of the time
• Feature efficiency histograms: showing the percentage of time each feature is in use of a time frame, and the percentage of time that individual licenses are actually used
• Feature plots: plots of a period of time showing capacity, peak usage and average usage, along with information on licenses requests, grants and denials

These reports can be used to make analyzing the tradeoffs involved in licenses more scientific. Of course it is never going to be an exact science, the jobs running today are probably not exactly the same ones as will run tomorrow. And, over time, the company will evolve: new projects get initiated, new server farms come online, changes are made to methodology.

No matter how many licenses are decided upon, there will be critical times when licenses are not available and projects are blocked. The job scheduling needs to be able to handle these priorities to get licenses to the most critical projects. At the same time, the software tracking usage must be able to provide information on which projects are using the critical licenses to allow engineering management to make decisions. There is little point, for example, in redeploying engineers onto a troubled project without also redeploying licenses for the software that they will need.