Archive for February, 2011

22 February, 2011

systemcday2011curveOpen SystemC Initiative Tackles the Future

If you have examined the DVCon program, you know that it is a week full of the Universal Verification Methodology (UVM).  And I certainly encourage those with an interest in UVM to attend the Monday tutorial and the technical conference the next few days.  But you may also want to bring a colleague to attend the SystemC Day activities.

For SystemC Day at DVCon, the morning session is the North American SystemC Users Group (NASCUG) meeting that features a Keynote presentation by industry luminary Jim Hogan.

Jim HoganJim’s keynote will be on “Navigating the SoC Era.”  NASCUG attendance is free, but you need to register to attend.

Jim Hogan will discuss the semiconductor industry’s growing adoption of SoC design, and its reliance on diverse sources of hardware and software IP, developed both internally and externally.

After considering recent survey data on both IP and verification drivers, Hogan will discuss the challenges that design and verification teams face for impacted areas such as design assembly and verification.

In the afternoon, a tutorial on software-driven verification titled Software-Driven Verification Using TLM-2.0 Virtual Platforms will be presented by experts from the OSCI, Accellera and the user community that are using standards-based methodologies in production today.  The afternoon tutorial requires registration at the DVCon website.  The tutorial is free for conference attendees.  A small fee is charged for those who wish to attend this tutorial only.  Is software-driven verification in your future?  Chances are highly likely it is and I suggest you look at attending this event.

I’ll see you there!

, , , , , , ,

18 February, 2011

By now you’ve probably heard that Accellera approved the Universal Verification Methodology Standard (UVM1.0) today. This announcement is the culmination of a great deal of work by the members of the Accellera Verification IP Technical Subcommittee (VIP_TSC), ably led by Tom Alsop of Intel and Hillel Miller of Freescale, and all who contributed to this outstanding effort should take a moment to bask in the glow of the accolades now flying around the blogosphere and twitterverse. To my colleagues on the VIP-TSC, I offer a hearty “Yo!” (sorry – inside joke) echoing those sentiments.

As a veteran of standards committees gong back to Verilog-95 (has it really been that long?), through Verilog 1364, SystemVerilog and now UVM, I’d like to offer my perspective. I have long been a proponent of Karen Bartleson’s First Rule of Standards, “Cooperate on standards; Compete on tools,” even before she had the brilliant idea of writing a book about it (which I strongly recommend, by the way). Having spent more time over the years than I care to recall trying to engage customers with new technology only to see them stuck where they are because of a mountain of proprietary code, I can’t tell you how much I’m looking forward to a level playing field. I expect that the user community is as well.

The value of standards has always been that a user can wrte one piece of code and use it across multiple tools to see which one is best. This is why Mentor has always been a strong supporter of standards, whether de facto, like OVM, or “official” standards from Accellera or IEEE. With UVM opening a new era of cooperation in the standards realm for functional verification, we invite our friends to join us in some healthy competition.

13 February, 2011

Somebody asked me a simple question: Why do need two different macros (`ovm_object_utils and `ovm_object_param_utils) to register classes with the factory, and why can’t it tell me when I’ve used the wrong one? The answer turns out to be quite long, and demonstrates the dangers of using certain macros without first understanding the code behind them. Some I’m posting the response here. Adam Erickson will be presenting a paper Are Macros in OVM & UVM Evil? at the upcoming DVCon11 on Wednesday, March 2nd that goes into more details about the costs and benefits of the OVM macros.

First I need to talk about parameterized classes in SystemVerilog and how they interact with static members of those kinds of classes.

When you declare a parameterized class, it is more like a template, or generic class than a real class type. Only specializations of parameterized classes are real types. Suppose I have the two class definitions in the table below:

Un-parameterized

Parameterized

class A;
  static string name = “packet”;
endclass

class B #(int w=1);
  static string name = “packet”;
endclass

The class A definition by itself creates the static variable A::name initialized with the string “packet” without any other reference to class A. As soon as you add parameters to a class definition, like the parameter w in class B, the class becomes a generic class and the static variable name does not get created. As soon as there are specializations of the class B, each unique specialization causes the static variables inside the class to be instantiated.  The following statements create two specializations of class B and two instances of the static variable.  B#(2)::name and B#(3)::name are both set to “packet”.

typedef B#(2) B2;
B#(3) B3_1h;
B#(3) B3_2h;

The two class variable declarations (B3_1h and B3_2h) represent only one unique specialization of B because its parameters have the same value in both declarations. The variable B#(1)::name does not exist unless there is some other reference to B or B#(1) somewhere else.

What if you wanted the static string variable name to have a different value for each unique specialization of B? You could write something like

class B #(int w=1);
  static string name = $psprintf(“packet%0d”,w);
endclass

Now assuming the previous typedef and variable declarations above, B#(2)::name would have the value “packet2” and B#(3)::name would have the value “packet3”. There would be no instance B#(1)::name and the string “packet1” would never have been generated.

Now let us go back to the `ovm_object_utils macro. Suppose we have the following class definition

`include “ovm_macros.svh”
import ovm_pkg::*;
class packetA extends ovm_object;
`ovm_object_utils(packetA)

endclass

Looking at just the factory registration statement this macro inserts for us (this little one line macro expands to over 100 lines of code just to support the field automation macros), we see a typedef for a specialization of the parameterized class ovm_object_registry called type_id.

import ovm_pkg::*;
class packetA extends ovm_object;
  typedef ovm_object_registry#(packetA,”packetA”) type_id;
  static function type_id get_type();
    return type_id::get();
  endfunction
  …
endclass

The specialized class type_id gives us access to all the static declarations inside ovm_object_registry. The code inside that class does something similar to what class A did above, except that it builds a global list of all string names and their associated types that can be used by the factory. The OVM gives you the choice of using the string name “packet” or the static function packetA::get_type() to set overrides, depending on which factory methods you use. The problem using the string names is that there is no type checking until run-time when the override statements are executed. We prefer you use type references to perform overrides

packetA::type_id::set_inst_override(extended_packetA::get_type(),”env.my_agent.*”);

Finally, let us take a look at a parameterized class, but assume we used the same `ovm_object_utils macro.

