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 a couple months setting-up one of them, and it was only possible after we established regular calls with their 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, I didn'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 this home-made 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?
Top comments (0)