Are you sitting down? Are you ready for some astounding news?
Thanks to Tufts EECS Professor Soha Hassoun and the entire DAC Technical Committee, I actually talked to an engineer by phone – two engineers, in fact – without any PR people in on the call. I mean, I actually got to ask questions of real EDA tools users without anybody standing between us.
“What?” you’re asking. “Where? How? Why?”
At DAC this year in San Francisco, a new kind of event debuted, the User Track Poster Session & Ice Cream Social, starting at 1:30 PM on Wednesday, July 29th. I attended along with a lot of other people ranging up and down the wide tunnel that connects North Hall and South Hall in Moscone Center.
Everybody who came got ice cream (actually, it was popsicles), while 38 different teams of EDA tools users and/or vendors and/or gad students stood and entertained questions from the milling masses that wandered in and around the posters. But it didn’t end there.
On Thursday, July 30th, those who attended the DAC Thursday Plenary Session found out which team won the DAC Best Poster Award, a new commendation inaugurated this year that stands alongside the traditional, highly coveted DAC Best Paper Award.
This year’s Best Poster Award went to a team of five, three engineers from Cisco and two from Synopsys, including Ben Chen, Srinath Atluri, Harish Krishnamoorthy, Alex Wakefield, and Balamurugan Veluchamy, for their paper: “Attacking Constraint Complexity in Verification IP Reuse.”
It was Ben Chen and Harish Krishnamoorthy from Cisco that I spoke with by phone.
The August 13th phone call …
Ben – First, I want to thank the Technical Committee from DAC. They put a lot of thought into what kind of papers they selected for presentation. The Poster Session is a very free-flowing process that takes a lot of pressure off of people, but it could use some additional checkpoints. I spoke to Soha Hassoun at DAC and gave her some ideas. She noted them down and said they would help next year to let authors know what to expect.
Q – Can you give me a brief synopsis of your paper?
Ben – We wanted to use real networking case studies that show how to solve specific constraint-random related issues.
Q – With respect to verification, what are your other options if not random?
Harish – You could do directed verification, rather than random, but random hits all combinations and then runs coverage to see what you’ve covered. With directed test cases, however, you’ll always know what features you’re testing.
Q – So random testing is always best?
Harish – No, directed testing is advised, because in random testing it takes a long time to set up the whole environment.
Ben – Both random and directed serve a purpose. We recommend a combination of both, because neither alone is proving to be enough.
Q – Why use networking cases to look at these issues?
Ben – That’s a good question. The direct reason is that we’re Cisco and we do networking ASICs. But, if you take the answer up one level, some of networking problems represent the question: Can you model mathematically some very simple problems that the constraint solver doesn’t have the capacity to solve?
It comes down to a random-ordering problem, a constraint random ordering problem, that can be used in CPU processor verification environments, so some of the problems with the mathematical model are not just restricted to networking.
This is one of the reasons that our paper was a little better received than others at DAC, because it was not just about the networking domain, but pretty much about all processor verification.
Harish – Also, this paper puts more emphasis on scalability. Any industry wants scalable solutions to their problem. Where there is a lot of networking knowledge, and lots of packets and constraints on packets, the problem has a scalable nature and the solution can be put on any processor.
Q – What parameters did you optimize to achieve the ideal design?
Ben – Ideal is not the right word. We’re looking for a more feasible solution, because we’ve simplified the problem into a very simple common mathematical model. Eventually, we did not find a solution just with the tool itself, but found the solution by working with the Synopsys application engineers.
Q – So this is a services solution, more than a product solution?
Ben – Yes.
Q – So some of the congratulations for your award should go to the Synopsys AEs?
Ben – Yes. They were our co-authors on the paper.
Harish – They helped us know what their tool does, but the solution was found because we were able to also know what the tool lacks. To those drawbacks, we added our methodology.
Q – I’ve always thought that a paper that’s too ‘real’ risks giving away the secret sauce of a design team. Is that a problem?
Ben – Yes, if you see it as our paper giving away a competitive edge, for instance, to a Juniper Networks engineer who can then do a better job with their verification work. But we’re not in the business of verification, so we’re not giving away our secret sauce.
Q – But isn’t verification part of what makes a good product?
Ben – Yes, absolutely, but we can compete and still exchange ideas. I compete, for instance, with Harish maybe as a co-worker, so we have a competition. But I don’t hold back some design secret from him [to win].
Q – Sometimes people are skeptical that the tool vendors are the ones who really write the papers, or propose the solutions.
Ben – Yes, that is a perception problem. If you look at some of the papers that were presented at DAC this year in the User Track, you could see some tool pitches. But, we knew that at DAC, and at conference like DVCon and SNUG, the first disqualification for any paper is that it’s a tool pitch. The feedback for our paper was specifically on this issue, because our paper came from the user’s perspective, and provides a user work-around and a practical solution.
Although we were presenting at DAC, we also spent some time at some of the other presenters’ papers and posters. It looks like at least some [of those submissions] were being presented from the tools vendors’ perspective, but ours was [more] from the user’s point of view.
Q – Is this a suggestion for next year for people who wants to submit to this session?
Harish – Yes, don’t be too vendor or tool specific. Our idea was [to submit] something that could be used by anybody, and also to highlight a common problem which basically anyone could run into. Anybody [could be] doing random verification. That’s why we picked it, rather than something [more esoteric].
For next year, [people might want to pick] as a problem something that is generic and relevant to many users, and whether it’s a services or tools solution, something that users ca relate to. [Of course], if it’s a tool solution that solve a lot of user issues, that’s okay.
Q – Do engineers get nervous when they have to make presentations?
Both Harish and Ben laughed.
Ben – Normally, if you hear a presentation [from someone who’s not nervous], there’s a good chance you’re hearing from the marketing people because they’re always smooth. However, we tried to prepare the heck out of our presentation, so if you disqualify our legitimacy because we were not nervous, that would be discouraging.
I’m not ashamed to say that we’re nerds and geeks, so the talking part of presentations is not our strong point. The free-flowing structure of sharing [ideas] at a user track session takes some of the butterflies out of it – especially because we’re so busy from day to day, that taking time to write a whole paper [would] take up a huge chunk of time.
The Poster Session doesn’t require a whole paper, just slides, which makes it a much more relaxed way to share ideas. Writing a full [conference] paper actually discourages users from submitting.
Harish – There is a lot of overhead with writing papers, a heavy workload, versus just making a presentation. A User Track session is just about sharing the ideas.
Q – The poster session seemed really lively at DAC.
Harish – Yes, at the poster session it was possible for people to actually talk to you, and that’s the real purpose of DAC. Yes, there is some marketing attached, but getting to say something to people [is the real purpose].
Ben – The secret is the interaction after the presentation, because it’s that follow-up that defines the Marketing versus Engineering presentation. If you ask Marketing people a question they can’t answer, they would say, “That’s all I know. Talk to an R&D guy.”
An engineer, however, would go on and try to answer your question.