DEV Community: Misha Zaslavskiy

To buy or to build - that is the question for a CAD manager

Misha Zaslavskiy — Fri, 19 Sep 2025 17:52:24 +0000

I've been asked this question so many times over the years, so I thought I don't need to think about the answer. But maybe the right answer is now different?

Any semiconductor company needs a lot of CAD tools. And while it's tempting (and rewarding) to develop your own "pet" tool, often this wasn't the best idea. Yes, such a tool will never be available to your competitors, which is a major selling point for the sponsor. With a home-grown tool you have full control over the list of features. Your own company decides how long it should be supported and when it's time to retire or refactor it. And you are insured from a sticker shock during the next EDA (Electronic Design Automation) contract renewal.

However here is the hard truth: a tool productization and long-term support could easily take 10X more resources than the first viable version. It's exciting to jump into building a cool prototype, and equally easy to underestimate efforts necessary for thorough testing, documentation and trainings. Every home-grown tool adds a long-term support load for the team, and imagine what will happen if the original developer decides to leave the company? There will surely be bugs discovered, new feature requests and evolution of the adjacent tools that provide input and rely on the output. EDA companies are able to spread the cost of this work across many clients, and even then their support and documentation is not always perfect. But unless your company sells EDA tools, my default recommendation was always: buy all the tools that you need and you can afford. There could be exceptions that only prove the general rule, say this tool will be intertwined with the "secret sauce" of your business, or you need something that doesn't exist yet on the market.

Now if all those arguments make sense, why would I reconsider them now? Well, software development is rapidly changing with AI assist tools like Cursor and Copilot. Whether we like it or not, it's already noticeable in the job market. The cost of SW development is going down, and I think this is also applicable to the long-term support efforts. LLMs are quite good at writing unit tests and documentation. Alternatively with full access to the source code, documentation is not that critical anymore. Instead of sifting through manuals, which could be out-of-date or not comprehensive, the end user could now ask a question in the chat window.

Here is a practical example to demonstrate this idea. In my recent two jobs I've been involved in the roll-out of IPLM - Intellectual Property Lifecycle Management tool. There is a need to track internal and external IP blocks that go to a semiconductor product. Those blocks form a hierarchical tree with arbitrary depth, and each IP has set of common attributes like provider, revision and IP maturity level (alpha, beta, production), as well as set of unique attributes that are only applicable to specific kind of IPs, like the output voltage for a bandgap, or clock frequency for a CPU core. The goals of IPLM system is to store all this information in the internal database and provide API for IP registration, search mechanism and release/audit capabilities for a product tape-out. And additional value of such tool comes from integration with data repositories, analog and digital development flows, ticketing system, etc. There are commercial IPLM tools available on the market, for example Keysight HUB and Perforce IPLM. They are not cheap, and more importantly integration of those tools in the workflow still requires a substantial amount of effort from the CAD team. An experienced engineer on my team spent couple months setting-up one of them, and it was only possible after we established regular calls with the supplier application engineer.

As far as I know, there were no specialized open-source IPLM tools available. So I decided to build and share a prototype for the basic IPLM system. The implementation is Python and MySQL database, and it has a registry of manufacturing processes, hierarchical IP classification and IP tree. Here is a GitHub repository.

The development process looked like this: define architecture, specify requirements, use Cursor AI code assist to do heavy lifting for coding, and iterate to pass tests and fine-tune functionality. The overall process took me ~ 1 week, some of this time spent on setting-up MySQL database, personal GH repo tokens and debugging CI/CD actions. For a project of this scale, you don't even need to spend money on a Cursor subscription, I run out of free tokens when the work was almost complete. Cursor is affordable and geared toward personal usage anyway, that's why I like it, but it's hard to beat free 😄

In my estimation the amount of effort needed to bring such in-house prototype to production might be less than setting-up a commercial tool, and we could also save on licenses.

Let me know in the comments below what you think about this experiment. Also if you find this project useful, what new features are the most important for your flow?

Use LLM for EDA licenses analysis

Misha Zaslavskiy — Thu, 28 Aug 2025 21:52:04 +0000

Why?

If your company has an EDA license monitoring system, you have a lot of useful data available for analysis.

Now what do we do with this "big-data"? There most likely will be time gaps caused by infrastructure failures/maintenance, as well as evolution of suppliers and available licenses over time, which certainly complicate manual analysis.

With the advancement of AI/ML tools, you could now connect your Prometheus database with AI assist tool via what's called MCP: Model Context Protocol. This allows LLM to query your database, automatically load relevant and up-to-date information in the context window, and as a result LLM will be able to accurately answer questions about usage, trends or whatever else you are interested in.

How?

Here is an example how to connect Prometheus DB to Cursor AI code editor.

Go to Cursor Settings -> Tools & Integration -> New MCP Server and add this code to the .cursor/mcp.json file:

