But will it get anyone laid?

Just got a press release email from www.design-reuse.com. 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:

"Jesus Mother of Fuck, what are you thinking! Do not
strap the 'Groupware' albatross around your neck! That's what killed
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 www.cpan.org. 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?

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.

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.

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

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.

Corporate Blogging

"Don't let your employees blog. And if they do anyway, don't admit it to anyone. And make sure they post a disclaimer. Otherwise, one of them will give away all your company secrets; another will commit libel and drop you in a lawsuit; and if you're really unlucky, and you're not an American, you'll end up in G'tmo. And your skin will turn green."

OK, that maybe exaggerates the warnings I got when looking into the idea of corporate blogging, but not by much. Here, however, is what I did ponder as I discussed the pros and cons of blogging with one of Verilab's consultants, JL Gray, author of Cool Verification.

First, we started from a position that blogging, done well, is a Good Thing. Verilab is home to some of the top experts in the field of VLSI verification, but often I still have to remind such a geek-heavy team that it's important not only to be good at what you do, but to be seen to be good. And blogging is one way of being seen. The question then is what, if any, are the costs and other pitfalls of blogging? And are those outweighed by any benefits?

The first potential pitfall is brand dilution. Take JL's Cool Verification for example. His blog stats show that lots of the traffic coming to the Verilab website is actually coming via his blog. On the one hand that's a good thing - traffic is, after all, coming to Verilab. On the other hand, it's "second-hand" traffic coming via Cool Verification. He and I discussed this back and forth a lot. For me, the key benefit of blogging and being not only good but seen to be good, is that it enhances the brand of Verilab. I'm happy - no, keen - for Verilab's brand to be enhanced by enhancing the personal brands of my
team. But I don't want the personal side to defocus the company side. In the end, this really became a non-issue because there is an inherent synergy between what JL is doing and Verilab. Of course there is, since he's a key member of my team. And were that not the case, no amount of blog rules, intended to force branding in one direction or the other, would be effective. My overall conclusion on the branding side of things - for me the most important issue - is that it is a reflection of the overall team spirit and effectiveness. Get that right, and the branding thing will follow. Don't get it right and you have bigger
problems than just ambiguous branding of blogs.

Next was the area of appropriateness of content. Verilab provides consulting services to some very large and well-known clients, and our influence is often at a significant strategic level. As a result we have tended to follow the McKinsey approach and keep much of our client names secret. And so we can't have bloggers speaking openly about things on which the company's policy is discretion. A related area is manners and good sense when it comes to discussing the sorts of tools and technologies we use in our daily work. Verilab is well known for it's neutral and objective stance on such things. We are partnered with the major tool vendors in our field, but are exclusive to none. We are, in a sense, the Switzerland of EDA. People come to us because we're friends with everyone. All of that has implications for blogging and for public discourse in general. Compared with the brand issue, however, this was relatively easy to handle. We follow a policy similar (remarkably similar) to that of Sun. It's not going to cover every single eventuality, but no policy will. It seems to work.

Finally, the biggest amount of time JL and I spent on this concerned the area of IP ownership. And it arose because of a part of Verilab's employment agreement that is fairly normal and, at first sight, unthreatening. In that agreement it says, in a nutshell, that if Verilab is paying an employee to do stuff - including writing stuff - then Verilab gets to own the stuff. What that means is, if someone blogs on Verilab time, then Verilab owns the post. Oops. Poor blogger invests his very heart into his blog only to have Big Bad Corporation "steal" it from him, or at very least serve him with a takedown notice after he leaves Verilab.

Now, one option could be to say that blogging cannot be done on "company time". But that doesn't really solve the problem. For a start, just because someone does something outside of company time doesn't mean the company doesn't have some rights in it. For example, JL blogged extensively about his travels to this year's DVCon and DATE conferences; travel which Verilab paid for. Even though he may have blogged about them in the evening, it's still arguable that Verilab was footing the bill. Also, remember that blogging is being seen as a Good Thing - i.e. it benefits Verilab. So it can be good to let bloggers do some blogging on company time.

Now from my (the employer) point of view, this was not really a problem. By the employee agreement, I may have a right to some of the employee blog posts. I don't have to enforce that right, but it's there
if I want it. Rather, it's a problem for the employee - in this case JL. For him, and for any blogger, the blog is a peculiar piece of work unlike a conference paper, or a trade journal article. It's peculiar in
that it is his blog. It's a daily or weekly (or whatever) stream of consciousness, of value not primarily because of any specific posting, but because it connects him to his readers and vice versa. But it's not just detached writings - it's his writings.

And I understood that (then, and even more so now that I'm blogging myself). So, to get around the problem, we first considered creating a special license that could be offered to our bloggers. It meant that
the core employment agreement - which created the issue in the first place - could remain unchanged. But the license would then effectively say, 'Although Verilab still owns that particular work product known as "your blog posts", it grants you a royalty-free license to use them on your blog even after you leave Verilab'.

That sounded fine at first, but as we mulled it over we realized it was contrived. It's just the sort of heavy legal stuff that a small and agile firm like Verilab would hope to avoid for a while. And so, amid thoughts of agility, I decided to ask some advice from the nice people at Thoughtworks. They appear
to have an excellent blog culture going, and it looks like it's unencumbered by too much legalese. For example, most of the blogs there, are personal blogs, not hosted by TW themselves. The implication is, TW is not trying to own them. So, I asked the question of a couple of Thoughtworkers; one a project manager, and one a senior technical figure there, and well-known blogger in his own right. Both came back with replies that confirmed my view of how TW manages its bloggers - with a light, encouraging hand, backed by common sense guidelines, and the (very) occasional wrist slap if needed.

So there JL and I, successfully and with a sense of relief, left it. Maybe we (and TW) are just asking for trouble in not having lots of legal stuff to control our blogging. But Verilab (and TW)  are characterized by relatively small groups of extremely smart people of the sort who perform best with a degree of trust and flexibility that may not be appropriate for the larger public firm.

One outcome of all of our discussion was that I decided myself to start a blog. A major reason was so that I myself could be on the blogger side of the table, in order to understand how any rules or
guidelines would affect the employee.

Finally, overall this is a particular area of interest for knowledge-base firms like consultancies, and JL is breaking a lot of new ground in that respect. In fact he's trying to coordinate a Blogging "Birds-of-a-feather" Session at the forthcoming DAC 2008 conference to which Verilab will be sending a team. If you're interested, drop him an email at jl dot gray at verilab dot com, or pop over to Cool Verification.

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