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. ]]

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.

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.  :-) )

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

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,

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, 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.

I have a script to handle many polys in memory in allegro. 

But after the completion of the script, 

I run the axlPolyMemUse(), it reports (31922 0 0 55076 252482)

Seems too many polys are still in the memory，and they are not being used. 

So how to delete these polys from the memory? And reclaim the memory?

BTW. I have no skill dev license. So gc() function doesn't work. 

Thanks.

I am working on some SKILL scripts which are loaded by allegro.ilinit at startup.

If I edit my .il-files how do I get them updated in Allegro?

Right now I restart the program but there must be a simpler way.

A newbie question, I know...  

Hi guys,

eDave,

I need to call (replay) a skill to combine some skills to ONE UI for more convenience and using as more easier.

Please help me to find the command to execute this.(code for example as more good)

HT,

Hi 

I'm trying to find the location of the assembly line in the design automatically without using "Show Element". And also I want to find the end points of that line. The line exists in "Package Geometry/Assembly_Top" Layer. So is there any code snippet to find the location of assembly line?

Hi All,

I'm trying to understand checkpoint concept. When I found save and restart concept in cdnshelp, There is just describing about "$save" and "xrun -r "~~~".

and I found also the below link about save restart and it saves your time.

But I can't find any benefits from my experiment from save&restart article( I fully agree..the article)

Ok, So I'v got some experiment  Here.

1. I declared $save and got the below result as I expected within the simple UVM code.

In UVM code...

$display("TEST1");
$display("TEST2");
$save("SAVE_TEST");
$display("TEST3");
$display("TEST4");

And I restart at "SAVE_TEST" point by xrun -r "SAVE_TEST", I've got the below log

xcelium> run
TEST3
TEST4

Ok, It's Good what I expected.(The concept of Save and Restore is simple: instead of re-initializing your simulation every time you want to run a test, only initialize it once. Then you can save the simulation as a “snapshot” and re-run it from that point to avoid hours of initialization times. It used to be inconvenient. I agree..)

2. But The Problem is that I can't restart with modified code. Let's see the below example.

I just modified TEST5 instead of "TEST3"

$display("TEST1");
$display("TEST2");
$save("SAVE_TEST");
$display("TEST5"); //$display("TEST3");
$display("TEST4");

and I rerun with xrun -r "SAVE_TEST", then I've got the same log

xcelium> run
TEST3
TEST4

There is no "TEST5". Actually I expected "TEST5" in the log.From here We know $save can't support partially modified code after $save. 

Actually, through this, we can approach to our goal about saving developing time. 

So I want to know Is there any possible way that instead of re-initializing our simulation every time we want to run a test, only initialize it once and keep developing(debugging) our code ?

If we do, Could you let me know the simple example?

Hi all,

         I want to know how to run a regressive test in cadence and merge all ncsim .trn file of each test case into a single file to view all waveform in simvision. I am using Makefile to invoke the test case.

         eg:-

               test0:

                     irun -uvm -sv -access +rwc $(RTL) $(INTER) $(PKG) $(TOP) $(probe) +UVM_VERBOSITY=UVM_MEDIUM +UVM_TESTNAME=test0

             test1:

                   irun -uvm -sv -access +rwc $(RTL) $(INTER) $(PKG) $(TOP) $(probe) +UVM_VERBOSITY=UVM_MEDIUM +UVM_TESTNAME=test1

          I just to call test0 followed by test1 or parallel both test and view the waveform for both tests case.

        I new to this tool and help me with it

Hi all,

I need to develop a digital design/verification solution to compile,elaborate and simulate SV designs (basically a complex xrun wrapper). I am an experienced user of xrun and I have done a number of these wrappers over the years but this one is to be more of a tool, intented to be used Company-wise, so it needs to be very well thought and engineered.

It needs to be robust, simple and extensible. It needs to support multi-snapshot elaboration, run regressions on machine farms, collect coverage, create reports, etc.

I've been browsing the vast amount of documentation on XCELIUM and, although very good, I can't find any document which puts together all the pieces of what I am trying to achieve. I suppose I am more clear on the elaboration, compilation and simulation part but I am really lacking on the other areas like : LSF, regressions coverage, where does vManager fits in all this, etc.

