There's so much to see at DAC.
The circus atmosphere of the Exhibit Hall floor with the enormous over-sized booths, the exhibitors in matching polo shirts manning their stations, milling attendees streaming up and down the aisles, the magicians, the talent, the barkers, the toys, the nonsense and the noise, and those ever-present and annoyingly loud neon lights, flickering so far overhead that you can't even see them if you try.
Elsewhere in the Convention Center, there's the sacred hush of the padded, labyrinthine corridors of the Demo Suites where secret deals are going down behind very closed doors and you just know that the real stories of the show are being told there, stories you'll never hear – at least for now.
There's the spacious Press Room on the second floor full of old friends, great staff, good cheer, and the ubiquitous – though sometimes lukewarm – coffee, and dozens and dozens of dutiful Press Kits standing ever at attention on long narrow tables that line the walls of the room.
There are endless Panel Discussions in rooms A and B and D – often served up with breakfast or lunch – with easy to understand concepts and lots of people in the audience. And there are Technical Sessions with thinner audiences, but ideas much tougher to grasp and, therefore, more satisfying once mastered. There are keynote addresses with speakers dwarfed by their own images, which are projected onto huge 30-foot screens on either side of the stage, so that the people in the back of the hall can see the color of the tie standing behind the podium.
There are jacketed guards at every door of every venue constantly, constantly checking your badge to be sure that you have earned the right to enter. There are bookstalls and tables full of bottled water and everywhere there are engineers, managers, people, and ideas – many thousands on all counts.
DAC is a complex event and hard to get your arms around.
However, halfway through the fourth of my five days in Anaheim, I happened onto a conversation with five technologists that was as good as it gets at DAC.
Jim Lipman's Wednesday panel started at 7:30 AM and had just concluded a 2-hour discussion of what's wrong with front-end to back-end hand-off. Many people had already rushed off to their next meeting or session.
But a few lingered on in Room 213A, and suddenly I was confronted with a set of business cards and an even more imposing set of intellects determined to dissuade me from my stated lament that no matter how clearly tool users articulate their needs, it seems EDA vendors stubbornly refuse to listen.
John Sanguinetti, Forte Design, was somber and direct in telling me that I was completely underestimating the seriousness of the problems facing EDA tool developers. “The reason that EDA tools don't solve all of the users' problems is because these problems are really tough.” His was a message of reprimand for me and anyone else foolish enough to try to simplify the long-standing challenges that have characterized CAD tool development for integrated circuit design.
Magma's Arvind Srinivasan tried to soften the message by assuring me that serious conversation happens on a daily basis between EDA tool vendors and their customers. “The phone calls are really flying back and forth every day.” He asked politely, but firmly, that I give credit where credit is due to the vendors who are trying so hard to meet their customers' needs.
Cadence's Eric Filseth said that vendors regularly face lots of tough questions from customers in one-on-one meetings, and that I needed to remain ever cognizant of the time lag between EDA tool development and EDA tool deployment.
He recounted a story, perhaps apocryphal but meaningful nonetheless, of a user who had carefully detailed his needs to a major EDA vendor. The vendor promised to get back to the user within 6 months with a solution. After 6 months, no solution was forthcoming. The vendor admitted that the problem was more difficult than he had initially thought, and asked for another 6 months. Again, however, no solution was forthcoming after the allotted time. The vendor said now he understood that the problem was really, really difficult and needed yet 6 more months.
After those additional 6 months, the required tool and functionality were finally delivered. Unfortunately by that time, as could have been predicted, the tool was no longer relevant. The technological aspects of the problem had evolved and the tool was essentially obsolete. Having seen this happen so many times, Filseth said, “Now I'm a nihilist when it comes to EDA.”
Magma's Yatin Trivedi (previously with Intrinsix) said, “The users' problems are a moving target. They're always changing even while we're trying to solve them.”
So I asked about a different strategy. Why don't designers and design houses just develop their own tools as their needs develop? Wouldn't that be much more efficient, producing solutions specific to each problem?
NEC's Wolfgang Roethig, said, “Internal CAD tool development at user companies is dead. It doesn't work. Now we're relying on the EDA industry to solve the problems.”
Srinivasan said, in any case, my strategy would be reducing, not increasing, efficiencies. He said it's a matter of keeping track of global solutions versus local solutions. Many users have the same or similar technical hurdles to get over, and tool vendors can provide the means to confront those hurdles with similar tools, albeit customized at times to address a particular end-user's needs.
I said that after wandering through many company meetings and booths at DAC – companies with only 10 or 20 employees – the whole business model seemed so wasteful. Why not join forces across all of EDA? I told them how frustrating it is to see so many great minds (well, maybe I didn't use the word “great,” but they knew what I meant) scattered across so many small companies, all seemingly at work on the same or similar problems. Why not join them all together in a great army of talent and knowledge, and have them work to solve the design issues in one concerted, integrated, and inspired effort?
Trivedi said, “Do you mean something like EDA, Inc.? Well, that's a great idea – but only if I get to be the boss.”
Sanguinetti said, “Small companies are the only place where innovation takes place. Big companies aren't the answer.”
I asked then, why do the large EDA vendors always seem to want to control the flow? Is that possible and why do they want to do that?
Several people standing in front of me said that no one vendor can own the flow, that it takes multiple vendors to provide all the necessary tools.
But Filseth said, “Actually, if you have a very small, very slow chip, you can design it with one flow – the Synopsys flow, now that Avanti is part of it.”
Roethig said, “Yes, but for high-end designs you still need lots of vendors, lots of tools. But, you also need standards. That's where the solution for the EDA vendors will be found. That's how you get the best tools.”
Several in the group were less than enthused. Sanguinetti said standards can often be counter-productive. Filseth mentioned the oft-cited VHS/Beta standards war that proved that “lesser” technologies sometimes win.
Sanguinetti countered, “Do you know why Beta failed? Because you couldn't record an entire football game on one tape. It was that simple.”
I referred to EDA, Inc. once again and said I wasn't trying to suggest that non-competitive, anti-free market strategies would solve the problems. I acknowledged that motivation often comes in the form of profits, particularly in small companies, should they be successful.
Sanguinetti corrected me one last time. “Engineers aren't really motivated to innovate by money. They're motivated by interesting problems.”
Srinivasan agreed. He cited many people within EDA who have already made their fortunes, but continue to work 14-hour days. “Engineers want to solve problems. They don't start EDA companies because they think they'll make a lot of money. They're just thinking about the engineering and the interesting challenges in all of it.”
Many minutes had ticked by. The 10 o'clock hour drew nigh. Many had meetings, sessions, other appointments. I told them that this was not the first time I'd been reprimanded for pointing out the muddle & meandering that I sometimes sense across the EDA landscape.