Cadence Blogs

What is Next for SystemC?

Steve Brown — Fri, 17 Jul 2009 19:00:00 GMT

Let your voice be heard at the North American SystemC Users Group interactive Town Hall Meeting! You are invited to a lively discussion for the system-level design community on the state of SystemC and what lies ahead. Providing an interactive format that encourages audience response and questions, this first ever town hall meeting features an open discussion on the state of SystemC, where it's at and where it's going. Design experts from OSCI Working Groups will address user questions on...(read more)

North American SystemC User's Group Co-Located at DAC 2009

Steve Brown — Fri, 17 Jul 2009 16:48:00 GMT

We've been hearing about SystemC for a while. It's a great language! What's it great for? Well, you can find out from other users at the coming user group meeting co-located with DAC in San Francsico. This year promises to be full of excitement as the emergence of TLM 2, and many product capabilities, are highlighting the vision of SystemC from its inception. Additionally, the conference ends with a Town Hall discussion about where SystemC needs to be driven to facilitate the next wave...(read more)

Write Right OVM Verification Components

Adam Sherilog — Fri, 17 Jul 2009 13:23:00 GMT

The OVM provides the most comprehensive reuse if you follow the methodology it prescribes. While its unique built-in classes are the technical heart of the reuse, you still have to write your own components. Now you have the new Paradigm Works OVC Template Generator to write them in the right way for you.

Paradigm Works, an industry leader in functional verification services has helped clients verify complex chips OVM SV and OVM e (eRM). The OVM Template Generator leverages Paradigm Works’ best-learned practices and offers pre-packaged verification environment templates that can be customized to further fit a team’s specific project requirements. The output of the Template Generator is an OVM compliant Verification Component (OVC).

To help us understand what the generator does and how it helps speed the verification process, I sat down with Dr. Ambar Sarkar. Dr. Sarkar is the Chief Verification Technologist at Paradigm Works Inc. and a self-declared open source enthusiast. He is the architect of the SystemVerilog FrameWorks^TM toolkit, which includes the Template Generator, among other tools and utilities to jumpstart a verification environment. This toolkit is based on soup-to-nuts experience of the PW team at numerous client engagements.

Q: Ambar, can you tell us more about the Template Generator?

Simply put, the SystemVerilog FrameWorks^TM Template Generator (SVF-TG) generates a detailed boilerplate for an OVM based verification environment (testbench) from scratch. The verification engineer is presented with a web interface where he or she enters a few parameters, and the resulting output is a tarball of the SystemVerilog environment code, with all the recommended components hooked up as recommended by OVM. From that point, the engineer needs to code the application-specific elements, but the plumbing that enables reuse has been taken care of already.

Q: Where can we find the Template Generator?

The Template generator is posted to the Contributions area of the OVM World. This takes you to the web interface. We are working on putting the entire source code of the template generator on SourceForge, the popular open source software hosting site.

Q: How do we know that the templates are OVM compliant?

We held several detailed internal reviews with our core team of highly experienced verification engineers who bring their own perspective and their knowledge of the various application domains they have consulted for. In addition, we cross-checked the generated code against Cadence’s OVM compliance list. That list comprehends the nearly decade-long experience with OVM e (eRM) and the more recent experience with OVM SystemVerilog.

Q: Why not just code OVCs by hand following examples?

To summarize, I see two main reasons for not doing this by hand.

First, which is I believe is the main reason, is that this tool offers a standard and powerful starting point for the engineer embarking on a new OVM project. All the necessary element templates, specified by the engineer, have been defined and hooked up. In fact, even the makefiles for multiple simulator vendors are provided so that the generated code compiles out of the box.

Second, it avoids tedium. Frankly, there is a significant amount of infrastructure code that needs to be written and hooked up for any real project. Copying and pasting from an existing example has the usual caveats – what if you did not update everything you needed to or forgot to define some key elements? To illustrate this point, take a look at some code snippet that is generated. This was done for a simple scenario where the testbench needs 3 APB masters and 1 APB slave. As you can see, it is quite possible that one may forget to hook up or mistype one of the numbers or names.

function void connect();

[ deleted… ]
// Assign reference for virtual sequencer
v_sequencer.apb_0_m_sequencer = apb_inst.masters[0].sequencer;
v_sequencer.apb_1_m_sequencer = apb_inst.masters[1].sequencer;
v_sequencer.apb_2_m_sequencer = apb_inst.masters[2].sequencer;

v_sequencer.apb_0_s_sequencer = apb_inst.slaves[0].sequencer;
[deleted …]

endfunction : connect

Q: What kind of demand are you seeing for this functionality?

We have been very excited with the response so far. From the OVM community page, we see that there have already been more than 400 downloads in a relatively short time. That’s 340+ on OVM World and another 70+ directly from our PW page (http://downloads.paradigm-works.com).

Q: What else are you seeing the OVM ecosystem demand?

As far as the templates are concerned, we definitely had requests for customizing the generated code. The web interface does not allow it, but the backend tool supports complete customization, and even knows how to merge changes from newer templates. As I mentioned earlier, we are working on putting the entire backend on open source for the OVM community. Imagine the ability to come up with a standard way to create testbenches across all projects in a company distributed across the globe! This tool can act as an executable specification for creating testbenches.

We also have uploaded an objection based shutdown manager as well as an OVM scoreboard package. While there are some alternatives to the shutdown manager available, this powerful scoreboard package fills a void in the OVM community today.

Another area we are looking at, depending on bandwidth and community interest, is OVM multi-language, including e and SystemC. We would like to hear from the OVM community if there is an interest for creating templates for these OVM versions.

We encourage folks to visit http://downloads.paradigm-works.com, and stay tuned for further contributions on http://ovmworld.org/contributions.php. Of course, we look forward to and will incorporate any feedback as appropriate and feasible.

Do you have any questions for Ambar or me? If so, you can comment here on this blog or contact Ambar directly at ambar.sarkar@paradigm-works.com.

=Adam Sherilog

Things You Didn't Know About Virtuoso: Search Assistant

stacyw — Fri, 17 Jul 2009 13:00:00 GMT

People say I have strong google-fu. Whether it's finding information on a homework topic for my kids or reviews for that little restaurant downtown, all it takes is a minute or two at the keyboard and there it is. Searching for information has become a very important skill in today's world, both in "real life" and at work. Laying your hands on reliable information quickly can make your life easier, amaze your friends and impress your boss.

So today, I'd like to introduce you to the new Virtuoso Search Assistant and Toolbar in IC6.1. Whether you're looking for all the places a certain design variable is used or which instances a particular net is connected to or where in your design hierarchy a specific device type is used, the Search Assistant will give you the information you need.

First of all, where is this little gem hiding? Virtuoso provides both a Search toolbar and an associated dockable assistant. Both can be invoked by--all together now--clicking the RMB near the top of the window and selecting Search from either the top (for the assistant) or the bottom (for the toolbar) of the menu. There's no difference in functionality between the two. In fact, clicking "Show All" from the Search toolbar results will open the Search assistant automatically.

Search engines are typical pretty self-explanatory, but recently, I've been amazed at what fun little secrets a little digging can expose. (For example, did you know that Google has a built-in calculator?) So it is with the Search Assistant (ok, no built-in calculator...yet, but some other cool details I'll talk about in a bit). Basically, you enter whatever it is you want to search for in the search field, hit Enter and you'll see everything in your design that matches that search string.

What do you mean--everything?

