The ESL Edge

DAC is still a big deal for our industry. It brings together researchers, EDA vendors and users to share information and ideas. I recently had the pleasure of talking to Chris Kappler, a founder of a small startup that will be at DAC for the first time this year.

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

Limor Fix writes:

I am very proud of DAC’s program this year. As usual, the program is so rich that it is impossible to cover all of it in only a few words. Thus, I have chosen to tell you about one of the many “diamonds” in the DAC technical program.

Session 28, “Jumping the High-Level Verification Hurdle,” is a must-attend session for every design and verification engineer to be held Wednesday, July 29, from 2-4pm.

Chaired by Somdipta Basu Roy of Texas Instruments, exciting new technologies and methodologies will be described, including how untimed behavioral models can be used to model and verify a high-level model of an ESL design. Attendees will learn how SystemVerilog is used for modeling and simulation-based verification of the high-level model and moreover, how the same model is used as a formal specification for the RTL implementations.  Additionally, presenters will highlight how advances in sequential equivalence verification allow for formal verification among models with different abstraction levels, that is, equivalence verification between the high-level model and the RTL.

Overall, important progress and great achievements are reported in the challenging area of system-level design and verification and I’m looking forward to hearing all of the details.

This isn’t the only session dedicated to the all-important category of verification and test. In fact, there are 18 sessions devoted to this topic, from one User Track session and four tutorials and special sessions to four technical sessions on verification and test.

An additional eight sessions are found on the DAC website and will be held at the IC Design Central Partner Pavilion or as part of the Exhibitor Forum or are additional meetings hosted by exhibitors.

For those of you seeking a more practical look at today’s verification challenges and solutions, check out the one final verification session, a pavilion panel called, “Seeking the Holy Grail of Verification Coverage Closure.” Chaired by Brian Bailey, author of this blog –– Verification Vertigo –– and noted verification consultant, it promises a look at the range of technologies available to meet this goal. Speakers include Jim Sullivan of Qualcomm, Jon Michelson from Cisco, David Bural of Texas Instruments and JL Gray of Verilab and author of the Cool Verification blog. Brian’s panel will coincide with the technical session on high-level verification –– Wednesday starting at 2 p.m.

DAC will host more than 200 vendors in this year’s exhibit hall, from industry leaders Cadence, Magma, Mentor and Synopsys to Atrentra, CoWare, EVE, Jasper, GateRocket, Nusym and Real Intent. The January 15 issue of DACeZine’s directory of verification tools has a more complete listing of verification vendors. For details, visit: www.dac.com/newsletter/shownewsletter.aspx?newsid=69

I encourage you to attend DAC and participate in the all-important industry discussions affecting all of us. See you in San Francisco!

Limor Fix works at Intel Labs in Pittsburg and is the Past Chair for the 46th DAC.

Thanks Limor, and thanks for the plug for my panel. It is too bad that verification events have to overlap each other, as well as the all day Virtual Platform Workshop on Wednesday that I will be participating in. However, it is good to see that at long last, verification is beginning to command the presence that it deserves at DAC.

The loss of Air France flight 447 is a tragedy principally in terms of human life, but also in the possible knock-on effect that it could have in the high-tech industry. Many years ago, I was a designer of flight control computers for Airbus and I remember at that time how uncomfortable I felt about fly-by-wire in civilian aircraft. We designed and built the systems, without simulators, without anything that would be considered a modern tool by today’s standards. Design was at the gate / board level. Verification was based on a few tests on a prototype and then relying on the test pilots to unearth the remaining problems. One of the early complaints that the test pilots had was that they had no feedback. They could not feel what the plane was doing, what forces were acting on it.

Where there was a lot of redundancy in the system, and special steps were taken to try and remove any single point of failure, it always seemed to me that there was a glaring problem with that. Someone, somewhere was deciding what was normal and what was abnormal. While everything was normal, the plane would operate normally. When abnormal conditions appeared, the computers had to decide if they believed the instruments, the other computers they were connected to, or the pilots. We were told when to “not believe the pilot”. Protocols were established whereby the pilot could say “just do it”, even if the computers knew it would lead to something bad happening. In the old, mechanical, analog systems few such discrete points existed, even if sometimes the ability to bring a plane back under control was limited by the strength of the pilot.

How could one person, or a group of people decide what was abnormal? It is like trying to find all of the corner cases in a complex verification problem, except that there is nothing to enclose the list of possibilities. Anything can happen, and you have to decide how to react – who to believe.

Fly-by-wire is attractive to airlines because it directly equates to lower weight and that in turn means lower fuel costs. Under normal conditions, it can also mean a smoother flight as the computers are better at making automated fine adjustments. While I also love that this means lower fares, is it a good tradeoff? I also accept that flying is the safest form of transportation and I will never stop doing it, but when as engineers do we feel uncomfortable with the product that we build? When do we stand up and say that we are not comfortable with the amount or completeness of the verification we perform – especially when an error can result in the loss of life. How can engineers handle the cost tradeoffs under these conditions, or feel good when a tragedy like this happens, especially if you know that it may have been avoided if you or someone else had made a different decision?

