How To Be World Class

A VP of one of the big EDA vendors once asked Jason, one of Verilab's founders, "How on earth does Verilab keep managing to consistently get such high grade engineers?" At the time, I'm sure we clucked and strutted and gave some deep theories. But in reality, our basic reply was, "Dunno. We just know 'em when we see 'em." Spotting talent is a bit like taking photographs. Just because you're good at it doesn't mean you're good at explaining to others how to do it. However, Malcolm Gladwell, whose book "Outliers" I've just finished, has something to offer on the latter. Here, in a nutshell, is what he says (he's a lot better at this than I am though, so don't worry about me spoiling things - you should still read the book).

To become world class you should:

1. Have some innate talent. This is, however, the least difficult part. Gladwell argues that you only need talent at or above a minimum level (e.g. an IQ of 110), and that's good enough. There is little or no correlation between world classness and innate talent *above* that minimum level.
2. Be lucky in your surrounding circumstances so that you get the opportunity to work hard on "meaningful work".
3. Actually work hard. Specifically, accumulate about 10,000 hours of practice.

In fact Gladwell's thesis really focuses on those first two points (the third point is not new - see http://norvig.com/21-days.html). He goes to some lengths to argue that innate talent, especially once you've reached some minimum level, is highly unimportant. Conversely, he stresses that the surrounding circumstances are crucial. An example of the latter is top class Canadian ice hockey players. Apparently they are heavily biased towards people born in the earlier part of each year. Read the book to find out the details of why, but basically it's because kids born in January, February or March are more likely to get the opportunity to put in the 10,000 hours of practice that will make them great.
As I say, worth a read. But I'll leave you with a thought about how to interpret it all for your own benefit.

First, you almost certainly have the required level of talent. If you're reading blogs about EDA, or consulting; if you're interested in high tech; you're smart enough. Let's move on.

Second, you can't really know if your surrounding circumstances are bad enough to kill off your chances. How bad things seem can as often be a function of your attitude to life in general - glass half full or half empty. And I'm pretty sure that for the vast majority of my huge audience of readers it would be true to say that greatness has arisen from surrounding circumstances far worse than yours. So, no excuses here either.
Which leaves only the final point. The 10,000 hours. This is where the focus should be. A modern phrase is, "Work smarter, not harder." Well, apparently not. Work smarter *and* harder. OK, so, remember to send me a ticket when you win your Nobel Prize.

Stress Management for Entrepreneurs

Sean recently wrote about the need for entrepreneurs to learn to deal with "unfamiliar pain". I think he's right. Running a small firm, where you have to worry not only about your own welfare, but those of your team, can be a pain in the brain. That can be particularly the case in that volatile industry sector known as high tech. I'm not sure if I've learned to deal with stress, or if I've just become so used to it that it's now merely part of the background noise. But I do know that I'm now able to shrug off things that in the past would have had me rocking gently back and forth in the corner of a dark and quiet room while muttering. So here are five stress management approaches I've come up with over the years. Your mileage may vary.

