Kathryn Kranen- Jasper Design Automation
It is different now than it was. It's almost 20 years since I got involved in EDA. My first job I the EDA industry was 1987. When I say 15 years, I don't count the four years I was retired. It might be different but the only thing I see is that I have more girl friends who work in the industry. That's the only thing I can tell.
In terms of how I am treated by the men in the industry and other customers I can't say that it was ever an issue for me.
Earlier this year Jasper acquired Safelogic, a firm located in Sweden. How do you deal with the time and distance separation?
I'm very good at it. At Verisity you may or may not know the entire development team was in Israel for the entire time I was there. They had a few people in the Bay area and now some in India. But when I was there all R&D was in Israel and I went over there every month and I liked that. To me having a multi-geographic company where you have a real critical mass in some alternate location has a few kinks and pros and cons. One of the advantages is you have the 24 hour time clock. You can discover a problem and diagnose it one side of the globe and have it fixed on the other side by the time you get in ti the office. That's very nice. But it is inevitable in human nature that over time an occasional little resentment or lack of respect will crop up. Someone will say “Those guys over in such and such a group are just stupid. I can't believe that are doing it that way. They just don't know anything.” Those kinds of disrespectful little comments will start to pop up. I know exactly what to do. You pick someone from the complaining side and you transplant them, they become the ambassador for the other side. So we do a lot of cross pollination and travel. Especially importing someone from Sweden. We brought the entire team from Sweden for a couple of weeks to have hallway conversations for a while with the rest of the design team here. I think if every one knows that is natural for little issues to crop up and it is just as important to deal with them head on. You head them off. It's quite easy to manage.
How large is the group in Sweden?
Eight engineers in Sweden.
How many in total?
We don't publish our headcount because will look at the funding that you raise and the head count and try to reverse engineer you financials. So we are trying to give you an idea about Sweden but we really don't disclose anything for people to reverse engineer financials.
Jasper's recent product announcements (Jasper Gold 4.0) referenced the work from Sweden. Was this integrated, interfaced, standalone?
Integrated. This was a very, very tight release that had about half of the code from one product and half from the other product line maybe not in terms of lines of code but in terms of major functions. The two big contributions from the Safelogic team were motivators for our acquisition. Number one they have been benchmarked by a major European provider of wireless devices (whom we can't name) for a year against seven formal verification static tools with so called PSL support. Safelogic tools which were integrated into Jasper Gold were so far superior in its PSL support with its completeness and semantic accuracy. But most important in the synthesis of these PSL assertions for high performance full verification. Harry Foster has said that there are many rudimentary implementations out there of PSL but that the Safelogic team was highly regarded by Accellera, the standards body for PSL. They were the pioneers that were actually implementing the functions and coming back to the committee saying “No, no. We tried that and it doesn't work. It's semantically incompatible”. They were actually implementing as the language was being defined. They were in front developing, implementing, testing and coming back with feedback to the committee. So they are just so far ahead in PSL implementation for formal verification than anyone else. They saved Jasper quite a bit of time to market and improved the quality dramatically of out PSL implementation because we were able to get these experts from Safelogic. So PSL expertise but it's not just PSL because they also have SVA expertise. It's assertion synthesis performance expertise was one area. The other area was formal proof engines. This is the proof engine that goes underneath our tool. There was one engine that was developed by engineers at Safelogic that went to an international competition of proof engines that was held I think in Vancouver that year that benchmarked number one. That was how we first heard about Safelogic. Also Harry Foster knew them from the Accellera committee. Fast engine as well as world's best PSL expertise.
There are a lot of different approaches to verification. How do you position you product relative to these (competitive, complementary)?
The way I would divide the question is first what level of abstraction are you working at? As I mentioned earlier system simulation is when you have integrated all of the parts of the chip Maybe you are integrating three chips together. Regularly use emulation at that point. But there has been really a void at the designer size for each macro. That's where all the work is in parallel. All of your designers in the company are developing different pieces and unfortunately with the traditional simulation methodology you don't get a lot of testing done, you don't get a sufficient amount of testing done until you integrate it all together and even then it's impossible to simulate the whole design. So we aimed at a much better way to verify the design size blocks and doing these formal statically. In terms of whether we are replacing or not I think we have the power and capability to ultimately replace block level simulation within every account. Several of our customers have already done that, i.e. chosen blocks that they are not going to simulate at all. They are simply going to verify them formally. When they do, they never find another bug in that block. That's it. It is totally exhaustively proven. But many, many customers start by formally proving their assertions that are already in their designs from simulation. So that is a complement to simulation at the block level. We find that customer evolve over time to simulation replacement at the block level. And of course they continue to simulate at the chip level and system level. What they get from replacing block level simulation is that they don't have to build a very time consuming testbench. Instead of building a standalone testbench they've completely and exhaustively verified their blocks formally using Jasper Gold only 1/4 to 1/2 the time. A big productivity increase not to mention that you shrink down the system simulation because you never find bugs in that block.
Is there any size limit to how big a block is?
I'm glad you asked because all of our customers have a different meaning of block, so it is good to get it on the record. When we say block we mean what one single RTL designer can design in the course of a project. For some customers the block may mean what three designers do. Okay, we will ask them “What is the natural division of work between the designers?” That would be a sub-block. We mean that sub-block. In some case a designer will design many, many little blocks and stitch them together. Whatever one designer did over the course of a project is about the right size to formally prove. Wherever your natural partitions are in your hierarchies, even if there is not a specification at that level. You find that's one of the risk when you have designers interfacing with each other informally because the spec didn't go down to that low level, Our tool is wonderful for formalizing (pun intended) the communication of what the interfaces between the designers sub-block are supposed to be.
Be the first to review this article