In most professions, people are held accountable for the decisions that they make and can be sued for making wrong ones. I hope that this does not happen as it would lead to highly escalating costs and it would scare away many people from the industry. Would you continue to design and verify the things you do if you could be held liable?

At DAC this year, they are not offering a free day into the exhibition. I can’t help but think that this is a bad decision, especially given that it is being held in the Bay Area. Many conferences are showing large declines in attendance, and this is one feature that has drawn a lot of locals in the past. This takes away the ability for people to network without having to draw on the company expenses.

So far I have heard from several people who have said that because of this decision, they will not be attending DAC this year.  What do you think? Are the poeple who just attend the free day people not worth having there? Is this a sign of the decline in the exhibition? Will DAC become just a conference without the exhibits?

Imperas has been providing a free ESL simulator and models called Open Virtual Platforms (OVP) since their OVPWorld site went live a year or so ago. Recently, they did a survey of their users to find out the demand for a Linux version and also to gauge if the market would be willing to pay for some of the capabilities. Imperas is already selling some add on tools, such as a multi-core debugger and productivity tools. While they remain committed to making the models open-source, it has never been clear what their long term strategy would be for the simulator. I recently discovered some of the results of their survey and it appears as if they may soon start charging for the simulator.

My sources were not able to tell me if the existing simulator version would remain free, or if it would be new improved versions that they would start charging for, but if you have any interest in this simulator, now would be a good time to get the free version before it is possibly withdrawn. Their timetable for this is unknown, so act quickly if you are interested.

The countdown to DAC has started. The program is now posted on the DAC website, and the companies who will be there, or not be there is known (there will always be some last minute changes). Last year I posted a blog entry about the new companies that will be at DAC, especially focusing on the ones related to verification and ESL – the two areas that I mostly focus on.

This year there is not a lot to write about. Whereas there were 41 new exhibitors last year, this years total is 19. Out of those 19, 6 of them are essentially services companies, although some of the other companies also offer services as well as products. 5 companies are involved with Analog/ Mixed Signal and 3 dealing with data or flow management. The OVM community will have a booth – which is the only pure play on verification, and there is no new ESL company to talk about.

I will provide an analysis of the papers and session related to these two areas later on.

In one of my Internet searches, I locate all news stories related to ESL (minus the English as a Second Language references). Today I saw a press release from Fujitsu that looked interesting  “Fujitsu Develops Chip-Simulation Environment for Mobile Phones”. Great I thought – an endorsement for ESL simulation, perhaps talks about SystemC or transaction modeling. That may be a good reference to keep.

So I start to read the article. It correctly identifies the problems – how do you make it both fast and accurate which leads to a second problem how do you know what accurate means when you have not yet designed and implemented it. I think my pulse even raced a little with anticipation about how they had resolved this. But then realization struck that this was not a real article – it was a piece of marketing fluff that was designed to try and impress the world about how great their methodology was and they had no intention to tell anyone about what they had done at all. Not a single piece of hard data – except for the claim that they can simulate 1 second of real time in dozens of minutes rather than several days for the old models.

The closest it comes to saying anything about what they did is contained in one cryptic sentence “By editing a program region that describes the operating patterns of the component, the user can control how that component will behave when embedded in the model.” So basically editing a model changes the behavior of the model – wow. The only other clue comes from the following sentence “system performance will be affected by factors such as the following: processing units that divide the data, the interval at which they are transmitted, and where they are inserted into the system bus.” So perhaps that tells us that this is transaction level simulation, but that is hardly new or press release worthy.

I think Fujitsu just wasted 20 minutes of my life. Not perhaps the reaction they wanted from a press release, but it has certainly changed my opinion of them.

We hear a lot about unintended consequences in the economy these days. When the government or some other organization meddles with something, things happen that they had not thought about or intended. Today I saw that Richard Goering is now the senior manager for technical communications at Cadence. Looking back at SCDsource, it has been over a week since anything new appeared on that site. It would appear as if another publication that attempted to provide vendor neutral reporting on the EDA industry has gone by the wayside. EDA designline has also gone – or at least brought back ‘in house’ and who knows if it will see much further activity.

So is the EDA industry so different from every other industry that it cannot support even a small independent trade press? Is it that the EDA industry does not want to advertise and support them? Perhaps this is the unintended consequence of the industry pushing for the lowest price deal that they can get on EDA tools. Advertising is just not worth it, especially when the number of customers they are serving is somewhat constant or even declining. The unintended consequence is that those very buyers will no longer be able to get unbiased information about the industry, and it will actually cost them more by having to talk to all of the suppliers out there to find out what they have, and then do the evaluations themselves to find out if the information they are being provided is indeed completely true and unbiased.

