Archive for July, 2010

26 July, 2010

For years one of the objectives in EDA has been to make formal property checking easy to use and its results easy to understand. With the Automatic formal check feature in the June release of the 0-In Formal tool version 3.0, I think we have made significant progress in this area.

The feature, which predefines a set of assertion rules to look for design issues automatically, makes formal technology accessible to users who are not yet ready to write properties in System Verilog Assertion (SVA) or Property Specification Language (PSL). To make it easier to comprehend problems in the design, the tool highlights the violations back to the RTL code.

Automatic formal check focuses on three areas inadequately addressed by dynamical simulation:

The first area is functional coverage. Today, when constrained random simulation fails to achieve the targeted coverage goal, engineers have to fine tune the environment or add new tests. These efforts, often attempted relatively late in the verification cycle, can consume vast amounts of time and resources while still failing to reach parts of the design. In contrast, automatic formal check can be used to identify unreachable code early in the verification cycle. These targets can be eliminated from the coverage model. As a result, the coverage measurement is more accurate and you know when you are done.

The next area is design initialization. If a design cannot be initialized reliably in silicon, it will not function correctly. An obvious precursor then is making sure all the registers are initialized correctly at RTL. If X’es are used, we need to monitor the X creation, propagation and usage cycle. Dynamic simulation does not interpret X’es accurately as in silicon, which has only 1s and 0s. Automatic formal check is ideal in verifying register initialization under different modes or configurations. Then, with internal assertions and formal technologies, we can check that although X’es are created, they are not used by downstream registers.

The final area is corner case design issues. Time and time again, designers unintentionally write code that violates logical correctness. Examples include combinational loops, full case violations, parallel case violations, undriven logic, finite-state machine (FSM) deadlocks and FSM livelocks. Unless tests are written to specifically target these corner case design issues are, such issues are difficult to exercise. On the other hand, by formally analyzing the design semantics, automatic formal check identifies these design issues statically and creates the stimuli to highlight them to the users.

If you are interested to know more about the automatic formal check feature in 0-In Formal, please feel free to register for our upcoming seminar in San Jose.

 

, , , , , ,

25 July, 2010

What does the word performance mean to you?

Speed? Well, obviously speed is an important characteristic. Yet, if the team is running in the wrong direction, it really doesn’t matter how fast they are going.

How about accomplishment? After all, we do assess an employee’s or project team’s accomplishments using a process we refer to as a performance review.

What about efficiency, which is a ratio comparing the amount of work accomplished to the effort or cost put into the process? Certainly, from a project perspective, effort and cost should be an important consideration.

Finally, perhaps quality of results is a characteristic we should consider. After all, poor results are of little use.

From a verification perspective, I think it is necessary to focus on the real problem, that is, the project’s verification objectives:

  • Reduce risk-find more bugs sooner
  • Know when we are done-increase confidence
  • Improve project productivity and efficiency-get more work done

Now, whenever I hear the phrase “get more work done,” I’m often reminded of Henry Ford, who was the founder of the Ford Motor Company. Henry is probably best know as the father of modern assembly lines used in mass production, and he revolutionized transportation specifically, and American industry in general. Henry once said, “If I had asked people what they wanted, they would have said faster horses.” This quote provides a classic example of the importance of focusing on the real problem, and thinking outside the box.

horsesjpeg
In fact, Henry Ford’s faster horses example is often used in advanced courses on product marketing and requirements gathering. The typical example of focusing on the real problem generally involves a dialogue between Henry and a farmer, as follows:

Henry:   So, why do you want faster horses?

Farmer:   I need to get to the store in less time.

Henry:    And why do you need to get to the store in less time?

Farmer:   Because I need to get more work done on the farm.

As you can see, the farmer really didn’t need faster horses-he needed a solution that would allow him to get more work done on the farm. Faster horses are certainly one solution, but thinking outside the box, there are other more efficient solutions that would yield higher quality results.

Now, before I move on to discuss ways to improve verification performance, I would like to give one more example of thinking outside the box to improve performance. And for this example, I’ve chosen the famous Intel 8088 microprocessor. I was just an engineering student when the 8088 was released in 1979, and like so many geeks of my generation, I couldn’t wait to get my hands on one.