{
  "mcpServers": {
    "prometheus": {
      "command": "docker",
      "args": [
        "run",
        "--network",
        "cad",
        "--name",
        "prometheus-mcp-server",  
        "-p",
        "8000:8000",
        "-i",
        "--rm",
        "-e",
        "PROMETHEUS_URL",
        "ghcr.io/pab1it0/prometheus-mcp-server:latest"
      ],
      "env": {
        "PROMETHEUS_URL": "http://prometheus:9090"
      }
    }
  }
}

Note that this example uses Docker deployment of MCP server. You don't need to run this container manually, Cursor will do it automatically. For that option you'll obviously need access to Docker, and Prometheus DB should run on the same cad docker network. If your setup is different, you'll need to modify this JSON file accordingly, see the source reference at the bottom of this post.

If your MCP tool shows green status and 5 enabled tools like in this snapshot, you are good to go.

Otherwise check the Docker container status and logs. Or you could ask Cursor itself to assist with debugging, it gave me good hints after I renamed Docker network and accidentally broken my setup. If you decide to go this route, make sure to add mcp.json file into the context and be specific that you have issue with MCP tools.

Now when our MCP tool is up, let's test it. Here is the Cursor chat prompt example:

query available licenses through MCP

And the result:

This table gives accurate summary of all licenses available in my system right now, current usage and overview of the infrastructure. Not a bad summary for beginning, right? Now you could ask about historical usage, deep-dive into specific license utilization, find who are the most active users, or search for anomalies and outliers. And all of this can be done now using natural langue instead of learning PromQL - specialized Prometheus query language. The LLM also shows in the chat window the PromQL queries that were used to obtain necessary information. This could help to speed-up writing code for new dashboards.

Please keep in mind that LLM output may be not always accurate, so it's a good idea to double check findings independently before acting on them.

Sources

What Is the Model Context Protocol (MCP) and How It Works

Prometheus MCP server

EDA license utilization dashboard

Misha Zaslavskiy — Thu, 28 Aug 2025 15:25:57 +0000

The 1st post in this series describes installation of the flexlm_exporter utility with a standard Grafana dashboard. Out-of-the box this dashboard gives very useful historical usage statistic. However I always wanted to see more concise summary. For the contract renewal or license remix, CAD team needs to identify underutilized and overutilized licenses. With the default dashboard this could be a tedious process if your company uses many EDA tools. Moreover EDA companies are not financially interested to make it any easier, and their license scheme is often quite murky. A single tool may use dozens of different licenses depending on the input, tool version, available hardware, phase of the moon, or who knows what else. Some licenses could be used interchangeably for the same run, others can be only used in conjunction with one another, and more often then not, those details are not described in the documentation.

To simplify long-term utilization analysis, I prepared an additional dashboard. There are 3 graphs so far:

weekly average time-series that allows to filter-out the noise from nights/weekends and look for trends
bar chart with average utilization over the whole plotting period, say the last 6 months
utilization table with average, peak, zero and 100% usage metrics.

Here is the installation link from Grafana dashboards library.

Licenses monitoring dashboard installation

Misha Zaslavskiy — Fri, 22 Aug 2025 23:15:30 +0000

Motivation

In this post I will share my notes for installation and configuration of 3 open-source tools that together work as an Electronic Design Automation (EDA) license monitoring system. The tools are flexlm_exporter, Prometheus time-series DB and Grafana observability platform.

While installation of each one of those components separately is well-described in their documentation, I haven't found online any resources that would give full picture how to configure them together and which installation option (cloud, bare metal, docker) to choose. So after some trial-and-error experiments here is a description of functional configuration. Obviously it's not the only viable option, but it could serve as a starting point for further improvements and production deployment in your environment.

Background

EDA licenses are expensive, and companies big and small want to optimize their license usage as much as possible. The first step for that is a usage monitoring system that goes beyond standard capabilities of lmstat utility. It allows to analyze historical license usage and answer essential questions like:

do we have enough licenses of tool X? Ok, if the answer is no, you'll probably get plenty of complains from your hardware designers. But how many extra do we need, or maybe the issue is not the license amount but the infrastructure?
are we paying for too many licenses of tool Y?
is there an increase/decrease in demand for tool Z recently?

This is crucial information that managers and executives need to define budget for the next EDA contract renewal, and the CAD team needs during regular license remix.

Some companies choose to write their own system for license monitoring, others use commercially available options.

In my experience the open source solution described in this post works pretty well. It is reasonably simple to install and maintain and will not break the bank.

Note that Prometheus DB and Grafana are powerful and multi-purpose tools. Chances are that they are already installed in your organization, and you only need to configure the remaining pieces. Otherwise keep in mind that besides license monitoring, there are many other use cases where Grafana shines: compute cluster performance dashboards, alerts in case of infrastructure issues, collection of PPA and code coverage metrics, etc.

Architecture

There are 3 components you'll need:

flexlm_exporter, kudos to Mario Trangoni for developing and sharing!
Prometheus time series DB
Grafana observability platform and FLEXlm dashboard

Installation

All 3 applications could be installed directly in your Linux environment or as Docker containers. In my opinion containerized installation is a cleaner way, and it also takes care of most dependencies. So below are the configuration files and gotchas for Docker-based installation.

