Cadence Community

What's Good About Optical Wiring On PCBs? See How Allegro PCB Editor Makes This Happen!

Jerry GenPart — Thu, 18 Mar 2010 13:00:00 GMT

This week, I'm taking a brief break from the usual PCB solution/product technical discussions and focusing on a very interesting capability used with the Cadence Allegro PCB Editor product.

You can read all the details from this article - Integrated Optical & Electronic Interconnect PCB Manufacturing in a recent PCB007 update.

Most of you know that my primary focus is the "front end" environment for the Cadence PCB products, so when I learn about PCB board intricacies, sometimes it's a bit more than I can comprehend. Nonetheless, there are key takeaways (that actually make sense to even me!) from the article:

"In the highest speed computers, for communication between the central processor arrays, hard disc storage arrays, and through data routing switches, there is now considerable interest in incorporating high speed "optical wiring," by means of plastic light-guides, within large, metre-scale, electrical PCBs combining optical and electrical interconnections (OPCBs)."
A three-year research project explored methods for the manufacture of optical waveguides within an optical layer laminated into the board and investigated their compatibility with techniques already in use in commercial PCB manufacturers.
Four different polymer waveguide manufacturing techniques were investigated and compared: Photolithography, direct laser writing, laser ablation and inkjet printing.
A large team of university and industrial collaborators worked to adapt existing PCB Design software (that would be Allegro PCB Editor folks!) to incorporate new rules suitable for designing optical waveguide layouts in OPCBs. You can read about all the team member contibutors in the article.
"University College London (UCL), having established waveguide design rules from comprehensive waveguide measurements and modelling, collaborated with Cadence to use their PCB layout software to design complex waveguide interconnection patterns and test waveguide component structures, The waveguide design files were supplied directly or after fabrication of photomasks to all fabrication partners for waveguide fabrication."
UCL was technical leader of the entire project and their research included the modification of Cadence Allegro/OrCAD to enable it to design the novel optically and electronically interconnected PCBs (OPCBs).
"The waveguide design rules were used to design a novel complex optical backplane layout. The end user system industrial partners specified two main requirements for demonstration of a practically viable system: First, the line-cards had to be directly interchangeable (without rotation); so all optical interfaces were designed to face in the same direction and to be identical to each other; second, the line-cards were required to be closely spaced. An interconnection pattern was designed to allow each of several daughter cards to have bi-directional low loss communications to each of the others."
"The optical interconnections were tested by UCL and Xyratex and it was demonstrated that 10 Gb/s Ethernet traffic could be passed error free through each of the waveguides, obtaining open eye-diagrams. This is, to our knowledge, the world's most highly-integrated demonstrator built to date, incorporating connectors to allow daughter cards to be attached and detached at right angles and to be interchanged."

As always, feel free to post your thoughts about OPCB technology.

Jerry "GenPart" Grzenia

SystemC AMS – A New Proposal For Mixed-Signal Verification

rgoering — Thu, 18 Mar 2010 13:00:00 GMT

In an effort driven by European semiconductor companies and universities, the Open SystemC Initiative (OSCI) last week announced the first version of the SystemC analog/mixed-signal language standard, AMS 1.0. Since Cadence is the industry leader in mixed-signal design and verification, and is strongly promoting a transaction-level modeling (TLM) based design and verification flow on the digital side, it's natural that folks at Cadence would take an interest in this development.

The message I get from our mixed-signal team is that while it's too early to speak of any potential support plans, Cadence is watching this development carefully and is seeking to learn more about the proposed standard and its current and future applications. We are reviewing closely the use of SystemC AMS, how it compares to other mixed-signal behavioral modeling approaches, and what the level of customer interest is.

Some background and commentary about SystemC AMS follows.

What it's all about

With increasing analog and mixed-signal content on systems-on-chip, design teams are looking for faster ways to run system-level simulations. They also need to incorporate mixed-signal functionality into system-level design and architectural exploration. Spice and Fast Spice are too slow for full-chip, top-level verification, and even languages like Verilog-AMS can pose a performance bottleneck.

According to the OSCI announcement, SystemC AMS extends the SystemC class library to provide functional modeling, architectural exploration, virtual prototyping, and integration validation for "embedded analog/mixed-signal systems." The extensions are intended to help engineers understand the interaction between hardware/software and mixed-signal subsystems at the architectural level.

A SystemC AMS whitepaper points out that system-level tools such as Simulink are often used for functional modeling but don't target architecture. It adds that Verilog-AMS and VHDL-AMS don't support hardware/software co-design at a high level of abstraction, and that co-simulation that mixes SystemC and Verilog-AMS or VHDL-AMS does not provide sufficient performance.

The whitepaper describes three types of SystemC AMS extensions:

Linear signal flow (LSF) models instantiate signal flow primitives such as adders, integrators, or transfer functions. They require a linear differential equation solver.
Electrical linear networks (ELN) instantiate predefined network primitives such as resistors or capacitors. They also require a linear differential equation solver.
Timed data flow (TDF) models consist of modules that are connected to signals using TDF ports. They accelerate data flow simulation by using static scheduling that is computed before the simulation starts.

The SystemC AMS 1.0 language reference manual (LRM) and associated documentation can be downloaded from the OSCI web site. Meanwhile, a 2009 article by Martin Barnasconi of NXP, OSCI AMS working group chair, provides more detail about modeling formalisms. The article notes support from NXP, STMicroelectronics, and Infineon in addition to several universities.

Questions and commentary

The basic idea behind SystemC AMS is right - mixed-signal design and verification need to move to higher levels of abstraction in order to run much faster. "When we talk about a system strategy, we need to make sure we include analog," said Andreas Kuehlmann, director of Cadence Research Labs. "To simulate any functionality, you need to simulate analog components together with software, processors, DSPs and so on."

There are, however, a number of practical questions, such as what one can and cannot do with transaction-level modeling in the analog world. Another question is what capabilities SystemC AMS might provide compared to other analog modeling approaches for high level design and verification, like Verilog-AMS wreal and VHDL real, and mixed language approaches like the combination of SystemC with Verilog-AMS/VHDL-AMS in a true mixed-signal simulator.

As noted in a recent whitepaper, real number models can represent analog behavior in a digital context, and the Cadence Incisive Enterprise Simulator can then run wreal and real models in a pure digital environment with all the advantages of high performance and metric-driven verification. Virtuoso AMS Designer can deal with mixed-language scenarios including SystemC, Verilog-AMS, VHDL-AMS, and Spice, providing a smooth path down to transistor-level implementation if needed.

So far, most of the push behind SystemC AMS has come from a few large European semiconductor companies, especially NXP, and academia. Now that the standard is out, will the interest extend more broadly? "As part of our interest in system-level analog modeling, this [SystemC AMS] is one of the options we will carefully monitor," Andreas said.

Feedback from analog/mixed-signal designers is very welcome!

Richard Goering

Built-in Message Logging – Part 2 of 2

teamspecman — Wed, 17 Mar 2010 22:30:00 GMT

[Team Specman welcomes back guest blogger, Michael Avery from our Services Group in the UK]

Building on the Part 1 introduction to Specman’s messaging built-in infrastructure, allow me to share some tips on how to programmatically control and scale message display to help shorten your debug time.

First and foremost: please, please, please avoid manually commenting out/in debug messages. While it’s very tempting to use this classic, quick & dirty technique, it’s always a waste of time in the end because Specman makes it very easy to control message viewing in a scalable, automated manner. Specifically, we can control which messages we see or don't see by configuring the loggers as follows:

Via constraints on the logger.
Via Specman commands or message logger GUI
By calling methods of the logger instances.

Additionally, message_loggers also have hook methods which allow us to customise how messages are handled. Consider the following example of a situation that may occur with big environments.

There you are with a large environment and find that you are seeing lots of low level messages that are not relevant to the area you are presently trying to debug. All these messages are simply creating a large amount of noise such that it’s hard to see the important messages relating to your current debug requirements.

Remember that a message request can potentially be displayed by any one of several loggers on the way from the unit that made the message request up through the hierarchy to sys.logger. If we set the message format to "long" then we get more detail about the message which is automatically added by the messaging infrastructure. An example Specman command to do this:

Specman> set message -format=long

So lets say that a message request is made like this:

mytcm() @myclk is { message(T1, LOW, "This is the text of my message"); };

This message will be passed up towards sys.logger. It may or may not get displayed. It will only be displayed if a message_logger has been configured to display messages with the “tag” T1 and a verbosity setting of LOW.

If such a message_logger exists then we will see in the Specman window the message like this:

[55] ENV UNITC (LOW) at line 113 in @msg_log_top in UNITC unit_c_u-@3:
This is the text of my message

So the information we get with message format=long can be described like this:

     [55]              - Time the message request was made
     ENV UNITC - Return value of short_name_path() method of unit which made the message request
     (LOW)          - Verbosity of the message
     line 113 in...  - Line of source code where message request was made
     UNITC unit_c_u-@3 - Unit instance which contained the message() request

