Friday, May 30, 2008

But will it get anyone laid?

Just got a press release email from They're appearing at DAC with "a major release of [their] IP Reuse Enterprise Platform". I wish them well; I really do. But I couldn't help recall a story by Jamie Zawinski in which he infamously (or maybe just famously) said, of Groupware:
Netscape, are you insane?"
Well, for "Groupware" read "IP Reuse Platforms".

Look, I'm not saying it can't be done. I'm not even saying it shouldn't be attempted. But it's not as if we have no experience in this area in EDA, and so far the results have been more than a tad poorer than underwhelming. Hey, I know the attraction. I dabbled in this stuff myself at Motorola. The "European Module Board" anyone? (BTW: I'm pretty sure they still owe Mark money for his Slavebus module). Then there was IPWorks. Can't say we changed the world there either. And I'm pretty sure I heard that
Ericsson had a go, and then went back to better things. And then of course there was the ill-fated Virtual Component Exchange (VCX) in Scotland. (And no, don't try to guess the website name [Addendum 2008.06.03: hint, such guessing would be not only ill-advised, but decidedly NSFW].) The similarities between it and D&R are striking. VCX was changing the world of reuse. And it had thousands of cores being added every day. And they were up to their eyes in page hits. And ... well, where are they now. (I told you not to guess the website name.)

The thing is, there are at least three key issues that are blocking success in the development of IP Reuse Platforms in EDA.

The first is, at its heart, lack of open standards. Look over the fence to our software neighbours. Take Perl, for example. If you want to do something of any complexity, you're going to at least have a look in And while CPAN is built on a lot of thought, and isn't just Any Old Scrapheap of Code, it is what it is in no small part because it is part of an open ecosystem. It's not just Perl itself; it's unix and everything that surrounds it. Apart from anything else, that openness then unleashes the larger population of potential users in Perl land (larger, that is, than we have in EDA). And as a result, Linus's Law applies.

The second issue is that IP Reuse Platforms tend to be developed by IP Reuse Platform specialists. Specifically, they tend not to be developed by front-line chip design and verification engineers. Now there's nothing inherently wrong with the Platform specialists. They can be very smart, and very good engineers. In fact, they are often front-line chip design and verification engineers who are so sick of not being able to implement proper reuse that they negotiate getting off the front line and take up a rear echelon position so as to put into practice all those good reuse ideas that they've had to shelve while actually building chips. The problem is, a madness overtakes you when you move off the front line - a kind of shell shock in reverse. The very freedom from the day to day melee of chip building gets you off thinking about grand plans, and abstractions, and before you know it you're reading The Timeless Way of Building and basically solving problems that don't really exist.

But the third issue blocking success in the development of IP Reuse Platforms for EDA may be the most important of all. And I can do no better than quote some more of Zawinski when he warned against Groupware:

"If you want to do something that's going to change the world, build software that people want to use instead of software that managers want to buy... So I said, narrow the focus. Your "use case" should be, there's a 22 year old college student living in the dorms. How will this software get him laid?"
So. D&R; Module Board and IPWorks people if you're still there; and anyone else who is tempted to strap the IP Reuse Platform albatross around their neck. You have to ask yourself one question. How will your software get your users laid?

Tuesday, May 27, 2008

DAC and the VLSI Homunculus

Let's do an experiment.

I'm going to ask you to close your eyes. (Not yet, or you won't be able to read the next bit!) OK, you'll close your eyes and focus your attention on your hands for a second or two. Don't move them, or wiggle your fingers; just focus your attention on them. After that, and still keeping your eyes closed, you'll move your attention to your shins. Again, a few seconds of focus. Ready? Go ahead.

OK, done? Now, which felt bigger - your hands or your shins? If you answered "shins", please see a doctor. Otherwise, that effect - the feeling that your hands are bigger than your shins - is due to the fact
that your brain "sees" your body differently from the way it appears to our eyes. And if we were to build a physical representation of that brain's-view of the body, we'd get the grotesque little figure known as
a Cortical Homunculus.


The size of each part of the distorted body of the Cortical Homunculus represents the number and sensitivity of nerves at that part. The Homunculus is what we'd look like to everyone else if we looked the way we felt. But of course, we don't look like that at all.

Now in about two weeks from now, those of us visiting Anaheim are going to get a close up view of a remarkably similar phenomenon. However, instead of it being a distorted view of the human body, it will be a distorted view of what is really important in chip design and verification. DAC, the Design Automation Conference, is a VLSI Homunculus.

Walk around the exhibits and you will see large booths and small booths; colourful booths and plain booths; booths that make you go "wow!", and booths that make you go "oops, sorry, I thought this was the restroom". Look over there and you'll see booth 1349 -- Synopsys. You can't miss it, it's huge. It's always huge. Oh, hang on, there's another monster exhibit; number 2439. Why, it's Magma. And - wow, there's another. Mentor of course. They're at 2301. Of course, notable by their absence are Cadence. But being absent from DAC doesn't mean being absent. CDNLive, anyone?

