Putting that into perspective for hardware design, we do tend to restrict ourselves to one language, and for most people that is SystemC. While you can throw in some C and C++, it really doesn’t add anything new or different. Others prefer Bluespec which they claim is better at describing abstract hardware because you don’t have to try and extract whatever possible parallelism happens to exist in a serial language. Ken made a similar point in our conversation.

I then brought up the subject of hardware synthesis – what we generally call behavioral synthesis. I was told that they really just consider it more as code generation and you can use most of Simulink, Stateflow and a subset of MATLAB to get to an RTL description. He told me that they are seeing substantial growth in this area. I asked him how much MathWorks charges for this. While he was reluctant to provide an actual figure, I got enough information out of him to ascertain that it is an order of magnitude cheaper that what traditional EDA charges for behavioral synthesis. So, immediately this says to me that either their product is much simpler, the EDA companies are charging way too much, or there is something else going on. I will come back to this point shortly.

So, in my previous blog I talked about how in the hardware world interfaces are quite central to the refinement process and Ken accepted. He said that typically they just treat this as a modeling problem as well. They approach design flows by considering a particular application and the type of people who will need that kind of solution and then prepackage the models and interfaces necessary to make it work for that group of people. That very much resonated with me. At DAC 2010, I gave a keynote address to a system-design workshop where I said that the people who were most likely to be successful with an ESL flow were those who restricted the problem in ways that it became soluble. I talked about how the platform developers could create tools that only had to deal with their specific platform, and FPGA vendors who had certain constraints on the problem space that meant that they didn’t have to solve everyone’s problems at the same time, and then it dawned on me that I had never considered MathWorks in this category. They are not making the restrictions because of the possible market they are going after, they are making choices that enable them to create solutions for targeted groups of people in a very economic manner.

And here, I think is the key. MathWorks is attacking the market in a way that means that while they cannot solve everyone’s problem, for defined groups of people, they can fully provide a totally adequate solution. They are not trying to do it all at once and some of their customers are not the ones attempting to create the biggest or most far reaching SoCs. At the same time, many of their customers are dealing with very complex systems, including the environments in which they operate, which may need to be modeled as well. In short, they attempt to understand and address the issues of specific classes of customers rather than trying to create a completely generic solution. Over time, as more groups of customers are included, full solutions may emerge. This basically means that they take a much more pragmatic approach to their development. Ken mentioned how he believes the typical EDA notion of a virtual prototype is overly complex for many design problems and yet at the same time they do not address the growing need to have analog represented at this level. He talked about the difficulty of really assessing a design without including things such as high-speed wireless or RF which are part of the tradeoff space.

Another difference between the MathWorks approach to the synthesis problem and traditional EDA is that EDA still lacks much knowledge about the embedded space. EDA always thinks about taking software and mapping it into hardware, but when you start with abstract descriptions of the complete problem, targeting software is equally valid and this also requires code generation. Again, by focusing on specific customer problems and the environment that is being targeted, they can deal with this and thus have hardware/software co-generation capabilities where everyone else still thinks they are not possible.

Simplify the problem until you know how to solve it and then charge a reasonable price for the people you are attempting to target. This seems to be the MathWorks philosophy.

Brian Bailey – keeping you covered

P.S. I also learned that they are no longer The MathWorks. They have dropped “The” from their name.

Now given that everyone else will have already regurgitated their release and the plentiful other pieces of information that Synopsys normally supplies with their releases, I will not bore you with that, except to put a context in place. Synopsys bought several companies recently including CoWare, and Vast and a few years before that Virtio. This is their bringing together of those technologies and using them to create Virtualizer – a product that focuses on analysis and debug, and flow integration. All models developed for those prior products are fully compatible with this product, but going forward the preferred modeling language is SystemC TLM, although any language can be used under the hood for even more performance.

They have indentified two primary user groups for the product – those who create models and platforms and those who use them. Different capabilities are necessary for those two groups. They supply a library of models to go along with the product, plus some reference designs that can help people get a prototype up quicker than starting from scratch.

