AUGER, the First User Group Meeting for Agnisys

AUGER, the First User Group Meeting for Agnisys
by Daniel Nenni on 04-01-2021 at 10:00 am
Categories: Agnisys, EDA, Events

As a long-time member of the EDA community, I really believe in user groups. EDA tools are complicated beasts, with many options and different ways to use them, and they are constantly evolving. Users interact with their local field applications engineers (FAEs) and sometimes corporate AEs (product specialists) as well on a regular basis. But there is a lot of knowledge on how best to use tools in the R&D teams that develop them. There’s also a great deal of experience spread among the user base, but it’s uncommon for users from different companies to talk directly.

User group meetings are a great way to get a critical mass of users, AEs, and R&D engineers together in one place. It’s best if they’re held in person so that all the participants can interact informally during breaks and meals in addition to the technical sessions. Of course, for now almost every type of meeting and conference is virtual. I was pleased to learn that Agnisys recently held its first-ever user group meeting, which they dubbed AUGER for some mysterious reason. I talked with CEO and founder Anupam Bakshi to find out the scoop.

What is AUGER and what does the acronym mean?

It stands for Agnisys User Group Educational Roundtable, and it is for the most part a traditional user group meeting. It was virtual, as you’d expect right now, but it was a really successful event. There’s also a bit of a pun involved since we wanted to drill down (auger) into technical details and not just present a bunch of fluffy sales/marketing slides.

What were your goals?

It seems to me that there are three key forms of communication that should occur in a user group meeting: vendor to user, user to vendor, and user to user. The host vendor should present updates on new tools and features, often directly from members of the R&D team, and provide guidance on best practices for using the tools, usually from the field and corporate AEs. The CEO should also offer a company vision and talk about future directions. Second, the vendor wants to hear from the users. It’s really nice to have some user presentations where they share their own experiences and best practices. There should also be a feedback session where the users suggest new tools, features, and support mechanisms to make their lives easier. Last but certainly not least, the users need to interact with each other. That’s harder to accomplish in a virtual format, but we included a roundtable slot where anyone could talk about anything related to Agnisys.

What sort of topics were covered in the technical sessions?

Our engineering team worked hard to develop brand-new slides with the latest and greatest information. Our engineering head summarized the most recent tools and features, many of which were suggested directly by our users. We had a second talk focusing deeply on the latest properties and customizations available for users to tailor our tools to meet their specific needs and fit into their design and verification environments. As you know, we started as a register automation company and this area remains a big part of our business. Accordingly, we held a session dedicated to the quality checks that we do on the register maps provided by users. The more accurate the input maps are, the better the results that we generate for RTL design, UVM testbench verification, embedded C/C++ code, system validation, and documentation. Finally, we had a presentation on how our tools can be used to ensure functional safety and security in chip designs, a hot topic in these days of increasingly autonomous vehicles.

Did the interaction with the users go well?

Honestly, it exceeded my expectations. I have to admit that I was a bit worried about the roundtable, wondering what we would do for 30 minutes if no one spoke up. Fortunately, that was not the case. We had a great facilitator in Tom Anderson, who ensured that we had a lively discussion. We had participation by users from multiple companies, and I was really pleased with that. The attendees were also active participants in the technical sessions, asking lots of good questions. A user from Intrinsix presented an excellent case study on how they benefit from our tools, and other users shared experiences during the roundtable.

Is there anything you might change for future events?

Well, we fervently hope that the pandemic subsides and that we will be able to meet in person next time. We plan on a hybrid event so that users unable or unwilling to travel can still participate. It might make sense to hold multiple events in different regions where we have concentrations of customers. We also hope to add a few more user talks; this first AUGER was developed on a rather tight schedule and not everyone had time to prepare slides. Overall, I expect that we will do many of the same things we did this year because they worked so well.

For those who missed the event, is it possible to access the talks?

Absolutely! We recorded everything, including the roundtable, and it is available on demand. To register, just go to https://www.agnisys.com/events/auger-2021/.

Also read:

Automatic Generation of SoC Verification Testbench and Tests

Embedded Systems Development Flow

April 1, 2021March 16, 2022

Bouncing off the Walls – How Real-Time Radar is Accelerating the Development of Autonomous Vehicles

Bouncing off the Walls – How Real-Time Radar is Accelerating the Development of Autonomous Vehicles
by Jeffrey Decker on 04-01-2021 at 6:00 am
Categories: Ansys, Inc., EDA

In the race to get people out of the driver’s seat, the developers of autonomous vehicles (AV) and advanced driving assistance systems (ADAS) have gone off road and into the virtual world.

Using simulation to design, train and validate the brains behind self-driving cars — the neural networks of sensors and systems that perceive the world then react to split-second changes in the environment — is an essential tool for building the AV/ADAS platform.

Without simulation, developers are limited to naturally occurring events on public roads as their proving grounds. That means they’d spend far more time and money creating specific scenarios to test that sensors recognize and algorithms respond appropriately and safely to routine and hazardous conditions: red lights, pets and wildlife, oncoming traffic, or a child darting into the street.

Real-world driving and simulation work together to advance ADAS/AV technology. Real-world driving data is an important measure of road-worthiness and system intelligence, and it provides additional inputs to improve their algorithms. Simulation complements on-road testing with its ability to run orders of magnitude more scenarios and challenging events that are rare in real-world driving but essential to get right.

CNET writer Kyle Hyatt describes how simulation technology gives Alphabet’s Waymo engineers the capacity to “simulate a century’s worth of on-road testing virtually in just a single 24-hour period.” Another way of looking at it: It took Waymo 10 years to log 20 million actual driving miles, and a single year to simulate 2.5 billion.

As valuable as simulation is, sometimes it needs to pick up the pace, too.