Now I can't tell you exactly what our big tool vendor pals spend on their booths, but it is way more than I spent on gasoline last week, and I drive a Nissan Armada and live in Texas (where journeys are only "long" if they're over 500 miles). And they do that because advertising like this works. It gets into the brains of the targets and makes them see the world differently from the way they would have seen it otherwise. In other words, DAC affects the way we see the world. The large marketing budgets of tool vendors are able to make you imagine that your hands are bigger than your shins.

The problem is, just like the Cortical Homunculus, the VLSI Homunculus of DAC, while not completely wrong, isn't completely right either. It's distorted. To the unwary conference goer, the most important part of the VLSI design and verification problem, is tools. Choose the right tool, and you'll be fine. Get it wrong, and you'll never tape out a chip again. And languages; they are just as crucial. Vera, or e, or SV - better get that right too. Everything rides on the choice.

But of course, if you can manage to open your eyes again, and try to shrug off the illusion, you'll realize what we all know deep down in our knowers. Of course tools and technologies are, particularly when we move through generations of those things (after all, Vera or e or SV are all superior to plain old Verilog when it comes to verification), important. But far, far more important are the knowledge, skills, experience, and artistry of the people who use those tools. Peopleware, not Software or Hardware, is the most important VLSI body part. After all, which would you rather have: a team of Olympic Gold  Medalist Verification Engineers using Verilog and assembly code; or a team of newbies using e, Vera, SV, you name it?

Looking forward to DAC. Looking forward to the Homunculus. But most of all, looking forward to meeting smart folks. Please say hi if you see any of the Verilab team.

Monday, May 26, 2008

On holidays, vacation, PTO, and other reasons not to work

Today is Memorial Day in the US. Verilab Inc (Texas) observes today as a holiday, along with six other days. Verilab GmbH (Germany) and Verilab Ltd (Scotland), however, do not. GmbH, on the other hand, has between eleven and thirteen holidays, depending on the year. Ltd has eight. Current base vacation levels are: 17 for the US (total holidays plus vacation is therefore 25), 26 for the UK (total of 34), and 30 for Germany (total of 41 to 43). The US has six "sick" days; by contrast our European sites have no specified limit on how often you can be sick. And each of the governments of the regions all have different rules about what someone must or must be able to do with "untaken" time off. Within the US, each state has rules about that. The one thing that is common to all of them is that the time we're talking about - vacation and holiday - is paid time off.

It is, to be honest, a pain in the elbow.

It's not that time off is a bad thing. Far from it. Lets have more today for everyone please. But let's also bear in mind that there's no such thing as a free lunch (or holiday). No - the reason it's a pain in the elbow is rather the bureaucratic complexity of regulation imposed on employers for something that really isn't the benefit to employees that the governments of the world would have us think. Paid holidays aren't really paid at all.

You see, what they'd have us think is that before they imposed paid holidays on the world (even to the extent of enshrining something so trivial -- Article 24 -- alongside things as noble as rights to life and liberty -- Article 2 -- in the United Nations Universal Declaration on Human Rights) any given employee was paid an effective rate of $X per day worked, but when they didn't work, they weren't paid. And then after the advent of  paid time off, the illusion is that people are paid $X per day worked, and also $X for a given number of paid days off.

That is, of course, not at all what happens. Instead, because employers look at overall cost and overall benefit, what happens - not necessarily by overt action - is that the $X is reduced so that the same total payment is made to the employee after the paid holidays rule was made as before it. In that sense, PTO is not really P at all. The employee sees her pay for the worked days lowered so as to create a pool of cash with which to pay her for when she doesn't work. Overall, she gets paid a fixed amount. What the law concerning vacation does is simply act to remove a little bit of her freedom by trying to force her to take vacation.

This is really Economics 101. It should be obvious to anyone who has ever looked at any employer's accounts. The trouble is, 'fessing up to this makes lots of people grumpy (go on, admit it, some of you are grumpy). And in fact it makes them so grumpy, they won't vote for you if you point it out.

Friday, May 23, 2008

The Point of Stallman

In "Be Realistic. Demand the Impossible", a commenter argues that in pushing free software, Richard Stallman was really just pushing his own ego by "...framing the narrative in terms of 'freedom'". I don't know if Stallman was actually doing that or not, but I'm firmly of the view that his underlying point - that freedom is The Point -- is correct.

For my part - well, I think the reason Stallman can come across as a religious zealot is partly because he  opposes something ("Intellectual Property") that is arguably religious zealotry itself. The problem is, the theory of property he opposes has gained the status of a "state religion", to the extent that most of us don't even see it, and when someone points it out to us we think they're a nut. But that very pointing out is probably Stallman's biggest contribution.

Even fellow hackers can miss this point. Some take the view that the best approach is to leave your own code open, if you choose, but still give others the "freedom" to lock theirs down if they want to. As Stephen Turnbull said in discussing the XEmacs/GNU Emacs fork:
"... many XEmacs developers take a different approach to the free software movement itself, and so will differ from GNU/FSF policy. The code we write will remain free. What we are possibly losing is the ability to force others to make their modifications free. This is central to the GNU Project because it is a social movement. To many developers as individuals, it is not so crucial."
"Isn't that the most free way?", they'd ask; "Make our own code free, but don't force anyone else to do the same." On the surface, who can criticize anyone for being so magnanimous? But the thing Turnbull's comment may be missing is that the "force" applied by something like the GPL is force applied only against other force. The only thing the GPL is doing is stopping you stopping someone else. The GPL would not even be necessary were it not for the fact that current legal structures allow you to restrict other people's freedom. The GPL is not really an enforcement; it is a de-enforcement.