When a virtual prototype is developed for SW development, most people today attempt to use it in the same way that would use a development board. They attach a debugger to it and start doing functional verification of the SW. But a virtual prototype is capable of doing so much more, and it will take time for the methodologies to change. In addition, the prototype is the place where the HW and SW come together and this provides a whole new set of things that people could do. For example, power is not dictated by either HW or SW individually, but it is affected by the way they interact with each other. The analysis capabilities that Synopsys is providing concentrate on this type of need and allow their existing methodologies (compilers, debuggers etc) to be used for the functional verification.

So why does it take so long for methodologies to make significant change? Mark explained that up until now, the big issue has been about the availability of models, and the ease with which a platform can be put together. Many of those problems have now been mitigated which makes it more likely that more companies will start using prototypes. But there are also secondary issues such as group communications, roles, and responsibilities in the user organizations that slow down adoption, especially for the new types of capabilities we are now beginning to see. Who creates and maintains the models, what models do they need to create and what levels of abstraction are going to be used? Companies are now gaining enough experience to decide on these issues, and to identify what they expect of the platform. Different users have different needs and a way has to be found to integrate those varying needs in an economic manner.

I asked Mark about the role he thinks Synopsys has in defining new flows for the system level. This includes things such as the definition of good verification practices for this level, how hybrid prototyping needs to be setup and used and the impact that this can have on things such as how a model is transformed over time. He said that the customers are basically the ones who need to decide what flows work for them and the tool must support those flows rather than the tool defining the flow. Only when there is significant alignment in the industry does it make sense to bring this into a standardized flow with added forms of automation. I think he is spot on with this, and is part of the learning flow associated with a new abstraction and moving into ground that has never been covered today. We are where RTL methodologies were about 20 years ago and at this point we are all in learning mode. The important thing is to be open, flexible and to listen. I think that is exactly what Synopsys is doing today and they are taking the right approach, but as an industry we have to work on moving forward as quickly as we can. We need a system level verification methodology that includes how stimulus is generated, coverage is defined and all that good stuff, but across multiple levels of abstraction using many different models. We also need to consider things other than functional verification as we have now introduced capabilities for power and performance as well as functionality being distributed amongst hardware and software. Treating them as separate entities is only part of the picture.

Brian Bailey – keeping you covered

In Portland, there was a proposal on the ballot for one of the largest increases in property taxes in history, the money to be used to repair schools. Not to improve education in any way. I know of many teachers who are being laid off at the moment or not having their contract for the next year renewed. I hear so many stories about education in this country being low and going lower compared to other countries. How then do we expect to earn our way out of the debt that we are taking on? Without a return on investment, stimulus is worthless, just like any other investment. Well, in fact it is worse than that, it is gratuitous spending that we cannot find a way to pay for.

So, what would be a good stimulus program for this country? There is one area that I can think of that inspires kids across the country, and would serve to set them on the right direction for their careers. I am talking about robots – designing them, racing them, solving challenges to make them do certain things, and OK for the more violent amongst us, robot destruction derbies or robots that fight. These challenges call for creativity, technical skills, team work – all of the things that I don’t see in many of the activities the kids spend their time on today, such as video games. I believe these kids need inspiration and this would be one way to do that.

About a month ago, National Instruments released a new version of its LabVIEW software, specifically tailored to LEGO Mindstorm and high school classrooms. Along with that, they made available several lessons that are accessible online.

Taken from their press release: “LabVIEW for LEGO MINDSTORMS completes the National Instruments and LEGO Education ‘robotics for all ages’ learning platform,” said Stephan Turnipseed, president of LEGO Education North America. “We now can deliver a framework of age-appropriate, hands-on learning technology and curricula that continuously progress with student skill level and learning objectives, from elementary all the way through university.”

And at ESC, Freescale was demonstrating their robot kit which contains a Tower System Mechatronics Board which is supported by Robot Vision Toolkit and RobotSee (a simple language with the power of C). The board has a 3-axis accelerometer and a 12 channel touch sensor.

