August 21, 2006
Calypto - Equivalence Checking
Please note that contributed articles, blog entries, and comments posted on EDACafe.com are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
| by Jack Horgan - Contributing Editor
Posted anew every four weeks or so, the EDA WEEKLY delivers to its readers information concerning the latest happenings in the EDA industry, covering vendors, products, finances and new developments. Frequently, feature articles on selected public or private EDA companies are presented. Brought to you by EDACafe.com. If we miss a story or subject that you feel deserves to be included, or you just want to suggest a future topic, please contact us! Questions? Feedback? Click here. Thank you!
Calypto's SLEC product family is proves functional equivalence between two IC designs that contain differences in levels of abstraction and sequential behavior. SLEC can verify designs with sequential differences such as micro-architectural changes, state machine modifications, timing re-balancing, and interface differences. On May 22 the company introduced version 2.0 that increases capacity by 100x for System Level designs over previous releases, dramatically improves runtime and further simplifies the design debug process with counter example enhancements. This new technology provides the capabilities required for the broad ESL market. I had an opportunity to interview Devadas Varma,
Chairman and Founder.
Would you give us a brief background?
I am a cofounder of Calypto. There are 5 cofounders. I was the founding CEO for three years. Six months ago we brought in a new CEO, Tom Sandoval. He was General Manager at LSI Logic involved in the rapid chip project. Before this company I was CTO at Ambit Design System which was acquired by Cadence. Before that I worked for several EDA companies including Silicon Compiler Systems and Mentor Graphics.
What was your motivation in founding Calypto?
We actually started differently from most EDA companies or for that matter from Ambit where we had some technology. But here we actually started with a problem in mind. About four years ago we began talking with Tallwoood Capital. They are not a typical EDA investor. They primarily invest in semiconductor companies. While talking to them, they started describing the problems they had with the long design times for startup companies bringing out chips and issues with verification, delays, respins and all that. We were discussing what sort of EDA tool set or technology could help with that. When we analyzed it more deeply, we figured that the way that chips are being designed, SoCs and
most of the software content required a different way of starting a design. You can not really start at the RTL level. That's how we went about looking at what issues we would have to solve so that we can improve productivity.
Eventually we ended up being categorized as an ESL company but we didn't really look it as an ESL company. We looked at it as what problems needed to be solved that are not being addressed by the existing flow using RTL. So when we looked at it that way, we came up with three reasons why somebody would use a flow that could be categorized as ESL. Our own definition of ESL evolved from that. One reason was the necessity to do hardware and software simultaneously and to keep them current. You can not do hardware design first and then develop software on top of that. This requires that you need to describe the entire system at a software level, create a silicon virtual prototype and
develop software on top of that. The second requirement we looked at was if you would do that, then you would have a huge verification problem because you had to verify the hardware in the presence of the software and take the hardware part of the entire system to silicon and make sure that the system worked exactly like your prototype software. The third issue we looked at was power management. In our opinion the three key things RTL can not do for which you require a flow and a new technology are co-design, validation, and power. It wasn't driven by specific technologies like behavioral synthesis or anything like that but based on the requirement that there are certain things you can
not do currently for which you needed something new. As we went deeper into that we realized that even for that power management at high levels you require changes to the design that required verification technology. Because it does not matter what changes you make to improve power, you can't really signoff without verification. So we came down one more level and said that verification is the key enabling technology to move into ESL design for co-design, for power management, etc. We decided to devote our first three years to trying to solve that verification problem. That's when we came up with our first product which is an equivalence checker. It can verify the functionality of
your RTL design by comparing it to a SystemC or C++ description of that functionality, thereby verifying the RTL design which you can now go ahead and implement.
Your website refers to your technology as sequential analysis.
If you look at the main difference between RTL and ESL it is the way the sequential behavior of the functionality is being changed at the architectural level. That does not happen when you stick with RTL. RTL is by definition register transfer logic. You define the registers. You don't move them, you don't touch them. You optimize the combination logic in between. Verification is somewhat more predictable for RTL. because you can do cycle accurate simulation. You do not need to change testbenches. You can go ahead optimize your design to meet the timing between registers. Synthesis was more interesting because optimization being the key to meeting timing which is the key to RTL.
But if you look at ESL or architectural design, the main issue here was that timing was no longer fixed by register boundaries. You needed to change the architecture. You needed to change pipeline behavior. You need to do all of these things to improve power, to make the makes sure that the functionality remains constant even if you change sequential behaviors, state machines, pipelining, resources sharing, architectural changes for power. How do you do that? How do you analyze the behavior of two designs and say that they are doing the same thing like we could in RTL? Of course RTL was much simpler because time was not a factor, it was only the functionality. We worked on this
technology we called sequential analysis which is essentially saying that if I take a design, I can tell you whether the sequential behavior changes. In other words a multiplier is still a multiplier even if you make changes to the timing behavior, whether you pipeline it or whether you don't even have timing. You can have a C program which tells you that A = BxC. There is no timing involved. It is a combinational multiplier. But when you go ahead and implement that in RTL, you have a ? multiplier or you have a different implementation of that architecture. Our sequential analysis technology can tell you that these are doing identical things even though they are under different
timing behavior. That's what we call sequential analysis.
Our equivalence checking is based upon that analysis. We can once again take a C++ or SystemC description, a much more simplified, much more abstract description of behavior and take the implementation into RTL which could have been generated by a behavioral synthesis tool but not necessarily. It could be handled in RTL. We can compare them without using any type of engine, without spending time writing testbenches and tell you by formal sequential analysis that these are equivalent in functionality.
Would you describe your product family?
There are two different packages. One is addressed towards RTL designers who make substantial architectural changes. Some of our customers such as Renasas and Freescale have microprocessor oriented designs. Initially their problem was power management. They took existing RTL and changed the RTL by applying clock gating, by changing the timing behavior of the design through retiming, by changing the pipelining and so forth. But they were still working at the RTL level. These types of changes were sequential changes that were very difficult if not impossible to verify using testbenches and simulation. This is one segment of the customers we have who are not really using C++ or SystemC,
at least not these specific groups. They are very high performance RTL designers. We have a tool that addresses their concern by basically doing RTL to RTL equivalence checking. Now these RTLs are so different that existing equivalence checkers like Conformal EC and Formality can not address most of these changes or it is very difficult to create new testbenches and run simulation on these designs. That's what we call SLEC RTL.
SLEC System is our more advanced product where we can take much more different designs. For example one design could be C++ or SystemC design and the other one a synthesized version, perhaps generated by Forte or Mentor behavioral synthesis or it could even be hand written RTL. The customer wants to make sure these RTLs are still behaving exactly as they have in their validated C++ or SystemC design. That's our SLEC System product.
You can find the full EDACafe event calendar here
To read more news, click here
-- Jack Horgan, EDACafe.com Contributing Editor.
Be the first to review this article