So it all boils down to this idea of property, as applied to code. IF we accept that a person can "own" code, then clearly Stallman is wrong. Making "your" code freely available may be a laudable choice, but it's a choice. It is, after all your code. But if Stallman is right to argue that code doesn't belong to a person - even the author - then any attempt to use force (and let's face it, all laws are eventually backed by threat of force) to stop people using it is plain old immoral.

Stallman's position appears to be (but hey, what do I know, I'm not Stallman) that putting a gun (or a having a cop do it for you) against someone's head for using code that you wrote is the same as putting a gun against someone's head for using the word "Stallman". Putting a gun against someone's head for any such reason is wrong. Immoral. And why? Because it denies people their freedom (as in, "we hold these truths to be self-evident" kind of freedom - big, heavy, nation-building, humanity-saving freedom).

Thursday, May 22, 2008

Going to DAC

DAC (Design Autotomation Conference) is the Main Event in our field. It hasn't quite regained the full spectacle of the glory years of the pre-NASDAQ bubble burst, but it's still the key conference for VLSI design tools and technologies.

Already, the main conference hotel looks full, and bloggers are noting interest. Harry the ASIC guy appears to be going; as does John over at his Semi-Blog. At Verilab, we'll be sending our own SWAT team. I'll be there, along with JL and David Robinson to name but two. JL will be presenting on Monday at the RealIntent booth. And David will be talking about verification planning at the Novas booth.

Please don't hesitate to say hi if you see me or any of the team there. Verilab is, as always, looking for very smart/opinionated/ambitious/energetic/enthusiastic engineers and consultants to join our international team.

Tuesday, May 20, 2008

Corporate Blogging




problems than just ambiguous branding of blogs.








guidelines would affect the employee.


Monday, May 19, 2008

(Trying to do) Business in Germany

It took me about half an hour to set up the Verilab Ltd corporation in the UK. I popped into the lawyer's office, picked a name, and did the stuff. We just bought an off-the-shelf pre-formed company (CrestEdge I think it was called), and renamed it. Verilab Inc, in Texas, took a wee bit longer - a month - but only because I was based in Scotland at the time. But for Verilab GmbH in Munich? Thirteen months. That's just over a year from start to finish, to hack my way through rules, and notarizations, and peculiar customs and conventions. And I can't deny that, given that lots of those peculiarities persist after formation, I sometimes wonder why I bothered.

One of the "best" bits of the formation process was our encounter with the Handwerkskammer. This is a kind of guild of craftsmen, intended, I think, to service traditional crafts, like plumbing, and carpentry, and cuckoo-clock making. I'm pretty sure it was not set up to have any jurisdiction over professional engineers working in the field of VLSI design. However, in Germany, rules are rules, and we inadvertently fell foul of one that drew us into the field of view of the Handwerkskammer.

The problem was our Articles of Association - the documents that define what Verilab GmbH planned to do to earn its keep. These were translated from the original UK documents - the ones used to create
Verilab GmbH's parent, Verilab Ltd. However, the problem was that in the UK it's common to make Articles of Association fairly broad and all-encompassing. Today we're doing chip verification; tomorrow we might be doing software testing; and who knows what comes next. (In practice no one is as flighty as that, but the lawyers like to leave things flexible). And so, our documents contained the fateful word "assembly". That meant that in the UK, should the "verification" of PC cases ever take our fancy, we would be OK as far as our Articles went.

But over in Germany, the word "assembly" translates as "die Montage". And "die Montage" is a trigger word for the Handwerkskammer. Get involved in anything to do with "die Montage" and you get a visit from the German version of the Wheeltappers and Shunters Social Club. But that's not the real problem. The real problem is that the Handwerskammer have the ability to insist that any company falling under their jurisdiction must hire themselves a Meister - a kind of über craftsman. Now personally I'd argue that all the Verilab engineers and consultants are extremely über at what they do, but that's not what the Handwerkskammer have in mind. I'm not sure what the precise requirements are, but your
typical Joe PhD from the US or the UK isn't going to qualify. And so as it stood, we were unable to complete our incorporation. No master cuckoo clock carver, no company.

Anyway, sanity eventually prevailed. Our German lawyer argued back and forth with the local HWK dignitary, explaining throughout what we actually did for a living. And three months later, we were allowed to continue with the next part of the process. (Oh no, it wasn't over at that point. Not by any means. But that's another post or five).

Now, don't get me wrong. Neither the UK nor the US can claim freedom from such rules. I'll tell you some stories about them when I get around to it. But the Germans (and, in a different way, the French)
are, well, they're Meisters at this kind of thing. They know what they're doing; they take their time; they get the job done.