FIRST (For Inspiration and Recognition of Science and Technology) was created by Dean Kamen in 1992 and is the world’s leading high-school robotics competition. This includes the original FIRST Robotics Competition (FRC) and the newer FIRST Tech Challenge (FTC) for ages 14–18, the FIRST Lego League (FLL) for ages 9–14, and Junior FIRST Lego League (Jr.FLL) for ages 6–9. By 2010/11 there were 245,000 students participating and the program provided more than $14M in college scholarships. It takes 90,000 volunteers to make the program work. We have about 50 Million kids in schools at the moment and while I am not saying that this is a program for everyone, I am sure it could be expanded to include many more than the 0.5 percent is reaches today.

I want to steal a graphic from the FIRST webpage shown here:

Now that is what I call stimulus in education, and to me this country should be putting a lot more money into programs such as this. How many pot holes get filled for $14M – not many! For NYC they have a budget of $190.4M for paving, but because of a bad winter, they are adding on another $2M just to fill a few more pot holes.

So what do you think would be a good stimulus program? Share your ideas here.

Brian Bailey – keeping you covered

Synopsys has placed significant effort into FPGA-based prototyping with a couple of acquisitions (Hardi, ProDesign) a few years back, plus the software flow to drive it through the acquisition of Synplicity. Then there was a raft of acquisitions that propelled it into the ESL space (CoWare, VAST, Virtio) and since then, Synopsys has been integrating these together along with its IP offerings into a more modern flow.

We have heard from Cadence, with their announcement at ESC and on the one year anniversary of EDA360, exactly how Cadence intends to respond in this area. They have formally announced their introduction of a virtual prototyping solution and an FPGA-prototype. In their case they are using a lot of the technology from their emulation business to drive the FPGA-prototype and their unique pitch is that once the design has been readied for emulation, then it is also ready for prototyping. I spoke to cadence about this a few days ago and Ran Avinun, director of marketing for the System Design and Verification segment. He said that if each technology adds enough value then having solutions that are fractured is fine, but the fracturing today is so large that it has a huge impact and results in technologies not being adopted. This integration between emulation and prototyping goes further than just the software chain in that both solutions will share things such as speed-bridges and analysis software. The FPGA-prototype has been in production since December but in the releases so far there is not much technical detail about the capacity, performance or extensibility of the solution. I am sure more will become known about this over time.

The other piece of the puzzle is the virtual prototype. This is an essential piece of the puzzle as it enables software to be designed, developed, integrated and verified before the hardware design has been completed, or at least stabilized. RTL simulation, emulation and prototyping all attack the problem after the design has been completed, or getting close to it. This part of the Cadence solution is still in the early adopter phase and a full release is expected later this year.

So where is Mentor? Their press release today talked about the integration of simulation with formal technologies and with intelligent testbench technology. Neither of the other two EDA companies have been pursuing intelligent testbenches. Vista is Mentor’s virtual prototyping platform, but unlike the other companies, their prototype is geared towards the hardware architecture rather than being a platform for software. They also have a whole division working on the embedded software part of the flow. I have heard nothing about them working on a prototyping solution, but maybe they have something up their sleeves. Several years ago I was asked who was the furthest along in putting together an ESL solution. My answer at that time was: Mentor has more pieces of the puzzle than anyone else, but the least likely to integrate them into a comprehensive flow. That is looking truer today than ever before or maybe Mentor just sees the future differently.

So, it is clear that all three of the major companies acknowledge that the software portion of the system is not only becoming more important, but that it present a significant revenue opportunity for them. Each has put in place a different strategy as to how to capitalize on it and I am sure this is just the beginning of their efforts into this area.

Brian Bailey – keeping you covered.
http://brianbailey.us/blog

Tom and I talked for well over an hour on the phone, with presentations that had been sent to me in advance and with WebEx for some more detailed technical information. At no point in the discussion did Tom appear to evade any of my questions or have anything to hide. I was also amazed at how well he conveyed the technical concepts. Most CEOs would have clammed up and said nothing in response to some of the questions I asked, but Tom gave me thoughtful answers and we exchanged ideas on things that I think are only suitable for EDA gossip rags. This is not one of them!

