Archive for March, 2011
Monday, March 21st, 2011
As EDA is a global business, even for smaller companies, most of us periodically find ourselves on a plane to visit customers and partners in different countries in order to build a global presence and business. Japan is a key destination which many of us in EDA are quite familiar with, and as the Vice President of Worldwide Sales, you can imagine that I am on that plane frequently. I had planned a trip to Japan, and as luck would have it, my trip was moved up a week to accommodate a customer. I scrambled to make arrangements to visit one of my favorite places in the world in my usual manner.
My flight from SFO to Narita was familiar, typical and uneventful in every respect. Once in Japan, my itinerary was typical and as usual everything came off like clockwork. I made visits to customers, talked with vendors, had conversations with my GM, meals with colleagues, rides on the trains, and strolls along the bay in Yokohama; nothing unusual to report.
While waiting at the gate in Narita airport to board my flight home, suddenly we all found ourselves in a situation that was not part of our original itinerary, as Mother Nature hit us with a 9.0 earthquake. Nothing about this situation was business as usual. As a Californian, I’ve experienced earthquakes before, but nothing on this scale. The magnitude of the shaking and the duration of the quake astonished me, but what was even more amazing is that the airport terminal survived.
As air, rail and freeway travel were suspended and we did not know how long we would be living in the airport, what I then witnessed was much compassion, caring and sharing. Strangers helping strangers – people who in most situations would not have even noticed others were now helping to make sure that all survived this ordeal. We scavenged food, water and blankets and shared with all who were in need. With limited information, we didn’t know the scale of the disaster, and it turns out that Narita Airport was probably one of the safer places to be…but we did not know this at the time, let alone the devastation being wreaked by the tsunami or the pending nuclear reactor crisis.
While I don’t mean to sensationalize, a typical trip was turned very quickly into an adventure of survival. While I was lucky to be able to fly away after a couple of days, the people of Japan are left with destruction and an ongoing nuclear crisis. As I feel compelled to help, I am taking a break from talking about verification in this week’s blog to make a plea to my friends and allies in this industry, which has a global presence and a compassionate heart; and to tell you how you can help our friends in Japan.
Japanese NGOs have the staff and materials needed to help survivors in Northern Japan, but they need financial assistance for logistics. The best way to help is to donate to organizations that have links to Japan so that donations are quickly wired to where they are needed. One such organization is the American Red Cross.
To help, please make a contribution to the Red Cross, by visiting http://www.redcross.org/. Or, you can simply text the word “REDCROSS” to 90999 from any US cell phone. Each time you do this, you will automatically donate $10.00 (of which 91 percent will go directly to the relief effort in Japan).
Tuesday, March 15th, 2011
Anyone who was around the ASIC & EDA industries 20 years ago will remember that Sign-off Verification used to consist of one step: Sign-off Simulation. There were a number of choices of simulators from the big three “DMV” of that day – Daisy, Mentor and Valid – plus one called Verilog-XL from a little startup called Gateway. ASIC Vendors developed design kits and qualified the simulation libraries for these tools in order to sign-off on the expected function and timing of their designs.
Sign-off simulation in that day was a single process, run with full timing, thereby verifying function and timing simultaneously. As this was computationally expensive, it could not scale as designs grew larger with each process node.
The 90s: Function versus Timing
With full-timing sign-off simulation running out of steam, the industry looked for faster simulation methods that used unit timing or cycle-based simulation. In addition, full-timing simulation did not check every timing condition in the design, leading to the possibility of timing errors slipping through the sign-off process.
Fortunately, synthesized blocks were already using static timing verification, since it was built into Design Compiler, so a path existed to expand timing verification to full-chip with the introduction of PrimeTime. With full-chip sign-off timing verification now available, function and timing could be handled separately. However, a very important requirement to enable this abstraction was that designs had to be fully synchronous.
The 2000s: Intent versus Implementation
With timing abstracted away, sign-off simulation was able to use faster methods that didn’t look at propagation delays and focused only on cycle-accurate functionality. This was fine for RTL but started to break down at the gate level. Fortunately, the synchronous nature of these designs enabled another abstraction – formally verifying that a gate-level design is functionally equivalent to the original RTL source, thus creating the market for formal equivalence checking.
This separated verification of the design intent – primarily performed dynamically – from verification of implementation correctness for both function and timing – primarily performed statically using equivalence checking and timing analysis. Thus, the split between dynamic and static verification fell along the lines between intent and implementation.
Today: SoC Design and Asynchronous Verification
Today, Systems-on-Chip design involves the integration of fully asynchronously connected computation islands, many of which are imported IP with disparate clocking requirements. In addition, power requirements often necessitate that different parts of a chip be clocked at different and/or dynamically scalable rates. Thus, the requirement enabling separation of function and timing is no longer valid at the asynchronous interfaces between blocks. New failure modes arise from corner-case confluences of timing and functionality that cannot be found in either simulation or timing verification, thus breaking the current sign-off flow. A large SoC may have hundreds of clock domains, and communication between them must be synchronized to avoid data loss or corruption. An “Advanced Sign-off” flow for today’s SoCs and future billion-gate chips must be developed that includes full-chip CDC analysis to sign-off on all asynchronous interfaces between computation islands, on-chip interconnect and external interfaces.
SoC Design Complexity and RTL Verification
Large SoCs are also fueling the demand for improved code quality before verification. With SoC design being increasingly driven by consumer product life cycles, we cannot expect that the development timeline to grow with design size. In order to keep simulation from spiraling out of control, higher quality RTL must be checked in for verification, and imported IP must be checked for code quality. RTL code must also be analyzed for efficient implementation in both silicon and emulation. Implementation constraints must also be analyzed for consistency with chip-level requirements. What is needed is a comprehensive RTL sign-off process that uses automatic checks to enable detection of dead code, FSM deadlocks, hazardous coding styles and analysis of X-Propagation risks before simulation begins, as well as dynamic checks to flag issues as they occur during simulation and emulation.
Thus, the sign-off flow must adapt again. Only with a comprehensive approach can an “Advanced Sign-off” flow scale to deliver defect-free SoCs over the coming decade.
Monday, March 7th, 2011
There are many trade shows & conferences for an EDA company to consider each year, and the decision may not be easy for small companies, as it involves tradeoffs on where the company should spend its resources. However, of all the options, DVCon has consistently proven to be of great value for Real Intent.
Larger trade shows like DAC offer an opportunity to reach more people, but with many different types of engineers in attendance, looking for everything from ESL to full custom design, the small guys can get lost in the shuffle. It can also be hard to get the approval to drive a panel, or hold a technical session. Therefore, small companies must work harder to get noticed among so many vendors, and most importantly, to reach the right audience for their products.
That’s why the smaller and more focused shows, like DVCon, offer a special opportunity for companies like Real Intent. We know that Design and Verification Engineers will be attending this show. We know that they are coming for the technical presentations. We know that the exhibit floor is a place they come to take a break from the brain dump they are getting upstairs. And we know that they will do a walk-through, stop by to hear about our products, and have a glass of wine and enjoy the appetizers that are being distributed by the smiling servers. One of the attendees mentioned to me that this was his favorite part of the show because it felt like old home week…we are all colleagues in this space, and you can feel the closeness in the room while we discuss the changing verification landscape. This has value!
This is exactly what we experience every year at DVCon. And, with an improved economy, this year at DVCon the attendance seemed to be very robust, with a lot of people coming from faraway places such as East Coast, Canada, Korea, and India. Through conversations, we learned that many people were faithful readers of this blog; they followed our news releases and press coverage and came to talk to us specifically to find out more. That is the value of having such a focused event like DVCon.
Another thing we greatly value at DVCon is the opportunity to learn from the Design and Verifiation Engineers that attend. To that end, we conducted a survey to learn what concerns and attitudes they have about various verification topics. And, we selected one lucky survey respondent to win a special prize (more on that later)! Among the questions on the survey, several yielded some interesting statistics that I will share with you.
One interesting question asked whether respondents had ever had a bug slip through to silicon due to a CDC problem. The majority – 60% – replied “Yes”. With the number of clock domains in SoCs going up, this number will probably increase unless designers adopt a comprehensive CDC verification solution and make it a sign-off criterion.
Speaking of that, we also asked respondents whether they consider CDC Verification a sign-off criterion today. Two-thirds replied “Yes”, indicating just how serious they consider CDC as an emerging verification issue. Clearly, simulation and timing verification alone can no longer pass as the only technologies required for verification sign-off.
Finally, we took the opportunity to ask about an emerging issue: bugs that slip through to silicon due to differing interpretation of X-Propagation by simulation and synthesis. This is an issue that has always been there, but with the rapid growth in SoC size and complexity, it is becoming a first-order concern for Design and Verification Engineers. When we asked about this, 40% of respondents told us that they are “Very Concerned” about X-Propagation bugs, while 45% said they were “Moderately Concerned”. Only 15% were not concerned. This is obviously an area in need of a verification solution and will get much more attention going forward.
With such informed attendees and the resulting interesting discussion, it is pretty obvious why we love DVCon: it offers opportunities to not only meet qualified users, and build relationships with people in the industry, but also to have in-depth and intimate conversation with real people having real design & verification challenges and seeking real solutions, and to learn from them!
So – A big thanks to everyone who visited us at DVCon and participated in our survey. Of course, I shouldn’t forget to mention our lucky winner for the drawing of an Amazon Kindle:
Program Manager, Chipset Enablement
Industry Standard Servers
Congratulations Krishnan! We look forward to seeing you all next year at DVCon 2012!
Wednesday, March 2nd, 2011
It is quite interesting to see how very difficult-to-find bugs in a synthesized netlist are often the result of simple errors in RTL code. There are many technologies available to help an RTL designer find coding mistakes, including formal checks and comparatively simple lint checking of the RTL code. Linting technology has been around a long time, but it is often not used as part of the design flow, and when it is used on an entire chip, the sheer quantity of rule violations reported make any sensible analysis for real problems difficult. Why? Because most of the older lint checkers tend to produce very noisy reports where the vast majority of reported violations are of no real concern, yet buried inside several thousand violations are a few that will cause design problems. Older lint checkers also do not have the speed to do checks in real time, while the code is fresh in the designer’s mind and design productivity can be greatly increased on the fly.
One could always argue that any RTL that is non-synthesizable would be reported by the synthesis tool, so why bother to check for it? The answer is that it is the synthesizable – but incorrect – code that is of greater concern. Examples of such incorrect code include: assignments where the widths of the operands do not match, case statements with partially enumerated tags and no default tag, arithmetic operations where the bitlengths of an arithmetic operator are not the same. Novice designers and experienced designers alike often make mistakes. The ability to detect those mistakes is crucial. Here is an example reported by Ascent Lint:
BA_NBA_REG: filename.v:100 Both blocking and non-blocking assignments to ‘VPipeLine’, other at filename.v:82
Example code at line 100:
VPipeLine = VDataIn;
Other use at line 82:
if (i != NSTAGES-2) VPipeLine[i] <= VPipeLine[i-1];
In the above fragment of Verilog code, it can be seen that a combination of blocking and non-blocking assignments to a register are used in the code. Clearly, this is a very bad coding style, and it is something that is very difficult for a designer to spot.
A Lint check of the code can address issues like these very efficiently, provided modern approaches to linting are used. I have seen my customers choose Ascent Lint v1.4 product from Real Intent for several important reasons.
Accuracy (Low Noise)
One of the most important reasons customers choose Ascent Lint is the low noise in the reports. This enables designers to get to a problem very quickly instead of wading through long reports of violations that are of no real concern. In addition, Ascent Lint 1.4 adds the capability to generate incremental reports, so that only new violations that occurred since the last run are reported to the designer, saving valuable time.
Another very important factor is the speed of Ascent Lint, which is at least 10 times faster than the leading competitive product. Often, I have seen speeds of 30 times faster than the competition when the run is done on a full chip. For example, a typical 5M gate design at RTL can easily be linted in just 10 minutes. The gate level netlist of that same design was run through the linting process in just 5 minutes and with very economical memory consumption of only a few gigabytes. The beauty of being able to do lint runs so quickly is that any designer working on the code may quickly run Ascent Lint, check the incremental report for any differences, and immediately correct the code while it is still fresh in his or her mind. This rapid turn-around is simply not possible with the leading competitor’s technology, which forces the designer to run lint overnight and therefore does not help get the code right as it is being written.
Flexibility and Ease of Use
Ascent Lint is very language-flexible. It can accommodate designs in Verilog, SystemVerilog and VHDL as well as designs containing a mixture of all these languages with ease. This enables full-chip Lint checks on designs containing IP from partner companies – a key requirement for some customers. Ascent Lint works at both RTL and gate level, and supports both hierarchical and flattened designs. It is also easy for any customer to develop separate policy files for RTL and for netlists.
Fast, accurate and flexible linting is crucial to our customers. Combining speed with informative and accurate reporting makes Ascent Lint v1.4 from Real Intent a definite winner. Call Real Intent to see for yourself!