1. Moral outrage is a luxury the entrepreneur can ill afford. My parents brought me up to abhor a lie and with a strong sense of fair play. I've never minded people playing tough -- I played tighthead prop in rugby. In the winter. Near Ferguslie Park -- but I try to play things straight, and expect to be treated likewise. As a result, I have a tendency to get well-nigh incandescent if I sense someone cheating me or anyone dear to me. But in business, that is, I've come to realize, not a positive characteristic. First, genuine cheats are, in my experience, rare. Business is complex, and different interpretations of contracts and other agreements are common. One man's cheating is another man's ambiguous non-compete agreement. That's why we have lawyers. I've never really bought the idea that some things are "Just business; not personal". But I've learned over the years that it's often best to treat things that way. Second, even if genuine cheating is going on, I've learned it's more productive to consider it in the same way I would a donkey stamping on my foot. That - like cheating - is not a pleasant thing to experience. But I don't get angry at the donkey in a "How dare you stamp on my foot" sense. By classing the cheat as a donkey I reduce the discomfort to a managable level. It's still a pain, but my desire to rip the cheat's head off tends to dissipate.
2. Learn detachment. I'm not a Buddhist, but I find their approach to detachment useful. I've actually learned the value of the phrase "Well there's no point in worrying about that." When I was younger, I found such an exhortation senseless. It implies that worrying is something we choose to do. I assumed it was pretty much involuntary. But in fact I've discovered that it is absolutely possible to simply switch off a worry for a time. The underlying concern may well still remain, but my fevered response to it can be turned down. Especially good for dealing with problems of the moral outrage variety, particularly when they're keeping you awake at night. It takes practice, but I'm no Zen monk and I've managed it. Give it a try.
3. Control secondary pain. This is, I think, related to Sean's "unfamilar" pain. I've found that there are often two pains or discomforts associated with any given unpleasant situation. First, there's the pain itself. I stub my toe, and my toe is sore. Pain, plain and simple. But then there's the pain I experience because of the existence of the first pain. "Oh no, I've stubbed my toe. Maybe it's broken. Maybe it'll get gangrenous. Maybe it'll get infected and I'll die. My wife and kids will be destitute. Ahhhhh!!" The key difference between the two pain types is that while you may not be able to control the first pain, you can very often control the second. Moral outrage is a good example. A large client pays slowly. They know you can't afford, and don't want to enforce the clear contract payment terms. So they cheat by paying late. They said they'd do one thing, and then they blatantly break their word. The first pain - the hit on your cash flow is real. And, within typical operating constraints, there's not much you can do about it. But the second one - the anger at the very fact they are cheating - is almost all in your head. With practice, it can be controlled.
4. It could be worse. A lot of stress is instantly lessened by putting it in perspective. Again, my awesome parents drilled this kind of thing into me when I was a kid. "The poor children in Africa would love to have your dinner", I'd be told, while complaining about Wednesday mince an' tatties. And it comes to the rescue often in running a business
5. You are already dead. This is my favourite coping strategy, and it's best illustrated by recalling a part of the World War 2 drama series, "Band of Brothers". The scene involves a young paratrooper, Blithe, confessing to his Lieutenant that he had stayed hidden in a ditch rather than fight on D-Day. Spears, the Lieutenant, asks if if he knows why he hid in the ditch, and Blithe replies that he was scared. Spears replies: “We’re all scared. You hid in that ditch because you think there’s still hope. The only hope you have is to accept the fact that you’re already dead. And the sooner you accept that, the sooner you’ll be able to function as a soldier’s supposed to function...” It may seem a bit dramatic to treat business like the assault on Carentan, but it works for me.

Excel-lent (update - or not)