What we did talk about was the strategy for the company and how it seemed to have changed over time. Calypto made a big splash at DAC 2005 with their sequential equivalence checking product (SLEC). Their booth was so packed at this show, that some of the nearby vendors were grumbling that people could not get to their booth, or that other people had to walk through their booth because the isles were too congested. Of course it could have been something to do with the stuffed toys they were giving away, but more likely it was one of those rare times when a completely new tool concept was shown for the first time. It seemed to come out of nowhere. Everyone wanted to know what it was. But a product such as SLEC is dependent on a vibrant high-level synthesis (HLS) market, which if you will remember back in 2005 was not really in place. Hmmm – sounds like a product ahead of its time.

But now in 2009 HLS is taking off and sales are ramping quite fast, and with Cadence being the new entrant on the block, it is now seeing quite a product battle raging between them, Mentor and Forte. Of course we should not forget Bluespec as well, but they are in a somewhat different class than the rest – but that is for another posting. All three of these HLS vendors have a close working relationship with Calypto, as they all depend on them to some extent. As Tom put it, equivalence checking is still finding problems with RTL synthesis tools and the bug rates for HLS are a lot higher given the rate at which this technology is advancing.

So with the HLS market catching up with them at last, it seemed strange to me that they were broadening their product line with some RTL optimization tools – particularly in the power optimization space. Tom told me that the early founders of the company had always wanted to do a system level power optimization tool, but that at the time they felt the market for this was even smaller than for SLEC (I can image these were not quite the same talks and messages that they gave to their early investors). He also provided an interesting twist on this that I hadn’t thought of. When Synopsys first came out with a logic equivalence checker, it was met with a high degree of skepticism. Was it the fox guarding the hen house? Weren’t they going to make the same mistakes in their equivalence checker that they made in the synthesis tool? So Calypto wanted to make a name for itself in verification first and then use some of the same technology to build design tools. Tom reminded me that the RTL market is a LOT larger than the HLS market and will be for quite a long time, and thus tools that work at the RTL level are likely to deliver them with more immediate gains, but that sequential equivalence checking remains a core technology on top of which they will continue to develop other products.

With most of the HLS vendors relying on Calypto to provide the sequential equivalence checking, I asked Tom how long he thought it would be before one of them bought his company. At that he chuckled and said I should ask them, but he did not appear to be too uncomfortable about the position he is in. I would imagine Mentor, Cadence and Forte would not feel quite so comfortable if one of them made a move and left the others out in the cold. I am taking bets now as to who will be the first to move.

The next question I had for Tom, was one I was sure he would punt on. I asked whether he saw more opportunities based on C, C++ or SystemC? While he did not say that he favored any one of them, he said that performing equivalence checking on SystemC tended to be easier because it was often closer to the RTL and that finding the right match points was relatively straight forward. With the tools based on C or C++ (or for that matter an early C description that is refined into SystemC), there were additional opportunities for doing C to C equivalence checking, when for example floating point to fixed point transformation are made, or other architectural changes are made. It is important at that stage to ensure that the functionality has not been compromised.

That seemed to me to be a huge challenge, so I asked Tom how much manual intervention was necessary in order to compare at this level of abstraction. He said that their goal is for it to be completely automatic, but with large designs or complex interconnect at the architectural level some manual intervention may be required. There is some information that is passed from the HLS tool to SLEC that helps it find the right match points, but even when these are provided, the first thing they have to do is to verify that this is indeed true, otherwise all of the rest of their analysis may be based on false information. When the HLS tool vendors implement new optimization strategies, they do not always provide this help in the first release, and then more manual work is required, but as the optimization matures, then these hints are provided. I was surprised to hear that Calypto has almost weekly calls with each of the HSL vendors to ensure that the tools are kept in sync as much as possible.

At this point in the conversation, we switched over to more technical discussions about the tools themselves, and I will be reporting on that at another time.

So thanks Tom and Diane. These are the kind of calls that provide me with the information I need to do my job.

——————————————————————————————————————

Brian Bailey – keeping you covered.