We can see where the message request is made but cannot easily see which message logger actually displayed the message.

If we are seeing lots of low level messages we don't want then it is probably because a message_logger is incorrectly configured, but which one? There is no easy way to find this out but we can extend a predefined method of the pre defined message_logger unit. The predefined method called format_message() is called automatically every time a message is to be displayed. We can extend this method to add more information to the message:

   extend message_logger {
   format_message():list of string is also {
        result.add( append( "Logger instance ", me, " displayed this message"));
   };
   };

Now our message request which looks like this:

message(T1, LOW, "This is the text of my message");

..will be displayed like this:

[55] ENV UNITC (LOW) at line 113 in @msg_log_top in UNITC unit_c_u-@3:
This is the text of my message
Logger instance message_logger-@12 displayed this message

Now we have identified the offending logger and can configure it so that we no longer see the messages which are currently irrelevant to us.

Even better: a very useful command option added in Specman 9.2 allows us to recursively turn off messages from some stated point in the hierarchy.

What it does:

Recursively traverse a unit tree starting from the specified root (which is "sys" by default)
Replace, add, or remove the messages specified by the filter on all loggers that are allocated the specified tags

Specman> set message -rec [-root=unit-exp] [-replace|-add|-remove] [-tags=tag-list|all] [filter]

For a more in-depth view of message loggers attend the Advanced Specman Training Course - http://www.cadence.com/Training

Michael Avery
Cadence Services, UK

ARM AMBA 4 Protocol And VIP – A Closer Look

rgoering — Wed, 17 Mar 2010 13:00:00 GMT

ARM last week announced the first phase of its AMBA 4 specification, and Cadence simultaneously released Incisive verification IP (VIP) for the e language and SystemVerilog. So why is ARM releasing AMBA 4, what's in the two phases, and what's in the VIP? To get a closer look at what's in the AMBA 4 specification I talked to Keith Clarke, vice president and general manager of Fabric IP at ARM's Processor Division.

The widely-used AMBA 3 spec has been around since 2003, and it was time for an upgrade, Keith said. He noted that AMBA 4 was developed in conjunction with some 35 partners, including Cadence. A big motivation, he said, is the increase in performance of processor cores, as well as the ability to place multiple cores on SoCs and to support many different functions on a chip.

Additionally, the phase one release that was disclosed last week adds new support for FPGAs. Phase one includes the AXI4, AXI4-Lite, and AXI-Stream protocols. The phase two release, which will be disclosed later this year, will bring in features that will help users develop and program multicore SoCs.

Pete Heller, product line manager for VIP at Cadence, said he is "definitely seeing interest" among the customer base for AMBA 4. "The traditional mobile guys are currently planning their roadmaps for it," Pete said. What's attracting customers, he said, is increased performance, along with a hoped-for power savings.

AXI4 Protocol

AXI4 is an incremental and backwards-compatible update to AXI3 that improves performance and interconnect utilization for multiple masters. It supports burst lengths of up to 256 beats (data packets). Previous support only went up to 16 beats. "We don't foresee ARM processor requests for 256 beats of data, but we do foresee certain types of masters, in certain types of applications, that do need these long transactions of data," Keith said. An example, he said, could be a data interface in a networking application.

AXI4 also adds quality-of-service (QoS) signaling and support for multiple-region interfaces.

AXI4-Lite Protocol

This is a subset of AXI4 designed for communication with simpler, smaller control register-style interfaces. It can reduce the number of wires required to access "peripherals that have simpler needs." While designed with FPGAs in mind, "there is nothing to stop it being used for SoCs," Keith said.

In this protocol, all transactions have a burst length of one, all data accesses are the same size as the width of the data bus, and exclusive accesses are not supported.

AXI4-Stream Protocol

This protocol, unlike AXI4-Lite, is not a strict subset of AXI4. Designed primarily with FPGAs in mind, it aims to greatly reduce signal routing for unidirectional data transfers from master to slave. The protocol lets designers stream data from one interface to another without needing an address, Keith said. It supports single and multiple data streams using the same set of shared wires.

AMBA 4 Phase Two - Simplifying Multicore SoC Design

ARM is not saying much about AMBA 4 phase two now, but the company has noted that it will provide hardware support for cache coherency and message-ordering barriers. By putting more capabilities in hardware, AMBA 4 will simplify multicore programming. Keith said phase two will "have quite a lot of new technology for coping with multi-master systems."

VIP Support

Cadence Incisive VIP support is "really important," Keith said. "Cadence announcing so quickly is really good news for our customers who want to get a start on designing with AMBA 4." Verification IP, Keith noted, is increasingly important because "the complexity of devices has gone up, and people need to know when they attach various design IP blocks together that they are actually talking the same language."

Pete Heller said that the Cadence AMBA 4 VIP is currently available as part of an early access program for customers. It will be in production later in the year. In addition to the testbench VIP that is available today, Cadence will also provide assertion-based VIP for formal verification and transaction-based VIP for system-level verification. The VIP is OVM-compliant and will include the Cadence Compliance Management System (CMS), which supports verification planning and metric-driven verification.

Pete noted that Cadence AMBA 2 and AMBA 3 VIP has nearly a 10 year track record and has been used in well over 1,000 projects, and he said Cadence is regularly working with ARM to ensure the highest quality and to support phase two of the AMBA 4 release with VIP. A Team Specman blog has more details about the AMBA 4 VIP and tells how you can request early access.

Richard Goering

UVM = OVM 2.1: Even Better!

tomacadence — Tue, 16 Mar 2010 17:00:00 GMT

Since I'm not a member of the Accellera VIP TSC, I did not attend the 2.5-day face-to-face meeting held last week in Massachusetts. But with the steady stream of tweets coming from several of those who did attend, I almost felt as if I were there. That experience will be subject of my next blog entry, but for today I want to touch on some of the interesting news from the face-to-face. Perhaps the most exciting was that the group has apparently decided to base its Universal Verification Methodology (UVM) on OVM 2.1 rather than on OVM 2.03 as voted back in December.

This is a welcome move since it adds some important and widely used features to the initial release of the UVM father than delaying them for the future. In fact, I have been vigorously advocating exactly this action for a while. I've also been suggesting that Accellera get UVM 1.0 out as quickly as possible, and then worry about adding major features such as a register-memory package that will require lots of discussion and even more validation. It sounds as if the TSC is on the right path here as well, with a stated goal to get the first UVM release out by the end of April.

As far as I can tell, the TSC has not made a strong statement about the UVM being fully compatible with OVM 2.1 as it exists today and is being used by countless thousands of users. I still think that full compatibility makes sense on order to foster rapid adoption of the UVM when it is released. Despite this concern, based on what I've gathered from the tweets and those who attended, the Accellera VIP TSC seems to have wisely separated a fast initial UVM release looking a whole lot like OVM 2.1 from all the additional features to be added in future releases. That's good news!

Tom A.

The truth is out there...sometimes it's in a blog.

Bringing MEMS Design To The Mainstream

rgoering — Mon, 15 Mar 2010 16:00:00 GMT

Micro-electrical mechanical systems (MEMS) have been around for years, and have found their way into high-volume applications such as automobile air bag controllers, GPS systems, and inkjet print heads. But MEMS devices such as accelerometers, gyroscopes, RF switches and pressure sensors are not as widely used as they could be. There are three limitations to the widespread use of MEMS:

MEMS design typically requires PhD-level experts in areas such as mechanical, optical, fluidic, and package design.
MEMS historically requires specialized process development for each design, and is mostly confined to IDMs who have their own fabs.
Even though most MEMS devices reside within electronic systems, the MEMS design flow has been totally separate from the EDA environment.

As a result, bringing a MEMS product to market today can cost $40 million, and take 4-10 years of development time. Multi-disciplinary teams of experts are required. The biggest growth area for MEMS is in high-volume consumer applications, and long, expensive development cycles won't cut it there.

What's needed is a way to bring MEMS out of the realm of experts working for IDMs, and into the IC design mainstream. Mike Jamiolkowski, CEO of MEMS tool provider Coventor, calls this process the "democratization of MEMS." This will result in a shift from traditional MEMS companies to semiconductor foundries and fabless design houses, and will make MEMS ubiquitous in everyday life, he says.

The democratization of MEMS calls for a more standardized design flow. What's needed is a "Mead Conway equivalent" for MEMS, as Randy Fish, product marketing director at Cadence, puts it. An important part of that flow is the ability to simulate a MEMS device along with the electronic circuitry in the overall system. "MEMS typically don't stand alone," Mike said. "MEMS and electronics interact strongly, and the designs need to be simulated together."

Also important is an ability to import a MEMS device into a schematic, and ultimately into a physical layout, of the entire system. Unfortunately, MEMS designers use 3D CAD/CAE tools while electronics designers work with EDA tools such as the Cadence Virtuoso platform. The handoff from MEMS designers to IC or package designers is mostly manual, requiring the expert handcrafting of MEMS models for the EDA environment.