That’s where the real-time radar (RTR) simulation engine takes the wheel. Ultra-fast and physics-based RTR can accomplish in minutes what used to take days.

Images Made Faster than Ever

Along with LIDAR, cameras and ultrasonic sensors, the typical AV also has multiple radar sensors for short-, medium-, and long-range sensing tasks. Long-range radars monitor traffic down the road for adaptive cruise control and collision avoidance. Shorter range sensors handle blind spots, cross traffic, and collision avoidance.

Traditionally, central processing units (CPUs) were used for automotive radar simulations. CPU architecture is fast, but not nearly fast enough to simulate complex radar systems at real-time frame rates.

Radars sample the world at up to 30 frames per second (fps). Automotive radars have multiple transmitters that broadcast hundreds or thousands of radar chirps and multiple receiving antennas that measure those signals at hundreds of frequencies for a single frame of data. Multiple-input multiple-output (MIMO) radars measure millions of data points per frame – hundreds of channels, chirps per channel, and frequencies per chirp. That’s all for one radar, and autonomous vehicles have multiple radars.

Caption: Range-Doppler image of busy street shows the radar mounted on the white car detecting distance (range) and relative velocity (Doppler) of objects from a moving vehicle.

CPU-based simulation requires up to a minute to simulate one frame of data from one radar, even with new algorithms invented by Ansys. A revolutionary leap forward is needed.

Ansys’ Real-Time Radar (RTR) overcomes these limitations with graphics processing units (GPUs) . The combined power of Ansys simulation and NVIDIA GPU acceleration can not only generate data from single-channel, multi-channel, and MIMO radars, it generates images faster than real-time. Scenarios that took days, months, or years to simulate before RTR are possible in seconds or minutes. Single-channel radars are over 5000x faster. MIMO radars that would have taken so long to simulate that we never tried also run thousands of times faster.

Radar perception algorithms detect buildings, curbs, and other street-level objects of interest from RTR range-Doppler imagery. The range-Doppler imagery is shown in the lower left quadrant with waterfall plots above and to the right. Post-processed ISAR imagery is shown in the upper right.

Real-Time Simulation Enables New Applications

Ansys engineers are using RTR to create amazing new capabilities, and the difference is astonishing.

Setting up a scenario at Waymo (picture courtesy CNET): https://www.cnet.com/roadshow/pictures/waymo-castle/3/

For example, Ansys RTR took just 11 seconds to simulate a car with five radars at 250 fps traveling down a 1-kilometer (0.6-mile) busy street for a 20-second scenario using an NVIDIA RTX A6000 GPU. Because safe urban driving means contending with all kinds of hazards and distractions, we packed our scenario with 70 vehicles, 14 buildings, over 300 streetlights and a nightmarish 42 traffic signals.

Ansys RTR simulates a vehicle with five radars at over 250 fps in a busy urban environment.

Before RTR, that same simulation would have taken more than 25 hours. If that seems like a vast improvement, consider this: Before Ansys developed new algorithms for Doppler processing, the simulation would have taken more than four years. RTR cuts simulation time to 11 seconds and maintains 57 fps for five radars, far faster than the 30 fps real-time metric. This 8000x speedup compared to 25 hours and nearly 3 million times speedup over four years.

“With real-time radar, high-fidelity simulation is no longer a barrier in the development of ADAS data pipelines. Radar sensor data can be generated at a rate never thought possible for physics-based simulations.”

Arien Sligar, senior principal application engineer, Ansys

RTR’s dramatic performance improvement has already paid off as an enabling technology in downstream analysis. Labeling images – identifying locations of objects such as people, cars, and buses in a radar image – is a time-consuming effort when done by hand. RTR users produced more than 160,000 labeled images overnight with RTR compared to 9,000 images in five days with slower simulation or several dollars per image labeling by hand.

Ansys engineers also connected RTR to a machine learning algorithm to teach a car to drive through reinforcement learning. Ansys principal application engineer Dr. Kmeid Saad conducted a week-long webinar, Reinforcement Learning with Physics-based Real Time Radar for Longitudinal Vehicle Control, that trained a throttle-control algorithm using GPUs on Microsoft’s Azure cloud. RTR simulated radar returns at a faster-than-real-time 50-60 fps on one GPU while three other GPUs ran the driving simulator and machine learning.

Physics-Based Simulation Built on Established Methodology

The RTR simulation engine is based on the well-established shooting-and-bouncing-rays (SBR) technique for large, high-frequency scenes. RTR generates range-Doppler images that display the distance and relative velocity of objects in driving scenarios under various traffic conditions. SBR models radar reflection off objects, multi-bounce propagation through the scene, material properties, transmission through windows, and radar antenna patterns. RTR incorporates all of these real-world interactions to produce physics-based simulation results.

RTR simulates both range-Doppler images and “raw” radar chirp versus frequency data. Raw data is used post-processing like angle-of-arrival (AoA), inverse synthetic aperture radar (ISAR), object detection, perception, and object classification analysis.

RTR models radar waveforms, which influence the radar outputs. The frequency modulated continuous wave (FMCW) waveform is common in automotive radars. RTR users enter waveform details from the radar’s specification, and RTR outputs capture physics specific to the waveform, such as range-velocity coupling.

Being able to measure the target range and its velocity has considerable practical applications, not the least of which is keeping the AV from bumping into the car in front of it as it slows or if it suddenly stops. Given that studies indicate AVs are involved in rear-end collisions more than any other type of accident, training forward sensors to detect when there’s danger ahead is critically important.

Trained for Any Situation

Human error contributes to 94 percent of severe traffic accidents according to the U.S. Department of Transportation’s National Highway Traffic Safety Administration (NHTSA). The ADAS/AV community is working to make ADAS/AV systems safer than humans by eliminating the preoccupied, tired, or careless person behind the wheel.