brian_bailey at acm.org

]]> http://www.chipdesignmag.com/bailey/2009/08/11/interview-with-tom-sandoval-ceo-of-calypto/feed/ 0 http://www.chipdesignmag.com/bailey/2009/07/13/innovations-in-formal-verification/ http://www.chipdesignmag.com/bailey/2009/07/13/innovations-in-formal-verification/#comments Mon, 13 Jul 2009 17:45:30 +0000 Brian Bailey http://www.chipdesignmag.com/bailey/?p=40 Last week, I received another press release from Jasper Design Automation that talked about advances they have made in a number of areas, including performance (a 2X increase in speed/memory footprint), packaging (common backend for several front ends) and technical (introduction of quiet trace and more parallel operations). This is not the first major product announcement that they have had in the last year. Towards the end of the year, there was the announcement of ActiveDesign – a product that really excites me. For full disclosure, I am on the technical advisory board of Jasper.

This got me to thinking about the other companies that have formal tools. Mentor and Cadence have been active in this area in the past, as has Synopsys. Real Intent seems to have gained some stability in CDC, a product category also being fought by many of the other formal companies. But I do not remember seeing any announcements from any of these about significant advances for quite some time. I went back and checked – nothing that I could find on the Mentor site for the past year, nothing substantial for Real Intent, nothing for Cadence. Calypto is still a relatively new entrant, but attacking a different market (sequential equivalence checking), for which they still have the market to themselves.

At the same time, Bill Murray in a recent article on SCDsource showed that usage of formal technologies had doubled over the past 3 years, which means that there is a real need and growing adoption of these tools. Jasper CEO Kathryn Kranen talks about 100% bookings growth for Jasper in 2008 compared to 2007 on Deepchip. So are the other companies just not talking about their technical advancements, or are they just trying to get what they have working properly? Are they giving up and leaving the market to the only one who appears to be innovating? Is Jasper becoming the formal gorilla?

Brian: First of all can you introduce yourself?

Chris: Sure, I have been with Achilles Test Systems as one of the founders, since 2006. I come from an ASIC and FPGA background, mainly in the areas of computer networking and graphics. I have been lucky enough to work with some of the best engineers imaginable at Cisco Systems, C-port, Meta Systems, Mitsibishi, UB Networks and Sun Labs. Prior to Achilles, I had only worked on the technical side of product development. Needless to say, playing a founding role in a company has taught me a thing or two.

Brian: Briefly, tell me a little bit about Achilles Test.

Chris: Achilles Test Systems’ products and services fill a simple and virtually unmet need of FPGA and ASIC teams. Our goal is to bring all of a team’s design and verification results together in one place for easy browsing and debug, real-time status, and historical trend analysis in a web browser. Modern teams are executing synthesis, static analysis, and verification jobs on 100’s or 1000’s of CPUs every day. Small teams are expected not only to digest the information that is created by all of this computation, but also to have a reasonable idea of how these things are changing over the life of the project. Achilles offers a set of tools that make it easy for engineers to harvest that information and tie it together on their desktop. This makes it easy to create single-page summaries of both real-time and historical result tracking for users to tag, monitor, and act on. We are getting great feedback from customers about the way it has changed their day-to-day work.

Brian: What made you decide that this year was to be your DAC debut year?

Chris: I personally think that this year should be very exciting at DAC, and I wouldn’t have wanted to miss it. No-one denies that the past twelve months have been hard on the industry. As a result, exhibitors and attendees alike have had to question the ROI of coming to DAC or any conference. I think that we can assume that the people who are coming this year have a compelling reason to do so. I am expecting both attendees and exhibitors to be talking about very clearly defined problems and solutions.

As a company, the main reason why we decided to attend this year has to do with the timing of our solutions to market needs. DAC is obviously an enormous opportunity for a small company to get a year’s worth of customer feedback in 3-4 days. From what we can tell, this is the year when engineers are realizing that all of the automation and parallelism that has been built into EDA tools is starting to take a toll on teams. The more automated things get, the more visibility and transparency the team needs in order to keep up with their own work flows. This year especially, teams are smaller and the costs of failure are higher, so we think that this is the year when our value proposition is easiest to demonstrate.

