EDA Marketing Problem

I started out trying to write an eloquent essay on the merits of different ways of sharing new ideas and information in order to further the art of digital design verification (in other words, how to market this stuff), but I couldn't make it sound right. Instead, let me just point to some recent examples:

Good examples

Namespaces, Build Order, and Chickens

Cadence's UVM video series

These are brief and to-the-point. If you have a question, they quickly give you answer. If you are taking 2 or 3 minutes to browse the internet while waiting for a simulation to finish, maybe even on your phone while you take a little time away from your desk, you can get all the info in that time. Perfect.

Examples of Ideas That Could be Marketed Better

Monitoring signals by name, for the UVM register package and more

and:

A 30 Minute Project Makeover Using Continuous Integration

First of all, kudos to Verilab for sharing ideas, knowledge, and source code as much they do. The next section of this document could be, Example of People that Don't Share Knowledge At All and it would be huge, but, you know, there'd be nothing to link to. So, I do not intend to disparage or discourage, rather to point out some areas for improvement. With both of these gems, first of all, I wasn't even sure what exactly I should link to. The PDF directly? The paragraph of text introducing the link to the PDF? Or should I link to the blog entry that links to the introduction text that links to the PDF? Next, the length. The first is a 20 page PDF, the second is 7 pages. If you really want to spread knowledge and advance the art, get to the good stuff quickly! My simulations don't take that long to run. I was about to say more on this, but I'm going to follow my own advice. I'll expound in the comments if you ask me to. Finally, PDFs. Really? This is the internet. Use html. Everything can reformat and display html nicely enough, desktops, laptops, phones. Even printers. PDFs, not so much.

In conclusion, I love that people in the EDA world, and in verification specifically, are sharing more and more information on the internet. It can be even more effective and help advance the art further if we do so in a modern internet-y way using good marketing techniques.

Environment Manager for More than Just Python

This whole virtualenv thing is pretty cool, but it has always seemed too specific to Python for me. Let me see if I can explain. At first I had no use for virtualenv whatsoever, I could just sudo apt-get install python-whatever and get what I needed. As my distro got older and I didn't want to update my whole system, I started using virtualenv and pip to install and manage python packages instead of apt. It's great, except that the postgresql packages that came with my distro were getting crusty too. Because postgresql is not a python package, I get no help from virtualenv. Does anyone else have this problem? How do you deal with it?


This reminds me of a very old problem from the chip design (EDA, ASIC design, whatever you want to call it) world. To design chips you buy licenses for expensive simulators and synthesis tools, and those tools are constantly being revved, fixing old bugs, introducing new features, and unfortunately, introducing new bugs. Because of that you never ever upgrade from one version to the next, you always install a whole new copy of each version, and then you manipulate your PATH and other environment variables that the tools use according to which version you want to experiment with today. I once worte a tool that's not too different from virtualenv if you squint a little, but it was more generic for managing your unix environment in general. It was great for dealing with all the versions of chip design tools we used. Unfortunately it's locked inside the company I wrote it for. I have since discovered that an open source project very similar to the one I wrote exists, but it uses far too much tcl ;-)


I started an open source project to try and tackle this again (before I had used virtualenv, actually), and I have wondered if it could solve this general problem for not just python. It's pretty raw, but you can see it here.


If you browsed around that project, you can see I haven't gone very far with it. It works for me, but it needs some love to make it easier for others to get up an running with it. I'm more than open to questions on how to install and use it, feedback on the design and usage model, and to contributions from others.

Mercurial Now Has commit --amend

Mercurial 2.2.1 is out, and, among other new features and improvements, the commit command now has a --amend option. Git has had this for a while. Before 2.2 you could get the same functionality in Mercurial by using the mq extension, but it took at least 3 commands (qimport, qrefresh, qfinish). It's nice that you can do it with just one command now. Mercurial's relatively new phases come into play with --amend in that, by default, they will prevent you from amending a commit that has been pushed to or pulled from a remote repository. It's a nice little safety net to have, and of course you can override that behavior if you need.

It's nice to see this incredibly capable and easy-to-use tool get even better.