At the same time, ADAS/AV systems lack human intuition and experience. People can differentiate whether a hazard up ahead is harmless litter to ignore, a stick in the road to swerve around, or a more serious roadblock that requires jamming on the brakes. Currently, most ADAS/AV systems cannot yet make the distinction.

But the day when they can might not be too far off. With ultra-fast tools like RTR, which can model radar bouncing off the walls and through the windows with Autobahn-like speed, automakers will be able train driverless cars to handle almost any situation, including scenarios that were impossible to model before. And that will put consumer confidence and acceptance into high gear.

ANSYS will discuss the new RTR solver and show results of automotive scenarios in busy, complex environments at the Nvidia GTC Conference April 12-16. Click to register.

For more presentations on autonomy, attend Ansys Simulation World, April 20-22. Click to register.

To learn more about Autonomous Vehicle Safety click here.

Also Read

The Electromagnetic Solution Buyer’s Guide

Electromagnetic and Circuit RLCK Extraction and Simulation for Advanced Silicon, Interposers and Package Designs

Need Electromagnetic Simulations for ICs?

March 31, 2021April 19, 2021

VersionVault EDA Integration: A Differentiated Value Solution

VersionVault EDA Integration: A Differentiated Value Solution
by Kalar Rajendiran on 03-31-2021 at 10:00 am
Categories: EDA, HCL Software

Capabilities and Benefits from Integration

HCL Technologies is a large, well-established multi-national company with an annual revenue of around $10B and worldwide employee count of well over 150K. They provide valuable solutions to about 20 different industries and related market segments. Over the years, I have had first hand insights to their semiconductor design services solutions but had not heard of VersionVault. Over the course of the last 12 months or so, there has been many writeups about HCL’s VersionVault software. Following is a summary what I gathered by researching VersionVault. The primary focus of this blog is to complement what was covered in a very recent blog by Manish Virmani, general manager at HCL Software Labs.

Before my research got underway, I figured VersionVault must be a product related to version control system. That turned out to be just the tip of the iceberg.

VersionVault offers a safe, secure and powerful configuration system that provides controlled access to soft assets, including code, requirements, design documents, models, schematics, test plans and test results and enables ease of hardware/software co-development. It allows for tracking and managing changes for all of a product’s assets throughout the entire lifecycle of the product.

As good a product VersionVault is in terms of its built-in capabilities, its value to semiconductor and EDA customers is further differentiated through its integration to EDA tool suite platforms. It is currently integrated with Cadence Virtuoso platform and exploring integrations with more EDA tool suites including Synopsys Custom Compiler.

Figure 1: VersionVault Virtuoso Integration

Source: HCL Software Labs

In addition to features (refer to Figure 1) such as Interactive graphical schematic diff, command-line interface, hierarchical design management through a GUI, common tooling for SW and HW teams, etc., VersionVault also offers the following, not very obvious, nonetheless very important benefits depending on your particular role in the organization. Your role may be as a developer, engineering manager, project manager, QA manager, field support engineer, support manager, IT manager, CIO or CTO.

Ease of Adoption and Consistent Use

For ease of adoption and consistent use in practice, anything new should fit into the regular workflow. Seamless integration with EDA tool suite enables designers to take advantage of core capabilities of VersionVault, without leaving their familiar design environment.

Handling Multiple Versions of Product

Software products typically support multiple versions in the market at any given time. An engineer needs to be able to quickly switch between one development setup on version 1 to another development setup on version 2. Developers should be able to visualize the difference in versions across streams. VersionVault’s Unified Change Management feature makes that possible and enhances developer’s productivity.

Compliance to Procedures and Effective Management

Need for compliance to procedures and desire for minimal overhead is a delicate balancing act. VersionVault provides controlled access to soft assets, including code, requirements, design documents, models, schematics, test plans, and test results. User authentication and authoritative audit trails capabilities help meet compliance requirements with minimal administrative overheads.

Role-based Access and Control

As a company, you want a tool that can control access to IP based on one’s role on a project-level basis rather than just at the user-level basis. VersionVault allows you to create role-based specifications of access control, and reuse that specification across teams by assigning users to roles for each team. Access control can be modified at any level of the asset hierarchy, or inherited through the hierarchy if desired.

VersionVault provides effective authoritative build auditing. It helps streamline the edit-build-debug cycle and accurately reproduces software versions. By detecting dependencies, reusing derived objects wherever possible and producing detailed build audit trails, it helps ensure the reproducibility of software versions and improve build performance. To recreate a result, for debugging purposes or for analysis and review by a third party, this information is important.

Auditing and Compliance Support

For projects within regulated industries which require every change to be captured and logged, VersionVault makes it effort-less to comply. Every build of a “derived object” can automatically create a configuration record with every tool version and every file version used in its creation recorded. The configuration record may then be used for comparison purposes when a build goes bad, making it very easy to find what change caused the problem. Every configuration, which may consist of hundreds of thousands of files, can be recreated instantaneously, whether the configuration was created yesterday, or a decade ago.

Fitting Name

The product name VersionVault is a two-word mashup. When we come across the word “vault”, a common imagery that pops in our head is of “bank vault”. Based on that, it is not unreasonable for one to think of VersionVault as just a safe and secure way to perform versioning. But as highlighted in this blog, VersionVault is much more than that. Out of curiosity, I looked up the word vault for synonyms and discovered that it has so many different synonyms. Some of the synonyms are bound (as in leaps and bounds), leap, rise, safe, soar, and structure. This expanded definition seems to be more descriptive of the scope and extent of the capabilities of the product.

You may want to do your own evaluation of VersionVault for consideration as a solution for use at your organization.

March 31, 2021March 25, 2022

Formal for Post-Silicon Bug Hunting? Makes perfect sense

Formal for Post-Silicon Bug Hunting? Makes perfect sense
by Bernard Murphy on 03-31-2021 at 6:00 am
Categories: EDA, Siemens EDA