Coventor's recently-released MEMS+ product takes a different approach. After assembling a 3D design, users can generate a schematic symbol for the Cadence Virtuoso environment, a netlist for the Cadence Spectre or Ultrasim simulators, and a PCell for Cadence Virtuoso layout. The MEMS device can be inserted into the schematic and simulated along with the electronic circuitry. The MEMS designer can view the simulation results in the Coventor 3D environment.

As a result, Mike said, "the handoff to the IC engineer is very simple, very clean." He said Coventor is selling MEMS+ to IC design teams as well as MEMS designers, opening up a new marketplace for MEMS design. Some expertise is still required to build the 3D MEMS device, but the barrier to entry is a lot lower than with traditional MEMS CAD systems, Mike said. An article on the Design Automation Conference (DAC) web site, co-authored by Coventor and Cadence, provides further perspectives about the connection of MEMS development to the IC design environment.

The next challenge is developing standard foundry processes for MEMS. There is some progress. According to Mike, many IDMs have figured out how to develop MEMS processes that can handle derivative designs, as opposed to the traditional "one design, one process" approach. There are also a number of specialized MEMS foundries.

Pure-play foundries are beginning to show interest. In 2008 TSMC announced it would upgrade a portion of its 0.35 micron logic process capacity to MEMS. In October 2009, Cypress spinoff SVTC and TSMC announced a joint development effort aimed at MEMS commercialization. What is ultimately needed is a foundry infrastructure including process development kits (PDKs), IP, and reference flows.

With the right tooling and with foundry support, we may be standing at the threshold of a tiny revolution.

Richard Goering

Built-in Message Logging – Part 1 of 2

teamspecman — Thu, 11 Mar 2010 14:00:00 GMT

[Team Specman welcomes guest blogger Michael Avery, from our Services Group in the UK]

Messaging is important for two main reasons:

It is essential for debugging

It can greatly impact simulation performance

This is why Specman has a messaging infrastructure built-in to provide an easy to use, scalable and efficient mechanism. Furthermore, Specman’s messaging capabilities allow you to do almost anything which you can conceive with messaging: colouring, formatting, rejection, modification, redirection, etc.

The infrastructure uses a predefined unit called a message_logger to deal with message requests. Message requests are made using the message() action. By default, the “sys.logger” message logger is available, where sys.logger will deal with all message actions if you do not specify your own. However, you can and should instance your own message_loggers, where at a minimum I’d recommend each UVC in a testbench should have its own message_logger. In practice, it is very likely that major units like agents and monitors will also have their own message_loggers.

Given this background, here are some message_logger first principals:

When a message request is made, this message is "seen" by every message_logger from the unit containing the message action, through each direct ancestor, all the way up until it reaches sys.logger.

Each message_logger has associated with it a maximum of 2 destinations: the screen and a file.

Each of these loggers may have been configured differently, where some loggers may have been configured to ignore a given message. In the “ignore” case, message requests still get passed on up the chain to sys.logger, but only message_loggers which have been configured to respond to the message will do so; and only if that message request has not already been sent to the same destination by a message_logger closer to the origin of the message request. i.e. the same message request will not be sent to the screen by more than 1 message_logger.

Even if a message logger deals with a message request, it still passes that message request up the hierarchy. This is because that message_logger does not know if a message_logger further up the hierarchy is configured to send the same message to a different destination (for example, a file to which the message has not been sent by another message_logger).

What about the amount of messages and the level of detail required from them? In general, two factors come into play:

Clearly different levels of maturity of verification environment or RTL strongly influence the message quantity & quality. For example, it’s oftern helpful to have lots of detailed messaging early on in the environment bring up and debugging process, then thin it out as the environment matures so you don't have thousands of detailed messages in our logs potentially obscuring important activity.

Verification at different levels of abstraction also influences messaging. While similar in practice to (1) above, in this case as we move from module to system level verification then the messages from the lower level become less relevant. In fact, the system integrator probably does not have enough detailed knowledge of the low level block to make sense of the message anyway. That said, unearthing the roots of a system level bug may require a temporary reactivation of detailed messaging for a particular monitor instance connected to a particular DUT interface.

In the next installment of this series, I’ll share some tips on how to programmatically control message display to help speed your debug process.

Michael Avery
Cadence Services Organization, UK

What's Good AMS Simulator’s Probing? Check Out The SPB16.3 Release!

Jerry GenPart — Wed, 10 Mar 2010 22:30:00 GMT

You'll need to check into the nifty new probe capabilities in the SPB16.3 Allegro AMS Simulator release

These enhancements will improve your experience with analyzing simulation results especially for dense designs.

These features include:

Easy to use pop-up menu for traces
Access to Trace Property and Hide and Show Traces
Customizing auto-rotation of trace color from an enhanced color set
Controlling background and foreground colors of the Probe Window

For more details, take a look at the screenshots and explanations below

Easy to use pop-up menu for Traces

The context-sensitive menu for traces is more usable with all the trace related options grouped together. When you select a trace and right-click, you get the options within context of the trace.

Access to Trace Property and Hide and Show Traces

You can right-click on the symbol for a trace to get the Trace Properties dialog box. This dialog box gives you a range of choices to change color, pattern, width, and symbol for a selected trace. If you have more than one trace, it is now easier to identify individual traces by changing their color, width, or pattern.

You can choose Hide Trace to hide the selected trace. You can then choose Show All Traces to show hidden traces or hide all traces by choosing Hide All Traces. If you right-click on a location other than the trace in a probe window, you can choose Show All Traces to show hidden traces.

Customizing auto-rotation of trace color from an enhanced color set

You can choose to change the default trace colors from the extended list of 145 supported colors. By default, the first trace is green, but you can open the Color Settings tab of the Probe Settings dialog box to specify your own set of colors and their sequence. You must restart PSpice for the settings to take effect.

Controlling background and foreground colors of Probe Window

You can now specify different colors for the background of the Probe window. The default is black. You can also specify the color of the foreground, such as grids and axis lines.

As always, let me know what you like about these new capabilities.

Jerry "GenPart" Grzenia

Signoff-Driven Implementation = Consistent and Convergent = Predictable and Efficient

mikeNaustin — Wed, 10 Mar 2010 17:38:00 GMT

Digital designs are reaching 10's of millions of instances, which makes efficiency of the overall digital implementation and signoff flow critical to ensure predictability in the design schedule. A major stumbling block that can be a real threat to that predictability is iterations between different stages of the design flow. There are multiple reasons why this happens but one that should not happen is because you have two design stages giving you two different answers with the same set of data.

The most common, and likely the most costly, is when your implementation tool disagrees with your signoff analysis or extraction tool. At this late stage in the design flow, fixes are costly and time consuming. Also, how do you know which is right? Did your implementation tool miss something or is your signoff tool too pessimistic?

Adding margin to your implementation tool for timing or power is one way to mitigate this problem but this can be costly in several ways:

Degrades chip performance when timing margins are already tight
Area and power consumption will increase
Makes your optimization work longer and harder to close timing - major productivity killer

The easy way around this dilemma is leverage high-precision tools which use the signoff analysis and extraction engines to drive implementation. This way your analysis results are consistent and convergent throughout the flow and you don't get any surprises at the end during signoff. You can essentially catch problems early in the design process which makes them much easier to fix.

It's for this exact reason that Cadence has integrated our signoff analysis and extraction technologies into our implementation environment. Our production proven signoff technologies - Encounter Power System for power analysis, Encounter Timing System for timing and signal integrity, and QRC for digital extraction are built-in the Encounter Digital Implementation (EDI) System. Since we've done this, our users have seen some major productivity benefits when using the complete solution.

A bonus is that, with this integration, you can also signoff during implementation if you like without going to a separate signoff tool. In fact, we have many customers doing just that at 65nm and above where the number of timing and power runs for signoff are much less. This eliminates the need to re-run your timing and power analysis in a different session or tool. Also, it allows the implementation environment to take immediate advantage of the latest analysis capabilities such as advanced OCV, statistical timing, thermal analysis, technology files, etc. to fix design problems instead of just finding them.

You may be wondering... will this slow me down if I'm using signoff engines at every stage? Actually, in this case an ounce of prevention saves you a ton of iterations. And, with the latest developments in mult-CPU performance and capacity of our analysis and extraction solutions, the flow stages are actually much faster.

In short, you should always be doing implementation with signoff in mind so there are no surprises. Signoff-driven implementation = consistent & convergent = predictable & efficient

Mike Jacobs

Things You Didn't Know About Virtuoso: IC 6.1.4 ADE Enhancements

stacyw — Wed, 10 Mar 2010 14:00:00 GMT

