Cyclopedia Square

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?

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.

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-for...

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’...

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’...