Click on the little magnifying glass at the left of the search field. This shows a partial list of the categories which will be searched (the complete list can be found by clicking Options... at the bottom of that menu). You can limit your search by enabling only one of these categories (or several if you use the Options... dialog). You can also limit your search to only those objects selected in the current view by choosing "Selected" at the bottom of the Search Categories menu.

Notice that you can even search for Skill functions and menu items. So if you forget where to find the grid snap spacing you can search for "snap" and find it right away.

Note: The Search Categories are also keywords for the search engine. So you can enter "instances nmos2v" or "nets bias" to restrict your search that way. Or type just "instances" or "nets" to get a complete listing.

Where is it searching?

Now click on the little triangle at the right of the search field. This will give you options for how the engine should match the search string (case sensitivity, substring, and/or, etc.). It allows you set the search scope, including the very powerful option to extend your search down through the design hierarchy. So now you can immediately find every place in the hierarchy where a certain block is used. In the search results, items not in the current view will be highlighted in gray.

What can I do now that I've found what I was looking for?

Good question. This is where I find the real power of the Search Assistant. First of all, you'll notice that selecting items in the Search Assistant cross-selects them in the main canvas as well as the Navigator and the Property Editor Assistant, so that's very handy right there.

But wait, there's more...

By holding down a certain mouse button (hmm..which one might that RMB...) over the items, you'll see a context-sensitive menu of options specific to items of that category. Depending on the category, you might be able to:

Add an instance of a cell
Open the cellview containing an instance or net if it's at a lower level of hierarchy
Open the Skill finder entry for a Skill function
Select a net and all instances attached to it
Open an options dialog or directly execute a menu command

In addition, you can save the search results to a CSV file for further documentation and reference.

"Searching is half the fun: life is much more manageable when thought of as a scavenger hunt as opposed to a surprise party."--Jimmy Buffett

As always, feel free to share your discoveries and experiences (good or bad) with any of these topics.

Stacy Whiteman

How To: Create a Self-Contained Testcase in Encounter

BobD — Thu, 16 Jul 2009 14:00:00 GMT

In the course of performing design work in Encounter, it frequently becomes desireable to create a self-contained testcase that can be shared with colleagues at other sites, or with Cadence to aid in troubleshooting tool issues. By self-contained, I mean the design data (netlist, floorplan, placement, routing, timing constraint files, etc) and all of the supporting collateral (.libs, LEFs, extraction tech files, etc) within a sub-directory that can be tarred up and uploaded to an ftp site such that someone else can download the design and see the design just as you're seeing it. Because this data is often drawn from various shared locations on the network, symbolic links are used, and pointers often make use of shell/TCL variables, creating a self-contained testcase is frequently quite a bit more complicated than it appears at first glance. But fear not- a new command has been introduced that automates this for us.

In the Encounter Digital Implementation System version 8.1.USR2, a new public command was introduced that automates the testcase creation. It is called: "saveTestcase"

Here's how it works...