You verified your product design against every scenario your team could imagine. Simulated, emulated, with constrained random to push coverage as high as possible. Maybe you even added virtualized testing against realistic external traffic. You tape out, wait with fingers crossed for first silicon to come back. Plug it into the test board and everything looks good – until an intermittent bug sneaks in. After much head scratching, you isolate a problem to read/write re-ordering misbehavior around the memory controller. Now you have to try to reproduce the problem in pre-silicon verification. Hunting for a bug you missed. But formal for post-silicon bug hunting? That’s not as strange as you might think.

Out of control

You know where this is going. There’s an interconnected set of state machines mediating interaction between the interface control unit, the buffer unit and the memory controller. In some overlooked and seemingly improbable interaction, old data can be read before a location has been updated. Not often. In the lab you only see a failure intermittently, somewhere between every 2 to 8 hours. Not surprising that you didn’t catch it in pre-silicon verification. I’ve seen similar issues crop up around cache coherence managers and modem controllers.

This is where formal methods can shine, finding obscure failures in complex state machine interactions. But in this application, you’re not setting out to prove there are no possible failures – that’s pre-silicon verification. Here you want to hunt for a bug you know must exist. That takes a different approach, one that won’t present any great challenge to formal experts but can be a frustrating search for a needle in a haystack for most of us. Through much experience Siemens EDA have developed a systematic approach they call a Spiral Refinement Methodology that should help you find that needle, without losing your mind.

Spiraling through a radar chart

They graph this refinement in a radar chart (the image in this blog is an example). The search progresses through multiple objectives at several levels. They start by reducing complexity to make formal analysis possible. Since the debug approach is formal, you first need to localize where, functionally, in the design the failure is happening. This insight typically emerges through bug triage in the lab. Then you can eliminate big chunks of the design that should not be important. And perhaps (carefully) add constraints. You will need access to formal experts, internal or external, to guide you away from pitfalls. Particularly as you start to abstract or divide up the problem to further manage complexity.

Assertions and initial state

Another key objective is to refine assertions towards the failing condition. One technique they mention here is “formal goal-posting”. This is a method to progress towards a condition through a sequence of proofs which allow you to step out through the state-space in digestible chunks, rather than trying to do the whole thing in one impossible leap. Along similar lines, they stress the importance of finding a suitable initial state to start proving cycles. For bugs that may not crop up for several hours, you’ll need to start close in the time, not just in space (function). Simulation can get you there, to set up that initial state.

Then they refine each of these objectives. Further abstractions, further tuning assertions, finding more suitable initial states. Zeroing in on a sequence or set of sequences that can lead to that failure detected in the lab. They describe application to three example failures, including this one. In each case localizing the problem through a very systematic search.

Very nice paper. You can read it HERE.

Also Read:

Library Characterization: A Siemens Cloud Solution using AWS

Smarter Product Lifecycle Management for Semiconductors

Observation Scan Solves ISO 26262 In-System Test Issues

March 30, 2021March 25, 2022

WEBINAR: Pulsic’s Animate Makes Automated Analog Layout a Reality

WEBINAR: Pulsic’s Animate Makes Automated Analog Layout a Reality
by Tom Simon on 03-30-2021 at 10:00 am
Categories: EDA, Events, Pulsic

Many years ago, digital and analog design flows diverged, with digital design benefiting from increasing levels of automation and more importantly separation between the front-end design process and the back-end design process. While digital design still requires linkages between the front and back end, they are well defined and the existing flows handle them in a straightforward manner. The same cannot be said for analog design. Despite the many advances in custom layout tools and improvements in the entire analog design flow, the dependencies between front-end and back-end have remained challenging along with the intricacies required in analog layout on its own.

Pulsic has a long history of providing design tools that can help improve the quality of custom digital designs and have recently turned their focus to solving the long-standing challenges of automating the analog design process. Their Animate Preview product can be used right from inside the Cadence schematic editor to begin creating and understanding the circuit layout. Because layout considerations are critical to design success, having insight and control of the physical design helps speed up the process and improve final design quality at the same time.

Paul Clewes of Pulsic gave me a detailed look at Animate Preview and talked about their upcoming webinar on April 15th. Animate is integrated with Virtuoso and when launched adds a preview window in the lower left corner of the schematic editing view. Animate will automatically detect when an analog circuit is loaded and then identify common structures such as differential pairs, current mirrors, matched pairs, etc. Animate will generate a layout on the fly and display it in the preview window.

Quite a lot happens when this layout is generated. Users do not need to specify constraints, the current technology information is used to create DRC correct results. The resulting layout is DRC correct and fully compatible and editable in Virtuoso. Because Animate is aware of the structures mentioned above, it is smart when it comes to placing devices. The webinar will show several examples of how Animate intelligently places devices to ensure optimal circuit operations.

Analog circuit designers can get quick and accurate area estimates and can then go into the Animate user interface to easily and graphically control device placement, guard ring configuration, dummy device location, etc. It is easy to modify the guard rings and dummy devices as well as control relative positions for devices. Each change made in the user interface triggers an update to the layout inside of Animate.

Users can also select from a variety of aspect ratios and also assign pins to the desired edge of the cell. Under the hood Animate is creating a DRC correct layout with proper spacing. From the user’s perspective it is a bit like using a drag and drop editor, but one intended for analog layout design. My first thought was about how WYSIWYG html editors hide the underlying html but let you move blocks easily to achieve the results you desire.

After talking with Paul, it was clear that Pulsic is onto something with Animate Preview. Because the layout of analog circuits is so important during circuit design, giving the circuit designer a tool to see and control the layout is going to help immensely. A lot of companies have taken a run at solving this problem, but there is a subtle combination of automation and direct control required to come up with a feasible solution. To make your own assessment of how useful this might be, feel free to watch the video here.