Brian: What do you hope to gain from being at DAC?

Chris: Our first EDA conference was DVCon in Feb 2009, and we got a lot out of it. We are expecting even more out of DAC since it is a bigger conference and will have a more diverse attendee base. Our focus is on bringing tool and simulation result information from the whole team together in one place, so the chance to talk to engineers and managers about a wider variety of results management issues should be exciting. We know how our customers deploy DV Notebook in the verification space. We are using DAC as a chance to meet people who are looking for the same types of productivity gains in architectural simulations, front-end synthesis, back-end synthesis, static code analysis, and embedded software development.

We will be organizing a birds of a feather session on project health which will allow a little more structured sharing and conversation. We will also be presenting a paper that we submitted as part of the DAC user track. We had a sell out crowd at a recent DVClub talk and we are hoping that these ideas will generate just as much excitement at DAC. The goal is to meet as many people as possible and get as much feedback as we can, and so we plan to take advantage of the lounges, hotel bars, breakfast, lunches, and dinners.

We learned a lot at DVCon by being able to talk dozens of working engineers and managers in three days. At a conference we can quickly learn about our customers’ needs and market competition. We have some tips and tricks to share about building dashboards for organizing and analyzing the results of your product development, and we are looking to collaborate, whether with prospects, partners, or other like minded individuals. We want to maximize the chance to learn, to get better at what we do, and to grow.

Brian: How easy have you found the whole process?

Chris: We are not a Cadence, Synopsys, or Mentor, and our tools are not a drop-in replacements for any standard tool. Like many of the startups at DAC, we are addressing a new part of the problem that not all customers have identified or sought to solve. A startup does not have enough influence or drawing power on its own to make a show work. However by banding together at DAC, we offer a one-stop marketplace for discovery, contribution, and sharing. In EDA, much of the innovation has been driven by the startups, maybe even more than by the big players. DAC attendees know this. They are not coming to such a large show to hit up the three big booths and call it a day. They are there to see the new stuff. In spite of this, since DAC is a really BIG show, our challenge will be getting noticed without the same marketing budget as some other firms.

What I would say to people is, if you want to see the latest tools from Synopsys, Mentor, or Cadence, they will gladly come into your place of business and demonstrate them for you. DAC is your only chance to see some of these startups side-by-side. Take advantage of it.

Brian: Any surprises along the way?

Chris: Most of my surprises have come from the change in role, from engineer to vendor. As an engineer and a technical contributor, if you have a new idea or a new methodology, other teams and groups are generally receptive. If your ideas make sense and if there is a nice improvement in performance, cost, or productivity, things get started with almost no evaluation or overhead. When you come into these same teams as a vendor, the rules are completely different. As a vendor in meeting with prospective customers, I have had to pay a lot more attention to what their exact situation is and how we can demonstrate, in their context, that our technology is going to help them. We do a lot of benchmarks and evaluations to prove what we can do.

Even the way that we introduce the problem and tell our story has needed to change. As an engineer, I feel compelled to start with the details and work up to conclusions. As a vendor, we tend to do more of a progressive disclosure, to see if there is a fit before diving into all of the details. It’s not that customers don’t want the details, but not everyone will be a customer.

Brian: What do you feel about the lack of a “Free Monday”?

Chris: It is our first year, so we don’t have anything to compare it with. We don’t really have an informed opinion either way. If I weren’t attending as an exhibitor or presenter, I would certainly be willing to pay to see what the latest batch of startups are up to.

Brian: Some people say that Free Monday attracted nothing but trinket gatherers. Will you be giving out any trinkets?

Chris: No, we don’t have any trinkets, but we promise great conversations. I would welcome anyone who has a results-management problem to come by booth #912.  We will be happy to meet you and brainstorm. The other 60+ startups at DAC will make it worth your $50 and more importantly your time. There is some cool activity that is going on that you should keep on your radar.

Brian: Thanks Chris. The question about Free Monday has now become mute, since EDAC today decided to sponsor this tradition. For more information and the sign-up link see the DAC free day blog discussion.

———————————————————————————–

Brian Bailey

email me at brian_bailey at acm.org