All is forgiven. The automatic HP update demon has just offered to give me a new and critical (yellow triangle an' all) update. I'm assuming it's going to fix my Excel problem. So I'm happy. Well, kinda. A bit. OK, not at all really. Turns out the update (coming, remember, via HP's own Vista utility) is entitled:

"?? HP ??????????"

with a description of:

"??????,??????????? HP ??????????????????"

:-/

Excel-lent

I put my car in for repair last week.
It took them quite a while to find the problem.
Even now, they're not sure it's completely fixed.
The problem seems to be that I use too much vinegar when making my sweet and sour sauce.

OK. The above story is a lie. The following one is not.

The growth in demand for Verilab's services appears to be unending. (Yes, yes, I know there's a recession on and stuff, but no one seems to have told our clients yet.) So, I'm always looking for a tool that will help us shuffle about our existing team, and expose exactly who/what/when we should hire to fill the gaps. Believe it or not, we used to, in Verilab's early days, use some pasta shapes with sharpie-inscribed initials on them. But we've moved on a bit since then. So I occasionally try out a few likely software candidates. So far, I've always ended up settling back on Excel as the best quick fix.
Until today.

The idea is simple. Each person's initials go in a cell, with a different background color for each. Then copy/cut/paste/drag can be used to move people about. Now, we already have more people than base
colors, so I was using light <color> for one person, and dark <same color> for another. For example, one consultant was dark (or, knowing this consultant, "deep") purple.  Trouble is, the default black font  doesn't show well against the dark. So I changed it to white.

Excel crashed.

I tried again.

Excel crashed.

I rebooted my machine and tried again.

Excel crashed.

I tried again.

Excel crashed.

Then Vista threw up one of those as-helpful-as-that-infernal-paperclip "we know how to solve this problem" boxes. Sighing, I clicked the "Fine, go on then" button, and it gave me:

"This problem was caused by a known issue with your Hewlett-Packard printer driver, which causes Microsoft Office 2007 programs to close unexpectedly when your HP printer is set as the default printer. Hewlett-Packard is aware of the problem and is working on a solution."

Knife. Wrists. Slash.
I'm off to buy some pasta shapes.
In the meantime:

1. If you know of a simple resource-allocation tool, please let me know
2. As ever - if you're an exceptionally strong verification engineer and programmer with a minimum of five years experience, only happy when wrestling with the toughest challenges, longing to travel, and want to join the best team of VLSI verification experts on the planet, what are you waiting for? Give us a call!

Connecting geographically distributed consultants

[Re-hash of a posting I made to the PSVillage forum]

Verilab is a multi-site, two-continent, three-country firm (UK, Germany, Texas), with consulting teams scattered across clients from the US West to East Coasts, to umpteen places in Europe, and with growing presence in Asia, the Far East, and South America. The challenge is helping my team to remember that they are a team, that they are my team (i.e. that they are Verilab as opposed to <whatever client they may be in>), to let them benefit from being that team, and to do all of that across space and time (zones).

To help keep us all together, we've tried (and still use) a number of tools and techniques, including:

1. Company-wide email lists. This is the oldest mechanism. We used to have several of them - some technical, some business, some serious, and some for Friday afternoon nonsense. But we realized that volume is important for lists, and too many lists each with too little volume would die. So we merged them into one until such time as the volume gets too much. This works well, but needed a lot of care and nurturing to begin with. Some shy individuals still hide in the shadows too much.
2. Company wiki (we use Twiki). This has lots of potential but hasn't yet worked as well as I'd hoped. We have a ton of stuff on there, but lots of "entropy food". There is a core of material that is useful, but a lot that is old and hairy. Overall, it's worth having, but probably needs more personal attention.
3. Internal blogs. Some success. This seems to be a very personal thing. Some people love to tell other people what they're up to - and some don't. This is a horse I'm still flogging, because I think it's A Good Thing.
4. External blogs. More success. My ideal would be that there would be *only* external blogs, but then there's almost no chance of getting the quiet shy people to speak up. Also, see point below about Yammer versus Twitter.
5. Yammer. A surprising recent success. We messed with Twitter, but that's externally visible. One of my guys found Yammer and we gave it a go. All of a sudden, people are ... well, yammering back and forth across the Atlantic. The odd one-liner of status, occasional yells for help, and even the beginnings of technical discussions that then move onto some of the more appropriate forums (like our mailing list). My aim was that it provide the same sort of impromptu conversation that
   co-located people get by standing up and yelling over their cubicle wall. Seems to be achieving some of that. The fact that Twitter (public) got very little uptake while Yammer (internal only) took off was noteworthy. As with all of this stuff, the human issues are more important than the technical ones, and obviously feeling safe that your conversation was only among "family" was an important human issue. Recommended if you want to try something out.

We've also dabbled with the usual meeting-enhancing suspects, including:

• GotoMeeting - works fine, does what it says on the tin
• Skype - ditto. We use this a lot for one-to-one, and occasional video conferences. Multi-cast video would be cool.
• Shared Google Apps presentations. Just tried this last week and it worked great. Much Cheaper than GotoMeeting, and if all you were using that for is PowerPointing, Google may be worth a look.

We've had at least one such meeting where the attendee list was:

• Group A - Austin, TX office
• Group B - Munich, Germany office
• Attendee C - at home in Edinburgh, Scotland
• Attendee D - in his car in Texas
• Attendee E - in Bristol, UK airport waiting for his flight

Worked surprisingly well.

Overall, the degree of technical collaboration we've achieved is, I think, superb. I see detailed technical inquiries flashing back and forth and being answered with a speed that the official support channels of the tools we use just can't match. And ramp-up time on any given skill is dramatically reduced for any engineer who wants to yell for assistance on a new area. This has huge positive benefits for our clients too. It's rare that any single engineer can know every answer to every question instantly. But in Verilab, our clients can get access, through any one consultant, to the much larger "verification hive brain".

And all meetings must now be carried out in Esperanto

Psst. Would you like to hear a secret? It could help you and me make lots of money. Maybe we'll be famous too. Either way, it's a really cool secret. Want to hear it? I have a condition though, before I tell you.

I need you to agree not to go off and exploit the secret without me. I've put quite a bit of work into figuring it out, so I want you to work with me, not against me. Of course if it turns out that you already knew the secret - maybe I'm only imagining that it's cool and new - then the condition doesn't hold. But if I'm really letting you in on a proper secret, I need you to agree to work with me, not against me. Sound fair?

Now, let me be clear. I will not be offended one bit if you don't want to hear the secret. I'll say that again. No Hard Feelings. Really. Some people don't like secrets. That's OK. And if you're one of those people, fine. We can even still work together. But not on the secret.

So, what do you think? I give you the secret. In return, you give me an assurance that you won't use it without me. Are you in? 

If you said "yes", you and I have just made a form of "Non-Compete Agreement", something that the worthy Joel Spolsky says is, in the context of employment contracts, "completely outrageous". His remedy reflects the fact that, whether he likes it or not, Spolsky is as good a salesman as he is an engineer (which is, incidentally and as far as I can judge, very). His remedy is to point out to engineers-under-pressure-to-sign-a-non-compete that they may have a bargaining chip. He suggests:

"If the employer absolutely, positively insists that you promise not to go work for a competitor when you leave your job, you can tell them: "fine. You don't want me to work for a year after I leave, that's fine, but if I'm going to be 'on the beach', I want you to keep paying me my salary for one year after I leave, until I can legally get a job that you approve of."

And you know what; providing that is proposed in the same "no hard feelings if you don't accept" spirit that my original "you must not use my secret against me", it's a reasonable tactic (although not one I'd recommend). The potential employer can weigh the costs and benefits, just as the potential employee can. And both can decide according to their own sets of individual priorities.