Also Read:

CEO Interview: Mark Williams of Pulsic

Analog IC Layout Automation Benefits

Webinar: Boosting Analog IC Layout Productivity

March 30, 2021November 21, 2022

Webinar: Rapid Exploration of Advanced Materials (for Ferroelectric Memory)

Webinar: Rapid Exploration of Advanced Materials (for Ferroelectric Memory)
by Tom Dillinger on 03-30-2021 at 6:00 am
Categories: EMD Electronics, Events, Intermolecular, Semiconductor Services

There are many unsung heroes in our industry – companies that provide unique services and expertise that enable the rapid advances in fabrication process development that we’ve come to rely upon. Some of these companies offer “back-end” services, assisting semiconductor fabs with yield diagnostic engineering and failure analysis. Some are “front-end” companies that pursue advanced research into promising new materials and processing techniques, and then assist with technology transfer to production manufacturing. We tend to focus on the large semiconductor foundries and their process roadmaps, yet the underlying support from these engineering firms is fundamental to the industry as a whole.

An exemplary front-end services company is Intermolecular, the Silicon Valley science hub of the EMD Electronics. They offer process development research and characterization services, spanning a wide range of materials – e.g., metal alloys, oxides/nitrides, thin films for specialized applications.

With each new process node, extensive investigations into new materials are pursued, to determine the optimum stoichiometry and electrical properties. This is especially evident in the pursuit of alternative memory technologies. A specific example is the introduction of new ferroelectric materials for very high density, non-volatile data storage.

Background

A ferroelectric material is a special dielectric, in that it exhibits two (stable) remanent polarization states. The figure below illustrates the hysteresis curve of the crystalline polarization when an applied voltage is cycled across the dielectric – note the two intersections of the curve with the vertical axis when the applied voltage is zero, representing the stored “state” of the material.

The polarization is the contribution of the electric dipoles in the material to the electric flux between the terminals in the presence of an electric field. The formula for the dielectric constant in the material is: epsilon = (epsilon_0 + P/E), where epsilon_0 is the dielectric constant of free space, P is the polarization in the material, and E is the applied field. The curve for a conventional, non-ferroelectric material would be a straight line through the origin – i.e., no polarization when the applied voltage is removed.

Note in the figure that the chemical bond orientation in the material differs slightly in the two states, resulting in the remanent polarization.

(The term ferroelectric is a bit misleading – there is no iron (Fe) constituent in the dielectric material. The hysteresis curve of the dielectric polarization resembles the curve of a ferromagnetic material in the presence of an applied magnetic field. After the external field is removed, the ferromagnetic material retains a magnetic polarization. When the concept of remanent electrical polarization in a dielectric was first demonstrated, the term ferroelectricity was introduced, which has lasted.)

The two polarization states of the ferroelectric material suggest that it may be used as part of a memory bit circuit implementation. The figure below illustrates a couple of potential implementations:

One depicts the ferroelectric material as a replacement for the storage capacitor in a 1T1C bitcell. Unlike a conventional DRAM, note that no refresh of storage charge due to leakage current is required – data storage is represented by a dielectric polarization state, not by the amount of charge stored on the bitcell capacitance. The other implementation depicted above shows the ferroelectric material directly integrated in the dielectric gate stack of a field-effect transistor. The two polarization states of the material will result in different threshold voltages for the device, representing the stored data value.

As you might imagine, the crystalline properties of the dielectric material are crucial to the magnitude of the polarization states and the opening of the hysteresis curve.

Intermolecular Webinar on Ferroelectric Materials Optimization

I had an opportunity to view an outstanding webinar from Intermolecular, describing their recent investigations into ferroelectric materials. Their prototype fab capabilities provided atomic level deposition (ALD) of a variety of hafnium oxide (HfO2) and zirconium oxide (ZrO2) films.

An image from the webinar is shown below, for the case of HfO2. There are three crystalline topologies for these oxides, however only one demonstrates attractive ferroelectric behavior.

It is therefore necessary to ensure the process flow for depositing (and crystallizing) the film results in a very high percentage of material with the desired crystalline structure.

Another process experiment pursued by the Intermolecular team evaluated the ferroelectric properties of a stoichiometric mix of hafnium and zirconium in the dielectric in a single thin film, as well as stacking separate ALD-deposited HfO2 and ZrO2 layers.

Even if you’re not directly involved in advanced process development, I would encourage you to view this webinar presentation from Vijay Narasimhan at Intermolecular. It is extremely informative, starting with the basics of ferroelectricity, and offering insights into the R&D flow for materials evaluation – e.g., deposition/annealing, crystalline spectroscopy, and electrical characterization.

Here is the webinar replay link.

Here is a link to more information on the front-end services provided by Intermolecular.

Also Read:

Executive Interview: Casper van Oosten of Intermolecular, Inc.

Integrating Materials Solutions with Alex Yoon of Intermolecular

Ferroelectric Hafnia-based Materials for Neuromorphic ICs

March 29, 2021March 25, 2022

Library Characterization: A Siemens Cloud Solution using AWS

Library Characterization: A Siemens Cloud Solution using AWS
by Kalar Rajendiran on 03-29-2021 at 10:00 am
Categories: EDA, Siemens EDA
1 Comment

Pressing demands on compute speeds, storage capacity and rapid access to data are not new to the semiconductor industry. A desire for access to on-demand computing resources have always been there. During pre-cloud-computing era, companies provisioned on-demand compute capacity by procuring high performance computing equipment that could handle peak demand. This led to under-utilization of equipment during typical demand periods. Interestingly, larger companies, in spite of their ownership of lot of high-performance computing assets, sometimes also experienced the opposite situation. And that was lack of availability of the right kind of compute resources during extreme peak demand periods, when multiple large projects were going on concurrently.

