What Would Joe Do?
Peggy Aycinena is a freelance journalist and Editor of EDA Confidential at www.aycinena.com. She can be reached at peggy at aycinena dot com.
Breker: The Art of Destructive Testing
April 26th, 2012 by Peggy Aycinena
Here in Silicon Valley, there’s a small company that should be on your radar. Founded in 2003 as a consulting service, the company discovered their solutions – developed to address customers’ verification problems – had become sufficiently robust to be commercialized. Over time, those solutions proved so successful that Breker Verification Solutions morphed into a 100-percent product company.
No longer a consultancy, Breker is thriving today, actively hiring with multiple openings posted on their website. and just this week named well-known EDA veteran Tom Anderson as Vice President of Marketing. I had a chance to speak by phone this morning with Tom Breker, CEO Adnan Hamid, and company CFO Maheen Hamid.
Adnan addressed the challenge of morphing from consultancy to product company: “As we have figured out how to do this, we feel we have done it with style. But still it’s true, this is a very hard path.”
Tom added, “We are relatively small, but already with people in Europe, India, and the U.S., and we have plans to grow over 2012 – looking for good AEs and hiring in R&D to implement the ideas customers constantly come up with. Our momentum is building as we cast a wide net for great employees, and work to serve our customers even more. So that’s the top-level view of company.”
And what does Breker provide?
Per Tom: “Huge number of design pieces today have to come together at the top level in an SOC, but customers are not doing a good job of putting those pieces together – it’s not like putting together Legos. The industry needs to go beyond today’s existing technology [to help] designers automatically generate verification code that will tie into a testbench for the entire SOC. I call it verifying from the inside out.”
Does that mean Breker’s solved the holy grail of system verification, I asked.
Adnan said, “Exactly, the holy grail of verification. And yes, we have solved it. Plug-and-play verification is what the industry needs, and this is what we’ve got. And like most technology solutions, we didn’t solve this directly, but in an unrelated way.
“Way back when I was in college, I worked for 6 bucks an hour for a research group working on problem-solving algorithms. Now it transpires that generating a system testbench is similar to generating a problem-solving algorithm.”
But if you’ve only now unearthed this SOC verification solution, I asked, how is it that there are so many complex chips functioning out there today?
Adnan said, “You’re asking, how the heck are the current chips being verified? Well, just as we wonder how they got 3 men to the moon in a tin can 40 years ago using nothing more than a calculator, 20 years from now they’ll ask how we verified these chips today?
“There’s such a deep stack on today’s SOC – so much technology – in theory nothing should really work, but it does, and that’s because of lots of hard work on the part of many smart individuals at the big chip companies.
“Twenty years ago, [PC makers] were sweating bullets getting everything validated, a huge nightmare, but the money was such that companies could hire thousands of people who labored in verification labs for up to 2 years just to make things work. And 20 years before that, it was IBM with a whole ton of people working really hard to do verification [on mainframes].
“Now today again, we have a whole bunch of people working really hard. Their lives suck, because no one person can possibly verify everything, yet somehow these guys are supposed to set up all of these handwritten tests. They don’t like it, but they don’t have a choice. It’s expensive and it’s really hard.
“It’s like the monkeys and typewriter. Given enough time, you get Shakespeare. Similarly, if you put enough random tests through the system, you’ll get the thing tested. But now as IP becomes a reality, as hardware becomes more programmable, there needs to be more focus. That focus is where the point of view of Breker differs from the rest of the industry.
“[In our opinion], EDA needs to move from processing data to processing knowledge, and we need to [consider] what’s going on in the engineers’ heads. How can we give engineers a truly intuitive way of writing down their version of how things should work? From our point of view, the whole is greater than the sum of the parts, and we need to educate the engineers that just because A, B, and C all work individually – IP blocks from various sources – you don’t know that they will actually work together.”
So, it’s a matter of education?
Per Adnan: “Yes, this is the biggest [challenge]. It’s true that in the more advanced SOC companies, they don’t need to be educated – the big guys, the Qualcomms, the STs, the NVIDIAs – but there are other people trying to come into the mobile space who are still trying to argue with us about all of this, who still need education.
“Breker believes the IP vendors do a great job of verifying individual components, so the question on the table is: When I put 2 pieces from Vendor A in with 3 pieces from Vendor B, along with these pieces from Bangalore and those pieces from godknowswhere, can I actually marry everybody’s work to everybody else’s?”
Tom said, “There is nothing that the IP providers can do with the block, per se, that will [anticipate] the problems that only appear at the SOC level.”
So again, what is Breker offering?
Adnan said, “We are offering a functional verification solution that’s tuned to generate tests for SOC systems. It can do two things.
“One is perfect vertical reuse, generating tests for individual IP that can be combined to create tests for sub-systems, which can then be combined for total system verification. At the lower levels, people want transactional tests, but once [everything] is in place, they then want a software test that will drive the whole thing seamlessly.
“The second thing we are offering is perfect horizontal reuse, a way of generating tests that work for the system TLM models, work on RTL simulation, on emulation and acceleration, and provide post-silicon verification.
“So, we take the problem of system verification, and look at how each block of IP in the system moves data. I don’t care what they’re doing [at the block level], we just want to know if they’re all dancing at the same time, and then we take them through all the use cases in the real world.”
And how do you define all of those use cases in the real world?
Per Adnan, “One way to look at the system, it’s all about data flow and knowledge management, and the question of how should knowledge be managed. Humans do well at representing data as information on a graph. Our underlying technology is a graph-based constraint solver, using something like CSP [constraint satisfaction problem] rules that produce a bunch of numbers.
“We need these more advanced constraint solvers, because human beings relate much better to [this type of solution]. Our verification systems are all about data flows, the underlying data representation being a graph of data flows. In the process, we’re breaking systems to verify systems.”
One of my favorite concepts in engineering being destructive testing, I asked Adnan if he feels Breker’s solutions are akin to that process.
Adnan, “We are absolutely all about destructive testing; it runs in Breker’s DNA. I sometimes talk with my customers about their SOCs, and I say, ‘Google might do no evil, but we believe just the opposite.’
“In fact, our work is organized to do as much as evil as possible. This sort of DNA – to do evil, to do destructive testing – runs through our powerful knowledge testing system. It’s really a great concept where we can run synthetic tests, as opposed to real world tests, because real work with real traffic does a lousy job of testing the system. In a very narrow behavioral space, real world tests are okay. But in 0.1 percent of the time, the behavior goes off into a corner case that does indeed break the system.
“At Breker, therefore, we put incredible synthetic loads on our customers’ system. In fact, we tell them, ‘We’re going to put these tests on your chip, and if your chip doesn’t melt we haven’t done our job!’”
One Response to “Breker: The Art of Destructive Testing”