I'd appreciate if someone can comment on whether there is a document which depicts how such a DV flow can be put together from scratch, or whether there is a kind of RAK with some example xrun wrapper.

Thanks

Hi,

I am facing this elaboration error when using Xcelium:

Command>

    xmverilog -v200x +access+r +xm64bit -f vlist -reflib plib -timescale 1ns/1ps

Log>

    xmelab: *E,CUVMUR (<name>.v,538|18): instance 'LUTP0.C GLAT3' of design unit 'tlatntscad12' is unresolved in 'worklib.LUTP0:v'.

I guess the plib was not referred to as the simulation configuration because the tlatntscad12 is included in plib.

The plib is compiled by INCISIVE 13.20 and I am using the Xcelium 19.30.

Please tell me the correct command on how to refer to the library directory compiled by different versions.

Thank you,

I am importing sessions which are run by other people to analyse and I would like to remove them from my vManager Regressions tab as they become obsolete. As I am not the original person who run the sims, I cannot "delete" sessions. What are my options? Thanks.

When I run simulation with irun, it may use may license features. How can I know which feature(s) a product use? I get below message in cdnshelp:

-------------------------------------------------------------

Which Products Are in the License File?

One Cadence product can require more than one license (FEATURE). The product to feature mapping in the license file lists the licenses each product needs.

For example, if the license file lists these features for the NC-VHDL Simulator:

Product Name: Cadence(R) NC-VHDL Simulator
#
Type: Floating Exp Date: 31-jul-2006 Qty: 1
#
Feature: NC_VHDL_Simulator [Version: 9999.999]
#
Feature: Affirma_sim_analysis_env [Version: 9999.999]

-------------------------------------------------------------------

But, in my license file, I can't find such info. There is only "FEATURE" lines in my license file. How can I get product to feature mapping info?

Thanks!

In the Allegro back-end layout products like Allegro Package Designer Plus, it would be reasonable to assume that the most often used command is none other than “show element” (shortcut key F4). This command, runnable at nearly any t...(read more)

Sample clues

18 across: Makoto Hagiwara and David Jung both claim to have invented it (7,6)

1 down: French impressionist who rejected that term (5)

3 down: Artificial surface used for playing hockey (9)

7 down: The sequel to Iliad (7)

12 down: Adipose tissue (4,3)

Extrowords © 2007 IndiaUncut.com. All rights reserved.
India Uncut * The IU Blog * Rave Out * Extrowords * Workoutable * Linkastic

Sample clues

6 across: Franchise revived by Frank Miller (6)

13 across: What Keanu Reeves and Zayed Khan have in common (5)

18 across: What Frank Sinatra and George Clooney have in common (6,6)

19 across: Dosa mix, for example (6)

2 down: Green, in a non-environmental way (7)

Extrowords © 2007 IndiaUncut.com. All rights reserved.
India Uncut * The IU Blog * Rave Out * Extrowords * Workoutable * Linkastic

Sample clues

5 down: Torso covering (6)

7 down: Government by rogues (12)

15 across: eBay speciality (7)

18 across: Demonic (8)

20 across: Common language (6,6)

Extrowords © 2007 IndiaUncut.com. All rights reserved.
India Uncut * The IU Blog * Rave Out * Extrowords * Workoutable * Linkastic

Sample clues

17 across: Beckham speciality (4,4)

4 down: Havana speciality (5)

19 across: Infamous 1988 commercial against Michael Dukakis (9,4)

11 down: Precisely (2,3,3)

13 down: City infamously ransacked by the Japanese in 1937 (7)

Extrowords © 2007 IndiaUncut.com. All rights reserved.
India Uncut * The IU Blog * Rave Out * Extrowords * Workoutable * Linkastic

Sample clues

11 across: Chandigarh’s is 0172 (3,4)

21 across: He’s a loser, baby (4)

1 down: Garment meant to shape the torso (6)

12 down: It’s slogan: “Life, Liberty and the Pursuit” (8)

