I have a technology library (given by foundry) with leLsw layer section defined.
I do not want to touch it

I added few layers with an ITDB approach. Now I'm unable to see the added layers, as it is not present in the leLsw layer section of the main techlib.

I want the user of the new techlib to see all the layers by default.(I don't want the users to go to the properties of palette and switch the display option to techfile layers instead of leLsw)

Hi,

I have a test session object that I am getting like this:

maeTstSession=maeGetTestSession(test ?session session)

Is it possible to get the test name from this object? I am asking because this object passed to several levels of functions and I don't want to pass an additional argument with the test name

Hello,

I have created an appForm with  the following attachmentList and size:

?attachmentList list(hicLeftPositionSet | hicRightPositionSet ; field 1
                     hicLeftPositionSet | hicRightPositionSet ; field 2
etc.

?initialSize    800:800
?minSize        800:800
?maxSize       1600:800

If I reduce the minimum y-size (?minSize        800:200), scrollbars are not inserted, unless I remove the attachmentList constraints.

Is it possible to have both scrollbars and "hicLeftPositionSet | hicRightPositionSet"? 

Thank you,

Best regards,

Aldo

Inside the scope of isCallable there is code which I don't want to be executed.

The procedure named in isCallable to-day is callable.

I want to make that procedure so it cannot be called.  How do I do that?

I can't change the isCallable line or the scope.  I want to change its behavior by making sure that the procedure does not exist (obviously this would be done before the code is executed).

I want to select a constraint, and then run a SKILL command that returns a list with the members of that constraint. Is this possible?

Thx,

Hi all,

I want to write a script SKILL to create the title & frame for view schematic. My question is whether SKILL supports any function for me to do this.

Best regards,

Huy Hoang

I have a top cell & need to revise all the instances' cellview & export top cell as a new GDS file.

So I write a SKILL code to do so and I find out it will be a little bit slow by using the dbSave to save the cellview of each instance.

Code as below:

let( (topCV subCV )
topCV = dbOpenCellViewByType(newLibName topCellName "layout" "maskLayout" "a")
foreach(inst topCV->instances
subCV = dbOpenCellViewByType(newLibName inst->cellName "layout" "maskLayout" "a")
;;;revise code content
;;;...
;;;revise code content
dbSave(subCV)
dbClose(subCV)
)
dbSave(topCV)
dbClose(topCV)
system(strcat( "strmout -library " newLibName " -topCell " topCellName " -view layout -strmFile " resultFolder "/" topCellName ".gds -techLib " srcLibName " -enableColoring -logFile " topCellName "_strmOut.log" ) )
)

Even if the cell content is not revised, the run time of dbSave will be 2 minutes when there are ~ 1000 instances in topcell. The exported GDS file size is ~2MB.

And the dbSave becomes the bottle neck of the code runtime...

Is there any better way to do such a thing? 

HI All,

I am new to skill. My requirement is

open layout 

get m0 layer cordinates in a layout

dump info into a text file

For example 2 input Nand, A,B output , vcc , vssx and internal net (n2) will be the m0 layers. I need info like in a text file.

n2 co ordinate

vssx (co ordinate)

a (co ordinate)

b (co ordinate ) .

I found similar code in cadence form . Can you help me on this

 procedure(printPts()
let(    (type
    (cnt 0)
    (objList geGetSelSet()))

foreach(obj objList
    ++cnt
    type = obj~>objType
    case(type
        ("inst"
            printf("%s %L at %L " type obj~>xy))
        ("rect"
            printf("%s on layer %L at %L " type obj~>lpp obj~>bBox))
        ("polygon"
            printf("%s on layer %L at %L " type obj~>lpp obj~>points))
        ("path"
            printf("%s on layer %L at %L " type obj~>lpp obj~>points))
        ("pathSeg"
            printf("%s on layer %L at %L " type obj~>lpp list(obj~>beginPt obj~>endPt)))
        ("label"
            printf("%s on layer %L at %L " type obj~>lpp obj~>xy))
        (t    printf("%s not defined " type))
    )
)
printf("%n objects selected " cnt)
); end of let
); end of printPts

Hi,

I am trying add multiple choices to my radio field in cdf parameters. when i see the select the instance and try editing the Instance properties I can not view them in a single window. Instead i get a vertical sliding bar. Is there a way to display them in multiple rows?

-Haareeth

Hi there,

I'm running a transient simulation, and I want to get all instances with model implementation hisim_hv because after that I want to process the data and to adjust some parameters for this kind of devices before dumping the values.

What is the easiest/fastest way to get those instances in skill/ocean?

What I did until now: 

- save the final OP of the simulation and then in skill

openResults()
selectResults('tranOp)
report(?type "hisim_hv" ?param "vgs")

Output seems to be promising, and looks like I can redirect it to a file and after that I have to parse the file.

Is there other simple way? I mean to not save data to file and to parse it.

Eventually having an instance name, is it possible to get the model implementation (hsim_hv, bsim4, etc..)? 

Best Regards,

Marcel

Hello,

After deleting cells using the following loop:

foreach(cellId ddGetObj(libName)~>cells
    ddDeleteObj(cellId)
)

the following warnings are printed in the CIW:

*WARNING* (SCH-2162): "... symbol" has been updated since "... schematic" was last saved. Validate that the schematic is correct and run Check and Save to suppress this warning.
*WARNING* (DB-270337): dbGetInstHeaderMaster: Failed to open cellview '...' from library '...' in read-only mode because the cellview does not exist. This cellview was instantiated in cellview '...' of library '...'. Ensure that the cellview exists in the library.

Is it possible to turn them off?

Thank you

Best regards,

Aldo

As the stakes for winning server segment market share grow ever higher an increasing number of companies are seeking to grasp the latest Holy Grail of multi-chip coherence. The approach promises to better enable applications such as machine learning...(read more)

It’s been quite a long 5-year journey building and deploying Performance Analysis, Verification, and Debug capabilities for Arm-based SoCs. We worked with some of the smartest engineers on the planet. First with the engineers at Arm, with whom we...(read more)

Here we conclude the blog series and highlight the results of Mediatek 's use of Cadence Perspec™ System Verifier for their SoC level verification. In case you missed it, Part 1 of the blog is here , and Part 2 of the blog is here . One of their key...(read more)

It’s always good to hear what real users think of products. Here is a very detailed review (~4000 words) by an Anonymous user, nick named Ant-Man (from the movie). Overall it’s a very strong endorsement of Perspec, and summarize...(read more)

The Cadence® Connections® Verification Program brings together a worldwide network of services, training, and IP development experts that support Cadence verification solutions. The program members help customer accelerate the adoption of new...(read more)

CDNLive is a user conference, and verification is one of the largest categories of content with multiple tracks covering multiple days. Portable stimulus is one of the hottest new areas in verification, and continues to be popular in all venues. At l...(read more)

Cadence pulled a fast one at DAC 2018, almost like a bait and switch. We advertised a hands-on workshop to learn about Accellera Portable Stimulus Specification (PSS) v1.0. But we made participants compete head to head, for prizes, and their pride! T...(read more)

Cadence continues to be a leader in SoC verification and has expanded our industry investment in Accellera portable stimulus language standardization. Some customers have expressed reservations that portable stimulus requires the effort of learn...(read more)

Vegas, here we come. All of us fun EDA engineers at once. Be prepared, next week’s Design Automation Conference will be busy! The trends I had outlined after last DAC in 2018—system design, cloud, and machine learning—have...(read more)

I have created a die and other components as symbols in sip and placed the symbols in sip through logic import capture netlist. It shows net connectivity but i couldn't add bond finger from the die pins. Please help on this. 

Hi all,

I have a question regarding the manufacture : how to check a cluster of same net vias spacing, with have no shape or cline covered

In this week’s Whiteboard Wednesdays video, Dave Apte discusses how to create the lowest power design possible by using architectural exploration and Cadence’s Stratus HLS solution....

[[ Click on the title to access the full blog on the Cadence Community site. ]]

Recently, I read an article about how failure is the stepping stone to success in life. It instantly struck a chord and a thought came zinging from nowhere about what happens to the failed arcs of a...

[[ Click on the title to access the full blog on the Cadence Community site. ]]

The 2019 HF1 production release for Clarity, Celsius, and Sigrity Tools is now available for download at Cadence Downloads . SIGRITY2019 HF1 For information about supported platforms, compatibility...

[[ Click on the title to access the full blog on the Cadence Community site. ]]

I recently attended a webinar presented by Wally Rhines about his new book, Predicting Semiconductor Business Trends After Moore's Law . Wally was the CEO of Mentor, as you probably know. Now he...

[[ Click on the title to access the full blog on the Cadence Community site. ]]

Cadence has a new white paper out on Computational Software . I've written on these topics in Breakfast Bytes, most recently in the posts: Computational Software System Analysis: Computational...

[[ Click on the title to access the full blog on the Cadence Community site. ]]

Autonomous vehicles are coming. In a statistic from the U.S. Department of Transportation, about 37,000 people died in car accidents in the United States in 2018. Having safe, fully automatic vehicles could drastically reduce that number—but the trick is figuring out how to make an autonomous vehicle safe. Internet-enabled systems in cars are more common than ever, and it’s unlikely that the use of them will slow or stop—and while they provide many conveniences to a driver, they also represent another attack surface that a potential criminal could use to disable a vehicle while driving.

So—what’s being done to combat this? Green Hills Software is on the case, and they explained the landscape of security in automotive systems in a presentation given by Max Hinson in the Cadence Theater at DAC 2019. They have software embedded [FS1] in most parts of a car, and all the major OEMs use their tech. The challenge they’ve taken on is far from a simple one—between the sheer complexity of modern automotive computer systems, safety requirements like the ISO 26262 standard, and the cost to develop and deploy software, they’ve got their work cut out for them. It’s the complexity of the systems that represents the biggest challenge, though. The autonomous cars of the future have dynamic behaviors, cognitive networks, require security certification to at least ASIL-D, require cyber security like you’d have on an important regular computer system to cover for the internet-enabled systems—and all of this comes with a caveat: under current verification abilities, it’s not possible to test every test case for the autonomous system. You’d be looking at trillions of test cases to reach full coverage—not even the strongest emulation units can cover that today.

With regular cars, you could do testing with crash-test dummies, and ramming the car into walls at high speeds in a lab and studying the results. Today, though, that won’t cut it. Testing like that doesn’t see if a car has side-channel vulnerabilities in its infotainment system, or if it can tell the difference between a stop sign and a yield sign. While driving might seem simple enough to those of us that have been doing it for a long time, to a computer, the sheer number of variables is astounding. A regular person can easily filter what’s important and what’s not, but a machine learning system would have to learn all of that from scratch. Green Hills Software posits that it would take nine billion miles of driving for a machine learning system of today’s caliber to reach an average driver’s level—and for an autonomous car, “average” isn’t good enough. It has to be perfect.

A certifier for autonomous vehicles has a herculean task, then. And if that doesn’t sound hard enough, consider this: in modern machine-vision systems, something called the “single pixel hack” can be exploited to mess them up. Let’s say you have a stop sign, and a system designed to recognize that object as a stop sign. Randomly, you change one pixel of the image to a different color, and then check to see if the system still recognizes the stop sign. To a human, who knows that a stop sign is octagonal, red, and has “STOP” written in white block letters, a stop sign that’s half blue and maybe bent a bit out of shape is still, obviously, a stop sign—plus, we can use context clues to ascertain that sign at an intersection where there’s a white line on the pavement in front of our vehicle probably means we should stop. We can do this because we can process the factors that identify a stop sign “softly”—it’s okay if it’s not quite right; we know what it’s supposed to be. Having a computer do the same is much more difficult. What if the stop sign has graffiti on it? Will the system still recognize it as a stop sign? How big of an aberration needs to be present before the system no longer acknowledges the mostly-red, mostly-octagonal object that might at one point have had “stop” written on it as a stop sign? To us, a stop sign is a stop sign, even with one pixel changed—but change it in the right spot, and the computer might disagree.

The National Institute of Security and Technology tracks vulnerabilities along those lines in all sorts of systems; by their database, a major vulnerability is found in Linux every three days. And despite all our efforts to promote security, this isn’t a battle we’re winning right now—the number of vulnerabilities is increasing all the time.

Check back next time to see the other side: what does Green Hills Software propose we do about these problems? Read part 2 now.

If you missed the first part of this series, you can find it here.

So: what does Green Hills Software propose we do?

The issue of “solving security” is, at its core, impossible—security can never be 100% assured. What we can do is make it as difficult as possible for security holes to develop. This can be done in a couple ways; one is to make small code in small packs executed by a “safing plan”—having each individual component be easier to verify goes a long way toward ensuring the security of the system. Don’t have sensors connect directly to objects—instead have them output to the safing plan first, which can establish control and ensure that nothing can be used incorrectly or in unintended ways. Make sure individual software components are sufficiently isolated to minimize the chances of a side-channel attack being viable.

What all of these practices mean, however, is that a system needs to be architected with security in mind from the very beginning. Managers need to emphasize and reward secure development right from the planning stages, or the comprehensive approach required to ensure that a system is as secure as it can be won’t come together. When something in someone else’s software breaks, pay attention—mistakes are costly, but only one person has to make it before others can learn from it and ensure it doesn’t happen again. Experts are experts for a reason—when an independent expert tells you something in your design is not secure, don’t brush them off because the fix is expensive. This is what Green Hills Software does, and it’s how they ensure that their software is secure.

Now, where does Cadence fit into all of this? Cadence has a number of certified secure offerings a user can take advantage of when planning their new designs. The Tensilica portfolio of IP is a great way to ensure basic components of your design are foolproof. As always, the Cadence Verification Suite is great for security verification in both simulation and emulation, and JasperGold platform’s formal apps are a part of that suite as well.

We are entering a new age of autonomous technology, and with that new age we have to update our security measures to match. It’s not good enough to “patch up” security at the end—security needs to beat the forefront of a verification engineer or hardware designer’s mind at all stages of development. For a lot of applications, quite literally, lives are at stake. It’s uncharted territory out there, but with Green Hills Software and Cadence’s tools and secure IP, we can ensure the safety of tomorrow.

In the former blog about Python and Specman: Specman: Python Is here!, we described the technical information around Specman-Python integration. Since Python provides so many easy to use existing libraries in various fields, it is very tempting to leverage these cool Python apps.

Coverage has always been the center of the verification methodology, however in the last few years it gets even more focus as people develop advanced utilities, usually using Machine Learning aids. Anyhow, any attempt to leverage your coverage usually starts with some analysis of the behavior and trends of some typical tests. Visualizing the data makes it easier to understand, analyze, and communicate. Fortunately, Python has many Visualization libraries.

In this blog, we show an example of how you can use the plotting Python library (matplotlib) to easily display coverage information during a run. In this blog, we use the Specman Coverage API to extract coverage data, and a Python module to display coverage grades interactively during a single run and the way to connect both.

Before we look at the example, if you have read the former blog about Specman and Python and were concerned about the fact that python3 is not supported, we are glad to update that in Specman 19.09, Python3 is now supported (in addition to Python2).

The Testcase
Let’s say I have a stable verification environment and I want to make it more efficient. For example: I want to check whether I can make the tests shorter while hardly harming the coverage. I am not sure exactly how to attack this task, so a good place to start is to visually analyze the behavior of the coverage on some typical test I chose. The first thing we need to do is to extract the coverage information of the interesting entities. This can be done using the old Coverage API. 

Coverage API
Coverage API is a simple interface to extract coverage information at a certain point. It is implemented through a predefined struct type named user_cover_struct. To use it, you need to do the following:

1. Define a child of user_cover_structusing like inheritance (my_cover_struct below).
2. Extend its relevant methods (in our example we extend only the end_group() method) and access the relevant members (you can read about the other available methods and members in cdnshelp).
3. Create an instance of the user_cover_structchild and call the predefined scan_cover() method whenever you want to query the data (even in every cycle). Calling this method will result in calling the methods you extended in step 2.  

 The code example below demonstrates these three steps. We chose to extend the end_group() method and we keep the group grade in some local variable. Note that we divide it by 100,000,000 to get a number between 0 to 1 since the grade in this API is an integer from 0 to 100,000,000. 

Pass the Data to a Python Module
After we have extracted the group grade, we need to pass the grade along with the cycle and the coverage group name (assuming there are a few) to a Python module. We will take a look at the Python module itself later. For now, we will first take a look at how to pass the information from the e code to Python. Note that in addition to passing the grade at certain points (addVal method), we need an initialization method (init_plot) with the number of cycles, so that the X axis can be drawn at the beginning, and end_plot() to mark interesting points on the plot at the end. But to begin with, let’s have empty methods on the Python side and make sure we can just call them from the e code.

 # plot_i.py
def init_plot(numCycles):
    print (numCycles)
def addVal(groupName,cycle,grade):
    print (groupName,cycle,grade)
def end_plot():
    print ("end_plot") 

And add the calls from e code:

 Before running this, note that you need to ensure that Specman finds the Python include and lib directories, and Python finds our Python module. To do this, you need to define a few environment variables: SPECMAN_PYTHON_INCLUDE_DIR, SPECMAN_PYTHON_LIB_DIR, and PYTHONPATH. 

 The Python Module to Draw the Plot
After we extracted the coverage information and ensured that we can pass it to a Python module, we need to display this data in the Python module. There are many code examples out there for drawing a graph with Python, especially with matplotlib. You can either accumulate the data and draw a graph at the end of the run or draw a graph interactively during the run itself- which is very useful especially for long runs.

Below is a code that draws the coverage grade of multiple groups interactively during the run and at the end of the run it prints circles around the maximum point and adds some text to it. I am new to Python so there might be better or simpler ways to do so, but it does the work. The cool thing is that there are so many examples to rely on that you can produce this kind of code very fast.

 In the example we used, we had two interesting entities: packet and state_machine, thus we had two equivalent coverage groups. When running our example connecting to the Python module, we get the following graph which is displayed interactively during the run.

When analyzing this specific example, we can see two things. First, packet gets to a high coverage quite fast and significant part of the run does not contribute to its coverage. On the other hand, something interesting happens relating to state_machine around cycle 700 which suddenly boosts its coverage. The next step would be to try to dump graphic information relating to other entities and see if something noticeable happens around cycle 700.

To run a complete example, you can download the files from: https://github.com/okirsh/Specman-Python/

Do you feel like analyzing the coverage behavior in your environment? We will be happy to hear about your outcomes and other usages of the Python interface.

Orit Kirshenberg
Specman team

Longfellow's metaphorical footprints on the sands of time is more profound and eternal no doubt but a footprint for silicon (a form of sand isn't it?) is as important for PCB designers. So, here we will list the steps to create a fo...(read more)

All PCB designers know the importance of proper power delivery for successful board design. Integrated circuits need the power to turn on, and ICs with marginal power delivery will not operate reliably. Since power planes can...(read more)

All engineers can enhance their mixed-signal low-power structural verification productivity by learning while doing with a PIEA RAK (Power Intent Export Assistant Rapid Adoption Kit). They can verify the mixed-signal chip by a generating macromodel for their analog block automatically, and run it through Conformal Low Power (CLP) to perform a low power structural check.  

The power structure integrity of a mixed-signal, low-power block is verified via Conformal Low Power integrated into the Virtuoso Schematic Editor Power Intent Export Assistant (VSE-PIEA). Here is the flow.

Applying the flow iteratively from lower to higher levels can verify the power structure.

Cadence customers can learn more in a Rapid Adoption Kit (RAK) titled IC 6.1.5 Virtuoso Schematic Editor XL PIEA, Conformal Low Power: Mixed-Signal Low Power Structural Verification.

• To read the overview presentation, click on following link: PIEA Overview
• To download this PIEA RAK click on following link: PIEA RAK Download

The RAK includes Rapid Adoption Kit with demo design (instructions are provided on how to setup the user environment). It Introduces the Power Intent Export Assistant (PIEA) feature that has been implemented in the Virtuoso IC615 release.  The power intent extracted is then verified by calling Conformal Low Power (CLP) inside the Virtuoso environment.

• Last Update: 11/15/2012.
• Validated with IC 6.1.5 and CLP 11.1

The RAK uses a sample test case to go through PIEA + CLP flow as follows:

• Setup for PIEA
• Perform power intent extraction
• CPF Import: It is recommended to Import macro CPF, as oppose to designing CPF for sub-blocks. If you choose to import design CPF files please make sure the design CPF file has power domain information for all the top level boundary ports
• Generate macro CPF and design CPF
• Perform low power verification by running CLP

It is also recommended to go through older RAKs as prerequisites.

• Conformal Low Power, RTL Compiler and Incisive: Low Power Verification for Beginners
• Conformal Low Power: CPF Macro Models
• Conformal Low Power and RTL Compiler: Low Power Verification for Advanced Users

To access all these RAKs, visit our RAK Home Page to access Synthesis, Test and Verification flow

Note: To access above docs, use your Cadence credentials to logon to the Cadence Online Support (COS) web site. Cadence Online Support website https://support.cadence.com/ is your 24/7 partner for getting help and resolving issues related to Cadence software. If you are signed up for e-mail notifications, you can receive new solutions, Application Notes (Technical Papers), Videos, Manuals, and more.

You can send us your feedback by adding a comment below or using the feedback box on Cadence Online Support.

Sumeet Aggarwal

I noticed some very interesting news last week, widely reported in the technical press, and you can find the source press release here. In a nutshell, the Embedded Microprocessor Benchmark Consortium (EEMBC) has formed a group to look at benchmarks for ultra low power microcontrollers. Initially chaired by Horst Diewald, chief architect of MSP430^TM microcontrollers at Texas Instruments, the group's line-up is an impressive "who's who" of the microcontroller space, including Analog Devices, ARM, Atmel, Cypress, Energy Micro, Freescale, Fujitsu, Microchip, Renesas, Silicon Labs, STMicro, and TI.

As the press release explains, unlike usual processor benchmark suites which focus on performance, the ULP benchmark will focus on measuring the energy consumed by microcontrollers running various computational workloads over an extended time period. The benchmarking methodology will allow the microcontrollers to enter into their idle or sleep modes during the majority of time when they are not executing code, thereby simulating a real-world environment where products must support battery life measured in months, years, and even decades.

Processor performance benchmarks seem to be as widely criticized as EPA fuel consumption figures for cars - and the criticism is somewhat related. There is a suspicion that manufacturers can tune the performance for better test results, rather than better real-world performance. On the face of it, the task to produce meaningful ultra low power benchmarks seems even more fraught with difficulties. For a start, there is a vast range of possible energy profiles - different ways that computing is spread over time - and a plethora of low power design techniques available to optimize the system for the set of profiles that particular embedded system is likely to experience. Furthermore, you could argue that, compared with performance in a computer system, energy consumption in an ultra low power embedded system has less to do with the controller itself and more to do with other parts of the system like the memories and mixed-signal real-world interfaces.

EEMBC cites that common methods to gauge energy efficiency are lacking in growth applications such as portable medical devices, security systems, building automation, smart metering, and also applications using energy harvesting devices. At Cadence, we are seeing huge growth in these areas which, along with intelligence being introduced into all kinds of previously "dumb" appliances, is becoming known as the "Internet of Things." Despite the difficulties, with which the parties involved are all deeply familiar, I applaud this initiative. While it may be difficult to get to apples-to-apples comparisons for energy consumption in these applications, most of the time today we don't even know where the grocery store is. If the EEMBC effort at least gets us to the produce department, we're going to be better off.

Pete Hardee 

On May 7, 2013 Cadence announced a 30% productivity gain in the June 2013 Incisive Enterprise Simulator 13.1 release.  Advanced debug visualization, faster turn-around time, and the extension of eight years of low-power verification innovation to IEEE 1801/UPF are the key capabilities in the release.

When we talk about low-power verification its easy to equate it with simulation.  For certain, simulation is the heart of a low-power verification solution. Simulation enables engineers to run their design in the context of power intent.  The challenge is that a simulation-only approach is inadequate. For example, if engineers could achieve SoC quality by verifying the individual function of each power control module (PCM), then simulation could be enough.  For a single power domain, simulation can be enough. 

However, when the SoC has multiple power domains -- and we have seen SoCs with hundreds of them -- engineers have to check the PCMs and all of the arcs between the power modes.  These SoCs often synchronize some of the domain switching to reduce overall complexity, creating the potential for signal skew errors on the control signals for the connected domains.  Managing these complexities requires verification methodologies including advanced debug, verification planning, assertion-based verification, Universal Verification Methodology - Low Power (UVM-LP), and more (see Figure 1).

Figure 1:  Comprehensive Low-Power Verification 

But even advanced verification methodologies on top of simulation aren't enough.  For example, the state machine that defines the legal and illegal power mode transitions is often written in software. The speed and capacity of the Palladium emulation platform is ideal to verify in this context, and it is integrated with simulation sharing debug, UVM acceleration, and static checks for low-power. And, it reports verification progress into a holistic plan for the SoC.  Another example is the ability to compare the design in the implementation flow with the design running in simulation to make sure that what we verify is what we intend to build.

Taken together, verification across multiple engines provides the comprehensive low-power verification needed for today's advanced node SoCs.  That's the heart of this low-power verification announcement. 

Another point you may have noticed is the extension of the Common Power Format (CPF) based power-aware support in the Incisive Enterprise Simulator to IEEE 1801.  We chose to bring IEEE 1801 to simulation first because users like you sometimes need to mix vendors for regression flows.  Over time, Cadence will extend the low-power capabilities throughout its product suite to IEEE 1801.

If you are using CPF today, you already have the best low-power solution. The evidence is clear:  the upcoming IEEE 1801-2013 update includes many of the CPF features contributed to 1801/UPF to enable methodology convergence.  Since you already have those features in the CPF flow, any migration before you have a mature IEEE 1801-2013 tool flow would reduce the functionality you have today.

If you are using Unified Power Format (UPF) 1.0 today, you want to start planning your move toward the IEEE 1801-2013 standard.  A good first step would be to move to the IEEE 1801-2009 standard.  It fills holes in the earlier UPF 1.0 definition.  While it does lack key features in -2013, it is an improvement that will make the migration to -2013 easier. The Incisive 13.1 release will run both UPF 1.0 and IEEE 1801-2009 power intent today.

Over the next few weeks you'll see more technical blogs about the low-power capabilities coming in the Incisive 13.1 release.  You can also join us on June 19 for a webinar that will introduce those capabilities using the reference design supplied with the Incisive Enterprise Simulator release.

=Adam "The Jouler" Sherer

(Yes, "Sherilog" is still here.  :-) )

The IEEE has announced the publication of the new 1801-2013 standard, also known as UPF 2.1, and immediate availability for free download through the IEEE 1801-2013 Get Program. Even though the standard is new to the whole world, for the people of the IEEE working group this standard is finally done and is in the past now.

There is a Chinese saying "好事多磨" which means "good things take time to happen." I forgot the exact time when I first joined the working group for the new standard -- about two and half years ago -- but I do remember long hours of meetings and many "lively" debates and discussions. Since the "hard time" has passed us, I would like to share some fun facts about the working group and the standard.

• The 1801 working group is the largest entity based ballot group in IEEE-SA history.
• The new standard was initially planned for 2012, but was delayed purely due to the large amount of work required.
• At one point, the group was debating on whether the new standard should be called UPF 2.1 or 3.0. It may sound weird now but we spent quite some time discussing this. Eventually we settled on 2.1 as it was the original plan.
• The 1801-2013 document has 358 pages which is 53% thicker than previous version (the sheer amount of changes in the new standard indicate that this is more than just a normal incremental update of the previous version as suggested by naming it 2.1)
• Around 300 real issues were reported over the previous version and a majority of them were fixed in the new release.
• This is the first release with constructs and semantics coming from Common Power Format (CPF), a sign of convergence of the two industry leading power formats.
• There are about 100 working group meetings in my Outlook calendar since 2011, with meeting times ranging from 2 hours to 8 hours.
• We extensively used Google Drive (which was called Google Docs when the working group started), a great tool for productivity. I cannot imagine how any standard could have been done before Google existed!

Personally, I had an enjoyable journey, especially from having the privilege to work with many industry experts who are all passionate about low power. I do have one more thing to share though. My older daughter went from middle school to high school during the period of the development of the new standard. Since most of the meetings took place in the early morning California time, she had to endure the pain of listening to all these discussions on power domain, power switches, etc. on her way to school.

I asked her if she learned anything. She told me that other than being able to recognize the voices of Erich, John and Joe on the line, she also learned that she would never want to become an electrical or computer engineer! She was so happy that the meetings stopped a couple of months ago. But what I did not tell her is that the meetings will resume after DAC! Well, I am sure this will be a big motivation for her to get her own driving license in the summer.

If you want to get some quick technical insights into the new standard, check out my recent EE Times article IEEE 1801-2013: A bold step towards power format convergence.

Qi Wang

DAC is right around the corner! On the demo floor at Cadence® Booth #2214, we will demonstrate how to use the Cadence mixed-signal and low-power solution to design, verify, and implement a microcontroller-based mixed-signal design. The demo design architecture is very similar to practical designs of many applications like power management ICs, automotive controllers, and the Internet of Things (IoT). Cadene tools demonstrated in this design include Virtuoso® Schematic Editor, Virtuoso Analog Design Environment, Virtuoso AMS Designer, Virtuoso Schematic Model Generator, Virtuoso Power Intent Assistant, Incisive® Enterprise Simulator with DMS option, Virtuoso Digital Implementation, Virtuoso Layout Suite, Encounter® RTL Compiler, Encounter Test, and Conformal Low Power. An extended version of this demo will also be shown at the ARM® Connected Community Pavilion Booth #921.

For additional highlights on Cadence mixed-signal and low-power solutions, stop by our booth for:

• The popular book, Mixed-signal Methodology Guide, which will be on sale during DAC week!
• A sneak preview of the eBook version of the Mixed-signal Methodology Guide
• Customer presentations at the Cadence DAC Theater
  • 9am, Tuesday, June 4  ARM  Low-Power Verification of A15 Hard Macro Using CLP 
  • 10:30am, Tuesday, June 4  Silicon Labs  Power Mode Verification in Mixed-Signal Chip
  • 12:00pm, Tuesday, June 4  IBM  An Interoperable Flow with Unified OA and QRC Technology Files
  • 9am, Wednesday, June 5  Marvell  Low-Power Verification Using CLP
  • 4pm, Wednesday, June 5  Texas Instruments  An Inter-Operable Flow with Unified OA and QRC Technology Files
• Partner presentations at the Cadence DAC Theater
  • 10am, Monday, June 3  X-Fab  Rapid Adoption of Advanced Cadence Design Flows Using X-FAB's AMS Reference Kit
  • 3:30pm, Monday, June 3  TSMC TSMC Custom Reference Flow for 20nm -  Cadence Track
  • 9:30am,Tuesday, June 4  TowerJazz   Substrate Noise Isolation Extraction/Model Using Cadence Analog Flow
  • 12:30pm, Wednesday, June 5  GLOBALFOUNDRIES  20nm/14nm Analog/Mixed-signal Flow
  • 2:30pm, Wednesday, June 5  ARM  Cortex®-M0 and Cortex-M0+: Tiny, Easy, and Energy-efficient Processors for Mixed-signal Applications
• Technology sessions at suites
  • 10am, Monday, June 3    Low-power Verification of Mixed-signal Designs
  • 2pm, Monday, June 3      Advanced Implementation Techniques for Mixed-signal Designs
  • 2pm, Monday, June 3      LP Simulation: Are You Really Done?
  • 4pm, Monday, June 3      Power Format Update: Latest on CPF and IEEE 1801  
  • 11am, Wednesday, June 5   Mixed-signal Verification
  • 11am, Wednesday, June 5   LP Simulation: Are You Really Done?
  • 4pm, Wednesday, June 5   Successful RTL-to-GDSII Low-Power Design (FULL)
  • 5pm, Wednesday, June 5   Custom/AMS Design at Advanced Nodes

We will also have three presentations at the Si2 booth (#1427):

• 10:30am, Monday, June 3   An Interoperable Implementation Solution for Mixed-signal Design
• 11:30am, Tuesday, June 4   Low-power Verification for Mixed-signal Designs Using CPF
• 10:30am, Wednesday, June 5   System-level Low-power Verification Using Palladium

We have a great program at DAC. Click the link for complete Cadence DAC Theater and Technology Sessions. Look forward to seeing you at DAC!     

There is no better way other than a self-help training kit -- (rapid adoption kit, or RAK) -- to demonstrate the Incisive Enterprise Simulator's IEEE 1801 / UPF low-power features and its usage. The features include:

• Unique SimVision debugging 
• Patent-pending power supply network visualization and debugging
• Tcl extensions for LP debugging
• Support for Liberty file power description
• Standby mode support
• Support for Verilog, VHDL, and mixed language
• Automatic understanding of complex feedthroughs
• Replay of initial blocks
• ‘x' corruption for integers and enumerated types
• Automatic understanding of loop variables
• Automatic support for analog interconnections

Mickey Rodriguez, AVS Staff Solutions Engineer has developed a low power UPF-based RAK, which is now available on Cadence Online Support for you to download.

• This rapid adoption kit illustrates Incisive Enterprise Simulator (IES) support for the IEEE 1801 power intent standard. 

Patent-Pending Power Supply Network Browser. (Only available with the LP option to IES)

• In addition to an overview of IES features, SimVision and Tcl debug features, a lab is provided to give the user an opportunity to try these out.

The complete RAK and associated overview presentation can be downloaded from our SoC and Functional Verification RAK page:

We are covering the following technologies through our RAKs at this moment:

Synthesis, Test and Verification flow
Encounter Digital Implementation (EDI) System and Sign-off Flow
Virtuoso Custom IC and Sign-off Flow
Silicon-Package-Board Design
Verification IP
SOC and IP level Functional Verification
System level verification and validation with Palladium XP

Please visit https://support.cadence.com/raks to download your copy of RAK.

We will continue to provide self-help content on Cadence Online Support, your 24/7 partner for learning more about Cadence tools, technologies, and methodologies as well as getting help in resolving issues related to Cadence software. If you are signed up for e-mail notifications, you're likely to notice new solutions, application notes (technical papers), videos, manuals, etc.

Note: To access the above documents, click a link and use your Cadence credentials to log on to the Cadence Online Support https://support.cadence.com/ website.

Happy Learning!

Sumeet Aggarwal and Adam Sherer

If you weren't able to attend the 2013 DVCon, you missed out on a great IEEE 1801/UPF tutorial delivered by members of the IEEE committee. Accellera had the event recorded and that recording is now posted on the Accellera.org website. Regardless of your work so far with low power design and verification, you need to watch this video.

Power management is becoming ubiquitous in our world. The popular aspect is that reduced power is good for the evironment and that is true. But for those teams that have been building chips around the 40nm node and below, there is another truth. Power management is required simply to get working silicon in many cases. As the industry expands the number of designs with power management and forges deeper into advanced nodes, we steadily identify improvements to the power format descriptions. The most recent set of imporvements to the IEEE 1801 standard are now available in the 2013 version of that standard.

To help bring the standard to life, five representatives from the IEEE joined to deliver a tutorial at DVCon in 2013. Qi Wang (Cadence), Erich Marschner (Mentor), Jeffrey Lee (Synopsys), John Biggs (ARM), and Sushma Honnavarra-Prasad (Broadcom) each contributed to the tutorial. It started with a review of the UPF basics that led to the IEEE 1801 standard delivered by the EDA companies. The IEEE 1801 users then presented tutorial content on how to apply the standard. The session then concluded with a look forward to the IEEE 1801-2013 (UPF 2.1) standard. The standard was released two months after the DVCon tutorial and is available through the Accellera Get program.

So after the bowl games are over and you'vre returned through the woods and back over the river from Grandma's, grab a cup of hot cocoa and learn more about the power standards you may well be using in 2014.

Regards,

Adam "The Jouler" Sherer

ST Microelectronics reported their success with IEEE 1801 / UPF low-power simulation using Incisive Enterprise Simulator at CDNLive India in November 2013. We were able to meet with Mohit Jain just after his presentation and recorded this video that explains the key points in his paper.

With eight years of experience and pioneering technology in native low-power simulation, Mohit was able to apply Incisive Enterprise Simulator to a low-power demonstrator in preparation for use with a production set-top box chip.  Mohit was impressed with the ease in which he was able to reuse his existing IEEE 1801 / UPF code successfully, including the power format files and the macro models coded in his Liberty files. Mohit also discusses how he used the power-aware Cadence SimVision debugger.

The Cadence low-power verification solution for IEEE 1801 / UPF also incorporates the patent-pending Power Supply Network visualization in the SimVision debugger.  You can learn more about that in the Incisive low-power verification Rapid Adoption Kit for IEEE 1801 / UPF here in Cadence Online Support.

Just another happy Cadence low-power verification user!

Regards,

 Adam "The Jouler" Sherer 

Freescale was a successful Incisive® simulation CPF low-power user when they decided to step up their game. In November 2013, at CDNLive India, they presented a paper explaining how they improved their ability to find power-related bugs using a more sophisticated verification flow.  We were able to catch up with Abhinav Nawal just after his presentation to capture this video explaining the key points in his paper.

Abhinav had already established a low-power simulation process using directed tests for a design with power intent captured in CPF. While that is a sound approach, it tends to focus on the states associated with each power control module and at least some of the critical power mode changes.  Since the full system can potentially exercise unforeseen combinations of power states, the directed test approach may be insufficient. Abhinav built a more complete low-power verification approach rooted in a low-power verification plan captured in Cadence® Incisive Enterprise Manager.  He still used Incisive Enterprise Simulator and the SimVision debugger to execute and debug his design, but he also added Incisive Metric Center to analyze coverage from his low-power tests and connect that data back to the low-power verification plan.  As a result, he was able to find many critical system-level corner case issues, which, left undetected, would have been catastrophic for his SoC.  In the paper, Abhinav presents some of the key problems this approach was able to find.

You can achieve results similar to Abhinav. Incisive Enterprise Simulator can generate a low-power verification plan from the power format, power-aware assertions, and it can collect power-aware knowledge.  To get started, you can use the Incisive Low-Power Simulation Rapid Adoption Kit (RAK) for CPF available on Cadence Online Support.

Just another happy Cadence low-power verification user!

Regards,

Adam "The Jouler" Sherer  

Key findings: 5X to 32X faster low-power verification using Palladium XP emulation

It’s hot in July in Korea, and not just the temperature; the ideas, too. The ideas that flowed at CDNLive Korea were exciting, and that includes a very interesting talk by Jiyeon Park from the System LSI division of Samsung Electronics.  His talk, titled “Enabling Low-Power Verification using Cadence Palladium XP,” struck a chord with the audience and the highlights bear sharing in this forum. This blog captures some of the highlights from the public talk in Seoul this summer.

Motivation

If you are familiar with the breadth of the product lines at Samsung Electronics, you will appreciate the diversity of the end-market requirements that they must fulfill. These markets and products include:

Mobile/Handheld

• Smartphones
• Tablets
• Laptops

Consumer/Digital Home

• High-definition/ultra-high-definition TV
• Gaming consoles
• Computers 

Networking/Data Center

• Servers
• Switches
• Communications

What all of these markets have in common is that energy efficiency is now an integral and leading part of the value equation. For design teams, a good knowledge of power helps the evaluation and use of a host of critical decisions. From design architecture, IP make-versus-buy decisions, and manufacturing process selection, to the use of low-power design techniques, all are critically influenced by power.

Using simulation for low-power verification

Once the decision to overlay power reduction design techniques, such as power shutdown, has been made, new dimensions have been added to the already complex SoC verification task. The RTL verification environment is first augmented with a power intent file; in this case, IEEE 1801 was the format.  The inclusion of this power intent information enables the examination of power domain shutdown, isolation operations, proper retention, and level shifting.

Figure 1: Incisive SimVision power verification elements example

Low-power verification using emulation

Simulation for low-power verification works well, so why emulation? One word—complexity!  It is easy to forget that “design complexity” (usually measured in gates or transistors) is not that same as “verification complexity” (which is really hard to measure). Consider a design with four power domains, three of which are switchable and one that is switchable but also has high- and low-voltage states. That yields nine basic states, and 24 modes of operation to test. Although some of those modes may not be consequential, when paired with hundreds or even thousands of functional tests, you can begin to understand the impact of overlaying low power on the verification problem. Thus, it becomes very desirable to enlist the raw computational power of emulation.

Power off/on scenario on Palladium XP platform

A typical functional test would be augmented to include the power control signals. For power shutoff verification, for instance, the cycles for asserting isolation begin the sequence, followed by state retention, and then finally a power shutdown of the domain must be asserted to verify operation. The figure below calls out a number of checks that ought to be performed.

Figure 2: Power shutoff sequence and associated checks to make

IEEE 1801 support in Palladium XP platform

The IEEE 1801 support found in the Palladium PX platform includes some noteworthy capabilities, as well as some implications to the user. First is a patented memory randomization provided by the Palladium XP platform. This capability includes randomization of memory during shutdown and power up, control over read value during the power-off state, non-volatile memory state retention, and freezing of data on retention. The user should be aware there is about a 10%-20% capacity overhead associated with IEEE 1801-driven low-power verification.

Figure 3: Palladium low-power verification enables schedule improvement

Palladium low-power verification flow

The great thing about the emulation work flow for IEEE 1801 power verification is that the only change is to include that IEEE 1801 power intent file during the compilation stage!

Considerations for emulation environment bring-up

A Universal Verification Methodology (UVM) approach was taken by the Samsung team. This provides a unique structure to the testbench environment that is very conducive to a metric-driven methodology.  Using a testbench acceleration interface, teams can run the testbench on a software simulator and the design on the emulator. In addition, the formalism allows for the case of incomplete designs that do not hinder the verification of the parts that are completed.

Experimental results

The most exciting part of the paper was the results that were obtained. For a minor overhead cost in compile time and capacity, the team was able to improve runtimes of their tests by 5X to 32X. Being able run tests in a fraction of the time, or many more tests in the same time, has always been a benefit for emulation users. Now low-power verification is a proven part of the value provided to Palladium XP platform users.

Figure 4: Samsung low-power verification emulation results

Conclusions

The key conclusions found were:

• No modification was needed for IEEE 1801
• There is a small capacity and compile time overhead
• The emulation and simulation match
• The longer the test, the more the net speed up versus software simulation
• Run times improved from 5X to 32X!

With this flow in place, the teams has begun power-aware testing that includes firmware and software verification to go along with the hardware testing. This expansion enables more capability in optimization of the power architecture. In addition, they are seeing faster silicon bring-up in the context of an applied low-power strategy.

Steve Carlson

Hello,

Would anyone know how to setup a PSS or QPSS simulation with 25% dutycycle clock sources or if such a thing is possible with QPSS.

Fig1 (below) is a snapshot of the circuit I am trying to characterize. This has 4 clock ports each with 25%duty cycle in the ON state. Fig2 below shows two of these clocks.

Each path in the circuit consists of two switches with a low pass RC sandwiched in between. The Input is a 50Ohm port sine wave and the output is a 1K resistor. The output nets of all paths are connected together.

I am trying to determine the swept frequency response from input to output (voltage) when the input is from 500Mhz to  510MHz. The Period (T=1/Fp) of each of the pulses is such that Fp=500MHz. The first pulse source has a delay=0, second has delay=T/4, third delay=2T/4, etc...

I am currently getting it working and seeing the correct result (bandpass response) with Transient but the problem is doing a dft at 500MHz with 10KHz spacings needs at least 100us and takes up a lot of time and disk space.

Many Thanks,
Chris.

Fig1

Fig2

Hello,

I am using virtuoso version IC 6.1.7-64b.500.1, and I am trying to follow the Spectre RF Workshop-Noise-Aware PLL Design Flow(MMSIM 7.1.1) pdf.

I could find the workshop library "pllMMLib", but I cannot find PLL Macro Model Wizard, and I attached my screen.

Could you please help me install the module "PLL Macro Model Wizard"?

Thanks a lot!

Hello

The document I referenced is https://filebox.ece.vt.edu/~symort/rfworkshop/Mixer_workshop_instruction.pdf. (This is cadence workshop document)

While following the pxf simulation in the above article, the results are different and I have a question.

My result picture is shown below.

<my result error>

<document result>

<my direct plot>

<document direct plot>

The difference with the documentation is that in the direct plot screen after the pxf simulation,

1.output harmonics-> input sideband

2.Frequency axis: out-> frequency axis: absin

3.The results for port0 (RF port) are also different (see photo below).

4.The frequency values in the box are different.

My screen shows 5G, 10G, 1K ~ 10M, but the document is the same as 1K ~ 10M.

Ask for a solution. Thank you.

Hello, i have made a power gain circle for 30dB,for setting a GAIN we need to set a matching network for input and output inpedance.

but in this Gain circles it shows me only one complex number instead of two.(As shown bellow)

Where did i go wrong with using it to find the input and output impedancies needed to be matched in order to have 30dB gain?
Thanks.

Hello, i have built a matching network of 13dB gain and  NF as shown bellow step by step.(including all the plots and matlab )

its just not working at all,i am doing it exacly by the thoery

taking a point inside the circle-> converting its gamma to Z_source->converting gamma_s into gamma_L with the formulla bellow as shown in the matlab->converting the gamma_L into Z_L-> building the matching network for conjugate of Z_L and Z_c.Its just not working.

where did i got  wrong?

Thanks.

gamma_s=75.8966*exp(deg2rad(280.88)*i);
z_s=gamma2z(gamma_s,50);
s11=0.99875-0.03202*i
s12=721.33*10^(-6)+8.622*10^(-3)*i
s21=-188.37*10^(-3)+30.611*10^(-3)*i
s22=875.51*10^(-3)-100.72*10^(-3)*i
gamma_L=conj((s22+(s12*s21*gamma_s)/(1-s11*gamma_s)))
z_L=gamma2z(gamma_L,50)

hi everyone, 

i'm trying to create a netlist for aging simulation. i would like to simulate how power, Gain and PAE (efficiency) are inlfuenced after 3 hours

i would be grateful if someone can correct my syntax in the netlist since i'm trying to make a sweep HB  simulation where the input power is the parameter.

i did it without any error for the sp (S parameters)  simulation.

you can see the images for both sp and hb simulation netlists. (from left to right: sp aging netlist; hb aging netlist)

i will be grateful if someone can provide me some syntax advices.

thanks,

best regards

hello there, i'm a student studying allegro PCB designer.

There are some commands that i can do with GUI, but i want to know what kind of commands i used so that i can route with commands only(ex) skill).

Is there any file that i can see what kind of commands i used something like log files or command history?

thank you for reading this long boring question.

We have many legacy board designs which have non-standard films. I'm writing SKILL code to automatically align a board's film records with our internal standard.

While I'm sure there will be multiple questions, here are the first two I've run into:

1. It seems the polyCutLayer parameter of axlFilmCreate() doesn't work. You can easily see this for yourself. Try typing "axlFilmCreate("test" ?polyCutLayer nil)" on the command window in Allegro. I'm returned "nil", indicating the film could not be created, and I see "*WARNING* (axlFilmCreate): Invalid option type: ?polyCutLayer" in the command window. Just to try a different parameter and see that it works, try "axlFilmCreate("test" ?negative t)". I'm returned a "t" and the film is created. Page 139 of 17.4-2019 algroskill.pdf shows this parameter and I can see it listed if I inspect an existing from from the DB, so what gives? Is the polyCutLayer parameter broken when creating films?

2. In conjunction with the above, if I loop through all current films and use axlDeleteObject() to remove them all, and then try to create new films but give an argument to the polyCutLayer parameter, films containing copper layers seem to be automatically created. There are four films (my test board has four layers) with the ETCH/, PIN/, and VIA CLASS/ subclasses. I am able to manually delete all films and see absolutely no films at all. Is there something weird going on here or is this to be expected for some reason?

I'm running Allegro 17.4s002.