Load a design into the tool (either via a .conf file -or- by restoring a design)
Get the design into the desired state (ie,placed or routed)
At the tool prompt, issue the command: "saveTestcase"
By default, a sub-directory in your current run directory will be created called "testcase" which contains the design data and collateral. The pointers in the .conf file and the viewDefinition file (if you're running in MMMC mode will all be resolved to point to these new locations relative to the current directory.
This new directory can be tarred up and E-mailed or ftp'ed to other people you're working with.

Complete usage:

Usage: saveTestcase [-name <testcaseName>]
[-dir <directoryName>]
[-rc] [-merge] [-overwrite] [-gzip]

Enter "man saveTestcase" at the tool prompt in 8.1.USR2 for extended help -or- see the complete documentation on Sourcelink here.

Additional nice features:

saveTestcase can automatically tar and gzip the resulting testcase. Use the "-gzip" option.
In 9.1 the GUI will be updated to include the image shown at the top of this piece. It will be accessible under "File->Save->Testcase..."

Not using 8.1.USR2 yet?

Here are Three Reasons to Move to 8.1
Download it here [select your platform, "then SOC81", then "SOC08.10.002"]
In versions prior to 8.1.USR2 there was is a script available in <install_path>/share/fe/gift/scripts/tcl/ called "userCreateZeroReg.tcl" with a very similar use model and capabilities.

Congratulations to userCreateZeroReg.tcl on "graduating" from the gift scripts to being a productized command. I'm proud of you. :)

Question of the Day: What are some of the scenarios where self-contained testcase creation is useful to you?

-Bob Dwyer

TLM Brings “ESL” Down To Earth

rgoering — Thu, 16 Jul 2009 13:14:00 GMT

Has ESL – meaning Electronic System Level, not English as a Second Language – outlived its usefulness as a label that supposedly describes the next step forward for IC and systems design? “ESL” has become a vague term that applies to many different things. A more specific term, such transaction-level modeling (TLM), gives us something we can understand and evaluate.

While I have written many articles about ESL over the years, I would be hard-pressed to define it. Some would say that ESL involves hardware/software co-development. But the best practical definition I can come up with, considering its use over the years by multiple vendors, is “anything that takes place above RTL.” ESL has grown to encompass such tools and technologies as:

Algorithmic development tools that were there all along (SPW, Matlab)
Virtual platforms for software and/or architectural development (Vast, Virtutech, CoWare, others)
High-level synthesis (such as Cadence C-to-Silicon Compiler)
Hardware/software co-verification tools (such as Cadence Incisive Software Extensions)
SystemC TLM modeling for implementation and/or verification

All these technologies are important, especially as software development looms as the biggest single obstacle to getting electronic products out the door. While interrelated, all are different. There is no one ESL market or methodology. There are different markets with different users, many of whom still think “ESL” stands for English as a Second Language.

For many years ESL – and its predecessor, if anyone remembers ESDA – were handy ways of referring to a diverse set of technologies aimed at raising the abstraction level of IC design. But now that the underlying technologies are starting to take hold, it’s time to look underneath the all-encompassing “ESL” label.

Cadence this week is rolling out a TLM-driven design and verification solution. It includes enhancements to existing tools such as C-to-Silicon Compiler and the Incisive Enterprise Simulator, upcoming methodology guides and manuals, and services. Unlike ESL, TLM is a clearly understood term – there are even standard definitions provided by the Open SystemC Initiative. Many design and verification teams already use TLM in some form.

Not only is TLM easy to understand, but its benefits are clear and, in some cases, quantifiable. A TLM-based flow promises faster design creation and bug fixing, much faster simulation, fewer bugs, and better support for hardware/software co-verification. But perhaps the most compelling benefit is IP reuse; if you design IP at the transaction-level, it is much easier to port to different micro-architectures.

Early attempts at ESL all too often tried to impose a new methodology or non-standard language from the top down, with little or no connection to the downstream design flow. The nice thing about TLM is that it’s an evolutionary step up that leverages the strengths of today’s design environments, rather than trying to replace those environments.

While incremental, the move to TLM puts us in a better position to drive innovations in other technologies that have fallen under the ESL umbrella – including algorithmic tools, virtual platforms, high-level synthesis, and hardware/software co-design and co-verification. For example, transaction-level models can help build virtual platforms. They can also be used in hardware/software co-verification. And high-level synthesis is a critical enabler of the TLM-based flow.

The move upwards in abstraction can start right now, with TLM-driven design and verification. All technologies identified as “ESL” will benefit. But as we move up, let’s speak in clear terms engineers can understand -- there is no need to invent a “second language” to describe a natural, evolutionary process.

Richard Goering

Technorati Profile

RF Measurement Library: Capturing Circuit Characterization Setups on the Schematic

alanw — Thu, 16 Jul 2009 13:00:00 GMT

Another design approach that Cadence supports that may not be obvious to all users… The process of setting up a circuit simulation has historically been one of setting up all of the simulation control parameters (i.e. which analysis you want to run, what simulation data you want to save, accuracy tolerances, etc.) and then, after the simulation has completed, defining the measurements you want to make (i.e. noise figure, dc supply current, gain, etc.). The expectation here is that the user...(read more)

TLM-Driven Design and Verification Solution

Steve Brown — Thu, 16 Jul 2009 00:15:00 GMT

At this week's CDNLive! Japan we made an important press release announcement about our new TLM-driven Design and Verification Solution, and delivered the first Techtorial covering the technology and methodology. The solution combines C-to-Silicon Compiler (CtoS) , Incisive Enterprise Simulator (IES) , Incisive Enterprise Manager (IEM) to enable customers to use transaction level modeling (TLM) for design and verification. The unified methodology is built upon the OVM and SystemC industry standards...(read more)

What's Good About ABIML in PCB SI? It's in SPB16.2!

Jerry GenPart — Wed, 15 Jul 2009 19:01:00 GMT

First - ABIML is an acronym for Algorithm-Based Interconnect Model Library.

Currently, the model in the interconnect model library (IML) can only be reused by matching model name, model type, or exact "TraceGeometryData", which includes key information such as shield layer, dielectric layer, trace layer and the exact trace physical geometry. If any of the model geometry data is mismatched, the field solver is called to create a new model. In addition, for dynamic analysis, the frequency spectrum must also be matched. This "exact" model matching procedure provides designers the most accurate electrical parameters as our tool can and will still be active in the future.

Interconnect modeling, which relies heavily on electromagnetic computation and optimization, is essential and critical in high-speed electronic circuit design. The more complex interconnect structures require the use of the new EMS2D full wave field solver, where computation is extremely CPU intensive and not practical in interactive design.

The new methodology is to shift the time needed in model generation by building the algorithm-based models off-line through rigorous full-wave EM simulation. These verified models are then reused to generate new required models efficiently without calling the field solver again.

In the algorithm-based interconnect model library (ABIML), interconnect models are all parameterized and validated for their application range with pre-specified accuracy control. When a specific model is requested from this library, the library will try to provide the model by checking if the needed model is within the algorithm range of the existing same kind of models in the library. Otherwise this library calls the field solver to acquire the model.

Algorithm-based interconnect models are designed to greatly enhance simulation times when interconnect models that match simulation criteria cannot be found in existing traditional models. Algorithmic model generation lets you create accurate interconnect models off-line that exactly match not only shield, dielectric, trace and physical geometry layer information but also entire frequency spectrums. These models are then integrated into libraries for reuse in multiple simulations. There is currently no capability for users to create their own ABIML models.

Algorithm-based modeling is optional. You can enable/disable it from the InterconnectModels tab of the Analysis Preferences dialog box in Allegro PCB SI or the Simulation Parameters tab in SigXplorer.

If you turn off algorithm modeling, the PCB SI tools will not search for algorithm-based models. Instead, it will directly engage the selected field solver to create the required model. This process is illustrated in the flow chart below.

I'm curious how many have been using this feature in the SPB16.2 release?

The ABIML libraries are stored in <install_dir>/share/pcb/signal. The syntax of the model contains two sections:

Model information such as parameter range, interpolation type, and sweep step type
Multiple RLGC data used in model generation

The following is a simple example of the file format.

[Model] abiml_test
[Model Info]
  [Field_Solver_Used] ems2d
  [ABIML_Version] 1.0
  [Model_Type] singletrace
  [Num_of_Port] 2
  [Num_of_DielectricLayer] 1
  [Num_of_ShieldLayer] 1

  [Parameter Info]
    [LayerStack]
      [Layer] 1
        * min max step step_type interp_type ID
        [Thickness] 1.0 1.0
        [Constant] 1.0 1.0
        [Losstangent] 0.0 0.0
        [IsShield] YES

      [Layer] 2
        * min max step step_type interp_type ID
        [Thickness] 1.0 2.0 5 linear linear 1
        [Constant] 4.4 4.6 3 log 2_order_poly 2
        [Losstangent] 0.0 0.0
        [IsShield] NO
    [End LayerStack]
    [CrossSection]
      [conductor] 1
        * min max step step_type interp_type ID
        [Thickness] 1.0 1.5 5 linear linear 3
        [Width] 1.0 10.0 20 linear 2_order_poly 4
        [Losstangent] 0.0 0.0
        [end CrossSection]
[End Model Info]
[Model Data]
    [Data] 1
      [R] 1.459500e+01
      [L] 6.088700e-07
      [G] 0.000000e+00
      [C] 5.162900e-11
      [Data Condition]
      *       ID          value
              1            1.0
              2            4.4
              3            1.0
              4            1.0
      .....
    [Data] 4725
      [R] 3.630000e+00
      [L] 4.567500e-07
      [G] 0.000000e+00
      [C] 7.440100e-11
      [Data Condition]
      *       ID          value
              1            2.0
              2            4.6
              3            1.5
              4           10.0
[End Model Data]
[End Model]

As always, I welcome your feedback!

Jerry "GenPart" Grzenia

EDA In 1964 – A Look Back At The First DAC

rgoering — Wed, 15 Jul 2009 15:59:00 GMT

The fact that the 46th annual Design Automation Conference (DAC) is coming up tells us that EDA has been around a lot longer than most people think. What were they talking about back in 1964, the first year for which proceedings are available? (This was technically the “second” DAC, although it wasn’t called that -- it was the first workshop hosted by the SHARE Design Automation Committee. At the “first” DAC, in Miami in 1963, the SHARE Design Automation Committee was formed.)

DAC founder Pat Pistilli, then chairman of the SHARE Design Automation Committee, introduced the 1964 workshop by talking about the history of SHARE (an organization of computer professionals founded in 1955) and the decision to launch a committee focused on design automation. “Design automation had grown, by that time [1963], from a searching infancy to a rapidly maturing adolescence as a result of increasing effort throughout industry,” he said. So it appears that electronic design automation was almost a teenager in 1963!

Keynote speaker August Bolino (affiliation not given) spoke about the benefits of “automation,” a controversial subject in those days. “As you know, there is very wide concern nowadays of what the computer is doing to man as an individual and a member of society,” he said. But Bolino ticked off the benefits. “We now have a 600 billion dollar economy, we have 70 million people employed, and per-capita income just passed the $2,500 mark. We have managed to take most of the drudgery out of work, we see a plethora of new products, and we have books which are being published by computers.”

Several papers were presented at the workshop. One IBM paper looked at “the problem of programming a digital computer to formulate and solve the algebraic and differential equations characterizing linear and/or nonlinear networks.” Another IBM paper describes an experimental program for computing the dc and transient response of transistor switching circuits of “arbitrary” configuration and size – all the way up to 20 transistors.

A paper authored by computer graphics pioneer Ivan Sutherland (then from MIT) described Sketchpad, a graphical communications system that “makes it possible for a man and a computer to converse rapidly through the medium of line drawings. Heretofore, most interaction between man and computers has been slowed down by the need to reduce all communication to written statement that can be typed,” the paper abstract said. A separate IBM paper described a 3D version of Sketchpad.

An MIT paper presented the AED compiler, a “single language which can take either verbal or graphical form” for CAD applications. This sounds somewhat like an early attempt at ESL. Other papers discussed Autocard, an automated pc-board design system from Boeing; a computer program for space frame analysis; the impact of design automation on production test; graphic data processing; and geometric placement of units on a plane.

In a concluding remark, F.G. Fielding of North American Aviation noted that the approximately 250 attendees represent “a new, young unique industrial art.” I wonder what those 1964 workshop attendees would think of DAC today, with its 200-plus exhibits, giveaways, promotions, lunches, parties, wall-to-wall panels, and extensive technical program. Could they have foreseen what their “new, young unique industrial art” would become some 45 years later? Proceedings of the 1964 SHARE Design Automation workshop are available in the ACM Library.

Richard Goering

Tips on Using e Macros to Raise Abstraction and Facilitate Reuse

teamspecman — Wed, 15 Jul 2009 13:30:00 GMT

[Please welcome Yuri Tsoglin of Specman R&D to the guest blogging rostrum.]

As my colleague Hilmar van der Kooij noted in a previous post, e's "defined as computed" macro capability is a great way to condense repetitive blocks of code into a few easy to read, parameterized lines. Building on Hilmar’s practical introduction, I’m going to ask you to take a step back and look at macros in broader context: specifically, consider that macros allow you to effectively introduce your own language constructs in an almost unlimited way. Whether you stick with a purely practical view of macros, or accept this proposed conceptual view, the benefits are the same: macros are a very powerful tool to help to raise the level of abstraction and facilitate reuse of your testbench.

Of course, using macros in a haphazard way can be more harmful than helpful since a macro defined improperly, or used in a situation that does not really require a macro, can cause the code to become obscure and less readable. Thus, allow me to give some useful tips on when macros should or should not be used, and when the “define-as-computed” macro capability referenced in Hilmar’s post is more appropriate than e’s “define-as” macro capability

A macro introduces a new syntactic construct to the language, and that's the primary reason they should be added to your code. For example, if you have a reused syntactic pattern in your code, such as a group of struct members related to each other in a certain way:

struct my_struct_s {

private a: uint;

get_a(): uint is {return a};

set_a(value: uint) is {a = value};

private b: uint;

get_b(): uint is {return b};

set_b(value: uint) is {b = value};

// same code for defining c,d,e …

};

A macro such as the following would be the best thing to do:

define <my_priv_field'struct_member> "priv_field <name>[ ]:[ ]<type>" as {

private <name>: <type>;

get_<name>(): <type> is { return <name> };

set_<name>(value: <type>) is { <name> = value };

};