Availability of outsourced cloud compute and storage services changed all this. The risks and costs of procuring the latest and greatest equipment was shifted to cloud services companies. Customers were able to convert large upfront fixed costs (capital expenditures) to use-based variable costs. Customers simply accessed what was needed, when it was needed and how (the resource mix) it was needed. Utilizing on-demand-computing capability from an outsourced cloud-services provider started making sense for companies of all sizes.

Is shifting to outsourced cloud-based on-demand computing just about cost savings and converting fixed cost to variable cost? Depending on the compute application and a combination of right tools and methodologies, the benefits could be lot more than the obvious cost benefits.

A recently published whitepaper showcases the value to a customer in characterizing libraries over the cloud. The whitepaper was collaboratively authored by Baris Guler and Kenneth Chang of Amazon’s AWS Division and Matthieu Fillaud and Wei-Lii Tan of Siemens EDA. Library characterization is the process of generating timing models for library elements that will be used for chip-level or block-level timing simulation and analysis. It is a task that lends itself well for scalability offered by cloud platforms.

In this blog, I’ll touch on just some of the key aspects of the Siemens-AWS solution for library characterization.

Rapid Deployments with Repeatable Success

Just as a reference design or platform contains essential elements of a system that a user may modify to customize as required, an AWS CloudFormation Template is a reference template that specifies essential elements needed for the cloud service. Siemens has collaborated with Amazon’s AWS division to create a template that is an excellent starting point for library characterization purposes. From this starting point, customers can easily customize to their specific need on hand by modifying the template. The AWS CloudFormation service itself leverages the template to create and provision the resources in an orderly and predictable way.

Rapid deployments of characterization runs are enabled by AWS ParallelCluster. It is an AWS supported open-source cluster management tool for quickly deploying and managing the clusters (resources) in the AWS Cloud. It automatically sets up the required compute resources and shared filesystem.

Data Security

The Siemens-AWS solution includes security measures incorporating user identification process and traceability for actions taken on the cloud. The solution also executes protocols to ensure data is transported, used and stored securely.

Predictability of Runtimes

A key benefit of moving to cloud-based on-demand computing will be lost if characterization runtimes become unpredictable. The Siemens-AWS collaboration has yielded a quick to setup, easy to use solution that results in predictable runtimes. Referring to Figure 1, users can adjust the resource provisioning in a predictable fashion, depending on how long a runtime their projects can tolerate.

Figure 1: Characterization runtime chart

Source: Siemens EDA

Efficient Scalability of CPUs

AWS ParallelCluster allows library characterization users to dynamically deploy and manage compute clusters. This allows invoking virtual machine instances on demand, as well as shut down and deallocation of virtual machine instances after use. This enables users to scale to large numbers of CPUs effectively during characterization runs. Referring to Figure 2, Siemens’ cloud characterization flow can achieve close-to linear scalability up to 10,000 CPUs on AWS.

Figure 2: CPU Scalability chart

Source: Siemens EDA

As summarized in this blog, Siemens and Amazon have collaborated to offer a rapidly deployable, secure, cost-effective and scalable cloud characterization flow to accelerate library characterization with runtime predictability. For a detailed insight into the solution, please refer to the whitepaper and have exploratory discussions with Siemens EDA. You can download the whitepaper “Siemens Cloud Characterization on Amazon Web Services” here.

Also Read:

Smarter Product Lifecycle Management for Semiconductors

Observation Scan Solves ISO 26262 In-System Test Issues

Siemens EDA wants to help you engineer a smarter future faster

March 29, 2021March 16, 2022

Why Would Anyone Perform Non-Standard Language Checks?

Why Would Anyone Perform Non-Standard Language Checks?
by Daniel Nenni on 03-29-2021 at 6:00 am
Categories: AMIQ EDA, EDA

The other day, I was having one of my regular chats with Cristian Amitroaie, CEO and co-founder of AMIQ EDA. One of our subjects was a topic that we discussed last year, the wide range of languages and formats that chip design and verification engineers use these days. AMIQ EDA has put a lot of effort into adding support for many of these in their integrated development environment, DVT Eclipse IDE. I know that the list includes SystemVerilog, Universal Verification Methodology (UVM), Verilog, Verilog-AMS, VHDL, e, Property Specification Language (PSL), C/C++/SystemC, Unified Power Format (UPF), Common Power Format (CPF), Portable Stimulus Standard (PSS), and probably a few more.

All these languages and formats are standards of one kind of another, most from IEEE and/or Accellera. As we talked about supporting design and verification language standards, and checking code for compliance, Cristian made the intriguing comment that they also have almost 150 non-standard checks. I was rather puzzled by that term, so I asked him to explain. Cristian said that these are checks for language constructs that deviate from the standards but are supported by specific EDA tools and vendors. Why would vendors do this? It turns out that there are two common reasons:

The vendors have older languages with constructs that their users like, so they add similar constructs on top of the standard to keep their users happy
The vendors have ideas for extensions to the standard that they may propose for the next version but, in the meantime, they want their users to benefit

That led me to wonder why users would use non-standard constructs. Cristian mentioned five possible reasons:

The users want to continue to use language constructs that they like from older languages but that are not in the new standard
The users see high value in the non-standard constructs and are willing to deviate from the standard in order to get the benefits
The vendors may not be entirely clear about what constructs in their examples and training are non-standard, so the users may not realize their deviations
The users have already used non-standard constructs in their legacy code, and are reluctant to perturb and re-verify working code
The users rely on a single EDA vendor for most of their tools, so they don’t worry too much about using non-standard constructs supported only by that vendor

I think that the last point is particularly important. One of the values of EDA standards is that users can code once and then work with any vendor, or any mix of vendors, without having to start from scratch. Relying on non-standard constructs can trap users with one vendor and make it expensive to switch to another. Unless they are making a deliberate choice to use these constructs, users want to know when they are deviating from the standard. In fact, it’s a good idea to warn them anyway.