I'm not going to beat around the bush here. I could tell you about all the things that are new in ADE (Analog Design Environment) in IC 6.1.4. I could tell you about the fact that the individual subwindows are now resizeable, rearrangeable (is that a word?), undockable and tabbable (I know that's not a word, but it's fun to say) just like the assistants in the main Virtuoso window. I could tell you that the Parametric Analysis UI has been redesigned. I could also remind you to read my earlier post about all the new features added to ADE in previous IC 6.1 releases.

But I won't. Why? Because there is one new feature in ADE in IC 6.1.4 that tops all the others in terms of fulfilling widespread long-awaited user requests. Dependent expressions. Being able to use the name of one expression in others expressions based on it instead of having to repeat the entire definition of the first expression. No longer do you have to go cross-eyed trying to parse enormous paragraph-long expressions. Break them up into smaller, more sensible expressions and build from there. It's logical, it's intuitive and it's here today in IC 6.1.4.

There is a great video available here in the Cadence Online Support Video Library showing you how this works. I have a favorite example I use in demos. The original expression (which was created in IC 6.1.3) looks like:

((1 - (average((VT("/OUTM") - VT("/INM"))) / ((value((VT("/OUTM") - VT("/INM")) 4.3e-09) + value((VT("/OUTM") - VT("/INM")) 1.23e-08) + value((VT("/OUTM") - VT("/INM")) 2.03e-08) + value((VT("/OUTM") - VT("/INM")) 2.83e-08) + value((VT("/OUTM") - VT("/INM")) 3.63e-08) + value((VT("/OUTM") - VT("/INM")) 4.43e-08)) / 6))) * 100)

Egads! That 33 sets of parentheses (hopefully in the right places), and 7 repetitions of the expression (VT("/OUTM") - VT("/INM")). Not to mention I'm also interested in the values of several of the subexpressions individually (so those will have to be repeated again on their own).

So now in IC 6.1.4 that above expression can be created as:

((1 - (GainDiffAvg / GainDiffErr6Avg)) * 100)

where:

GainDiffAvg = average(GainDiff)
GainDiff = (VT("/OUTM") - VT("/INM"))
GainDiffErr6Avg = ((GainDiff_4p3 + GainDiff_12p3 + GainDiff_20p3 + GainDiff_28p3 + GainDiff_36p3 + GainDiff_44p3) / 6)
GainDiff_4p3 = value(GainDiff 4.3e-09), etc.

Granted, it's still pretty involved, but by breaking up the expression into more manageable bits, it's a whole lot easier to see what's going on (and to make sure you've got it right).

Expressions can be added in any order and can be based on any number of other expressions. No cyclic dependencies, please.

Hopefully, this improvement will help make it a bit easier to create the measurements your really interested in.

Stacy Whiteman

Challenging Misconceptions About Verification Languages

rgoering — Wed, 10 Mar 2010 14:00:00 GMT

One thing I learned from the recent DVCon conference is that there are a number of common misconceptions about hardware verification languages (HVLs). I had a few of these myself. Two provocative and well-attended presentations provided a different way of looking at HVLs:

"Apples Versus Apples HVL Comparison Finally Arrives." Presented by Brett Lammers of Cadence Feb. 24.
"Where OOP Falls Short of Verification Needs." Presented by Matan Vax of Cadence Feb. 25.

Some of the misconceptions identified in these talks are as follows.

Misconception #1: The design language defines the HVL choice

At the beginning of his talk, Brett noted that verification is fundamentally different from design. With design, one is implementing a spec; with verification, one is checking the implementation. Instead of what the device should do, verification engineers are concerned about what the device should never do. Instead of area, timing and power, verification engineers prioritize test generation, coverage, and corner cases.

It thus makes sense that the unique characteristics of verification make HVLs "special," as Brett put it.

An attentive DVCon audience listened to Brett Lammers' HVL presentation.

Misconception #2: Object-oriented programming is the best way to get verification reuse

While OOP facilitates reuse in many software applications, it's not a complete solution for HVLs, Matan argued. His paper explained that verification does not lend itself naturally to classic object-oriented design, and that attempts to insert OOP techniques place an additional burden on programmers. In a video interview in a recent blog by Joe Hupcey III, Matan stated that "what you're doing with the object-oriented mechanism is emulating a different paradigm, and it would be much easier if the language could use that paradigm directly."

As Brett noted in his presentation, OOP allows a modular approach by encapsulating behavior within objects, but verification presents many "aspects" (like checking, coverage, and error injection) that cut across many objects. An aspect-oriented programming (AOP) language like the e language makes it possible to represent aspects as modules of their own. "Verification represents a lot of aspects, and AOP allows you to capture them in a more manageable way," Brett said.

Misconception #3: Verification productivity = simulation runtime

Verification engineers tend to focus on how fast simulators run. But overall project productivity involves more than just simulation speed, Brett noted. If you can shrink the time required to create the verification environment and write the tests, and spend more time, rather than less time, in regression testing, this will provide more time to find and fix bugs.

Brett noted that simulator performance depends on simulation tools and has no inherent connection to the language that's chosen.

Misconception #4: Compiling languages are best and fastest

Compiled languages such as e and SystemVerilog do provide the highest simulation performance, Brett acknowledged. But a language that can be either compiled or interpreted, such as e, provides more flexibility. A mix of interpreted and compiled code may be better for development, and using all interpreted code helps with debugging.

Misconception #5: Legacy VIP means you're stuck with an HVL forever

Not so, Brett said. Cadence has extended the Open Verification Methodology (OVM) to support e and SystemC testbenches and verification IP (VIP) along with SystemVerilog. VIP in these languages can be mixed in a common environment. The Cadence Incisive Enterprise Simulator supports e, SystemVerilog, and SystemC, making it possible to migrate from one language to another.

Misconception #6: One HVL is best for all

Not even the e language, with all its capabilities, is the best choice for everyone. Brett's last slide looked at "which language fits best where." As you can see, there's a place for both SystemVerilog and e.

Cadence's approach is to support both SystemVerilog and e, along with SystemC. Why pick just one HVL when you can offer a choice?

Richard Goering

Photo by Joe Hupcey III

Cadence Community blogs about DVCon 2010

Steve Svoboda: Quiet Before The Storm? And What To Expect at DVCon 2010

Adam Sherer: DVCon: Showcasing The Cadence Passion For Verification Excellence

Joe Hupcey III: DVCon "Day 0" - Quick Report From SystemC Day

Richard Goering: DVCon SystemC Day - Forging A TLM Design/Verification Flow

Joe Hupcey III: DVCon 2010 - Day 1

Richard Goering: DVCon SystemC Day Quandry: Need For Third Party TLM IP

Richard Goering: Lip-Bu Tan Keynote: Rethinking EDA For 2010 And Beyond

Joe Hupcey III: DVCon 2010 - Day 2

Tom Anderson: DVCon 2010 Rocked!

Richard Goering: DVCon Panel: Why Verification Engineers Are "Sleepless"

Joe Hupcey III: DVCon 2010 - Day 3

Richard Goering: DVCon Panel: Three Ways To Minimize Verification Effort

Joe Hupcey III: Why OOP Falls Short For Verification

Richard Goering: DVCon OVM Panelists: Easing The Debug Challenge

VIP Portfolio Extension: New AMBA 4 Protocol Support

teamspecman — Tue, 09 Mar 2010 00:30:00 GMT

ARM-loving Specmaniacs's rejoice: we are now at liberty to announce that we are providing Verification IP (VIP) support for the new AMBA 4 protocol simultaneously with ARM’s introduction of said protocol. Here is the official announcement, which includes AMBA4 and VIP highlights.

What this means in practical terms:

If you have licenses for the Cadence VIP Portfolio (part number "VIP100"), you will receive the AMBA 4 VIP for no additional charge when it goes into production. If you are qualified and willing to be an Early Access user, you will receive it even sooner. To request early access, contact your friendly local AE or Salesperson (or email us an we'll forward the request).

Like all VIP in the Cadence VIP Portfolio, this OVM-compliant UVC has the Compliance Management System (CMS) built-in -- meaning the full set of AMBA4-specific sequences&scenarios, its coverage model, and detailed compliance checks and metrics -- all automagically tracked via a Compliance vPlan -- are all included.

FYI / brief history lesson: the AMBA UVC is easily one of the most popular, time-tested UVCs in the Portfolio. It's in use / has been used by 1,000s of projects, and the code base is one of the most mature pieces of VIP anywhere -- built on almost 10 years of AMBA VIP experience!

Happy verifying!

Team Specman

When Will We Move From RTL to TLM? I Need to Know!

Bob Loblaw — Mon, 08 Mar 2010 18:00:00 GMT

My esteemed colleague, Steve Brown, recently wrote a well-thought piece trying to forecast what it will take to move the bulk of design from RTL abstraction to transaction-level modeling (TLM). He uses the gate-level to RTL migration as a reference point so that we can learn from history. He lists a lot of factors that enabled the mainstream shift from gate-level to RTL, and sketches out a similar list of what would be required to move from RTL to TLM. It's a long list. Having worked in the logic...(read more)

Q&A: New Challenges, New Solutions In IC Implementation

rgoering — Mon, 08 Mar 2010 14:00:00 GMT

Advanced nodes are raising tough new challenges for analog/mixed-signal and digital IC implementation, according to David Desharnais, group director and product manager for implementation at Cadence. In this interview, he notes where IC designers are struggling and succeeding, and describes Cadence's 2010 strategy to help make customers more productive and profitable.

Q: David, what does your job at Cadence involve?

A: Every day I get to work side-by-side with the sharpest minds in the world of electronic design - people who are working on designs and design solutions for the biggest, most complex chips on the planet, which ultimately find their way into the coolest products and gadgets that change the world in which we live. I get to be in the center of all the action, with customers, R&D, field operations, and partners - right where I want to be.

Officially, I lead product management and marketing for our digital, full custom, and analog design, implementation, and signoff verification offerings.

Q: What are the biggest customer challenges in IC implementation?

A: When you clear away all the fancy jargon and speak in everyday language, there are really two main things designers and their companies are concerned about today - how to be more efficient and effective in the design of their chips, and how to make the most money from the chips they choose to make. Simply put, it all boils down to productivity and profitability in the end.

Companies are making fewer but significantly bigger bets on the designs they target. It used to be that companies would do 10-12 SoCs, hedging with the expectation that only a handful would have reasonable-or-better market success. Today these same companies are only targeting 2-3 SoCs, and it has become a very expensive proposition. The success or failure of these SoCs can mean the success or failure of the enterprise itself.

As a consequence, these 2-3 designs are insanely large and complex - from the loads of functionality that has to be shoehorned onto them, to the advanced process nodes used to hit aggressive area or performance targets. Getting to the point where you have the most competitive and differentiated die-size, performance, power, and yield for an SoC is a Gordian Knot that somehow engineers need to find a way to cut through.

For the implementation engineers, it's a really crazy time. The shrinking of process nodes and the sheer number of gates they have to deal with on a single SoC can really throw a wrench in the works if they aren't prepared for it. New and more severe factors come into play that design engineers traditionally didn't have to worry about, like how to architect the clocks when the size of the chip requires 2-3 clock cycles to traverse it, or how to optimize interactions of multi-mode, multi-corner timing, power, signal integrity, and DFM [design for manufacturability] in parallel. Optimizing these things sequentially becomes a whack-a-mole situation.

Then there are things like how to deal with parasitics from the board and/or package and how they impact the silicon and vice-versa...and who's going to make sure that all the team members are compliant and aligned. The list goes on, but it comes down to about a 10X increase in complexity for each major node transition.

Q: Does this complexity call for a higher level of collaboration?

A: I would say there is a bit of a paradox happening right now. To improve productivity, collaboration is vitally important. However, the harder the problem or challenge, the worse the quality of communication seems to be. You would want the opposite to be true to solve problems in a more cohesive way. But, when you have a team in Texas and a team in India and a team in Europe all working on various blocks of an SoC, it is non-trivial.

Things have to be done differently than in the past. Flows have to be very coordinated, unified standards must be applied, and full transparency is needed across all the pieces. Otherwise what you have is inefficiency and waste. Complexity has compounded in a very systematic way.

Q: What is Cadence's strategy for helping customers with productivity and profitability?

A: To reign in the productivity crisis, we need to help engineers harness complexity. One approach we've taken is through recommended design flows and methodologies we call Foundation Flows. Our approach is to bring downsteam intelligence up front in the design process and to provide tight linkages, out-of-the-box scripts, and visibility from the system level all the way down to final silicon. Besides integration, we are also focused on establishing better handoff points across the flow, data abstraction, and overall simplification - like reducing the number of keystrokes or decisions that designers have to make in the course of a design. All this is done so designers can move their low-power or mixed-signal SoC to the next process node with as few barriers as possible.

When it comes to profitability, our focus is to help customers create the most differentiated silicon possible, getting them to market in a predictable manner, and achieving the highest-yielding parts. For example, when we help a customer gain an extra 3-4 points in yield on a high volume part, by showing them how to optimize for DFM and yield right there in the design cockpit well before silicon, this can make multiple millions of dollars in difference to their top-line revenue, and it carries straight through to their bottom line profitability.

Design cycles that used to be 18 months or 2 years are 6 or 9 months now. And the silicon has to work and work well. If you miss the window, you miss it completely.

Q: What are you seeing in terms of adoption of advanced nodes? Are customers moving on or staying put?

A: We see a cautious approach by the industry. The bulk of the market is still at 130 nm or 90 nm, but definitely people are starting to move. Every conversation I have with customers today includes advanced nodes and DFM - 40 nm or 32/28 nm, and more recently even 20 nm. These kinds of designs can run into the $60-$100 million range, so there is a definite gut check that happens before taking the plunge.

Customers want to know what to expect in terms of additional overhead they have to take on, compared to the benefit they hope to get. On top of this, they have to find enough of a market to give them upwards of 80 million units to support that kind of investment. This kind of volume typically means consumer, which also means advanced node, mixed-signal and low power. Companies serving the consumer market are the trailblazers as you might expect.

Q: There's been much talk about 3D ICs with TSVs [through silicon vias]. Are you seeing customer interest, and if so, for what types of applications?

A: Yes, definitely. It's a very exciting area. Customers are producing test chips and production designs with TSVs already, and we have had longstanding partnerships with foundries and heavyweight customers in this area going on for 3 years now.

3D itself is not new. It's been done for years. However, 3D with TSV is new and the projections for growth in this area are high. A key driver is that a 3D IC gets you a better form factor than a traditional side-by-side SiP, and brings significant advantages in performance, low power, and time-to market. A 3D IC approach also lends itself very well to design reuse and derivative designs.

Consumer electronics, wireless communications are by far the heavy users for 3D ICs, but we also see customers in other applications, such as bio-medical devices and automotive, moving to this technology now.

Q: What's been successful with low power design, and what remains to be done?

A: We have made great strides in low power, and we very much pioneered low power automation for the EDA industry. Every piece of our flow entirely supports and comprehends Si2's CPF [Common Power Format] today, and over the past two years we've seen literally had several hundred designs tape out using the Cadence Low Power Solution. Along the way, we established mature, high-quality support for the various low-power techniques in broad use in the industry, and we have automated advanced low-power techniques like multiple supply voltages, multiple power domains, power shutoff, dynamic voltage and frequency scaling, and disjoint power domains as some examples.

Going forward our objective is to extend our leadership in low power, and we'll provide even more aggressive innovations like mixed-signal, variation-aware low power support, and enhanced thermal analysis.

Q: How will Cadence move forward on mixed-signal SoC implementation?

A: This is a core strength for Cadence. We have the technology, flows, expertise, and a significant user base that has been taping out these kinds of designs for over 20 years, and we continue to set the pace for new developments. We handle all aspects - design, verification, and implementation of mixed-signal SoCs.

With our latest release of Virtuoso [IC6.1.4] alone, customers are seeing upwards of 30% improvements in productivity. But mixed-signal design is not just about analog or full-custom design -- it requires strong digital technology as well. And the convergence of our digital [Encounter] and analog [Virtuoso] platforms drives many new opportunities for efficiencies across a mixed-signal flow. Things like mixed-signal floorplanning, block and chip-level electrical analysis, substrate analysis, late-stage ECOs, unified constraints, and usability become very straightforward when you integrate the analog and digital design, implementation and verification worlds together. That is very important for our customers and the industry overall.

Q: There are some new competitors in the analog/custom space. How will Cadence maintain its lead?

A: We are experts when it comes to analog and full-custom design, and we got this way from working with leading edge companies around the world to achieve technology breakthrough after breakthrough for well over 20 years. Every significant design in the world today uses Virtuoso. We have taken this experience and have folded this knowledge into our tools. We never stop innovating here. It's in our DNA.

For example, we recently reinvented our entire analog/full-custom suite of tools from schematic capture, environment, layout, automatic routing, and chip-finishing with Virtuoso 6.1, and customers are experiencing a massive difference in productivity and capability right out of the box. There is a lot you can do when you know everything about the transistor -- how to build it, model it, simulate it, and connect it, particularly in the context of mixed signal SoCs. We also constantly track flows and metrics with our major customers and use the results to further enhance productivity and the user experience.

Competitors will have to walk before they run. If customers want a place to walk, okay - but we're light-years beyond that, and from what we see, designers cannot afford to erase a decade of advancement in analog/full-custom design automation, even if it is free.

Q: Cadence recently announced Encounter 9.1. What's special about that release?

A: Last year we introduced a completely re-architected digital implementation product line called Encounter Digital Implementation [EDI] System. This has really been a hit with customers. Our newest release of EDI System - 9.1 - builds on this very high-capacity, multicore, integrated infrastructure, and adds much more.

We consider EDI System 9.1 to be our "productivity" focused release, bringing higher capacity, performance, and usability, along with a full suite of integrated signoff capabilities for timing, signal integrity, power, extraction, and DFM. Heck, even the user-interface has been completely rebuilt from the ground-up and now adds many analog-style capabilities to address the requirements of very sensitive, high-speed clocks and signal nets that take on more and more analog characteristics as the process nodes shrink.

In EDI System 9.1 customers will find that we've built manufacturing and signoff intelligence into what a designer does by default, so the quality of results are significantly better. Also there is some very exciting technology around design exploration and automatic floorplan synthesis. Not only can a designer can give the tool some criteria, and it will automatically build a good floorplan that attempts to meet the criteria -- it will actually leverage our multicore backplane to automatically create multiple permutations of floorplans, and rank and rate them from best to worst based on the criteria set. Our customers tell us that this capability alone can take months off of the time it normally takes to arrive at an optimal floorplan. Now that's what productivity is about, right?

Q: What do you see as the most exciting trend in implementation right now?

A: I think the most interesting trends are in 3D-IC and in the bringing together of analog and digital design to make mixed-signal SoCs.

A good friend told me once that doing analog design is like doing surgery. The surgeon has to do it all very hands-on, methodically, and precise, and take the time to get it right. Improvements come in the form of new tools, and better methods to drive more efficiency and performance without sacrificing the quality. Conversely, doing digital design is like being a race-car driver - it's all about performance, timing, and breaking all the rules you have to, in order to get to the checkered flag. As process nodes shrink the racetrack turns from a nicely paved road to a bumpy dirt road. Improvements come in the form of absorbing the shocks and putting on meatier tires and heartier equipment, and tweaking the driving style to still win the race.

If you follow that analogy so far, then the punchline is that designing today's mixed-signal SoCs is like asking that surgeon to jump in the racecar and do surgery while going 200 mph down a bumpy dirt road. It's a problem the customers are trying to solve. Design, implementation and verification across analog and digital boundaries can be tripping points for customers. The most exciting thing for me is the opportunity to tie all these together.

Richard Goering

Have You Considered e Lately?

tomacadence — Fri, 05 Mar 2010 14:00:00 GMT

Richard Goering's recent interview with Mitch Weaver on the future of Specman and e put me in a reflective mood about my own evolving opinions. My hands-on experience with Specman is minimal; back in my 0-In applications days I co-developed a joint demo with Verisity (prior to acquisition by Cadence) in which I had the chance to do a bit of e testbench coding. I was very familiar with formal at that point, but it was my first exposure to constrained-random simulation and I was impressed.

Six months later I was working at Synopsys, where I was deeply involved in their SystemVerilog rollout. My impression there, based largely on the fact that I talked almost exclusively to SystemVerilog and Vera users, was that e was dead or dying. Fast-forward a couple of years, and I joined Cadence. I can honestly say that nothing I have seen or learned in my time at Cadence has surprised me as much as finding out as soon as I joined just how powerful and popular e really is.

Mitch does not overstate reality at all - Specman and e continue in very broad usage with very few users switching to SystemVerilog and, in fact, new projects and new companies signing up every year. Of course, by now I've had the chance to talk to many e users and I understand how its technical advantages fuel their passion for the language. It's nothing against SystemVerilog to acknowledge that e has some unique features for advanced verification; it's a simple statement of fact.

However, I do talk to the occasional customer who is "e-lergic" (an old Verisity term) and who doesn't even want to hear e mentioned. Some are actually suspicious that our support for e somehow compromises our support for SystemVerilog! As Mitch explains in the interview, this is simply not the case. We support all IEEE-standard languages equally well, and enable just about any combination of e, SystemVerilog, and SystemC models in customer verification environments.

Since there are such strong opinions about e out there, I'm frankly surprised that there have been no comments on Richard's interview. I'll try for some response here since I'm quite curious to know what all you testbench developers really think. If you're unwilling to consider e, I'd like to know why. If you have an open mind on verification languages but didn't choose e, I'd like to know why. If you did choose e, I'd still like to know your reasons. So ... have you considered e lately?

Tom A.

The truth is out there...sometimes it's in a blog.

DVCon OVM Panelists: Easing The Debug Challenge

rgoering — Thu, 04 Mar 2010 14:00:00 GMT

The good news about the Open Verification Methodology (OVM) and the advanced verification techniques it supports is that verification engineers are now finding more bugs than ever. The bad news is that the bottleneck is shifting to debugging. What are we going to do with all those bugs? User and vendor representatives grappled with that question at a Cadence-sponsored lunch panel at DVCon Wednesday, Feb. 24.

Moderator Mike Stellfox, principal verification solutions architect at Cadence, noted that OVM and techniques such as constrained-random test generation have dramatically shortened the time it takes to build a testbench. "We're finding a lot more bugs than we could with traditional directed-test approaches, but now we're getting more bugs than we can debug in a timely manner," he said. In a recent Cadence survey, he noted, advanced verification users said that debug now takes about 50 percent of the overall verification effort.

Panelists (left to right in the photo below) included Steve Jorgenson, verification specialist at Hewlett-Packard; Jerel Canales, design verification manager at Zoran; Stellfox (at podium); Umer Yousafzai, solutions architect at Cadence; and Alicia Strang, principal verification engineer at Marvell. Yuchin Hsu, vice president of R&D for verification products at Springsoft, was also on the panel.

Panelists pondered debug challenges at an OVM lunch at DVCon.

With an emphasis on the user presenters, here are several perspectives that I thought were interesting.

How OVM helps with debug

"We find that OVM is very useful," said Strang. "If you just use that methodology, and use the naming conventions, everybody is on the same page." Canales noted that easier debugging is a key OVM benefit. He said that the "limited scope of issues" in testbenches that are all built to the same methodology makes it easier to find bugs.

In a conventional directed-test environment, Yousafzai said, users spend a lot of time debugging test stimulus. In OVM, which supports up-front planning, users spend less time tracking down problems in the testbench and more time finding bugs in the design. Jorgenson noted that OVM supports higher levels of abstraction, and said that "I really think abstraction is what will save us in the end from our debugging problems."

Testbenches need debugging, too

Jorgenson commented that verification teams can easily spend half their time just debugging problems in the testbench. One antidote is to move up in abstraction and reuse as much as possible from previous verification environments. Strang had another suggestion. "In a modern software environment like a testbench, you can do whatever you want. Keep it simple, and you can avoid a lot of bugs in the testbench."

Constrained-random stimulus may obscure bug causes

When a bug is found in a directed-test environment, Jorgenson said, a designer can very likely help identify the root cause. But with constrained-random techniques, "you don't always know what the test did. One thing we've had to do is go in there and get the test to tell us what it did."

Specman: Don't just load and compile

Canales observed that many new engineers load and compile an entire Specman run, not realizing that the e language makes incremental changes possible. There's no need to recompile everything when a change is made. "Hardware verification languages should allow you to very quickly make changes to the testbench, and get feedback, without having to recompile," he said.

Assertions are important

Zoran verifies video frames with a great deal of data, and achieves a "tremendous benefit" with assertion-based verification, Canales said. If written properly, he said, assertions will cause the simulation to stop right away. Strang noted that some kinds of bugs can be found only with assertions. These include bugs that do not affect data. "If it's data in, garbage out, I know it's wrong, but if it's data in, data out I don't see anything wrong," she said. Jorgenson said his group has been using assertions for 8 or 9 years, long before SystemVerilog assertions were standardized.

Yousafzai told of a customer who ran a single test 30,000 times on a block, and still had to do a respin because all these tests couldn't find a "trivial" bug - a signal that wasn't toggling correctly under some conditions. He noted that simple assertions that can be added easily are often the most effective ones.

How to find software bugs

Strang uses transaction monitors that generate waveforms that show what firmware is doing in parallel with hardware signals. From this, she said, "I can tell whether software issued a wrong command, or hardware is behaving incorrectly."

A conclusion

As I noted in a blog last year, based on part on an interview with Mike Stellfox, the bug diagnosis-and-repair cycle is becoming the biggest bottleneck in the verification flow. If debug really takes 50 percent of the verification effort - and verification takes 60 to 70 percent of the total design effort, as we've repeatedly heard - do the math and you can see this is an area that deserves far more attention. The OVM lunch panel was thus a very timely event.

Richard Goering

Running Incisive on Ubuntu Linux

jasona — Thu, 04 Mar 2010 14:00:00 GMT

Ubuntu is by many accounts the most popular and the easiest to use Linux distribution for the desktop. Unfortunately for Linux enthusiasts, Cadence tends to follow the EDA Industry OS Roadmap when selecting operating systems to support. I would guess that it's a fairly common problem that users don't want to use one of the two primary Linux platforms, Red Hat Enterprise Linux (RHEL) or SUSE Linux Enterprise (SLES). Most of the time it's because these are not easily available. From time...(read more)

What's Good About Capture’s Auto-Wiring? You’ll Need The SPB16.3 Release to See!

Jerry GenPart — Thu, 04 Mar 2010 08:47:00 GMT

Just a brief post this week to highlight one of the new SPB16.3 features in Allegro Design Entry CIS.

In complex designs containing a large number of parts, the task of wiring the parts together is often a time consuming and tedious task. Wiring multiple pins to a bus can also be a tedious and repetitive task. Capture now includes an Auto-Wiring feature that allows you to wire two or more pins or wires on your schematic page.

There are three (3) modes in which Auto Wire will work:

Connect two points
Connect multiple points
Connect to a bus

For more details and screenshots, read below.

Connect two points

To wire two points on a page (pin-to-pin, pin-to-wire or wire-to-wire).

1. From the Place menu, choose Auto Wire then choose Two Points as shown in the screenshot bellow:

Or click the Auto Connect two points button - - on the Draw toolbar. Capture is now in the Auto-Wire mode. Notice the cursor changes to the Auto-Wire cursor.

2. Click the pin or wire to start the net. As you move the cursor across the page notice a wire (from the start pin or wire) is formed. The wire stretches as you move across the page.

3. Click the pin or wire to end the net. A wire is created between the start and end points.

4 Choose the selection tool to exit the Auto-Wire mode or go back to step 2 to Auto-Wire other pairs of pins and wires on the page.

Connect Multiple Points

1. From the Place menu, choose Auto-Wire then choose Multiple Points.

Or click the Auto Connect multiple points button - - on the Draw toolbar. Capture is now in the Auto-Wire mode. Notice the cursor changes to the Auto-Wire cursor.

2. Click the pin or wire to start the net.

3. Click the next pin or wire on the net.

4. Continue to click on as many pins or wires as required to create the complete net.

Note: Since you are in the Multiple Point mode, you do not need to press the Ctrl key to multi-select points on the page.

5. Finally, right-click anywhere on the schematic page and choose Connect.

Connect to Bus

1. From the Place menu, choose Auto Wire then choose Connect to Bus.

Or click the Auto Connect to Bus button - - on the Draw toolbar. Capture is now in the Auto-Wire mode. Notice the cursor changes to the Auto-Wire cursor.

2. Select any number of pins and/or wires to be connected to the bus.

Note: Since you are in the Connect to Bus mode, you do not need to press the Ctrl key to multi-select points on the page.

3. Select the bus. As soon as you select the bus, the wire connections between the selected points on the page and the bus are created. Notice that the bus entries for these connections are also made. When all the connections to the bus are made, you are prompted for the net alias. This net alias will be used for all the connections to the bus. You need to provide an alias name prefix followed by a numeric range in square brackets so that each net alias in the connections will use a name prefix followed by the sequenced numeric value. Take the example of the following alias name prefix and number range:
AD [9-0] - the net aliases will be named AD9, AD8, AD7 through to AD0.

4. Enter the net alias name prefix followed by the numeric range. All the connections to the bus are complete along with the number sequenced net aliases.

As always, I'm interested in your feedback on how you've adopted this new feature in constructing your schematics.

Jerry "GenPart" Grzenia

Why OOP Falls Short For Verification

teamspecman — Thu, 04 Mar 2010 01:30:00 GMT

Last week at DVCon, frequent Team Specman guest blogger Matan Vax of R&D gave a paper on "Where OOP Falls Short of Verification Needs". In the following video, Matan elaborates on his paper, where it becomes clear that OOP languages like -- well, you know -- are at an inherent disadvantage vs. AOP approach (like in e) when it comes to the unique requirements of verification.

Click here if the embedded video doesn't play.

Joe Hupcey III for Team Specman

Things You Didn't Know About Virtuoso: Thumbnails

stacyw — Wed, 03 Mar 2010 14:00:00 GMT

Boy, you must think we're a few sandwiches short of a picnic over here at Cadence.

A couple of months ago we came out with this great new Virtuoso software release (IC 6.1.4). So, despite my best efforts to get you to use the recently-opened files list or to create bookmarks, the first thing you did after starting virtuoso was open the Library Manager. (Don't try to deny it, I know you did...).

So there's the Library Manager with your libraries all neatly grouped and color-coordinated, and down in the lower right corner of the window, there's now a little black square. You say to yourself, "Wow, that's the one new feature I was hoping for in this new release...a little black square in the corner of the Library Manager. Thanks, Cadence!". (Actually, you probably thought something not so suitable for a family-friendly blog such as this.)

Well, before you run off and start tweeting all your friends about how Cadence has had another brain fart, read on a bit and let me tell you how to unlock the magic of that little black box.

Thumbnails, my friends. Thumbnails are the wave of the future. And thumbnails are what that little black box is for. But first you've got to create them and that's why the box is empty right now.

So, to create thumbnails for the cellviews in your library, just RMB over a library name or a cell name or a schematic, symbol or layout view name and select "Update Thumbnails" (or select Edit->Update Thumbnails from the main menu).

Now the little box will contain a small image of the cellview so you'll know it's the right one without having to open it. These thumbnails will also appear when you use the File->Open... form to browse for a cellview.

So, now that we've begun exploring the wondrous diminuitive world of thumbnails, leave a comment to let us know where else you think thumbnails might be useful in the future...

Stacy Whiteman

Analog Behavioral Modeling - What Language Do You Speak?

MS Guy — Tue, 02 Mar 2010 14:00:00 GMT

An increasing number of mixed-signal design teams are contemplating adding analog behavioral modeling to their repertoire in order to achieve reasonable simulation speeds. Utilizing analog behavioral models can yield simulation performance improvements that can make full chip verification a reality. This approach can be several magnitudes faster than transistor-level; however, the actual performance improvement is greatly dependent on the level of detail in the model, as well as, the language of choice. Analog behavioral models are generally written in one of the languages below:

Verilog-AMS – A derivative of Verilog, it includes analog and mixed-signal extensions in order to define the behavior of analog and mixed-signal systems, providing both continuous-time and event-driven modeling

Wreal – An extension of the Verilog-AMS modeling language allowing analog block operation as a real data flow model

Verilog-A – An extension of Verilog to describe analog and non-electrical behavior as a continuous-time subset

VHDL-AMS (IEEE1076.1) – similar in concept to Verilog-AMS, providing analog and mixed-signal extensions in order to define the behavior of analog and mixed-signal systems

One of the biggest challenges in the creation of analog behavioral models is; whose job is it? The analog designer is the most familiar with the circuit performance and specific behaviors, however, many analog designers typically are not programmers and familiar with the languages mentioned above. The digital designer, who also tends to be the full chip verification engineer, is most familiar with programming languages, but lacks the analog specific circuit knowledge. Therefore, a blend of both skill sets is required or a conscience effort for both designers to work together. One must continually make the tradeoff of effort versus benefit when deciding to create an analog behavioral model. Some of the questions that come to mind are: Can I re-use it? How long will it take me to create a high quality model? What performance gains can I expect?

Finally, as you consider adding analog behavioral modeling to your design repertoire; consider your modeling goals and language. A performance model needs to capture specific circuit behavior and can affect your effort versus benefit equation, while a functional model requires you to only capture the 1^st order effects that are needed to verify the circuit functionality. Model On!

Greg Curtis

DVCon Panel: Three Ways To Minimize Verification Effort

rgoering — Tue, 02 Mar 2010 14:00:00 GMT

With verification taking up more and more of the design cycle, is there any hope that verification will keep up with escalating design complexity? Yes, according to panelists at the DVCon conference Thursday Feb. 25. From the discussion, I distilled three basic approaches to improving verification productivity:

Raise the level of abstraction for verification and design
Apply more intelligence throughout the flow, at every level of abstraction
Educate new engineers for real-world design and verification challenges

Verification consultant Brian Bailey, panel moderator, started the discussion on a hopeful note. "We've muddled through a 16X increase in design complexity since 2004, and we're not in verification hell," he said. "We're obviously doing an awful lot right." But how, he asked, will we survive another six years and another 16X increase in design complexity?

1. Raise the level of abstraction for verification and design

Perhaps the most obvious way to improve verification productivity is to move to a higher level of abstraction. This means less code, fewer bugs, easier reuse, and faster simulations. Indeed, as I reported in an earlier blog, Bailey spoke about the advantages of a SystemC transaction-level modeling (TLM) based flow earlier at DVCon.

Panelist Ran Avinun, marketing group director for system design and verification at Cadence, noted that the transition from gate level to RTL began 15 years ago. "We see the same thing happening right now with SystemC," he said. Moving up in abstraction, Avinun noted, makes it possible to separate functionality from constraints and leverage high-level synthesis.

DVCon panelists included (left to right) Brian Bailey, Ran Avinun, Janick Bergeron, Shawn McCloud, J.L. Gray, and Rajeev Ranjan.

"I'm calling for the death of state-based design," said Janick Bergeron, fellow at Synopsys. "That term includes RTL, and C level synthesis that's barely above RTL." Don't start with states, he said - start with the application, build a corresponding virtual platform, and then bring in synthesis and equivalence checking.

Shawn McCloud, director of high-level synthesis at Mentor Graphics, said that a customer survey showed that verification is the number one reason that people move to high-level synthesis. Moving to a high level not only speeds verification, he noted, but makes it easier to find tricky corner-case bugs.

2. Apply more intelligence throughout the flow, at every level of abstraction

This second point is perhaps more subtle, but is no less important. We can move to a TLM-based flow, but that doesn't mean that RTL and gate-level design will disappear. What's needed, Avinun said, is a "unified verification environment that we can use throughout the flow."

This flow, Avinun said, has three components. One is metric-driven verification guided by an executable verification plan and coverage metrics. Another is the use of verification IP, which he said is "as important, or in many cases more important, than [design] IP." A third is scalable performance throughout the verification process. This is where acceleration and emulation become important.

Rajeev Ranjan, CTO at Jasper Design Automation, noted that formal technology can offer improvements during all phases of the verification flow. In particular, he noted, formal tools can allow a "designer pre-verification" without having to generate a testbench.

3. Educate new engineers for real-world design and verification challenges

A point that was made in a Feb. 24 DVCon panel, and reported in my previous blog, is that universities are doing a poor job of training engineers for the real world of IC design and verification. University graduates need a lot of additional training before they're really useful on design and verification projects, and as a result, are often not hired in today's economy.

J.L. Gray, verification consultant at Verilab, moderated the Feb. 24 panel. As a panelist on the Feb. 25 panel, he noted that "the thing I've realized about the advanced verification techniques we need to move forward is that a very large majority of engineers don't have the skills to take full advantage of these techniques."

"The lack of educated people for design and verification is a big challenge," Ranjan concurred. He talked about graduating from U.C. Berkeley in 1997, and noticing that fewer students and professors were involved in IC design and verification.

"If training is one of the biggest issues, we've got to fix the educational system," Bailey said. That's a tall order. As I wrote last year, the Cadence Academic Network is one attempt to bring real-world relevance into university education. The time has come for an industry-wide discussion of this issue.

Richard Goering

Photo by Joe Hupcey III

DVCon 2010 - Day 3

jvh3 — Tue, 02 Mar 2010 14:00:00 GMT

Click here or on the image below to go to the annotated photo blog of DVCon 2010 Day 3.

The images and notes include highlights from:

A paper on "Where OOP Falls Short of Verification Needs" (And there is also a video interview of Matan elaborating on the paper

The paper "Tweak Free Reuse With OVM"

A paper on "Mixed Signal Verification of Dynamic Adaptive Power Management in Low Power SoCs"

The closing panel "Ever Onward! Minimizing Verification Time and Effort"

I also had the pleasure of interviewing one of our long time Verification Alliance partners, AMIQ, in their first appearence at DVCon (yes, they are growing even in these tough times!). In this video, their director of marketing Corina Mitu introduces their company, their "OVM aware" integrated device environment "DVT", and some new announcements ...

If video fails to launch click here.

Last but not least, my colleague Richard Goering has been writing detailed articles on the main keynote and panel sessions.

Enjoy!

Joe Hupcey III

DVCon Panel: Why Verification Engineers Are “Sleepless”

rgoering — Mon, 01 Mar 2010 14:00:00 GMT

I view a panel as successful when I leave the room knowing more than when I came in. Such was the case at the "What keeps you up at night" panel at DVCon Feb. 24, which offered some interesting, provocative, and in several cases surprising perspectives about challenges and solutions in IC design and verification.

Moderator J.L. Gray, verification consultant at Verilab and author of the Cool Verification blog, said the purpose of the panel was to "let people purge, get things off their chests, and have a good discussion to see what kinds of solutions we can come up with." While previous DVCon "Industry Leaders" panels included EDA CEOs or representatives, this year's panel was very different. Participants were:

Steven Gary, vice president of professional services at Numetrics Management Systems, a provider of enterprise software tools for IC companies.
John Goodenough, worldwide director of design technology at ARM Ltd.
Sheela Pillia, senior manager of process, circuit and technologies at AMD.
Jim Crocker, vice president of engineering at design services firm Paradigm Works.
Victor Melamed, director of engineering at digital media device provider Ambarella.

Following are some of the conclusions I found most interesting.

The "What keeps you up at night" panel included John Goodenough, Victor Melamed, Sheela Pillia,
Steven Gary, and Jim Crocker (left to right).

Analog models come too late, or are just plain wrong

Pillia noted that her group works with mixed-signal blocks with small amounts of digital content. Verification starts with the digital part, but the analog model comes too late. "We are trying to come up with a solution to get an architectural model up front," she said. She also noted that Verilog-AMS is too slow, and that AMD uses a "homegrown" simulation tool that requires a lot of hand-holding.

"When I ask an analog designer to give me a model so I can start verifying, they give me something that is similar but not exactly the same as what they're designing," said Melamed. "My struggle is to convince them that what they give me has to reflect what they're doing."

Flows are more important than methodologies or standards

"Asking about methodology is the wrong question," Goodenough said. "Asking about workflow is the right question, because that's what impacts cost and schedule. There is no end to clever languages. It's more about how you use them in the workflow." He noted, however, that "some languages allow us to be more productive, and some allow easier SoC integration."

People are more important than anything...but training is lacking

Tommy Kelly, CEO of Verilab, spoke from the audience to say that a quality verification team is the key to reaching time-to-market. "I would much rather have a mediocre tool flow and great engineers than a great tool flow and mediocre engineers," he said.

This comment touched off a discussion about the lack of training for new verification engineers, and the failure of universities to prepare new engineers for the real world. "I see a lot of resumes from young engineers coming from school," said Crocker. "There is no adequate software training for people going into this [verification] business."

"Verification is a mix of hardware and software," Melamed said. "New college grads who know a lot about software and a little about hardware do okay. Those who know a lot about hardware and have only rudimentary ideas about software don't do very well."

(Note: Last year I blogged about the Cadence Academic Network, which was set up to help universities train new engineers for real-world occupations).

There can be a "negative benefit" from IP reuse

If silicon IP is not easy to integrate and reuse, it can actually hurt more than it helps, according to Gary. "When the reusable design data falls below 50 percent, the benefit in terms of effort savings is almost zero," he said. "At lower levels, it costs more to try and reuse IP than to build from scratch."

Open source IP is not the answer

An audience member asked if open-source IP will help engineers sleep a little better. Apparently not. "There is no free lunch," Goodenough said. He noted that the software community is large enough to support and maintain open source, but the IC design community is much, much smaller.

"Okay, so you get some open-source VIP and run it in simulation," Melamed said. "When it core dumps, who do you call?"

85 percent of projects are missing schedules

Numetrics helps IC design companies optimize staffing and productivity, and it's a challenge. "We try to keep design cycles short," Gary said. "The reality is that 85 percent of the projects out there are missing their schedules, and unfortunately they're off by 10 to 150 percent. Quantifying tasks is a critical issue."

The $50 question: one vendor or two?

Before the panel, moderator J.L. Gray put out a request for questions and offered a $50 prize for the best question. It was: "Is what keeps you up at night the fact that you went to bed with only one vendor, or more than one vendor?"

If you stick with one vendor, Melamed said, you miss the "flexibility and opportunity" of having two. But having to deal with two or more vendors causes a lot of pain. He then expressed the hope that OVM and VMM will combine into one methodology. As I noted in a recent blog, that is one goal that's now within reach.

Richard Goering

Photo by Joe Hupcey III

...

DVCon 2010 Rocked!

tomacadence — Sat, 27 Feb 2010 07:32:00 GMT

I've spent much of this week at the San Jose Doubletree Hotel for DVCon 2010, and I have to say that it was a really good show. This is arguably the most important conference of the year for verification. DAC is lots bigger of course, but DVCon is really focused and there's a core group of colleagues and customers that always make it a fun and simulating event. Although DVCon is still officially the "Design & Verification Conference & Exhibition" every year it looks more and more as if the first ampersand is living on borrowed time.

Cadence and our customers had an especially active presence at DVCon this year, plus I always like to check out what our competitors and their customers are doing, so I couldn't possibly attend every session I wanted. I was really impressed with the technical papers that I did see, especially talks from Doulos on connecting SystemVerilog withC/C++/SystemC and on asynchronous assertions. They have a knack for presentating complex topics in a way that works even for those of us who no longer think about simulation timewheels on a daily basis.

The panels were generally lively, with some pithy comments that I (and others) tweeted in real time. I was really pleased with our sponsored lunch and its panel on debug. It was great that our CEO Lip-Bu Tan made his DVCon debut with a well-attended keynote address. Finally, I was just delighted with the pervasive OVM-related content -- our lunch, the UVM update at the Accellera lunch, exhibition floor demos, three tutorials, and at least five technical talks including the Best Paper award. It's only a day after the closing session and I'm already looking forward to next year!

Tom A.

The truth is out there...sometimes it's in a blog.