flexlm_exporter

Prepare a YAML configuration file that defines all suppliers/licenses that you'd like to monitor, and paths to license files. Here is the content of my experimental licenses.yaml file:

licenses:
  - name: dirt_cheap_llc 
    license_file:  /some_path/dirt_cheap_llc.txt
    features_to_exclude: 
    monitor_users: True
    monitor_reservations: True
    monitor_versions: False
  - name: arm_and_leg_inc
    license_file:  /some_path/arm_and_leg_inc.txt
    features_to_exclude:
    monitor_users: True
    monitor_reservations: True
    monitor_versions: False

Create an executable file with this content and customize your paths before running:

#!/usr/bin/bash

export DOCKER_REPOSITORY="quay.io/mjtrangoni/flexlm_exporter:latest"

# two variables below need to be customized with the actual paths in your network

# define path to the directory with lmutil and other license utilities here
export LMUTIL_LOCAL="some_path"

# put path to your YAML config file here
export CONFIG_PATH_LOCAL="some_path/licenses.yaml" 

docker run --name flexlm_exporter -d -p 9319:9319 \
    --network cad --network-alias flexlm_exporter \
    --volume $LMUTIL_LOCAL:/usr/bin/flexlm/ \
    --volume $CONFIG_PATH_LOCAL:/home/exporter/config/licenses.yml \
    $DOCKER_REPOSITORY --path.lmutil="/usr/bin/flexlm/lmutil" \
    --path.config="/home/exporter/config/licenses.yml"

Notice the --network cad --network-alias flexlm_exporter options. This trick helps to connect flexlm_exporter with Prometheus DB. Docker network allows to set aliases, that are more stable and easier to use vs IP addresses. Before executing this file, you'll need to create a new Docker network using those commands:

docker network create cad
docker network ls

Now it's time to run the executable file and check that flexlm_exporter Docker container is running without issues.

Prometheus DB

Prepare configuration prometheus.yml file. This file defines where Prometheus "scrapes" the data from. In our case we instruct Prometheus to get information from the flexlm_exporter server:port.

scrape_configs:
      - job_name: 'flexlm'
        static_configs:
# Here you'll need to specify server name and port of the exporter
# The network alias makes this task simple
          - targets: ['flexlm_exporter:9319']

Customize your path to prometheus.yml configuration file and run Prometheus Docker container:

docker volume create prometheus-data
docker run --name prometheus -d -p 9090:9090 \
    --network cad --network-alias prometheus \
    -v /some_path/prometheus.yml:/etc/prometheus/prometheus.yml \
    -v prometheus-data:/prometheus \
    prom/prometheus

Note the 1st docker volume command, this will make a persistent docker volume to store Prometheus data when container is re-created. Similar volume will be used below to store Grafana dashboards and credentials.

Grafana

Here are the commands to make one more Docker volume and run the 3rd container for Grafana:

docker volume create grafana-data

docker run -d --name=grafana -p 3000:3000 --network cad --network-alias grafana \
    -v grafana-data:/var/lib/grafana grafana/grafana-enterprise

To access Grafana, open this URL in your browser: http://localhost:3000/

To login the 1st time, both your login and password are admin, then you'll be prompted to change the password.

Now it's time to to add a new Grafana dashboard. First let's add a Prometheus data source to Grafana. Because we use Docker networks, the Prometheus URL will be http://prometheus:9090. Go to Connections -> Data Sources -> Add new data source -> Prometheus:

Then go to Dashboards -> New -> Import, and paste this URL:

https://grafana.com/grafana/dashboards/3854-flexlm/

And select Prometheus as the data source. Note that if you don't see a valid Prometheus DB in the selection box, you might need to refresh your browser window before this step.

If all parts work properly, now you will see historical license usage in your dashboard, like shown in the very first image at the top.

Debugging

Here are useful commands that will help with debugging.

List running docker containers with docker ps command. There should be 3 containers running (Status=UP)

If any of the containers is not running, use docker logs <container_name> to see the diagnostic.

Another option is to try accessing flexlm_exporter and Prometheus DB in Web browser:

http://localhost:9319/ - flexlm_exporter

Here you could follow Metrics link. When exporter works as expected, there will be information like this:

# TYPE flexlm_feature_issued gauge
flexlm_feature_issued{app="arm_and_leg_inc",name="feature1"} 100
...
# HELP flexlm_feature_used License feature used labeled by app and feature name of the license.
# TYPE flexlm_feature_used gauge
flexlm_feature_used{app="arm_and_leg_inc",name="feature1"} 30
...
# HELP flexlm_feature_used_users License feature used by user labeled by app, feature name and username of the license.
# TYPE flexlm_feature_used_users gauge
flexlm_feature_used_users{app="arm_and_leg_inc",name="feature1",since="1729442400",user="user1"} 3
...

http://localhost:9090/query - Prometheus DB

The first check is that URL is accessible. Then the following queries should work and respond with your license usage info:

up
flexlm_server_status
flexlm_feature_issued
flexlm_feature_used
flexlm_feature_used_users