Cristian said that’s exactly where AMIQ EDA comes in. DVT Eclipse IDE tells users when their code contains non-standard language constructs. These are warnings by default; users who want strict compliance to standards can choose to elevate these warnings to errors. These users will have a much easier time switching EDA vendors or adding new tools into their design and verification flow. On the other hand, users who have made a conscious decision to use certain non-standard constructs can disable or waive the related warnings.

Then I asked Cristian how they figure out when other vendors have non-standard support. Much of this information comes indirectly from their customers. Typically, a user runs DVT Eclipse IDE and sees an error for a language construct that is accepted by their simulator (or, occasionally, another tool). AMIQ EDA investigates and, if the construct is actually legal, updates their own tool. If the construct is non-standard as per the relevant Language Reference Manual, they add a check to issue a warning upon use of the construct.

Cristian noted that they have excellent partnerships with other EDA vendors, and have many tools in house so that they can easily cross-check how languages are handled. He stressed that they never reveal to users which tools support which non-standard constructs, since that would potentially be a violation of their partnership agreements. Users don’t require that information anyway; what they need to know is that they are using non-standard language constructs. Then they can decide whether they wish to continue this usage and accept the loss of vendor portability, or to conform strictly to the standard.

Most of the non-standard checks are for SystemVerilog, not surprising given the complexity of the language. These same checks are available in the AMIQ EDA Verissimo SystemVerilog Testbench Linter, useful for users who run lint in batch mode rather than from the IDE. VHDL is also noted for having vendor-specific extensions, and so DVT Eclipse IDE has checks for these deviations from the standard as well.

I found this whole conversation and topic to be quite interesting. The ability of AMIQ EDA’s tools to detect and report language compliance issues is clearly a benefit to users. It enables them to make fully informed decisions on whether to make use of non-standard language constructs specific to one or more vendors.

To learn more, visit https://www.dvteclipse.com. To see the list of AMIQ EDA’s non-standard checks, see https://dvteclipse.com/documentation/sv/Non_Standard_Checks.html.

Also Read

Does IDE Stand for Integrated Design Environment?

Don’t You Forget About “e”

The Polyglot World of Hardware Design and Verification

March 28, 2021March 29, 2021

MRAM Magnetic Immunity – Empirical Study Summary

MRAM Magnetic Immunity – Empirical Study Summary
by Mads Hommelgaard on 03-28-2021 at 10:00 am
Categories: IP
2 Comments

The main threat for the wide adoption of MRAM memories continues to be their lack of immunity to magnetic fields. MRAM magnetic immunity (MI) levels has seen significant research over the years and new data is continuously published from the main MRAM vendors.

This data, however, is rarely compared to magnetic field exposure scenarios which will occur in consumer applications. The study will show the state of magnetic immunity reported from the most prominent players with focus on Spin Transfer Torque MRAM (STT-MRAM). Then two specific exposure scenarios are evaluated, and the results are compared to the reported MI levels from suppliers. Finally some improvements are proposed.

Embedded STT-MRAM Magnetic Immunity Overview

TSMC and GlobalFoundries have published a set of standby MI levels vs. exposure time and temperature for their most robust macros, and provided an extrapolation to 10-year exposure levels. Below these levels are plotted again adjusted to 1ppm bit error rate (BER).

Figure 1: MRAM MI levels from GlobalFoundries and TSMC with 10-year extrapolation

While both companies show ability to withstand more than 1000 Oe @ RT in standby mode, they also show a significant degradation over temperature. Both have also published active magnetic immunity levels, which are 2-4x lower (250-500 Oe) depending on conditions. Depending on your application, the active mode may be the worst-case threat scenario.

DC Field Exposure from Rare Earth Magnets

Exposure from powerful rare-earth magnets are regarded as the worst-case scenario, as these are now widely used in various product cases and smartphone holders.

As an example of this scenario, we used data for two Neodymium magnets with a surface field strength of 5000 Oe (N52) and 3500 Oe (N48) and plotted the field strength at various distances.

Figure 2: Neodymium magnetic field vs. distance to components

Although the magnetic field quickly deteriorates, components within 2-3 mm of the magnet surface are still experiencing field strength above what MRAM technology is capable of handling today.

AC Field Exposure from Wireless Charging Pads

Wireless chargers are becoming more powerful to a point where they could threaten MRAM data integrity when charging.

The Federal Communications Commission (FCC) specifies a maximum permissible exposure (MPE) to magnetic fields generated by such devices, and specifies a compliance limit for devices at 50% this MPE level. Below are plotted the converted exposure levels for a 15W wireless QI charger, a 5W wireless QI charger, as well as the FCC compliance limit with a square law attenuation wrt. distance.

Figure 3: Estimated magnetic field exposure from wireless chargers & FCC compliance limit

It is clear that the concerns wrt. wireless chargers are much lower than was the case for static magnetic fields. Still for some MRAM offerings, the level of 100-200 Oe at close range may impact memory reliability in active mode.

Conclusion

Judging by the data presented, STT-MRAM memories are not yet able to guarantee reliable performance in these common use-cases. When integrating STT-MRAM these effects must be taken into consideration and discussed with your memory vendor.

To fully mitigate the risk from these scenarios, the MRAM technology needs to improve current standby and active MI levels by 2-4x. MRAM suppliers should be encouraged to report MI levels in a uniform or standardized way and to develop standard reliability flows for quantifying MI levels for their customers.

As there are no good alternative for embedded memory in advanced nodes, the incentive for vendors to create such standardized data to mitigate this risk should continue to grow.

The full study including references to all material used is available at the resource page on MemXcell.com.

March 28, 2021March 29, 2021

Can Our Privacy be Protected in Cars?

