"Jesus Mother of Fuck, what are you thinking! Do notWell, for "Groupware" read "IP Reuse Platforms".
strap the 'Groupware' albatross around your neck! That's what killed
Netscape, are you insane?"
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?
Post a Comment