But suppose they - both employer and employee - were forbidden from doing that weighing. Suppose Someone Else decided that under no circumstances is a non-compete permitted unless the employer continues to pay salary after the person has gone. What that Someone Else would be doing is effectively imposing a form of minimum wage. They'd be forcing the employer to pay above a certain mininimum OR NOT AT ALL. That Someone Else would have taken the ability of the potential employee to try to work a deal and turned it into an Unalianable Right. And I've already argued how careful we have to be with those.

So, does such a Someone Else exist. Well, yes it seems they do. And, unfortunately, it's the German government again. Here is the clause - something identical being legally required in Germany - covering non-competition in a new draft employee contract I just reviewed for a business partner in Munich:

"During the non-compete period the Employee shall receive a compensation which amounts for every year of the prohibition to half of the contractual benefits last received by the Employee."

Remember, there is no negotiating on this. The Employer has only two options if he feels he must protect the secret: he can either have the non-compete and pay money to the Employee after they leave; or he can simply not give the Employee access to the secret at all. There is NO MIDDLE GROUND. Even if they both agree, the Employee and Employer cannot make that agreement the basis of employment. (Well perhaps they could; but it would be unenforceable).

So, with a simple swipe of a pen, some bureaucrat has added another nail to the coffin of German engineering employment. Because with that pen, said bureaucrat has made Indian, Chinese, Roumanian, you name it employees more attractive (to the extent that those governments have a more laissez-faire approach) by making German employees less attractive.

They may as well have said that all meetings in Germany must be carried out in Esperanto.

Much Ado About Methodologies

ACT 1 Scene 1

It's an an early morning in Verilab Austin. Tommy's office. He's just picked up Davie Robinson who is visiting from the UK Verilab team. Davie's now working in the conference room with JL, while Tommy goes over his email. As he works his way through the list, a sequence of visitors arrive, either physically or via new emails or IMs:

[Davie pops his head through Tommy's office doorway]

Davie: So, when did we standardize on the VMM?

Tommy: When did we what?

Davie: The VMM. You said we standardized on it.

[JL arrives next to Davie]

JL: Why did you say we've standardized on the VMM?

Tommy: [suspicious] Who says I said we standardized on it?

Davie and JL: [together - pointing to a press release] That did!

Email from Gordon (Verilab UK): Seems we've standardized on the VMM

JL: Did you see Gordon's email?

Tommy: Hang on I'm ....

Email from Mark (Verilab Germany): I'm using OVM at the moment. Am I supposed to stop?

Tommy: %*&!$....
[Exeunt JL and Davie. Backing away, slowly]


Here's the reason for the consternation:

http://synopsys.mediaroom.com/index.php?s=43&item=605

You see, the trouble with press releases, as any political press secretary will tell you, is the devil's in the details but the message is in the large. You have to keep an eye on them both. Here's the core of our quote:

"We have found that VMM can act as a key component in such a deployment [of an effective methodology]..."

And that does indeed reflect the reality of our day to day work. The VMM really can, and in fact does, add significant value to chip teams. We have deployed, are deploying, and will continue to deploy the VMM at clients where it is appropriate. Now as is normal with press releases, that phrase and others went through various revisions, back and forth between us and the final editor.  But in the end, the meaning stayed intact. Now look at the bigger context:

"Leading European Design Consulting Firms Standardize on VMM Verification Methodology"

Unfortunately that can obviously be interpreted as:

"Leading European Design Consulting Firms Standardize EXCLUSIVELY on VMM Verification Methodology"

And of course in Verilab's case, that isn't correct. Here's why.

Verilab tries to plough a scrupulously objective furrow in EDA when it comes to tool vendors. Our primary allegiance is, rather, to our clients. And while we consider Cadence and Mentor and Synopsys (see how they're in mere alphabetical order) among several others to be our good friends and partners, we are exclusive to none of them. And by "objective", we don't mean we'll say the same amount of nice things about each vendor. If vendor A's offerings were consistently inferior to vendor B's for a given client, we'd tell the client (and, if they were open to our advice, the vendor). And if A was consistently worse than B for everyone else; well we may well tell everyone. That's our job. And it's why our clients like us. We're not just contractors, we're consultants. We've seen more chip flows, across more tool suites, in more clients and more countries than most any other team on the planet. And we have no hidden tool agenda. If a spade needs calling a spade, we'll do it. So if the amount of nice (or nasty) things we say about each vendor happens to be the same for each, that's because that's how we call it. And in fact, that *is* in general how we call it. Our view is, consistently, that choice of tool vendor is not, from a technical point of view, the decisive factor in verification capability. Verification is fundamentally a problem of Peopleware; not, per se, Software, or Toolware.

So there you have it. Verilab absolutely believes that the VMM can be a key component in the deployment of an effective verification methodology. But it is not the only such key component and it is not the only approach used by Verilab.


It is, as Shakespeare said, my bad. None of this was the fault of anyone at Synopsys.

The Dangers of Gratuitous Unalienability

Suppose there was a bill passed tomorrow, creating a law that made the minimum hourly pay rate for engineers in the US $10,000/hr. As of tomorrow, paying a US engineer anything less than that minimum rate would become illegal.

Would you care?

Well, if you're a US engineer, I hope your answer is, "Hell, yes I'd care. What a stupid law". And, contrariwise, if you're an engineer anywhere else, you could be forgiven for rubbing your hands in glee at the thought of all that formerly US work coming your way.

But suppose, now, that the same law was created, but with an "Only If You Want To" exception. In other words, suppose the law said that your clients could pay you no less than $10,000/hr, unless you and your client made a prior arrangement for a lower rate. Let's call that prior arrangement an ... oh, I dunno ... how about "a contract".

Now would you care?

In this case, I imagine the answer is a puzzled, "But surely that's no different from no law at all?" And you'd be correct. By allowing you to give away, or abandon the "right" to a $10,000/hr rate, the damage created (in the form of making you unemployable) of the original law is undone. In other words, the damage created by the original law arose out of the fact that the original law took a simple pre-existing right to a $10,000/hr rate (hey, I'm free to quote that to you today if I want) and forced it onto you and your intended clients or employers in the form of an obligation. The damage arose because laws tend to make some rights unalienable - that is, you cannot choose not to have the right in the question.

Ah but if only this was just a wee story. And of course, it's not. As well as operations in Austin, TX; Bristol, England; and Edinburgh, Scotland; Verilab also has an office in Munich. And the German bureaucrats are very, very good at this kind of thing. Take, for example, the recently announced German "Nursing Care Leave Act" (Pflegezeitgesetz “PflegeZG”) which came into force earlier this month and which my friendly neighbourhood legal advisors in DLA Piper sent my way. Germany regularly comes up with little gems like this, adding more and more "rights" to employees. As a result, the poor Germans, saddled as they are with an increasing burden of unalienability, find themselves increasingly uncompetitive in the world market.

Of course, work goes on in Germany. Verilab has had an office there for over five years now, and we're looking to hire, as always, superb engineers. But we, and everyone else, would be hiring even more superb engineers if the burden of gratuitous unalienability was lightened. nicht die Spur einer Chance.

Verification Planning

David Robinson, another Verilab dude, has started a blog over here. Coincidentally, David also just uploaded his recent DAC presentation, made in association with Springsoft. The document is simply the PowerPoint slides, so it'll be of primary use to anyone who attended one of David's sessions and wants the slides as a reminder. Verilab does however provide intensive consulting on requirements-based verification, so if you'd like to discuss that in more detail, give us a call. Our emails take the usual canonical form: firstname dot lastname at verilab dot com.

What does business need from "The Government"

That - specifically about EDA, but it applies more widely - was the thorny issue tackled by some brave souls at one of the numerous panels at DAC last week. It's good I wasn't on that panel. My answer to the question tends to be a more or less (usually less) polite version of "To have them get out of my face and let me get on with running a business." In particular, the visa issue they discussed is always a raw nerve for me. It's not just that I myself am an immigrant. It's the fact that my US clients, owned by US shareholders, with lots of US employees, paying US taxes, are crying out for good technical people to make more money for those shareholders, employ more of those US folks, and pay more US taxes, but can't find enough of them because the immigration policies of their own of-the-people-by-the-people-for-the-people government are:

1. Blocking foreign talent who want to come here from doing that and, as a result
2. Scaring the local talent away from engineering (because they think all the jobs are going to India)

The first point is particularly frustrating. Put it this way. There is very little question as to whether the amount of VLSI engineering being done by Indian, Chinese and other "foreigners" is going to increase. It is. The only question is, where are they going to be doing it: India or China, on the one hand; or, on the other hand, here. And as current policy stands, it's not going to be here.


It reminds me of a survey in which I participated earlier this year. Somewhere in "The Economist", I'm on a list of people to whom they send such surveys from time to time. As a reward for participating, they'll send me books and let me see the results. This one was on how immigration rules were affecting business in the US. And they appear to have published the results more widely than usual. I'm not sure how long these links will stay live, but here's the press release:

http://graphics.eiu.com/upload/eb/EIU_immigration_PR.pdf

and here is a graphical version:

http://tinyurl.com/3e3bum

Personally I think they're being overly hard on the Americans. I mean, the UK isn't exactly open-armed to the world either. And Europe as a whole - not exactly the land of immigration opportunity, is it? (Just say "van der Elst Visa" and stand back.) No, the real criticism I'd have to reserve for those who although clearly understanding the principles of "Life, Liberty and the Pursuit of Happiness" choose to ignore them; those for whom the terms jus soli and jus sanguinis should be mere Olde Worlde artefacts, never to be used in anger, but instead are baked right into the zeitgeist. The real criticism is reserved for any nation which, despite being:

"...conceived in Liberty, and dedicated to the proposition that all men are created equal",

despite knowing that - to misquote Lincoln:

"They that can give up essential liberty to purchase a little temporary [job security], deserve neither liberty nor [job security]."

and despite having stapled to a big bloody statue the words:

"Give me your tired, your poor, Your huddled masses yearning to breathe free."

still choose a policy that is the modern equivalent of the common ownership of the means of production.

Did I mention this was a raw nerve for me?

Cadence, bla, Mentor, bla, acquisition, yada ...

So now we, 60 and climbing EDA bloggers, have something to blogstorm about. JL's on it already, scooping me by five minutes. And John, at his Semi-Blog, is even gathering comments. Daniel Payne, over at Chip Design Mag, has a take too, and none too complimentary.


Daniel's general sense of underwhelmedness is understandable. But he misses one semi-important verification issue when he says, of a merger, "it really wouldn’t bring the EDA industry anything new". One thing it could do is reduce the number of SystemVerilog methodologies out there, from three to two. The three being the VMM, and let's call them: OVM_m (Mentor's OVM) and OVM_c (Cadence's OVM).

Twittering and Tumbling

Interesting comments on Twittering. And now I'm wondering where, if anywhere, Tumbling fits in.

On Write-Only Code and SystemVerilog Implicit Port Connections

At the iDesign II session, Cliff Cummings gave a great overview of SystemVerilog implicit port connections. Cliff was, as always, an excellent and enjoyable presenter. And the material was spot on, and current. But at several points during his talk, I felt like someone was scratching fingernails down a blackboard. It wasn't so much Cliff and his presentation. I'd have to say his was one of the best in DAC. Rather it was those subtle wee implications you can pick up if you listen really carefully to a presenter's ad hoc sidebars. Here then are Three Important Things I learned from Cliff (other than the undoubtedly useful details of how implicit port connections work).

The First Important Thing was Cliff's observation that the connectivity-intensive HDL top level of a big SoC is almost completely uninteresting to the human reader. While we have to get those connections down "on paper", few people will ever then want to read them. In "The Budding Artisan's Big Book of Beautiful Code Examples - Learn from the Masters", nowhere will you find a chapter on top level SoC connection code. The top level is, effectively, Write-Only code. In that respect, it's the opposite of what Don Knuth advocated with Literate Programming. The question is, why? The whole point of high level languages is to wrap boring, repetitive, typo-prone structures in an abstraction that protects the humans who have to write things down. The fact that SystemVerilog hasn't really figured that out (interfaces aside) suggests that the abstraction SV provides is, at best, leaky. Look hard enough at Java and you'll see, well, Java. Look hard enough at SystemVerilog, and you'll see wires, and flip-flops, and gates. Oh my.

OK, but so we still need the top level. And interfaces don't take away all the pain. Fair enough. The nice people at the Department of SystemVerilog haven't left us to wallow in our typos. There's a solution in the form of implicit port connections. If the ports on a top level instance have the same name and width as the wires to which they are to be connected, you can avoid the usual shenanigans of connecting them all up and instead just saying the magic words "dot star". Now I'm not a language expert, so take the following with a pinch of salt. But .* smells bad. My first reaction was similar to the one I had when I heard about the use of the * wildcard in sensitivity lists; namely, well why didn't they go the whole hog and give us full regular expressions?

The Second Important Thing I learned came from Cliff's explanation of why they didn't give us full regular expressions. In fact it turns out that the idea of expanding the simple * wildcard to a more complete regexp was discussed. See, those language committee dudes are clever people. The reason the language dudes (hurray) didn't implement the regexp's was because the tool vendors (boo, hiss) pushed back on the idea. Said those same Evil Tool Vendors:

"Hang on. Let's get simple .* going first, before we mess with the gore and pain of more complete regular expressions."

And of course, who can blame them? The key point though is that languages such as the ones we use in EDA are not developed in the cathedral-like purity in which things like Lisp and Haskell arose (if indeed even they did). Our industrial-strength, real-men-have-fabs, your-methodology-sucks-three-cheers-and-a-cookie-to-me languages have a large political component to them. Surprise, surprise. Let's get over it and just remember not to simply blame the poor language committees when they make something a bit smellier than we'd like.

The Third Important Thing was Cliff's explanation for the existence of the ".name" construct. Are you sitting down? (I was, which is just as well.) The ".name" construct is a compromise, made because your typical user of SystemVerilog is scared of the .* construct. Having that 2000-line piece of incomprehensible top level connectivity reduced to a 1000-line list of .*'s, is giving designers the world over the heebie jeebies. And the depressing thing is - Cliff is right! Partly because your typical chip head is a EEE graduate who didn't get the chance to write much code at university, and partly because his typical manager is an EE graduate who may not have had the chance to write any code at university, today's typical VLSI engineer is less comfortable with software engineering than is good for our craft.

So there you have it. Three Important Things I Learned Today:

1. The SV abstraction is leaky, especially at the top level
2. Tool vendors have more to say about language design than your average Joe Designer may realize
3. Average Joe is, however, taken into consideration. Specifically, the fact that he is not too smart on the software engineering front is a bigger factor than you might think

I can just hear the collective, "Well, duh!" resound across EDA-land.

Panning for Gold in California

I'm not sure I actually attended DAC. That root canal flared up and I needed a visit to an emergency dentist the day before flying out in order to pick up some antibiotics to kill off the nascent abscess. That, and heavy doses of Vicodin and ibuprofen left me a bit dazed as I wandered around the exhibits.

Or maybe that was just the exhibits.

Because as the pain, abscess, and Vicodin wore off (and yes, it was just those things - I didn't even make it to the Denali party), I realized just what DAC is (apart from being a Cortical Homunculus). It's another California Gold Rush. True, we're a bit further south than Coloma, but it feels the same. Excited people, from all corners of the globe, descending on an unsuspecting town in the hope of finding a particularly large nugget of value. And, as with the actual Gold Rush, much of the hope is forlorn. It's not that there's no value to be found. Far from it. But the really big nuggets? Like the one found by Spider Conway in "Pale Rider"? Those are rare events.

Finding a major nugget can be industry-changing and create one of those inverted knees in growth curves. Unfortunately, but not unexpectedly, there were none at DAC this year. In fact, in the area of front-end digital VLSI design, I reckon there have really only been two such nuggets found in the last 25 years. The biggest was synthesis of RTL in the early 80's. This was to VLSI design what the then Taniyama-Shimura Conjecture was to Fermat's Last Theorem. Taniyama-Shimura said, very (very) roughly, of two areas of mathematics,

"See elliptic curves? See modular forms? Well, they're kinda the same thing."

As a result, theorems from one area were then able to be applied to the other area, solving problems that had remained pains in the neck for years. And so it was with synthesis in VLSI design. Acting as chip design's very own T-S Conjecture (now a proven Theorem):

"See hardware design? See software design? Well, they're kinda the same thing"

And then all of a sudden, freed from the restrictions of schematic capture, chip designers were able to look to their software cousins and pinch years of well-established methods and norms and apply them to their problems.

The other major nugget was "found" a decade later, in the form of high level hardware verification languages, such as e and Vera. It was more of a corollary to the bigger discovery of synthesis, rather than a significant theorem in its own right. But it was still highly significant. While RTL, expressed in Verilog or VHDL, was a huge advance on schematic capture, it was still little more than assembly code. HVLs raised the abstraction significantly, and were to HDLs, what C, C++ and beyond are to X86 assembler.

But anyway, as I say, no such nuggets this year. There were, however, a fair number of smaller prizes. None will create a revolution, but if each can knock 2% or so off product cycle times, that can soon add up to significant value.

The most obvious has to be the perennial (and my word is it perennial!) Formal Verification. Jasper, One-Spin, Averant, to name but three. FV's biggest problem is probably its associated over-hyped expectations. But keep it in perspective and it's absolutely a Good Thing. Only yesterday, there was a rapid-fire internal mailing list discussion between some of the Verilab teams in the UK, Germany and US about the applicability of FV to a particularly complex arbiter structure. If the time to verify that structure can be reduced from four weeks to one week, with the added benefit of the confidence provided by FV, what's not to like. Just don't get carried away. FV has been touted as The Answer for at least the past ten years, and it will be so touted for years to come. It's not, and it won't be. But not being The Answer doesn't mean it can't be an answer.

Another example is Certess's Certitude. This is trying to deal with the worrying problem that testbenches are becoming at least as complex and, as a result, bug-prone, as the designs they are meant to verify. Given that growth in complexity, how can we be sure that the testbench is able to spot a bug in the design if one exists. In some ways, Certitude is more like a nugget of platinum than one of gold, in the sense that it has been staring us in the face for ages but we haven't noticed its value. I spoke to one of Certess's founders, Mark Hampton, several years ago when they first conceived the idea. It was one of those "Dang, that's so obvious. Why didn't I think of that?" moments. Five years or more on, and clearly putting that "obvious" idea into practice has taken a lot of work. But it looks promising. Again, it's not like inventing the wheel, or discovering penicillin, or realizing that if you stick your finger in a glass of newly-poured diet coke the froth will dissipate more quickly. But worth keeping an eye on nonetheless.

Finally, an at-first-sight uninteresting nugget from Starnet. Their X-Win32 X server is barely noticeable amid the shouts of "OVM!", "VMM!", "My simulator can beat your simulator!" heard all around the DAC exhibition floor. But think about it. VNC-ish-ness, persistence an' all, but faster (if their claims are true). With the increase in use of distributed teams, that could be similar to the sort of performance improvement you get when moving from a 12" monitor to two 22" monitors. A lot. And, at a couple of hundred bucks or less to get those wave displays refreshing faster - not so uninteresting after all.

How lawyers govern their own corporate blogs

Sitting for two hours in the dentist's chair this morning for part 3 of 4 of a root canal treatment, I took the opportunity of various pauses (wait five minutes for the local anaesthetic to take effect; wait for six minutes for the post to set; wait for six minutes for the crown impression mould to set; and so on) to catch up on some blog and email reading using my new iPhone. (Aside: I've used iPaqs, Blackberries, and Treos. The iPhone simply buries them all.)

Some interesting blogging stuff over at Real Lawyers Have Blogs. In particular, this sample blog policy could be useful. And, the "Related Posts" at the bottom of that article are good starting points for further browsing.

Ow. Have to go. Local is now wearing off. Where did I put those painkillers...

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.