As I’ve said before, in every sizeable EDA company that I’ve worked, a huge percentage, 30-50%, of all calls to the support hotline are to do with license keys. Why is this so complicated? Are EDA software engineers incompetent?
Most of these problems are not directly with the license key manager (the most common, almost universal, one is FlexLM). Sometimes there are direct issues because customers want to run a single license server for all the EDA tools they have from all their vendors, something that the individual EDA companies have a hard time testing since they don’t have access to everyone else’s tools. More often license problems are simply because licenses are much more complicated than most people realize.
All sorts of license problems can occur, but here is a typical one. The customer wants some capability and discusses with the salesperson who provides a quote for a particular configuration. Eventually an order gets placed and a license key is cut for that configuration. At this point, and only then, it turns out that the configuration doesn’t actually deliver the capability that the customer thought he’d asked for, and that the salesperson thought she’d provided. Something is missing. The customer calls support to either to report a bug or, if they realize what is going on, to try and get the specific license added. Often an option has been omitted from the configuration (such as a special parser) that everyone assumed was included, or assumed that it wasn’t needed, or that turned out to be bundled with some other capability in a mysterious way.
Digital Equipment, in the heyday of the Vax, actually had an AI program XCON salespeople had to use to configure Vax computers since otherwise they always had similar problems, although in the hardware domain. The order omitted a required cable, or overloaded a power supply or left out a software driver. Without this error being corrected, the delivered system could not be assembled in a way that would run. This is worse still in the hardware world since it takes from a couple of days to a couple of weeks to get a missing cable to the customer site. It can’t simply be fixed over the phone.
The fundamental problem is that it is hard to map capabilities that marketing wants to sell and price, into the actual control points in the software that permit or deny certain activities, and the ways in which the different components interact. Few people have a good understanding of this, and there is no correct answer to many of the questions.
Here’s an example. Should a long-running tool claim a license when it starts for an optional feature that might be required later? Or should it wait until it has run for hours and then fail if a license is not then available? Which inconveniences the user less? There are pressures on the vendor side to want to claim licenses as early as possible (so the customer needs to buy more licenses) which at least means that if a tool is going to fail due to lack of licenses, it does so immediately without having done a lot of wasted work, and in a part of the code where it is easy to handle. There are pressures from the customer side to want to claim licenses as late as possible (so they don’t get held for long periods when they are not being truly used) but also to expect that the tool will behave gracefully when their paucity of licenses comes to light and the run is deep in the innards of the tool when it finds out it cannot continue.
Interactive tools are worse still. Do you claim a license in order to show the capability on a menu? Or do you show a menu item that may fail due to lack of a license when you click it? Do you behave the same if the customer has licenses but all are currently in use, versus the customer not having any licenses to that product at all?
None of these problems typically affect the engineers developing the product or their AEs. Usually all employees have a “run anything” license. The licenses issues often only come to light when customers run into problems. After all, they may be the only site in the world running that particular configuration. Some testing can be done easily, but exhaustive testing is obviously impossible.
EDA companies want to create incremental revenue for new capabilities, so they don’t want to simply give them to all existing customers even though they may want to make sure that all new customers are “up to date.” This drives an explosion of license options that sometimes interact in ways that nobody has thought of.
Until some poor engineer, in the middle of the night, tries to simulate a design containing two ARM processors. That’s when they discover that nobody thought about whether two ARM simulations should require two licenses or one. The code claims another license every time an ARM model is loaded, in effect it says two. Marketing hadn’t considered the issue. Sales assured the customer that one license would be enough without asking anyone. Nobody had ever tried it before. “Hello, support?”