18 down: Noise made by badminton players? (6)

Extrowords © 2007 IndiaUncut.com. All rights reserved.
India Uncut * The IU Blog * Rave Out * Extrowords * Workoutable * Linkastic

Sample clues

5 across: The US president’s bird (3,5,3)

11 down: Group once known as the Quarrymen (7)

10 across: Cavalry sword (5)

19 across: Masonic ritual (5,6)

1 down: Pioneer of Ostpolitik (6)

Extrowords © 2007 IndiaUncut.com. All rights reserved.
India Uncut * The IU Blog * Rave Out * Extrowords * Workoutable * Linkastic

Sample clues

14 across: FDR’s baby (3,4)

1 down: A glitch in the Matrix? (4,2)

4 down: Slanted character (6)

5 down: New Year’s venue in New York (5,6)

16 down: Atmosphere of melancholy (5)

Extrowords © 2007 IndiaUncut.com. All rights reserved.
India Uncut * The IU Blog * Rave Out * Extrowords * Workoutable * Linkastic

Sample clues

6 across: Alejandro González Iñárritu’s breakthrough film (6,6)

19 across: Soft leather shoe (8)

7 down: Randroids, for example (12)

12 down: First American World Chess Champion (7)

17 down: Circle of influence (5)

Extrowords © 2007 IndiaUncut.com. All rights reserved.
India Uncut * The IU Blog * Rave Out * Extrowords * Workoutable * Linkastic

Sample clues

5 across: Robbie Robertson song about Richard Manuel (6,5)

2 down: F5 on a keyboard (7)

10 across: Lionel Richie hit (5)

3 down: ALTAIR, for example (5)

16 down: The problem with Florida 2000 (5)

Extrowords © 2007 IndiaUncut.com. All rights reserved.
India Uncut * The IU Blog * Rave Out * Extrowords * Workoutable * Linkastic

Sample clues

9 across: Van Morrison classic from Moondance (7)

6 down: Order beginning with ‘A’ (12)

6 across: Fatal weakness (8,4)

19 across: Rolling Stones classic (12)

4 down: Massacre tool (8)

Extrowords © 2007 IndiaUncut.com. All rights reserved.
India Uncut * The IU Blog * Rave Out * Extrowords * Workoutable * Linkastic

i had encountered error message like this before. 

but in liberate, i did not find the entry to input section info. 

Hi,

I tried to open my layout by Library Manager, but the Virtuoso CIW window sometimes pops up the follow WARNING messages( as picture depicts). Thus, layout can't open.

Sometimes, I try to reconfigure ICADV12.3 by the iscape and restart my VM and then it incredibly works! But, often not!

So, If anyone knows what it is going on. Please let me know! Thanks!

Appreciated so much   

Optimizing power can be a very convoluted and crucial process. To make design chips meet throughput goals along with optimal power consumption, you need to plan right from the beginning! (read more)

Several tools can generate power reports based on libraries & stimulus. The issue is what's NEXT?

• Is there any scope to improve power consumption of my design?
• What is the best-case power?
• Pin-point hot spots in my design?
• How to recover wasted power?

And here is the solution in form of Joules RTL Power Exploration. Joules’ framework for power exploration and power implementation/recovery is stimulus based, where analysis is done by Joules and is explored/implemented by user.

Power Exploration capabilities include:

• Efficiency metrics
• Pin point RTL location
• Cross probe to stim
• Centralize all power data

 Do you want to explore more? What is the flow? What commands can be used?

There is a ONE-STOP solution to all these queries in the form of videos on Joules Power Exploration features on https://support.cadence.com (Cadence login required).

Video Links:

How to Analyze Ideal Power Using Joules RTL Power Solution GUI? (Video)

What is Ideal Power Analysis Flow in Joules RTL Power Solution? (Video)

How to Apply Observability Don’t Care (ODC) Technique in Joules? (Video)

How to Debug Wasted Power Using Ideal Power Analyzer Window in Joules GUI? (Video)

Related Resources

Enhance the Joules experience with videos: Joules RTL Power Solution: Video Library