Can Our Privacy be Protected in Cars?
by Roger C. Lanctot on 03-28-2021 at 8:00 am
Categories: Automotive

“Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety.” — Benjamin Franklin

I hope Ben Franklin was not opposed to enhancing driving safety, but he may have looked with a jaundiced eye at the proliferation of in-cabin driver monitoring technology. It’s clear that Consumer Reports does not approve.

Mere months after applauding Comma.ai’s aftermarket driver assistance device for its integration of driver monitoring technology, Consumer Reports has taken issue with Tesla Motors’ acknowledged use of in-cabin video to advance its development of self-driving technology. CR sees the activity as an undisclosed invasion of privacy.

I am no expert on privacy. Listening in on Morrison & Foerster’s Webinar on the new Virginia Consumer Privacy Act and how it compares and contrasts with California’s Consumer Privacy Act and the European Union’s Global Data Protection Regulation it became clear that if these three jurisdictions were unable to agree on a single path to privacy protection it is clearly not an easily resolved issue.

Virginia’s Consumer Data Protection Act: What Changes Does It Require, and How Does It Compare to CPRA

The complexity of preserving privacy – which will now be left to attorneys and judges to sort out in the context of these new laws – is unfortunate given the proliferation of cameras in public spaces, on mobile devices, and in and around automobiles. This proliferation raises questions of access and control and, of course, privacy.

Making the matter even more difficult to resolve is the reality that privacy regulations are not confined by boarders. A company or an individual based or living in the U.S. that does business in the E.U. – even without traveling there – is subject to GDPR, just as anyone transacting in or traveling through California or Virginia must be mindful of these new regulations. And all of these regulations have already seen revisions and will be forced to respond to legal interpretations.

The fundamentals are the same everywhere. Clear and concise disclosures. Require affirmative consumer opt in. Data access and transparency. Disclosure of intended uses. Right to erasure. It’s the details that get thorny.

Jon Fasman’s “We See It All” chronicles the increasing role of technology in law enforcement and the many ways privacy is steadily being compromised in the pursuit of enhanced security and public safety. Early on in the book he notes the use of facial recognition technology by airlines during boarding and he advises readers to avoid this technology at all cost – even if doing so makes boarding less convenient.

Fasman’s message, which is conveyed throughout the book, is that if an intrusive potentially privacy violating technology can be abused, it will be. No pollyanna, he goes on to note the range of negative collateral impacts from the use of “shotspotting,” body cameras, and widely dispersed closed circuit video cameras as well as the use of artificial intelligence for deploying police forces and in sentencing.

Fasman argues for improvements in the regulation of these technologies including such measures as limiting access to the data gathered by these systems and limiting the period of time allowed for their storage or retention for future use. But the moral of the story appears to be that the battle to preserve privacy must be fought continuously even though it already appears to be lost.

China is, of course, the worst case scenario, as detailed in Kai Strittmatter’s “We Have been Harmonized.” The author describes a scenario where the local police’s city ubiquitous CCTV-based surveillance system, equipped with facial recognition technology, is able to locate allowing officers to detain him in a matter of minutes in a test.

Something similar is coming to the cabins of cars. In-cabin sensors are increasingly being used to detect driver drowsiness. But the transition to camera-based systems is being pioneered for solutions such as General Motors’ Super Cruise driver assistance system – which uses camera-based monitoring to ensure driver vigilance when the hands-free driving function is activated.

The European New Car Assessment Program (Euro-NCAP) – Europe’s protocol for granting five-star safety ratings for new cars – will require driver monitoring systems beginning sometime after 2022. Like local privacy policies that have global influence, Euro-NCAP’s requirement will have a global impact.

What remains unclear is how consumers will react. In the past few years, consumers have “discovered” far more passive monitoring systems in their cars – such as Daimler’s in-dash coffee cup icon when one has been driving too long uninterrupted – but inward facing cameras is something new.

Seeing Machines, which provides in-cabin cameras for General Motors’ Super Cruise and for fleet operators, has been careful to note that its devices do not store video and that they neither transmit video nor are externally hackable. But cameras do represent both a privacy and a security vulnerability.

In its own research, Strategy Analytics has found a wide range of conflicting insights regarding consumer perceptions of privacy. Consumers have expressed concerns about protecting their privacy, but readily surrender that privacy when pressed by a manufacturer or service provider – somewhat more so in the U.S. than in the E.U.

Ironically, a global survey conducted by Strategy Analytics revealed that policies, such as the E.U.’s GDPR, have caused consumers to lower their privacy guard even further. Presumably the institution of the regulation instills a sense of security and safety rather than raising a sense of necessary vigilance.

Not all consumers are so sanguine. An Amazon driver recently created headlines when he quit as a result of the company’s deployment of Netradyne four-camera vehicle monitoring systems. Thomson Reuters quoted the man: “It was both a privacy violation, and a breach of trust, and I was not going to stand for it.”

It may well be that the price of access to semi-autonomous vehicle functions, like GM’s Super Cruise, will be a loss of consumer privacy manifest in cabin-mounted cameras. Car makers will surely promise not to store or transmit sensitive data, but the best consumers may be able to hope for is to have fun sending selfies while driving. That sounds like a reasonable tradeoff, right?

There is a bit of good news from Strategy Analytics research. In a world increasingly bereft of privacy protections in spite of new regulations, car makers stand out in the minds of consumers. According to Strategy Analytics research: “Though consumers have mixed feelings about trusting telecom and tech-centric hardware and software firms with their data, this concern clearly does not extend to automakers.” Time will tell whether auto makers can preserve this perception as they flirt with invasive monitoring technologies.

Consumers and the Data Trust Gaps Between Automakers and Big Tech

Data Privacy: Lack of Knowledge, Resignation, and Unfounded Confidence

Survey Highlights Privacy Paradox