as this would allow you to implement a new language construct to represent a private field definition as well as the two required methods:

struct my_struct_s {

priv_field a: uint;

priv_field b: uint;

…

};

However, it is not a good idea to use a macro where other basic language tools will do. For example, don't use a macro to make up a "pseudo-method" that multiplies the field “f” in a certain struct by a given factor:

-- This is an example for what should NOT be done

define <print_hex'exp> "multiply_f$<factor'exp>$" as {

( f * <factor'exp> )

};

Although the macro works, it is preferable to use a regular method in this case. Also notice that although this macro is expected to be called only in the context of the struct, nothing prevents it from being called outside that context.

Special Macro Constructs: “Define As” and “Define As Computed”
The e language supports two unique constructs for creating macros: “define as” and “define as computed”. The difference between the two: a “define-as” macro directly defines the textual pattern for the replacement code, whereas a “define-as-computed macro” contains procedural code that is executed at compile time and computes the replacement code string.

Define-as macros are more simple and readable, so use a define-as macro whenever the general replacement code pattern is fixed and does not depend on the macro arguments. In more complicated cases, when the replacement code can be different and depends on the macro arguments in a non-trivial way, a define-as-computed macro is the way to go. To illustrate, let me start with an example where a define-as macro seems to be fine at first glance, but actually it isn't.

Assume your struct “packet” has a boolean field “flag”, and you want to introduce a new action construct of the form "switch p on/off", which will modify that field accordingly.

define <switch_packet'action> "switch <packet'exp> (<HOW>on|off)" as {

if "<HOW>"=="on" then {

<packet'exp>.flag = TRUE;

} else {

<packet'exp>.flag = FALSE;

};

This macro, as such, works fine. But let's see what in fact happens here. Whenever the macro is used in the code, it is replaced at compile time with the specified replacement code as is, and the replacement code is executed as is at the run time. So, the following code: "switch p off" is in fact replaced with this code:

if "off"=="on" then {

p.flag = TRUE;

} else {

p.flag = FALSE;

};

and this is what will be executed every time the action is reached by the flow of the program. This obviously does not make sense: the condition checks the syntax of the macro call itself (namely, whether it was used with "on" or with "off"), rather than something in its run-time context, thus it could have been checked and applied already at compile time. If the condition had been checked at the compile time, the replacement code (to be executed at run time) could have become simply:

p.flag = FALSE;

Furthermore, in more realistic cases (than this trivial example) this can also avoid unneeded performance overhead.

Alternatively, a define-as-computed macro would be the right choice in this case. In the example below, notice the check becomes part of the define-as-computed executable code, rather than part of the replacement code string it returns.

define <switch_packet'action> "switch <packet'exp> (<HOW>on|off)" as computed {

var res_string: string;

if <HOW>=="on" then {

res_string = "TRUE";

} else {

res_string = "FALSE";

};

// return the assembled code string

return append(<packet'exp>, ".flag = ", res_string);

};

To summarize, the following simple tips should help you make powerful macros:

Don’t use a macro when there is no real need to do so (eg. Don't "simulate" methods with macros)
Use define-as macros when appropriate. They are less powerful than define-as-computed, but more simple and readable.
Don't perform syntactic checks on the macro call at run time; and if a define-as macro would cause this, use define-as-computed instead.

Yuri Tsoglin
Member of Consulting Staff
Specman R&D
Cadence Israel Development Center, Rosh Ha'ain

Embedded Software Plays an Important Role in Low Power Design

jasona — Wed, 15 Jul 2009 13:05:00 GMT

At Cadence, there is a big focus on low power design . In the mobile world, power has become the primary design constraint. Everybody knows that dead batteries are no fun. When Cadence IT sent me a new laptop last year, I was very happy to get a machine which was faster, had more memory, and a bigger hard drive, but was sad to learn that the battery lasted about 2 hours vs. a 4 hour battery on the old machine. This is the difference between enough battery to fly to San Jose and not enough battery...(read more)

Using wreals to Simulate Frequency Scaling for Dynamic Power Reduction

Neyaz — Wed, 15 Jul 2009 13:00:00 GMT

Some background info:
Taking a quick look at Power dissipation in CMOS:

Leakage power is well managed by powering down parts of the design when not in use. This is a well understood problem and can be simulated well in IUS (Incisive Unified Simulator) using CPF (Common Power Format) commands to capture power intent. For details refer to “A practical Guide to Low Power Design” – download a copy at http://www.powerforward.org/

The Problem:
So, how to deal with parts of the design that can not be powered down during the operation of the chip? Some examples are – processor cores, and other dedicated applications that have variable computing needs, but do remain to be always on.

A practical solution:
One of the primary techniques used in the industry is DVFS – Dynamic Voltage and Frequency Scaling which consists primarily of:

Reducing the frequency & voltage of a design
Done in real-time
Based on processing needs to run at lowest possible frequency and voltage that will support the application needs

DVFS is used for both:

Power-saving during off peak processing times, and
As a protective measure to avoid over heating

In this blog, I will primarily focus on Frequency scaling and how to effectively simulate that in the context of SoC level simulation. Later blogs will focus on Voltage Scaling.

Some more background info:
In order to simulate Analog elements in the SoC we need a way to simulate Analog behaviour at digital speeds so that system-level simulations containing both analog and digital components can be performed. Cadence has introduced a digital centric mixed signal verification environment – Digital Mixed Signal (DMS). This new verification environment targets customers using digital centric use models. It refers to – but is not limited to – mixed signal verification using digital simulators only. In other words, it delivers capabilities to verify the mixed signal design using digital centric methodologies. This is effectively done by using Real Valued Modeling (RVM) where speed is traded off for very high level of accuracy typically involved with simulation of analog elements.

RVM is a mixed approach, borrowing concepts from analog and digital simulation domain. The values are continuous, floating-point (real) numbers, as in the analog world. However, time is discrete, implying that the real signals change values based on discrete events. In this approach, we apply the signal flow concept so that the digital engine can solve the RVM system without support of the analog solver. This guarantees a high simulation performance in the range of a normal digital simulation and orders of magnitudes higher than the analog simulation speed.

There are four different language standards that support RVM, namely:

wreal ports in Verilog-AMS
real in VHDL
real variables in SystemVerilog
real types in e

It is important to note that the real-wire (wreal) is defined only in the Verilog-AMS LRM. Thus, a wreal can be used only in a Verilog-AMS block. However, it is only the digital kernel that solves the wreal system. There are no performance drawbacks when using these types of Verilog-AMS modules in a digital simulation context.

Wreal example:
Here’s an example of using wreals for creating a VCO model that is used to control clock speed and can be effectively used for dynamically scaling of frequency to verify dynamic power management.

In this example, two VCOs are instantiated to independently generate clocks for the DSP and MCU blocks in the design. Depending on processing needs, the clock speed is independently controlled from an on-chip controller – see waveforms..

vco vco_mcu (.vin(vco_vin_mcu_clk), .clk(mcu_clk));
vco vco_dsp (.vin(vco_vin_dsp_clk), .clk(dsp_clk));

The control logic on the chip runs the design units DSP & MCU in this case, at the slowest possible speed in order to conserve dynamic power. Details of the control mechanism are left out and can form the basis of another blog.

The effects of dynamic frequency scaling on system performance and throughput can be effectively measured and verified using this simple approach.

Stay tuned for more...
Neyaz Khan

Guest Blog: The RF Challenge In Portable Designs

rgoering — Mon, 13 Jul 2009 13:00:00 GMT

The need for RF integration in consumer electronics presents some tough challenges, says veteran electronics industry editor John Donovan. He notes several emerging approaches that might help ease the challenge.

In simpler times most designs were digital. Add a few converters to handle I/O and you could ship the product. Consumer electronics—and cell phones in particular—changed all that. Now there are few consumer designs that don’t involve a large analog/mixed-signal component as well as multiple RF chains. Adding a few ADCs and DACs to the signal path isn’t enough; the three worlds are now heavily intertwined.

Digital and analog designs start with some basic differences. Digital designs tend to focus on the time domain, whereas analog designs are more concerned with the frequency domain. Digital designers worry about time delays; analog designers worry about the accuracy of their components, which they can’t change by editing a few lines of code. For RF designers there are no simple components; every resistor has stray capacitance and inductance, and every trace is an antenna. Parasitic extraction hits a whole new level of complexity in RF designs. RF integration is the single biggest challenge for SoC designers and a major headache at the board level, too.

Designing the RF front end for a cell phone involves some serious tradeoffs. The power amplifier (PA) is second only to the display as an energy hog in handsets. Modern handset receivers typically have a sensitivity in the range of -106 dBm. They also need to be able reject a 60 dB out-of-band signal without flattening the front end. The obvious solution is to crank up the power to the front end, since bandwidth and power are directly related—a tough tradeoff in a portable device.

In handsets you’ll also need to provide multiple RF chains that operate on different frequency bands for cellular, Bluetooth, Wi-Fi, UMTS, Mobile WiMAX, GPS and more. Oh, and you want DTV, DAB and FM with that, too? Just finding room on a tiny PC board for a combination of these protocols, each with different antennas operating at different frequencies—or MIMO antennas with multiple data streams—is problematic enough. Keeping them from interacting or radiating spurious signals back into the analog sections of the board is a serious headache. Integrating RF components onto silicon along side analog mixers, filters and LNAs is trickier still.

One way to ease the pain of RF integration is to go digital as quickly as possible. So-called “digital RF” doesn’t really replace a UHF sine wave with a string of bits, but it comes close. On the receive side, direct-conversion receivers combine direct RF sampling with discrete-time signal processing. The RF signal is sampled at the Nyquist rate, converted into packets, filtered, down-converted and fed to the baseband processor. The transmit PA, in one configuration, is a series of digital NMOS switches that feed a matching network. On-chip capacitors smooth the square waves into an RF sine wave that is then fed to the antenna. This approach can cut PA power consumption in half.

The tools to enable designers to simulate and verify an RF/mixed-signal design have only recently started to appear. Traditionally analog designers have used Spice models while their digital colleagues used VHDL or Verilog. Rationalizing the results was at best time consuming. Now we’re starting to see SystemC models that include concurrency, bit accuracy, timing and hierarchy, enabling designers working at the architectural level to do hardware/software co-design, synthesizing and verifying a design down to the silicon. We’re still not to the point where you can go smoothly from algorithmic exploration to netlists, but we’re getting there.

Someday soon analog and RF will no longer be the exclusive turf of grumpy greybeards in corner cubes. They’ll be just two more tools in every designer’s toolkit.

John Donovan

John Donovan is the editor of Low-Power Design (www.low-powerdesign.com), a new on-line publication. He was previously Editor-in-Chief of Portable Design, managing editor of EDN Asia and PR Director at Cypress Semiconductor. He has spent 25 years covering the electronics industry, focusing on semiconductor and wireless technologies. He can be reached at john@low-powerdesign.com.

AOP Discussion on LinkedIn

teamspecman — Fri, 10 Jul 2009 13:00:00 GMT

Hello All,

Last week over in the LinkedIn Design Verification Professionals group, a thread came up in the discussion area regarding support for AOP in VERA. The discussion quickly changed to the benefits of AOP for Verification. Unfortunately, for the user who kicked off the thread, most of the other respondents seemed to only have experience with VERA's limited AOP capabilities and not with the more complete implementation of AOP in e. In case this question comes up at your company (and in case you not already a LinkedIn subscriber), allow me to repeat my reply on the value of AOP in e/Specman below.

Also I forgot to mention this in the original LinkedIn post but added it later. I personally think a great reference on this topic of AOP and e, is the book: Aspect Oriented Programming with the e Verification Language by David Robinson

Enjoy! Brett Lammers

************************ Post to LinkedIn discussion *************************

Hello All,

I just could not resist putting my 2 cents in on this discussion. Not being a Vera user myself, I cannot comment on AOP support in Vera, but I am getting the feeling from the other posts that there may be some limitations especially if it can only be used to layer testcases on top of an existing tesbench.

I would agree with Dean and Igor that a very powerful usage of AOP is to manage testcases layered over an existing testbench. However, at least when using e, I would argue that AOP plays an important role in testbench design also.

As a reminder, (you all probably already know this): AOP (at least as implemented in e) goes beyond OOP in providing the user more flexibility to organize their code modules not only by objects, but also by cross-cutting-concerns (functionality that touches multiple objects in the code set). In verification, these cross cutting concerns can include DUT related functionality such as operation modes as well as verification related functionality like coverage collection or checking. Of course, as Dean and Igor already mentioned, the test itself is a cross-cutting-concern as it configures and constrains many objects within the testbench. However, using AOP in designing the testbench is extremely useful encapsulating object functionality, safely maintaining existing code, and reusing existing code.

In the context of encapsulating object functionality, just like in OOP, it is good practice to go through some planning to organize both objects and their associated concerns into the appropriate modules. This will prevent code that is difficult to read and maintain. In fact, it may even make it easier to read and maintain since there will be additional modularity and encapsulation. If we think about it modularity and encapsulation are really the motivation behind OOP in the first place. AOP just gives you yet another dimension in which to manage your code.

As Igor mentioned, since AOP gives you more freedom to split object functionality across multiple modules it is possible for you to create some incredibly messy code. However, back in the day (over 7 years ago), the Specman team understood this risk, and in partnership with lighthouse customers created what was called the e Reuse Methodology ("eRM"). Today the same eRM concepts for building reusable testbenches in a methodical and organized manner can be found under the OVM umbrella as OVM e. The success of eRM (it's been adopted by 98% of e/Specman customers), and the ongoing growth of Specman usage itself, shows that "structured AOP" is effective for block, chip, and system level verification challenges.

Brief digression: For additional information on OVM and how it applies to Specman/e check out this article and the related discussions:

www.cadence.com/Community/blogs/fv/archive/2008/07/12/why-is-ovm-important-for-specman-e-customers.aspx

What about code maintenance and reusing existing code? Here again, AOP is almost indispensable. By using AOP extensions, users can methodically update an existing environment with concerns that were missed in the initial planning, or are the result of changes that occur later on in the project. This sort of "after-the-fact" manipulation can be difficult in a standard OOP environment and/or if you only hold yourself to strict OOP practices. In the context of reusing existing Verification IP, AOP allows you to configure, control and add functionality to the existing VIP without touching the base code set - hence the reference to "safety" above since you don't have to muck with proven code. This can become critical when sharing IP across multiple projects or groups.

I would also invite you all to check out additional discussions on this subject as well as other related topics here: www.cadence.com/community/posts/teamspecman.aspx

Cheers, Brett

********************************** End Post **************************************

Using A Dual Flop Methodology for Dynamic Power Savings

Design4Life — Fri, 10 Jul 2009 13:00:00 GMT

Imagine this scenario: Your chip is a low power design. You’ve used everything in the book – clock gating, multiple threshold optimization, power shutoff, multiple supply voltages etc. What else can you do to reduce power in your design?

Or, maybe you can’t do power shutoff – the entire device is always on. Maybe you can’t use multiple supply voltages (face it – if you’re already running at 0.8V, how much lower can you go?) But you know you have plenty of random logic, and you know you have to reduce power in your design.

A dual flop methodology could help to furter reduce power in your design. What is a dual flop? It’s basically two flops physically merged into one. Kind of like a multi-bit flop, but in parallel instead of in series. The merged flop will share the same clock pin, but besides that, it’ll have two separate inputs and outputs.

This setup saves dynamic power in two ways: first of all, there is some savings from efficiency by using a common clock pin. In the worst case scenario, the new clock pin will have double the amount of capacitance, resulting in no significant savings, but usually there is some amount of efficiency and the resulting capacitance of the clock pin will not be double the original capacitance of the individual clock pins, but some amount less than that. Therefore some amount of dynamic power will be saved there.

The second way this setup saves dynamic power is in the clock network distribution. For every two flops, instead of the clock network having to route to two individual places, the clock network now only has to reach one location. Therefore, dual flops are more tighly clustered than individual flops, which results in savings on clock distribution net length, and more importantly, the buffers needed to drive the clock distribution network.

So, how much power does dual flop save? It really depends on what kind of design you’re dealing with. For designs with a large portion of random logic, and especially designs where clock power is a significant contributor to total power (e.g. designs with large clock networks or low signal-to-clock switching ratio), using a dual flop methodology will yield better results. Used in the right design category, a dual flops methodology has the potential of saving roughly 10%-20% of total power in the design.

What do you think?

Wei Lii Tan

Things You Didn't Know About Virtuoso: The View From Above

stacyw — Thu, 09 Jul 2009 13:00:00 GMT

A few years ago I bought a wonderful book called "Earth From Above". An amazing French photographer has put together a collection of truly unique aerial photographs of all kinds of unusual natural and man-made landscapes. It's fascinating how different things look from high altitude--sometimes you can hardly recognize what you're looking at. You wonder what that same scene would look like if you were down at ground level. Well, maybe that's not the case when you're looking at penguin poop from space, but you know what I mean.

Okay, you guessed it, as usual, now I'm going to tie this subject into Virtuoso. You see, one of the new assistants available in IC6.1 is the World View Assistant. This handy little widget is activated by--you guessed it--clicking your RMB at the top of your schematic or layout window and selecting "World View". The assistant pops up in the corner of your window with what the manual refers to as a "panoramic view" of your complete schematic or layout.

The yellow rectangle, or "view box", superimposed on the view represents the current design area displayed in the main canvas. You can resize this rectangle using the drag handles on its edges. This will change the zoom level in the main canvas to display the area under the view box. You can drag the view box around to different areas of the design and the main canvas will pan right to that area. Or just click in the World View at the location you want to see and the main canvas go there. And since layouts tend to have just a bit more detail than schematics, the World View Assistant in layout has a menu available on the middle mouse button which allows you to zoom in and out of the World View itself to more easily guide the viewing area.

It's that simple. No zooming in and hitting the arrow keys a zillion times to pan across to where you were going. No "bindkey f", then zoom in over and over again. Just move the little yellow rectangle around and you'll know just where you are.

Bonus Tip: I know we did a whole article on RMB a while back, but did you know that there are some cool things tied to the MMB (middle mouse button) as well? The one I found particularly useful has to do with toggling the direction of pins while you're placing them. Like many people, when I'm drawing schematics, I often find myself placing a whole pile of pins all at once. Some are input, some are output, some are in/out. It's kind of annoying to have to keep popping back to the form to change the direction.

What I didn't know was that clicking Shift-MMB while in the "Create Pin" function will toggle through the possible pin types. Also, just clicking MMB allows you to rotate the pin before placing it (MMB will also do rotation during the "Create Instance" function--very handy!).

I did run into some trouble with this when I was using VNC and I had previously reprogrammed my middle mouse button in Windows, but these functions can be easily bound to a different key or mouse button.

That's all for now. Keep watching this space for more handy features in Virtuoso IC 6.1.

Stacy Whiteman

Q&A Interview: Andrew Kahng Describes What’s New At DAC

rgoering — Wed, 08 Jul 2009 13:00:00 GMT

Andrew B. Kahng is general chair of the 46th Design Automation Conference (DAC) set for July 26-31 in San Francisco. He is also a professor of Computer Science and Engineering (CSE) and Electrical and Computer Engineering (ECE) at the University of California at San Diego. In this Q&A interview, he describes what’s new and notable at DAC 2009 and discusses his expectations in light of today’s economic climate.

Q: We’re in an economic downturn that has severely impacted EDA vendors and their customers. What’s the impact on DAC this year?

A: We see impacts in the exhibition, since that is a reflection of the EDA and design industries. Travel budgets are impacted, so we’re trying to help attendees stretch their travel dollars. On the positive side, the DAC community has really come together to support DAC as the once-a-year meeting place for the industry. Paper submissions were noticeably up this year, especially in the areas of system-level design, low-power design, manufacturability issues, and high-level synthesis. San Francisco is a favorite destination, and the hotel prices are the lowest in years. Also, many workshops and industry groups are meeting alongside of DAC to offer synergies with respect to travel costs.

Q: What’s new and exciting about DAC this year?

A: First, the User Track – by, for, and selected by the users of EDA tools. This is complemented by other timely, design-focused events such as the Virtual Platform workshop and the SoC development-centric Management Day program. Second, the IC Design Central Partner Pavilion, a new area of the exhibit floor that hosts “IC Design Central” –– a cluster of exhibitors from across the semiconductor and electronics design supply chain. Third, the exhibitor forum has expanded due to strong demand. And we’re expecting a large contingent of bloggers and attendees using new media channels.

Q: The User Track is new in 2009. How is it structured, and what’s the basic idea?

A: We’re very happy with how the User Track has come together. Leon Stok of IBM and Soha Hassoun of Tufts University led the creation of this new part of DAC. The core idea is to serve the part of the design community that drives EDA tools. Until this year, the users of EDA tools did not have a dedicated forum at DAC. The User Track addresses this gap – and it really is by, for and chosen by the users of design tools. The 20 committee members represent a who’s-who of design teams and leading-edge methodology.

The User Track this year features more than 80 technical papers and posters presented by designers from around the world who will share their experiences creating today’s most complex chips. Its scope covers the latest innovations in tool use and design methodologies across the entire design process, from system design exploration and embedded software synthesis in the front end, to constraint generation and physical verification in the back end.

Q: What’s especially notable in this year’s keynote presentations and panels?

A: First, we have the Monday afternoon CEO panel with Aart de Geus of Synopsys, Wally Rhines of Mentor, and Lip-Bu Tan of Cadence. I cannot think of a subject more important to the EDA industry than what the CEOs of our three largest companies have to say about the future of EDA business and technology. With new leadership at Cadence, and with all the challenges we face, I believe this is a very timely return of the “CEO panel” to DAC.

On Tuesday and Wednesday, we have two of the most exciting and cutting-edge technology companies – TSMC and NVidia. The speakers – Fu-Chieh Hsu and Bill Dally – have done it all; technology innovation, technology leadership, and business leadership. Thursday afternoon brings a plenary panel on “Green” design and EDA moderated by Wally Rhines of Mentor Graphics. This is the first time that DAC has put together a lineup of keynote and plenary content Monday through Thursday – all available to anyone with an exhibits or conference badge.

Q: How many exhibitors do you expect? How does this compare to previous years?

A: We expect approximately 200 exhibitors, which is very similar to last year’s number. We are very glad that the four largest EDA vendors are all back on the floor, and we’re very excited about the increased presence of exhibitors from across the entire design chain of suppliers. We also have more than 25 new exhibitors this year.

Q: What does the “Exhibits” pass buy?

A: This year, exhibit-only registration gives access to all four days of the exhibition, the keynote sessions, all DAC pavilion and exhibitor forum sessions, plus the new IC Design Central Partner Pavilion. Now that it’s past June 29, passes to the DAC exhibit floor are available for $95 prior to the conference. I should note that attendees can also get free access to the exhibit floor from exhibitors who are providing complimentary passes to their customers. Attendees need to contact their vendors to receive a complimentary exhibit-only registration code to be used during online registration at the DAC Web site.

Q: What do you expect in terms of attendance, and how does that compare to previous years?

A: We’re looking to maintain the level of 3,000-3,500 exhibitor participants, and to have as strong a showing as possible given the economy and budget constraints. There are still nearly four weeks until the conference, and typically it is during these last few weeks that the majority of DAC attendees wake up and register and find their hotel rooms.

Q: What technology themes do you think will be “hot” this year, either on the exhibit floor or in the conference program?

A: Obviously, the tool user perspective will be hot – that means details of design and chip development challenges, and practical solutions. For both vendors and researchers, system-level design, co-design and verification are hot. Physical and chip implementation issues – power management, manufacturability, reliability and integrity, and design closure – are still dominant user issues. Multicore SoC is another obvious topic on the minds of both EDA providers, algorithm researchers, and chip implementers. And in the technical conference we’re starting to see more of a critical mass of activity centered around beyond-CMOS and “nano” – including new memory and interconnect technologies.

Q: With so much information on line these days, why is it still important to attend DAC in person?

A: One answer is that quite a bit of DAC content – whether keynotes, special sessions, or even the conference papers – does not go online right away, or in some cases, ever. But more importantly, DAC is the opportunity for all of us in the EDA industry and the IC design ecosystem to come together once a year. It is the natural location for meaningful dialogue on the latest ideas and the key future directions across the industry. DAC is where the dialogue takes place. I believe that this year it’s even more important than ever that the community meet face-to-face to keep networking, learning, and moving forward.

Further information about the DAC program and registration is available at the DAC web site.

Richard Goering

How to Pick a Synthesis Tool - The Right One for You - Part 2

Team FED — Tue, 07 Jul 2009 13:00:00 GMT

By Kenneth Chang, Core Comp AE, Team FED . In my previous blog , I had written about how "Synthesis matters." Snippet below. <snip> I had a boss that once said that all synthesis tools are same. This guy knew his stuff, been in the industry forever. He said "synthesizing with Tool X may give different results from Tool Y, but once it gets into P&R, it was all the same, P&R will take care of the rest." In a heavy benchmark, I proved him wrong. Synthesis does matter...(read more)

Cadence System Design and Verification at DAC 2009

Ran Avinun — Mon, 06 Jul 2009 15:00:00 GMT

Traditionally in Cadence Marketing there were always two major events you really had to focus on: Sales Kick Off in the winter and the Design Automation Conference (DAC) in the summer. A lot has changed. Starting a few years ago, Cadence added a great deal more: webinars, seminars, segment-specific trade shows, and of course CDNLive! -- all to help you, our customers and users, stay up to date on the latest Cadence technology.Some voices in the past have accused Cadence of "ignoring" the...(read more)

Low-Power Workshop Advances Power Format Interoperability

rgoering — Mon, 06 Jul 2009 13:00:00 GMT

Design teams concerned about managing two different power formats will find some relief July 26, 2009. That’s the date of a Low Power Coalition (LPC) workshop that will present some ongoing work aimed at interoperability between the Common Power Format (CPF) and P1801 (Unified Power Format). The workshop will also unveil a new idea -- an Open Power Data Model that could potentially support both formats.

The user-driven LPC, managed by the Silicon Integration Initiative (Si2), not only oversees CPF but has also defined a reference flow for low-power design and is tackling ESL power modeling issues. That will all be explained at the free workshop, which is scheduled for the Sunday before the Design Automation Conference at the Moscone Convention Center in San Francisco from 1:00 to 4:30 p.m.

One session at the workshop will report plans and goals towards interoperability between CPF and P1801. A summary of the goals can be found in a CPF 1.2 roadmap presentation on the Si2 web site. They include identifying a set of commands and options that can be used in both CPF and P1801, resolving ambiguities bewteen compatible subsets of the formats, and providing name mapping between CPF and P1801 objects.

Qi Wang, senior architect at Cadence and a presenter at the workshop, said the basic idea is to define an interoperable subset of the features supported by both CPF and P1801. “If you keep within that subset, potential issues with interoperability will be minimized,” he said. Further, the subset will make it easier to develop translators between CPF and UPF. Work on the subset is ongoing and may be completed later this year.

Another possible approach to interoperability is represented by a proposed power intent data model and associated API. Called Open Power Data Model, it’s intended to work with the OpenAccess (OA) API and data model. The intent is to allow design teams to build automated low-power flows regardless of the power formats they use.

“The notion is that the formats will become an input/output way to get into the data model, in the same way that LEF/DEF is an input/output format into OA,” said Nick English, vice president of development at Si2. The result? “You’ll get out of the format wars. And you’ll be able to build an entire power-aware flow such that each tool can access the power information using OA.”

Sumit DasGupta, senior vice president of engineering at Si2, described the data model as a “neutral container” that can accept different file formats. But it will take some time to implement. He said that LPC members have been doing a lot of “deliberate thinking” about how to resolve syntactic and semantic differences between the two power formats. Also, the data model doesn’t determine how the tools will actually make use of the power data.

Finally, the workshop will include a presentation about ESL power modeling. LPC’s work in this area follows its publication of a low-power reference flow. The development of the flow exposed a lack of power models, particularly at the system level. A Modeling Working Group was established to tackle the problem. Jerry Frenkil of Sequence Design will present its latest work.

A “what’s next in low power” panel promises to be interesting as well. One topic that’s likely to come up is adaptive power management, in which chips can evaluate the external environment and scale voltage or frequency accordingly.

In addition to the low-power workshop, Si2 is offering a free workshop on DFM challenges at 45 nm and below. That workshop will be held Monday July 27 from 1:00 pm to 3:00 pm at the Moscone Convention Center.

Richard Goering

Another New Blog on e/Specman

teamspecman — Fri, 03 Jul 2009 13:00:00 GMT

Specmaniacs rejoice: there is a new blog centered around verification with e/Specman by Sandeep Gor:

http://digitalverification.blogspot.com/

Team Specman, and we dare say Specmaniacs everywhere, welcome this new resource to the community!

Here are some other e/Specman-oriented sites we know of, and by all means please send us links to any sites that are missing from this list so we can promote them:

* The venerable Specman Yahoo group
http://tech.groups.yahoo.com/group/specman/

* The IEEE 1647 Working Group
http://ieee1647.org

* The Cadence Functional Verification forums
http://www.cadence.com/community/forums/30.aspx

* Avidan Efody's "Specman Verification" site
http://www.specman-verification.com/index.php

* Yaron Ilani's "Think Verification" blog
http://www.thinkverification.com

* e verification by Shivayogi
http://e-verification.blogspot.com/

* OVM World Forums (for OVM e discussions)
http://ovmworld.org/forums/

* JL Gray's "Cool Verification" blog
http://www.coolverification.com

Happy coding!

Team Specman

Industry Standard SystemC is What Designers Want

SteveSvoboda — Fri, 03 Jul 2009 08:00:00 GMT

This past Monday saw not one HLS related announcement but two...this space is really heating-up! Mentor’s Catapult announced support for control-logic design, and clock-gating (to reduce power) and Forte announced a new release with some minor new features. Today, I'll focus on Catapult, since their direction seems the most interesting in my view. Mentor is promoting ANSI-C as their HLS input language with extensions into ANSI-C to create a "lightweight" (and Mentor proprietary...(read more)

Inside Cadence: Food for Charity & Freedom

jvh3 — Thu, 02 Jul 2009 21:48:00 GMT

Earlier today at the Cadence San Jose campus, a charity event was held off-cycle from the regular "Stars & Strikes" charity event series, where this time the focus was on food with a hot dog eating contest to benefit for Second Harvest Food Bank’s "Share Your Lunch Drive".

For more images from the event, click here for an annotated gallery

This event might seem like it's coming out of the blue, but hot dog eating contests are actually a 4th of July holiday tradition. The first such contest was held on July 4, 1916 in Coney Island, New York by Nathan's Famous hotdogs; and this particular contest continues to this day.

Our Cadence contestants didn't threaten the world record of 66 hot dogs eaten in one sitting (OMG!) set in 2007 by Joey "Jaws" Chestnut, since the goal of the contest was speed -- how many hotdogs you can eat in 5 min -- versus quantity. Despite some chicanery by a tricky Viking, our winner managed to down 9 hot dogs and remain vertical. Even better, $525 was raised for a good cause. Many thank yous are due to the ticket buyers, the hearty contestants, as well as the donation of time & materials from our catering provider Guckenheimer.

The winner!

Indeed there is a *delicious* irony here: a benefit to fight hunger that's based on competitive gluttony. (Sorry, some puns are impossible to resist.) I also can't resist tying this event to 4th of July itself: whenever "hunger" appears as an issue, I always recall the famous Norman Rockwell "Freedom From Want" illustration of a traditional Thanksgiving dinner that was inspired by President Franklin D. Roosevelt's "Four Freedoms" speech.

In real sense, this charity event was small step toward providing this particular freedom in advance of a day that's primarily about celebrating freedom in all its forms.

Happy 4th of July!

Joe Hupcey III

Reference links:
Second Harvest Food Bank
http://www.2ndharvest.net/

Second Harvest is conducting a three month campaign called Share Your Lunch. The goal for this campaign is to raise the resources to feed 66,000 children each month this summer. For less than the price of a lunch out, you can feed 20 children. Find out more at ShareYourLunch.net.

Flow? What Flow?

Design4Life — Thu, 02 Jul 2009 21:30:00 GMT

For EDA software, it seems that it takes just as much effort to develop a methodology to use the software, as writing the tool itself. Ask any CAD group or design group that has to develop their own methodology and you can quickly gauge the many challenges in building a flow for your favorite EDA tool.

Why is it so hard to build and maintain a working flow? There are many reasons. First of all, EDA tools change. Updates, revisions, bug fixes etc - all these change the way the tool is used, sometimes incrementally, or sometimes in a drastic way. Secondly, every design is unique in at least a couple of ways. Design requirements (whether it's a low power design, or a 32nm design that needs advanced node capabilities, or both) dictate the necessity of steps needed in the design flow.

EDA companies have all tried to create flow wrappers that cater for every design (similar to a makefile system), but there are challenges in that too - with unique design requirements in each design, as well as ever-changing use models, creating an all-encompassing design methodology system is difficult.

One thing that EDI System has done is not to focus on creating a comprehensive flow wrapper, but a set of "Foundation Flows" that act as a baseline for user-customizable flow scripts. These Foundation Flows are based on a specific need, e.g. a Timing Closure Foundation Flow, or Low Power Foundation Flow, and contain a set of commands that are usually used by designers, in the order they are usually done. Foundation flows are available starting EDI System 8.1.

In your design environment today, how is the issue of flows handled? Is there a central group that handles flow-related issues for design groups? Do you use a makefile system? Or do design teams build their own custom flow for each project? Most importantly, do you think flow management should be provided by the tool? Sound off in the comments section!

Wei Lii Tan
Cadence Design Systems