import ovm_pkg::*;
class packetB #(int w=1) extends ovm_object;
  typedef ovm_object_registry#(packetB#(w),”packetB#(w)”) type_id;
  static function type_id get_type();
    return type_id::get();
  endfunction
  …
endclass

There are two problems here. The first is that this is now a generic class. The string “packetB#(w)” will not put on the factory registration list unless there is a specialization of the class packetB somewhere. The second is that if there are more than one specializations of packetB, they all will be registered with the same string name, producing an error at run time.

The `ovm_object_param_utils macro simply leaves the second parameter to ovm_object_registry as the null string and forces you to use type references for your overrides. These type references also create the specializations needed to create the static methods inside these classes.

packetB#(2)::type_id::set_inst_override(
  extended_packetB#(2)::get_type(),”env.my_agent.*”);

The references to packetB#(2) and extended_packetB#(2) are checked at compile time and cause the static methods within these references to be created.

You can use $psprintf to register a string name as long as the string is unique for each specialization of the class. This can be difficult when the parameters are types.

import ovm_pkg::*;
class packetB #(int w=1) extends ovm_object;
  parameter sting name = $psprintf(“packetB%0d”,w);
  typedef ovm_object_registry#(packetB#(w),name) type_id;

OK, I’m done. If you still need more background information. I recommend another DVCon09 paper I wrote with Adam about Using Parameterized and Factories.

, ,

3 February, 2011

ieee_mb_blueIEEE Standards Association Hosts Design Automation Standardization Workshops in Bangalore & Delhi

I, along with several other individuals, will participate in two IEEE-SA EDA standardization workshops in India on Friday, 4 February 2011 in Bangalore and on Thursday 10 February 2011 in New Delhi.  In the last year, the IEEE announced it opened an office in Bangalore, India.  This is the fourth IEEE office in Asia, following China, Japan and Singapore.

A large number of IEEE’s members reside in India and the EDA standards get a lot of use and attention in India.  There is a strong and thriving IEEE Std 1800™ SystemVerilog community in India that are helping to extend the verification capabilities of the language.  As the IEEE office gets setup, I look forward to it to help better coordinate standards development of a global community of companies and individuals.

Agenda: Bangalore, India Workshop (Register)
Location: Mentor Graphics, Bangalore

8:30 Registration opens
9:00 Welcome–Pamela Kumar (IBM)
9:05 IEEE-SA and the World of Standards
Dennis Brophy, Member, Board of Governors, IEEE-SA
Director of Business Development, Mentor Graphics
9:45 Standards in Design Automation: Influencing Design and Verification Methodologies
Low power (1801); Design & Verification productivity (1800, 1735); System Design (1666)
Yatin Trivedi, Member, Standards Education Committee, IEEE-SA
Director of Standards, Synopsys
10:30 Tea-Break
11:00 Impact of Standards in Design Environment
Sri Chandra, Chair, Standards Interest Group, India Chapter, IEEE-SA
CAD Manager, Freescale
11:30 Anecdotes of Participation in Standards Activities
Srinivasan Venkataramanan, CTO, CVC, Bangalore
11:45 Panel Discussion: Standards, Industry and Academia
Moderator: Pamela Kumar
Participants: Dennis Brophy, Yatin Trivedi, Sri Chandra, SriniVenkataramanan, Anuradha Srinivasan (Intel)
12:30 Conclusion & Thank You

A set of IEEE-SA Board of Governors meetings will be held at the beginning of the the week of February 7th.  And in addition to the meeting on design automation standards in Bangalore, a group of workshops are also planned in Mumbai on 4 February 2011 on Cloud Computing and Smart Grid by other colleagues I volunteer with on the IEEE-SA Board of Governors.   There are more IEEE-SA events planned for the week of February 7th and a full list can be found here.

For those who wish to join the New Delhi design automation workshop, some details of it can be found below.

Agenda: New Delhi, India Workshop (Register)
Location: IIT

8:30 Registration opens
9:00 Welcome—Karen Bartleson (Synopsys)
9:05 IEEE-SA and the World of Standards
Dennis Brophy, Member, Board of Governors, IEEE-SA
Director of Business Development, Mentor Graphics
9:45 Standards in Design Automation: Influencing Design and Verification Methodologies
Low power (1801); Design & Verification productivity (1800, 1735); System Design (1666)
Yatin Trivedi, Member, Standards Education Committee, IEEE-SA
Director of Standards, Synopsys
10:30 Tea-Break
11:00 Impact of Standards in Design Environment
Sri Chandra, Chair, Standards Interest Group, India Chapter, IEEE-SA
CAD Manager, Freescale
11:30 Anecdotes of Participation in Standards Activities
Srinivasan Venkataramanan, CTO, CVC, Bangalore
11:45 Panel Discussion: Standards, Industry and Academia
Moderator: Karen Bartleson
Participants: Dennis Brophy, Yatin Trivedi, Sri Chandra
12:30 Conclusion & Thank You

, , , , , , , ,

@dennisbrophy Tweets

  • Loading tweets...

@dave_59 Tweets

  • Loading tweets...