Buzz words can kill the buzz

Much of this story will remain anonymous because my intent is not to embarrass anyone or company, but during a couple of interviews recently I have asked for definitions of a buzz word that they were using and they have not been able to define it properly, or in a way that I can understand what they mean. Of course, it is quite likely that the problem is with me, in which case people need to dumb things down when they talk to me perhaps.

The first event happened when a company was using so many acronyms that I had to stop them and ask what they all meant and how they fit together. They had acronyms that were generic, some were product specific, some for flows and some seemed to be umbrella acronyms that grouped the other acronyms together into a total acronym soup. I remember many years ago when Dan Gajski (did anyone see him at DAC this year?) said to me that you could tell how significant a research paper was by the length of the title. The longer the title became, the more words they needed to distinguish it from what had been published in the past. While there are some exceptions, I have found it to be a good rule of thumb. The same goes for some of these concepts that people are trying to coin and then shorten them with an acronym. Enough!

The second happened just before DAC. The conversation went something like this:
Them: …if you look at Gary Smith’s report on DAC, he calls this a silicon virtual prototype variation, so that’s the same as …
Me: I have to admit I’ve never really understood what that means. What is a silicon virtual prototype?
Them: you’re trying to create your silicon, but then rather than finding issue later in the implementation stage and come back and modify your RTL or modify your architecture, and that’s too late or it’s too costly, right, so it’s better to create a prototype of your silicon or your design up front.
Me: Okay, but how is that different than just an RTL model?
Them: the RTL has already captured the micro-architecture level, but a little higher than that, you can still do a lot of restructuring of logical hierarchies to make many virtual implementation you want. So you have an opportunity to change the micro-architectures to reduce power or…
Me: So that is a virtual prototype – right?

Well, this conversation continued for quite some time, and after establishing that this has not raised the abstraction level in any way, and did not actually involve any changes in micro-architecture, which would have happened when using high-level synthesis, we were back to RTL. The only thing I got out of this is that a silicon virtual prototype potentially has different physical and logical hierarchies. In emails after the interview, I was asked to just forget that they had ever said their tool was in this category.

Lessons learned: 1) Don’t obfuscate your pitch with so many buzzwords and acronyms that the real message cannot get through and  2) if you place your tool in a category, or someone else does it for you, make sure you can properly describe what it is and how you do, or do not, fit.

Are there aspects of presentations that confuse or annoy you?

Brian Bailey – keeping you covered

---

If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).

Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you).