A couple of weeks ago, Oski Technology issued a press release saying that their 72 hour challenge at DAC was a success. I wanted to get more information about it so I spoke to Vigyan Singhal President and CEO for Oski Technology.
Where did the idea come from?
One of the biggest problems with formal is that it is an unknown and so few people have seen success with formal. This is always a challenge when we talk to new people. There are always questions such as how much time does it take to set up, what can you do with a new design and how does it compare to simulation? As we were bouncing ideas around about how to work with customers we thought we could take advantage of DAC and do it on a design there. The idea got refined further but basically we wanted to show how a formal testbench gets created and show it from scratch and show the good and the bad. Now 72 hours is not enough time to verify any design completely. Initially we thought about asking people to bring a design on a USB stick but we got it at the start of the show in an encrypted file and went from there.
You must have been pretty confident of success
We were very confident that something would come out of it but we did not know what success meant. We had a fair degree of worry that it would blow up in our face and on the second day we really thought it was not going to work. It was not just the time pressure and a new design but we were doing it live and talking about it live in front of people and a camera.
We had planned to work on it as much as it took and even after the floor closed we said we might continue working on it. People could log in and see us working on it. One guy logged in at midnight and found them still working on it.
By Tuesday things were working better and Chirag Agarwal, the guy working on it even went to the DAC party.
So you did get some results. How did it compare to your expectations?
It was better in the end. On Monday I would have said we are not going to do this again. What was important was deciding up front what we were going to do and not do. When we looked at the design and went through the spec, we decided that it was too big a design to work on everything in 72 hours so we will exclude write transactions and just concentrate on the reads. We would allow the writes to happen, but not verify them.
By the end of Tuesday we had verified everything we wanted to on the read path so we came out ahead of schedule. It was nice to find bugs in the design but that was not the goal. At that stage we were ready to call it a success. Then on Wednesday we did something different because we had extra time. We built an X-propagation app. We wanted to show the design would not produce an X under any corner case. We found three failures buy only had time to debug two of them. Nvidia confirmed that they were real bugs.
Would you do it again?
Possibly but we would want to do something different otherwise it would not be as unique. But there was so much heartache associated with. Since DAC, more people have come to us and asked if we can do something on their design. So we may start offering this as a service. Then they can actually give us more information than we had at DAC.
It appears as if education is still a big barrier to adoption. How do we go about putting education programs in place?
We think about it all the time. The more people trained in formal means the more business possibilities out there. The techniques we use are not rocket science. Any smart engineer could figure it out. Most people that we hire do not have a formal background or experience. We manage to train them. It would be nice if universities included it, such as a lab course. The tools out there are good, but that is not enough. You have to have a methodology around them. You need to be able to plan and predict how much you can do.
We have an apprenticeship model that works out well for our customers. We ask them to give us a couple of their engineers and a design and we will verify a portion of that design. They will plan, see what works for formal and all of the code developed is free for them to take with them and use. It is early stages for this, and they don’t necessarily become experts but they know how to approach the problem and go into places that are likely to yield results. Someone can become an expert in a year.
Back to challenge. Tell me about the selection process.
We wanted to make sure we had a design. We announced the challenge at DVCon but we had no idea what the response would be. We said that the design could be at any stage. We wanted to make it as easy as possible because so many companies would not want stuff done on camera etc. We got five companies that came back to us and we discussed it with them. The design selected was at a critical stage and was about to tape-out within weeks of DAC. When we showed Nvidia the results there was some degree of flurry in the company to apply the results.
Was this the best place in the flow to apply formal?
A lot of people say that the earlier you can apply formal the better, but we have had success with designs at all stages. Yes, it is different kinds of success. We have had some customers who have silicon and they are trying to find out if a fix is complete. We have had customers who have paid us to find bugs in their design. If they decide not to fix the bugs that are found they don’t have to pay us. That makes it a win-win for both of us (assuming we find a bug). But this is late and you would have preferred to find the bug earlier on.
Formal is a lot more successful than it was even 10 years ago. Companies today are making formal part of their sign-off process. People are beginning to realize that formal can complement simulation and it can be a competitive advantage for companies to adopt formal.
They have also produced a video of the challenge that you see here.
If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you).
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.