Millennium Software Design Blog
Enter your email to subscribe to updates through simplelists
At DVCon I attended three different sessions where the relatively new Portable Test and Stimulus Standard (PSS) was discussed. It took me a while to realize that I was watching something play out that has played out many times before in the EDA world. Some smart engineers have an idea for a new tool. They develop this new tool, either in-house as part of their job at a semiconductor company, or as a start-up company of their own. It doesn't matter, the story goes roughly the same either way. At the semiconductor company someone realizes that the company has become dependent on this tool and A) the company is not a tools company and they shouldn't be spending time and money on developing this, and/or B) if these engineers leave, the company will be stuck with nobody to support this tool. So, the company approaches an EDA company and says, "hey guys, can you build us a tool that does this?" Here's where the story intersects with the other scenario where the engineers started an EDA company to develop and sell their tool instead of developing it in house. In both cases, the EDA company finds out that people want to buy this tool, but they don't want to be tied to a single supplier of the tool. Smart buyers know that if they get hooked on using this proprietary tool and only one EDA company sells it, that EDA company now has some serious leverage over them. Let's just call this, The Proprietary Tool Problem.
This is the story of PSS that I was watching partially play out right there at DVCon. PSS was initially invented by a start-up company, Breker. I imagine sales had been a little slow despite everyone seeing how great the technology was, because only Breker had the rights to this technology. It was a Proprietary Tool. Breker likely went the usual route that has always been taken in the EDA world to solve the Proprietary Tool Problem. Listen to how ridiculous the usual way is. First you have to join the Accellera standards organization by paying them $25,000 a year. Then you have to pay one of your top engineer to sit on a weekly teleconference call with representatives from other EDA companies for several years and essentially teach those other companies enough about your tool so that they can build competing versions of the tool which they can sell. For good measure, a couple of the large semiconductor companies usually also join this teleconference (also paying $25,000 a year, also paying some of their top engineers to sit in this teleconference) so that they can make sure all the EDA companies include the features that they want in the tool. Eventually the information that was shared and agreed upon in these teleconferences gets published by Accellera as The Standard.
- You create a tool
- People don't want to be held captive by a single provider of a tool, so…
- You pay for the privilege of teaching other companies how to make their own interoperable version of your tool
- Now people will finally buy the tool from you (or from one of your competitors)
Madness. But there is no other way to meet these customer demands and solve The Proprietary Tool Problem, right?
Humor me for a moment as I propose a much more efficient and less expensive way to make customers happy in this situation. Instead of paying Accellera and spending years hashing out a standard, just open source your tool and sell it the same way Red Hat sells open source Linux or Millennium Software Design sells our tools. Just like that, at no additional cost to you, your tools is now no longer a Proprietary Tool. No joining a standards body, no dues to pay, no teleconferences for years before a standard is ratified. Yes, you will still have the problem that other people can sell competing versions of your tool, but without all the other time and expense involved! It's even better because you don't have to sit down with the other companies and tell them details about your tool. They can just read the source. Or, if you are feeling like you want to be more helpful, they can pay you for training, instead of you paying Accellera!
Published: March 13, 2020
We just updated our MSD Design and Verification suite with support for Red Hat Enterprise Linux 6. With a simple download and install you can now run the latest versions of Icarus Verilog, Verilator, GHDL, CoCoTB, and GTKWave on RHEL 6. To make these new tools run smoothly on this older OS, the latest gcc, openssl, and python3 are included as well.
Existing customers can go to their dashboard to download and install 1.0.1. New customers will get this new version by default.
This update was done because a customer requested it. Please let us know through our contact form if there is a specific version of a linux distribution that you would like us to support.
Published: Feb. 28, 2020
This is the second post in a series on: "Bringing Low Cost, Flexibility, and Freedom to EDA."
Proprietary EDA software sells you a license to obtain a copy of their software and run it for certain purposes and under certain conditions. They then go a step further and attempt to enforce this license by making you install and run a license server that their software checks in with each time you run it. Sometimes the license server goes down (because the hardware it's running on goes down, the network goes down, the license server software itself crashes or locks up, your renewed license has been paid for but the bureaucracy hasn't yet updated the license file, etc., etc.). Suddenly the software you have paid thousands of dollars for and you are legally entitled to run, won't run. I don't know about you, but I have never found anything in chip design more frustrating than that.
This is one of the reasons Millennium Software Design does not sell you licenses and most definitely does not try to enforce anything with license server software. We are confident that we can all treat each other like trustworthy professionals in this business.
The other reason we don't sell you licenses is because we simply can't. Our software is distributed under various Open Source licenses. You are free to copy the source code as much as you want. You are also free to run the software wherever, whenever, and however you like. You can run the software without a network connection, on an airplane even. You can install our software on a big beefy server and have people from all over the world log in to that server. Heck, offer the public logins to that server, we don't care. Run virtual machines, containers, whatever you want.
With that being said, what are you paying for then? We briefly mentioned in the last post that we are selling subscriptions. We do need to be fairly compensated for everything that we provide as part of our subscriptions and so we looked to the examples of others that sell open source software subscriptions and came up with a way based on the number of CPU cores per physical machine that you are running the software on.
Published: Feb. 26, 2020
Hopefully you've seen our tag line: "Bringing Low Cost, Flexibility, and Freedom to EDA." This post is going to talk about low cost. Yes, that means there will likely be posts about Flexibility and Freedom in the future too :-)
If you haven't seen our prices, take a look now. If those aren't much much lower than the prices you have seen for other EDA tools, please let me know. I'd be very surprised to hear that. Our least expensive offering comes out to only $8.25 a month to run it on one 4-core machine. Even our premium offering comes out to only $62.42 a month. How can we be so inexpensive?
One reason we don't cost as much as other EDA tools is our sales model. Our prices are right there on our website where you can make an easy purchase with a credit card. We don't have to pay salespeople to travel, take people out to lunch, and conduct extensive price negotiations. Buying our software is simple and straightforward and we pass the saving on to you.
Licensing vs. Subscriptions
You have probably noticed that we don't sell licenses. Our software is all open source. There is no copyright license to sell you1. That part is free. What we do sell are subscriptions. I know, this is a little confusing if you've never seen it before. When Red Hat first introduced this model it confused me at first too. We already have a page explaining everything our subscriptions provide, so I won't go over that again. It is substantially more than you get when you download and (possibly compile and) run the open source code yourself. I feel like we offer a great value for a great price here, and because we treat you like fellow trustworthy professionals, we don't have to spend a lot of money on attorney fees, license enforcement, copyright protection schemes, and so forth. Again, we pass the savings on to you.
Going open source means that many of us collaborate on the development of these tools. This saves Millennium Software Design costs, cost savings that yet again we can pass on to you.
Published: Feb. 18, 2020
At DVCon 2013 I asked JL Gray's panel if we would ever have Free tools, like the software world. None of panelists seemed to think so. One of the panelists, a Mentor employee, scoffed, "you get what you pay for with free tools." Never mind that their (and Cadence's and Synopsys'1) products are very likely developed with tools that contain millions of lines of Free software.
I've been been ruminating on that ever since, and this past November I decided to do something about it. Thus you see this business, Millennium Software Design.
Millennium Software Design loves Free software. Our goal is to bring it to the EDA world. We are starting with unmodified existing open source tools such as Icarus Verilog and Verilator (see complete list here). Many engineers already quietly use these tools with great success. Our plan is to spread the use of these tools and to help improve upon them in order to continually offer you more (as part of your subscriptions, of course ☻).
A top priority of ours is to provide an open source mixed language simulator. Many existing code bases are a mix of (System)Verilog and VHDL, and these projects need a simulator that can handle both languages. Once support for those two core languages is working, then support for newer, even better HDLs can be added to the mix.
With that said, welcome to our blog. We will be posting a mix of technical content, announcements and news, and will even sometimes wax philosophical.
Published: Jan. 30, 2020
Page 1 of 1