Perhaps on a personal level, it will help all of the independent EDA consultants, like myself, who will now be the only source of impartial information about what the EDA companies are up to, and if the claims they make are true. But even consultants rely on the trade press to bring things to our attention. It could also mean a lot more work now for us to keep up with the tool introductions and developments.

What a charming little book! If that sounds in any ways demeaning, then that is not at all what is meant. A few weeks ago, Ray Salemi, an applications engineering consultant from Mentor Graphics, sent me a pre-publication copy of his new book entitled “FPGA Simulation. A complete Step-by-Step Guide.” Most books set out to cover new ground, to promote the latest tool, language or methodology, to bring the latest thinking on an emerging area – not this book. In fact nothing in this book is new or perhaps even exciting to most people in the industry. It talks about the mundane, the technologies that advanced users have been using for quite some time. So why do I like this book? Because it attempts to convert the laggards, to show them that there is a better way. The people we are referring to are the FPGA developers who have reasoned – why do I need to use a simulator? This design is going into an FPGA, why not just put it there and let it rip!! While that may have worked for some people in the past, it is quickly becoming a way to ensure that the product never gets out of the door.

Rather than just tell these people: you got it all wrong and here is a modern verification methodology that you should be using, the book guides them in small, manageable steps to a better, brighter future. Each chapter gently guides them up the progress ladder in steps that add value and slowly build upon the previous steps. While there may be a little bit of waste along the way given the end-point that is reached, there is little waste at each stage of the progression, and each stage adds new value and capabilities.

This book would also be good for someone who is just starting out in verification. It provides an overview of many subjects without going too deep into any of them, but deep enough, and with enough examples that they can get a practical grounding. I think Ray will have a lot of success with this book. He has also set up a companion website http://www.fpgasimulation.com where he continues to provide additional insights and worked examples to common issues.

I do have a couple of gripes with the book. The first is not their fault at all, but the fault of our industry. Because of the number of languages that we have (Verilog, VHDL, SystemVerilog, PSL) it takes almost 90 pages to describe how to use OVL and that may be enough to turn off many people at step three of seven along the adoption path as defined. Why can’t we make things easy for the users even if it means that the implementation is a little harder and takes a little longer? At the very least – hide our mistakes from the potential user community. The second gripe is the price. While the asking price of $97.95 is not out of line with many of the books within the EDA field, this is a high price for FPGA developers and may significantly limit their sales – especially in the downturn that the industry is currently facing.

But leaving those issues behind, this book is a valuable new book that fills a niche that has not been addressed to date. I do not hesitate to give this book the thumbs up! Two thumbs up!!

In a recent Synopsys press release they talked about the advances that they were making in their Confirma™ and CHIPit® product lines. Clive Maxfield did an excellent write-up of this in Programmable Logic DesignLine which I will not repeat here. Along with the press release, Synopsys also sent out a number of frequently asked questions related to this technology. Scanning that I saw something that really peaked my interest.

They were discussing the potential for product overlap between Confirma and Innovator. Confirma is the FPGA rapid prototyping environment that came from Synplicity and Innovator is their system level virtual prototype based on the Virtio technology. They said:

“Going forward, customers may not have to choose between the two approaches. Hybrid prototyping is an emerging approach that combines virtual platforms and rapid prototypes into a single unified system representation. This approach enables legacy blocks of RTL to be included in virtual platforms without impacting performance, and transaction level models to be included in rapid prototypes for higher performance or improved debug features.”

I believe that this is potentially huge. It would allow for a single unified prototyping environment to exist all the way from design conception to deployment in the field with the ability to arbitrarily replace any design block with models at different levels of abstract, with an FPGA mapped version or with real hardware.

I questioned their marketing department about these statements and received this response from Frank Schirrmeister, the director of marketing for the Innovator product line:

“We have demonstrated interfaces to hardware based solutions for a while with Eve and Palladium. We now have the three necessary technology components in house and are preparing for demonstrations with various customers. Here are the three technology components to enable hybrid solutions: Starting on the hardware side, physical interfaces must be provided to connect the actual hardware prototype to the workstation running the simulation. PCI Express is a common solution here. Second, data must be transported using an agreed upon protocol between the software and hardware worlds. SCE-MI has become a standard in this domain. Finally, for conversion from the transaction-level model to the transport interface, transactors are necessary to translate high-level protocols like AXI, OCP and AMBA.”

Frank also wrote about this in his Blog entry. I am very much looking forward to the day when this is released, but for now we just have to relax in the comfort of knowing that Synopsys is actively working on it. Of course there is no harm in asking “is it ready yet?”