Archive for January, 2012

16 January, 2012

IEEE Std. 1666™-2011 Available as Free Download

In November 2011 I blogged the IEEE Standards Association (SA) approved a revision to the popular SystemC standard, known officially as IEEE Std. 1666™-2011.  One of the key elements of this standard includes the addition of Transaction Level Modeling (TLM).  I pointed to several online resources to learn more about the revised SystemC standard in that blog.  But missing from the list of resources was information on how to get the revised standard from the IEEE.  As I concluded my blog, I indicated that the final editorial review and formatting for publication was underway and that I would report back when this work was completed.

IEEE Std 1666-2011I can report that the IEEE SA concluded their editing of the specification and it is now ready for download.  Many of you know the prior version of the SystemC standard was available for free download and have wondered if this would be the same for this revision update.  The good news is the revision update is available as a free download as well.  If you wish to have a printed and bound copy, that too is available, but that will have to be purchased.

IEEE Std. 1666-2011 is part of the “IEEE Get Program” that offers individuals the ability to retrieve, download and print one copy of the standard for free.  Click on the link above to get your personal copy of the standard.  You will need to share some basic information with the IEEE on your user type (Academic, System/Semiconductor Company,  EDA Company, IP Company or Other).  This is certainly worth if for a free copy.

The original standard, IEEE Std. 1666™-2005, had more than 50,000 free downloads since it was made available and I expect this version to do even better.  With the addition of TLM to the standard and the move up in abstraction to handle system design requirements, the need for this standard is even more pressing today.

, , , , ,

8 January, 2012

I think very few engineers would argue with the claim that the longer a bug goes undetected, the more expensive it is to fix. In fact, the general rule-of-thumb is that the cost to fix a bug increases by an order of magnitude as a project progresses from one milestone to the next. Bugs found before simulation obviously have the lowest cost. Bugs found at block or subsystem simulation are generally easier to debug and incur a lower cost to fix versus bugs found at high levels of integration—such as chip- and system-level simulation. Bugs found during post-silicon validation might require a new spin of the chip, while bugs found after product release can be devastating, costing millions of dollars to fix.

Years ago, while conducting an assessment on a project team trying to improve their processes, I learned that a simple bug had escape through the project’s verification process and resulted in a  respin. I refer to this as a simple bug since it could have been easily caught by running a static linting tool. The interesting fact related to this particular bug was that the project team was fairly mature in its verification processes—having adopted constrained-random and coverage-driven verification approaches.

Now, don’t misunderstand what I’m saying—I’m certainly not claiming that you only need static linting to solve all your verification challenges. The same could be said for any single verification solution—after all, verification is an exponential problem. However, there are a few valuable lessons in the simple bug example I just gave. That is, the longer a bug goes undetected, the more expensive it is to fix—and that multiple verification solutions are required to minimize risk for today’s complex designs.

One interesting verification solution that has emerged recently uses formal verification technology to automatically perform a set of design checks for a common set of RTL problems. The key point here is that the user does not need to be an expert with formal technology. This aligns well with my philosophy that any solution that is easy to use and finds bugs as early as possible within a verification flow is worth investigating. What’s interesting about this verification solution is that it can verify a class of problems that cannot be found using static linting tools as well as a class of problems that cannot be found with traditional four-state RTL simulation.

If you are interested in learning more about this verification solution, I would like to invite you to check out the web seminar “Questa Formal’s AutoCheck – The Push-Button Way to Find Bugs,” which is part of our free Transforming Verification On Demand Series of webseminars.

@dennisbrophy Tweets

  • Loading tweets...

@dave_59 Tweets

  • Loading tweets...