For any questions, general feedback, or future blog topic suggestions, please leave a comment. 

Analog and Mixed-signal (AMS) designs are increasingly using active power management to minimize power consumption. Typical mixed-signal design uses several power domains and operate in a dozen or more power modes including multiple functional, standby and test modes. To save power, parts of design not active in a mode are shut down or may operate at reduced supply voltage when high performance is not required. These and other low power techniques are applied on both analog and digital parts of the design. Digital designers capture power intent in standard formats like Common Power Format (CPF), IEEE1801 (aka Unified Power Format or UPF) or Liberty and apply it top-down throughout design, verification and implementation flows. Analog parts are often designed bottom-up in schematic without upfront defined power intent. Verifying that low power intent is implemented correctly in mixed-signal design is very challenging. If not discovered early, errors like wrongly connected power nets, missing level shifters or isolations cells can cause costly rework or even silicon re-spin. 

Mixed-signal designers rely on simulation for functional verification. Although still necessary for electrical and performance verification, running simulation on so many power modes is not an effective verification method to discover low power errors. It would be nice to augment simulation with formal low power verification but a specification of power intent for analog/mixed-signal blocs is missing. So how do we obtain it? Can we “extract” it from already built analog circuit? Fortunately, yes we can, and we will describe an automated way to do so!

Virtuoso Power Manager is new tool released in the Virtuoso IC6.1.8 platform which is capable of managing power intent in an Analog/MS design which is captured in Virtuoso Schematic Editor. In setup phase, the user identifies power and ground nets and registers special devices like level shifters and isolation cells. The user has the option to import power intent into IEEE1801 format, applicable for top level or any of the blocks in design. Virtuoso Power Manager uses this information to traverse the schematic and extract complete power intent for the entire design. In the final stage, Virtuoso Power Manager exports the power intent in IEEE1801 format as an input to the formal verification tool (Cadence Conformal-LP) for static verification of power intent.

Cadence and Infineon have been collaborating on the requirements and validation of the Virtuoso Power Manager tool and Low Power verification solution on real designs. A summary of collaboration results were presented at the DVCon conference in Munich, in October of 2018.  Please look for the paper in the conference proceedings for more details. Alternately, can view our Cadence webinar on Verifying Low-Power Intent in Mixed-Signal Design Using Formal Method for more information.

When the Arduino Mega2560 is added to the first serial port, the dynamic memory is 2000 bytes, and when the second serial serial is added, the dynamic memory is 4000 bytes. Now I need to add the third Serial serial port. The dynamic memory is 6000 bytes. Due to the many variables in the program itself, the dynamic memory is not enough. Please help me how to save the dynamic memory?

Since the release of the Automated Device Placement and Routing solution last year, we have continued to improve and build upon it. In this blog, I’ll talk about the latest addition—the Auto Device Array form—how this is an integral piece of the new Automated Device Placement and Routing solution.(read more)

The IC6.1.8 ISR10 and ICADVM18.1 ISR10 production releases are now available for download.(read more)

If you have one of those Die layouts, which doesn’t have bumps, but rather uses pad shapes and labels to identify I/O locations, then you might be feeling a bit left out of all of this jazz and tango. Hence, today, I am writing to tell you that, fear not, we have a solution for your Die as well.(read more)

visit News18 Urdu for latest news, breaking news, news headlines and updates from Lower Subansiri on politics, sports, entertainment, cricket, crime and more.

India Lockdown: ફસાયેલા લોકોને ટ્રેનથી જવાની કેન્દ્ર સરકારે આપી મંજુરી

Modi સરકારે ત્રીજી વખત Lockdown માં કર્યો વધારો, જાણો કેટલા દિવસ સુધી રહેશે લોકડાઉન ?

લૉકડાઉનને (Lockdown Part 3)4 મે થી આગામી બે સપ્તાહ સુધી વધારવાની જાહેરાત કરવામાં આવી છે. એટલે કે 17 મે સુધી લૉકડાઉન રહેશે

આજથી દેશભરમાં Lockdown 3.0 નું પ્રારંભ, શરતોના આધારે અપાશે છૂટછાટ