Monday, October 26, 2009

Flexlm, let me count the ways

Trivial to defeat for the dishonest, a complete hassle and waste of time for the honest, who are we, in the EDA industry, kidding with flexlm licensing? As customers we buy this incredibly sophisticated and powerful (and expensive!) simulation and synthesis software, and then it fails to run at times because of this fragile, buggy license software wrapper around it. Why do we put up with it?

And vendors, you treat your enterprise customers, who shell out tens if not hundreds of thousands of dollars for your software, as if you don't trust them? You force them to set up, troubleshoot, and babysit these finicky and frail license servers, just so they can run the software they've already paid you (a lot!) for? Why?

Friday, October 23, 2009

Convert putty key to openssh on linux

I had a putty generated ssh key that I wanted to use on my linux box (long story). Turns out it's simple to convert it using linux tools. Here are the steps:

sudo aptitude install putty-tools

Then, to convert a private putty key named id_dsa.ppk to an openssh key named id_dsa:

puttygen id_dsa.ppk -O private-openssh -o id_dsa

Then just type in the key's passphrase and you're done. You can type puttygen --help to see similar options for public keys.

Thursday, October 22, 2009

New Job, New Focus

I have a new job! I am now a verification engineer at a relatively new hardware company in Utah. I worked on digital design and verification stuff back during internships in college and then for the first few years that I worked full-time. Then about five years ago I switched over to embedded software. It's fun to be back in the hardware design world. Better verification and system modelling was a hot topic five years ago, and it looks like a lot of progress has been made in the intervening years. It's really cool to see. Another big win with the new job is, no more windoze! ASIC designers know a good development environment runs on Linux ;-)

I mostly use this blog to write down helpful reminders for myself, and as a start, here's my first verilog tip. Code browsing with ctags works for verilog too! I used find to get a list of all our verilog files and put that in a file called, file-list.txt. Then I generated tags like so:

ctags -e --verbose --language-force=verilog -L file.list

One huge oversight of emacs verilog-mode is that they overrode the pop-tag-mark keybinding to insert a multi-line comment instead. I got distracted with other things so I haven't done it yet, but I'm sure that's not too hard to fix.

Anyway, I'm excited for the new opportunity. In closing, here are some verification blogs that I found, but haven't read much of. Yet.

How's that for a focused blog post?

Wednesday, October 21, 2009

.bash_profile vs. .bashrc

There are many subtleties in the way shells start up and what they automatically source when they do. At one point I had to have this down pat for my job, for both Red Hat Linux systems and HP-UX systems. It has gotten a little fuzzy since then, but I rediscovered this basic point today: profile files are sourced once when you log in, your rc file is sourced every time you start a shell.

But what does that mean? If you put something like this in your .bashrc:

export PATH=$PATH:/home/username/bin

And start up, say, a gnome-terminal, your PATH will have /home/username/bin appended to it. To see it type this:

echo $PATH

Good enough. Now, in that gnome-terminal, if you execute something that causes another sub shell to be spawned (like, you execute a script), your .bashrc will be sourced again, and that export statement will execute again. Try typing this in your gnome-terminal:

bash # starts a subshell
echo $PATH

See /home/username/bin repeated twice? That’s really not what you want to happen. That’s why you want to export environment variable in your .bash_profile, not your .bashrc. I don’t like logging out of my desktop session and logging back in to effect changes made to my .bash_profile, so I go into my gnome-terminal preferences under Title and Command and check the box next to “Run command as a login shell.” That way every time a gnome-terminal starts up, it’s acts like a new login. It starts up with a clean environment and it sources my .bash_profile. Then I add this at the end of my .bash_profile to make sure my .bashrc gets sourced too:

if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

I'm sure my former self could have explained this better and with more precision, but for what most command-line junkies do, this should be sufficient.

Wednesday, October 7, 2009

Little Things

Things that never fail to fill me with childlike giddiness:

  • When code that I wrote talks over a network.
  • When multi-threaded code that I wrote shows evidence of actually doing two or more things in parallel.
  • When my code makes an LED blink.
  • When my code makes a motor move.

These are not new things to me, but each time I do them with a new piece of hardware or as part of a new project it fills me with such wonder and joy, and once it’s done it’s still fun to run the code over and over and watch it happen again and again. It takes a long time for the satisfied feeling to wear off. It’s even more amazing if it’s more than one of those in combination (multi-threaded blinking of many LEDs, over a network, while moving a motor!). I haven’t confessed this to anyone before, but lately I’ve seen engineers more seasoned than I show the same excitement that I feel in these same scenarios, and I believe that I am not alone. It’s the little things that count.