The 8088 had a maximum clock speed of approximately 5Mhz. It took multiple clock cycles to complete an instruction (on average about 15). Furthermore, a 16-bit multiplication required about 80 clock cycles. So the question is, how could we improve the 8088 performance to get more work done?

Well, one approach would be to speed up the clock.  However, this would only provide incremental improvements compared to what could be achieved by thinking outside the box and architecting a more clever solution that took advantage of Moore’s Law.  In fact, over time, that is exactly what happened.

First, the multiplier performance can be improved by moving to a single-cycle multiplier, such as a Wallace Tree, Baugh-Wooley, or Dadda architecture. These architectures calculate multiple partial products in parallel.  Second, the average number of clock cycles per instruction can be reduced by moving to pipelined architectures, where multiple instruction executions overlap, giving a net effect of one instruction completing every clock cycle (as an ideal case example).

The point is that we have moved to solutions that get more work done by “increasing the amount of work per cycle,” instead of just a brute force approach to the problem.

In my next blog, I’ll discuss why performance even matters, followed by thoughts on improving verification performance.

, ,

13 July, 2010

Another frequently asked question: Should I import my classes from a package or `include them? To answer this properly, you need to know more about SystemVerilog’s type system, especially the difference between its strong and weak typing systems.

In programming languages, weak typing is characterized by implicit  or ad-hoc conversions without explicit casting between values of different data types. Verilog’s bit vectors, or integral types, represent these weak typing aspects by implicitly padding and truncating values to be the proper bit lengths – at least proper by Verilog standards. If you perform a bitwise AND of a 7-bit and 8-bit vector, Verilog implicitly zero pads an 8th bit to the 7-bit operand and returns an 8-bit result. In contrast using VHDL, you would have to explicitly state whether you wanted the 7-bit operand to be padded, or the 8-bit operand to be truncated so that you have an expression with operands of equal size.

With a few exceptions, all other types in SystemVerilog follow strong typing rules. Strong typing rules require explicit conversions or casts when assigning or expressing operands of unequal types. And understanding what SystemVerilog considers equivalent types is key to understanding the effect of importing a class from a package versus including it from a file.

Inheritance aside, SystemVerilog uses the name of a type alone to determine type equivalence of a class. For example, suppose I have these two class definitions A and B below:

class A;
int i;
endclass : A
class B;
int i;
endclass : B

SystemVerilog considers these two class definitions unequal types because they have different names, even though their contents, or class bodies, are identical. The name of a class includes more than just the simple names A and B; the names also include the scope where the definition is declared. When you declare a class in a package, the package name becomes a prefix to the class name:

package P;
class A;
int i;
endclass : A
A a1;
endpackage : P
package Q;
class A;
int i;
endclass : A
A a1;
endpackage : Q

Now there are two definitions of class A, one called P::A and the other called Q::A. And the variables P::a1 and Q::a1 are type incompatible referencing two different class A’s. Re-writing the above example using an include file creates the same situation – two incompatible class definitions.

File A.sv File P.sv File Q.sv
class A;
int i;
endclass : A
package P;
`include “A.sv"
A a1;
endpackage : P
package Q;
`include “A.sv"
A a1;
endpackage : Q

After `including class A into each package, you wind up with two definitions of class A. Using `include is just a shortcut for cut and pasting text in a file. Importing a name from a package does not duplicate text; it makes that name visible from another package without copying the definition.

File A.sv File P.sv File R.sv File S.sv
class A;
int i;
endclass : A
package P;
`include “A.sv"
endpackage : P
package R;
import P::A;
A a1;
endpackage : R
package S;
import P::A;
A a1;
endpackage : S

Class A is declared in package P, and only in package P. The variables R::a1 and S::a1 are type compatible because they are both of type P::A. The fact that class A was `included from another file once it is expanded is no longer relevant once you consider the placement of the text from the file.

When you get compiler errors claiming that two types are incompatible even though they appear to have the same name, make sure you consider the scope where the types are declared as part of the full name. Class names declared in a module are prefixed by the module instance name, so the same module instantiated multiple times will create unique class names, all incompatible types.

For further information about packages, check out the June Verification Horizons article entitled “Using SystemVerilog Packages in Real Verification Projects”.

Dave Rich

, , ,

@dennisbrophy Tweets

  • Loading tweets...

@dave_59 Tweets

  • Loading tweets...

@HarryAtMentor Tweets

  • Loading tweets...