webinar banner2025 (1)
Semiconductor Expert Forum

Posted on

Auto Architecture and the Need for Speed

Auto Architecture and the Need for Speed
by Roger C. Lanctot on 10-11-2019 at 10:00 am
Categories: 5G, Automotive

Automotive makers and their suppliers are jacking up the processing power being introduced to cars along with higher speed wireless external connections. These high speed systems promise to collect, process, interpret and transmit sensor data for the purpose of enabling advanced collision avoidance and, ultimately, automated driving systems.Strategy Analytics is moderating the 2019 Automotive Smart Architecture Symposium in Bonn, Germany, this month to spotlight these issues with expert speakers from Aptiv, Micron, Valens, Visteon contributing their insights. At the heart of the vehicle architecture debate is the reality that the traffic jams we observe on highways throughout are analogous to the data traffic jams shaping up in increasingly connected vehicles. The connections and interfaces currently in use are demonstrably not up to the task of enabling the affordable mass market systems and solutions capable of transforming transportation.

To deliver the latest advanced solutions in real world production vehicles – as opposed to autonomous vehicle test mules – requires industry coordination to bring in-vehicle networks and interfaces literally up to speed. A big step forward occurred earlier this year when the MIPI Alliance (Mobile Industry Processor Interface) announced major enhancements to its MIPI A-PHY – a physical layer specification targeted at advanced driver-assistance systems (ADAS) and autonomous driving systems (ADS) and other surround sensor automotive applications.

While most MIPI specifications are designed for shorter reaches for use within mobile devices, A-PHY will be capable of reaching up to 15 meters in the demanding automotive environment. The new specifications provide greater resilience and capability for higher bandwidth and higher speed mission-critical use cases.

Valens has been a contributor to the new specification and will be able to provide further insight during the Automotive Smart Architecture Symposium set for the eve of the ELIV conference taking place in Bonn….

Valens has been a contributor to the new specification and is sponsoring the Automotive Smart Architecture Symposium set for the eve of the ELIV conference taking place in Bonn, Germany this month. The free event takes place October 15, from 15:30 p.m. at the Maritim Hotel Bonn on Godesberger Allee (Kurt-Georg-Kiesinger Allee 1) and will include expert presentations and dinner.

Participant presenters at the event will include Aptiv, Valens, Micron and Visteon. Strategy Analytics will be presenting at the event – sharing industry forecasts and insights – and moderating a panel discussion of the participating experts. The panel discussion will focus on the challenges and opportunities inherent in deploying high-speed in-vehicle connections.

Presentations will include:

  • Emerging Vehicle Networks: What’s Driving the Race for Bandwidth?
  • Automotive PCI Express: The Optimal High Speed Sensor Data Backbone of Tomorrow
  • The Need for Multi-Gigabit Speeds for In-Vehicle Connectivity
  • Memory Architecture in Autonomous Vehicles
  • The Challenges and Opportunities for Automotive Architecture Evolution

Bringing increasingly sophisticated safety systems and autonomous driving technology to mass produced vehicles will require additional progress in advancing processing and data transmission speeds, but the A-PHY enhancements from MIPI (and Valens) marks an important step. The MIPI Alliances’ announcement of new interface standards will ultimately translate to saved lives, reduced vehicle emissions, and mitigated congestion as automobiles are able to operate on the road with greater intelligence easing in-vehicle data and external traffic jams.

Event registration is here: https://www.eventbrite.com/e/2019-automotive-smart-architecture-symposium-tickets-71641205775

Posted on

My Top Three Reasons to Attend IEDM 2019

My Top Three Reasons to Attend IEDM 2019
by Scotten Jones on 10-11-2019 at 6:10 am
Categories: Events, FD-SOI, FinFET, Foundries, Intel Foundry, TSMC

The International Electron Devices Meeting is a premier event to learn about the latest in semiconductor process technology. Held every year in early December is San Francisco this years conference will be held  from Decembers 7th through December 11th. You can learn more about the conference at their web site here.

This is a must attend conference for me every year.

The following are a few of the announced papers I am particularly excited about:

(1) TSMC to Unveil a Leading-Edge 5nm CMOS Technology Platform: TSMC researchers will describe a 5nm CMOS process optimized for both mobile and high-performance computing. It offers nearly twice the logic density (1.84x) and a 15% speed gain or 30% power reduction over the company’s 7nm process. It incorporates extensive use of EUV lithography to replace immersion lithography at key points in the manufacturing process. As a result, the total mask count is reduced vs. the 7nm technology. TSMC’s 5nm platform also features high channelmobility FinFETs and high-density SRAM cells. The SRAM can be optimized for low-power or high-performance applications, and the researchers say the high-density version (0.021µm2) is the highest-density SRAM ever reported. In a test circuit, a PAM4 transmitter (used in highspeed data communications) built with the 5nm CMOS process demonstrated speeds of 130 Gb/s with 0.96pJ/bit energy efficiency. The researchers say high-volume production is targeted for 1H20. (Paper #36.7, “5nm CMOS Production Technology Platform Featuring Full-Fledged EUV and HighMobility Channel FinFETs with Densest 0.021µm2 SRAM Cells for Mobile SoC and High-Performance Computing Applications,” G. Yeap et al., TSMC)

(2) Intel Says Heterogeneous 3D Integration Can Drive Scaling: CMOS technology requires both NMOS and PMOS devices, but the performance of PMOS lags NMOS, a mismatch which must be addressed in order to wring every last bit of performance and energy efficiency from future chips. One way to do that is to build PMOS devices with higher-mobility channels than their NMOS counterparts, but because these are built from materials other than silicon (Si) which require different processing, it is challenging to build one type without damaging the other. Intel researchers got around this with a 3D sequential stacking architecture. They first built Si FinFETNMOS transistors on a silicon wafer. On a separate Si wafer they fabricated a single-crystalline Ge film for use as a buffer layer. They flipped the second wafer, bonded it to the first, annealed them both to produce a void-free interface, cleaved the second wafer away except for the Ge layer, and then built gate-all-around (GAA) Ge-channel PMOS devices on top of it. There was no performance degradation in the underlying NMOS devices, and in an inverter test circuit the PMOS devices demonstrated the best Ion-Ioff performance ever reported for Ge-channel PMOS transistors (Ion=497 µA/µm and Ioff=8nA/µm at 0.5V). The researchers say these results show that heterogeneous 3D integration is promising for CMOS logic in highly scaled technology nodes. (Paper #29.7, “300mm Heterogeneous 3D Integration of Record Performance Layer Transfer Germanium PMOS with Silicon NMOS for Low-Power, High-Performance Logic Applications,” W. Rachmady et al., Intel.)

(3) Versatile 22nm STT-MRAM Technology: Many electronics applications require fast nonvolatile memory (NVM), but embedded flash, the current dominant technology, is becoming too complex and expensive to scale much beyond 28nm. A type of embedded NVM known as STT-MRAM has received a great deal of attention. STT-MRAM uses magnetic tunnel junctions (MTJs) to store data in magnetic fields rather than as electric charge, but this ability decreases as temperature increases. That makes STT-MRAM both challenging to build – it is fabricated in a chip’s interconnect and must survive high-temperature solder reflow – and also to use in applications such as automotive, where thermal specifications are demanding and the ability to resist outside magnetic fields is critical. TSMC will describe a versatile 22nm STT-MRAM technology that operates over a temperature range of -40ºC to 150ºC and retains data through six solder reflow cycles. It demonstrated a 10-year magnetic field immunity of >1100 Oe at 25ºC at a 1ppm error rate, and <1ppm when in a shield-in-package configuration. The researchers say that by trading off some of the reflow capability and using smaller MTJs, even higher performance can be achieved (e.g., 6ns read times/30ns write times), making them appealing for artificial intelligence inference engines. (Paper #2.7, “22nm STT-MRAM for Reflow and Automotive Uses with High Yield, Reliability and Magnetic Immunity and with Performance and Shielding Options,” W. Gallagher et al., TSMC)

About IEDM
With a history stretching back more than 60 years, the IEEE International Electron Devices Meeting (IEDM) is the world’s pre-eminent forum for reporting technological breakthroughs in the areas of semiconductor and electronic device technology, design, manufacturing, physics, and modeling. IEDM is the flagship conference for nanometer-scale CMOS transistor technology, advanced memory, displays, sensors, MEMS devices, novel quantum and nano-scale devices and phenomenology, optoelectronics, devices for power and energy harvesting, high-speed devices, as well as process technology and device modeling and simulation. The conference scope not only encompasses devices in silicon, compound and organic semiconductors, but also in emerging material systems. IEDM is truly an international conference, with strong representation from speakers from around the globe.

Posted on

Mentor’s Questa verification tools now run on 64-bit ARM based servers

Mentor’s Questa verification tools now run on 64-bit ARM based servers
by Tom Simon on 10-10-2019 at 10:00 am
Categories: EDA, Siemens EDA

The server market has been undergoing changes in the last few years. The traditional go-to for server processors had been x86 based chips from Intel or AMD. However, if you go on Amazon AWS looking for EC2 instances, you will see the “A1” instance type, which is an ARM based instance. This is not what you might think at first. The A1 instance uses AWS Graviton processors which are based on 64-bit ARM Neoverse cores and custom silicon designed by AWS. Amazon is not the only company building servers using the Neoverse cores.

With ARM’s CMN-600 mesh interconnect, up to 128 or more cores can be connected in hyperscale servers for impressive processing power combined with high throughput and power efficiency. There is already a wide ecosystem of OSs, development tools and application software available for Neoverse based machines. These include several flavors of Linux, VMWare, Docker, and all the usual software stacks for web and internet-based services.

Where it gets interesting for chip designers, however, is that computationally intense design tools are now available for this platform as well. Mentor has just announced that their Questa verification suite is available on the 64-bit Neoverse processors. Mentor decided to do this based on their assessment of market demand. Of course, ARM, a large user of verification tools, wanted this, but also Mentor found that other customers wanted this new platform. And, of course if the Neoverse machines are not in-house, running jobs on AWS is a readily available option.

Questa already is OS agnostic, running interchangeably on Windows or Linux. The ability to run on x86 or Neoverse machines gives their customer more choices. Mentor has made the selection of processor architecture easy to do at runtime. The implementations are bit for bit compatible, so the same results will be achieved regardless of the platform. Mentor partnered with ARM on development and qualification. Already Mentor has announced qualification of a number of server manufacturers that are producing Neoverse based servers.

Prior to this announcement I had a conversation with Neil Hand, ICVS Director of Marketing at Mentor to talk about their new support for the ARM Neoverse cores. He highlighted the power, performance and price benefits of running on the new ARM based servers. Another key advantage in his mind is the very high memory bandwidth they offer. Digging into the details, he said the porting process was fairly straightforward. However, to achieve their high-performance, Questa tools actually generate native code to accelerate simulation performance. Porting to the ARM Neoverse did require adding a new native code generator. This means that the high performance this approach offers has been preserved. This is probably one area where working directly with ARM offered a big advantage.

The server market will not turn on a dime, but the upcoming changes in the overall computing market that will be brought on by increased IoT deployment and also the introduction of 5G will change the landscape dramatically. Some people speculate that mobile and edge devices may actually produce more data than can be ported back to servers, necessitating changes to edge processing and server utilization. ARM seems well positioned to take advantage of these coming changes. EDA users might find common cause with IT teams to take advantage of ARMs new offering to achieve scalability for the most computationally intense applications. More information about this announcement is available on the Mentor website.

Posted on

Accellera IP Security Standard: A Start

Accellera IP Security Standard: A Start
by Bernard Murphy on 10-10-2019 at 5:00 am
Categories: Accellera, Security, Semiconductor Services

IPSA Workflow

I mentioned some time ago (a DVCon or two ago) that Accellera had started working on a standard to quantify IP security. At the time I talked about some of the challenges in the task but nevertheless applauded the effort. You’ve got to start somewhere and some way to quantify this is better than none, as long as it doesn’t deliver misleading metrics. Now they’ve released a white paper and setup a community forum for discussion.

The working group is unquestionably worthy: multiple people from Intel and Qualcomm, along with representatives from Cadence, Synopsys, Tortuga and OneSpin. I didn’t see Rambus among the list of authors, a curious omission since they’re pretty well known in this space.

The white paper is somewhat reminiscent (to me at least) of the Reuse Methodology Manual (RMM), not in length but in the general approach. This is a very complex topic, so even with a lot of smart people working on it you can’t expect an algorithmic process laid out with all the i’s dotted and t’s crossed plus a definitive metric at the end.

The overall standard is called IP Security Assurance (IPSA) and in this first incarnation primarily defines collateral to be provided with an IP along with an evolving and generally available database of common IP security concerns (CIPSCE). The latter is modeled on the MITRE Common Weakness Enumeration, widely accepted as the reference for software security weaknesses. CIPSCE aims to do the same for hardware security, providing a standard, shared and evolving set of known weaknesses. This really has to be the heart of the standard.

Starting with the asset definition and the database, the IPSA process requires building, either through a tool or manually, an attack surface consisting of those signals though which an attack might be launched into the IP or privileged information might be read out of the IP. Adding CIPSCE associations to this info produces a threat model. Here the flow becomes a little confusing to me, no doubt to be further refined. It seems you do verification with the attack surface but the threat model is primarily documentation for the integrator to aid in mitigating threats, rather than something that might also be an input to verification (at both IP and integration levels)?

A CIPSCE database does not yet exist, however the paper illustrates an analysis using some example weaknesses for a couple of demonstration OpenCores test cases. The paper suggests that some of the attack surface signals may be discoverable by an EDA tool whereas some others might require hints to be added manually through attributed if the tool fails to discover certain potential problem signals. OK, an obvious safety net, though I’m not sure how much we want to be depending on safety nets in this area.

Hence my reference to RMM (maybe draft rev). This is an outline of a methodology with some very sensible components, especially the CIPSCE concept, but still largely an outline so too early to debate the details. Also as a standard it’s agnostic to automation versus manual discovery and documentation, as it should be. Still that creates some questions around what can and cannot be automated, as currently defined. But it is a start.

You can read the white paper HERE.

Posted on

Functional Safety ARC Processor IP will speed automotive system design

Functional Safety ARC Processor IP will speed automotive system design
by Tom Simon on 10-09-2019 at 10:00 am
Categories: Automotive, IP, Synopsys

In the automotive space you can’t even get out of the starting gate without Functional Safety (FS). All electronic system that go into cars must have ISO 26262 certification. However, this is not something you slap on after the fact. From the ground up the requirements for ISO 26262 must be considered and the proper processes must be employed. Nowhere is this truer than for the embedded processors used in so many automotive systems. Of course, not all of these systems need to meet the requirements for ASIL-D – where failure can lead to death or injury. Systems such as door locks still need to meet the less stringent requirements, such as ASIL-B for instance.

Embedded processors pose a challenge because they really represent a constellation of deliverables that all must adhere to the ISO 26262 process. Each physical piece, such as interface blocks, memory, interrupt units and timers, Instruction execution units, etc. must be built specifically with ISO 26262 compliance in mind. Additionally, the compilers and runtime libraries must also have been built for FS. Even the test systems implemented in the silicon must be able to support FS requirements. Automobile applications need several different types of processors, each optimized for their specific use. A processor used to provide ADAS is a different beast than the one needed to operate the door locks. This means that it is not enough to just have a single processor when building automotive systems.

To make the entire process easier, Synopsys has just announced ARC processor IP that was designed for FS. They are offering ASIL-B and ASIL-D versions of three different families of processors. The EM22FS will be available for systems requiring low power. Power is always an issue in the automotive environment because of battery life, cooling and reliability issues. For higher performance systems, Synopsys will have the HS4xFS Processor Family. Lastly for systems that require vision processing or machine learning capabilities, they are announcing the EV7xFS Embedded Vision Processors. This is a well-rounded set of processors that should facilitate their customers’ design needs.

For use cases that do not call for ASIL-D, and where ASIL-B will suffice, the dual core processors can be uncoupled from lockstep operation to provide two independent processors for increased throughput. The HS4xFS processors come in single, dual or quad core configurations. With quad core performance, the processors can be used for high performance safety applications such as vehicle-to-vehicle (V2V) or vehicle-to-infrastructure (V2I) communication.

As part of this, the FS processors will be fully supported by the DesignWare ARC MetaWare Development Toolkit for Safety. This provides an ASIL-D certified compiler and collateral. Synopsys provides a safety manual and safety guide, to help developers of safety-critical systems fulfill the requirements of the ISO 26262 standard and prepare for compliance testing. The toolkit is a complete solution for development, debugging and optimization of system software for automotive embedded systems. The vision processors are supported by a specialized development toolkit also targeted at FS.

Processors will increasingly be used in automobiles, and safety will always be the topmost requirement. System developers want to leverage their domain expertise and not reinvent the wheel. Fortunately, Synopsys has been investing in both ARC processor IP and in functional safety for years. This is key enabling technology for solutions in this space. More information regarding ARC Functional Safety Processor IP can be found on the Synopsys Website.

Posted on

WEBINAR: Generating and Measuring IP Security Threat Levels For Your SoCs

WEBINAR: Generating and Measuring IP Security Threat Levels For Your SoCs
by Daniel Nenni on 10-09-2019 at 6:00 am
Categories: EDA, Events, Perforce

IPs have an attack surface that indicates how they can be compromised in real world scenarios. Some portions of the attack surfaces are well known, others are discovered during analysis, testing or out in the field. SoCs that use large collections of IPs need a systematic and reliable way to determine the various security vulnerabilities across the hierarchy, even as these vulnerabilities are discovered in heterogeneous environments. Percipient provides a platform for IP analyzers and test teams to convey the security threats detected and for SoC managers to consolidate and measure these threats in a systematic manner, not only for a single SoC, but across all SoC’s in their company.

WEBINAR: Concerned about IP security threats for your SoCs?

What is The IP Security Threat Level In Your SoC?
The average SoC in today’s design environment has more than 100 different IPs. In many cases, the actual count is much higher because IPs are embedded in other IPs due to reuse or flattening of the IP hierarchy. Additionally, these IPs come from many different sources including external vendors, internal – usually far flung – IP teams, and even locally developed content.

As the SoCs are assembled over the course of several months, or even years, these IPs go through various mutations, feature changes, bug fixes, and revisions, all of which have to be incorporated into the chip. In the high pressure, compressed timelines of today’s projects, not every change can be thoroughly verified or exercised. Often seemingly innocuous changes are ignored or left to be “tested later.”

As shown in the figure, the SoC is a patchwork of IPs with various origins, quality levels, and sometimes poorly understood attack surfaces.

This scenario is a security headache for most chip teams, because it leads to four serious problems:

  1. Inability to pinpoint the exact content of your chip
  2. Inability to test and guard against all possible scenarios for security attacks on the known content of the chip
  3. Inability to know if vulnerabilities discovered in contexts outside of the immediate verification impact the SoC or not
  4. Inability to determine if vulnerabilities discovered in context of one SoC impact other SoCs being developed, or even worse, other SoCs that have been released

This ‘needle-in-a-haystack’ problem keeps getting worse as the cost and the consequences of security breaches become magnified. If your product plays a critical role in self driving cars, remote surgical procedures, high performance AI hardware and a host of other mission critical systems, both the chances of attacks and their impact can be severe.

IPLM To The Rescue
An IPLM system such as Percipient from Methodics is the definitive, single source of truth for all of the IP content in every chip in the enterprise. Percipient is a traceable platform that allows all design information to be connected throughout an enterprise.  Using Percipient allows a chip lead to determine exactly which version of which IP was used in the design. It also provides a channel of information through integrations to bug tracking systems like Jira where a vulnerability found in one context – say a lab test or out in the field – can be annotated on the exact versions of impacted IPs.

Each team can now transparently see the exact security impact of using all of these specific IPs in their design as the threats are uncovered and take the right steps to ensure that these are addressed.

These security vulnerabilities, found in the various contexts of the IPs that constitute the system, can also be rolled up at the SoC level into a well understood ‘threat level’ for the SoC that changes dynamically as new threats are detected and existing threats are addressed. SoC owners can also preview how this threat level will be impacted when they incorporate newer versions IPs into their SoC.

About Methodics
Methodics solutions enable high-performance hierarchical analog/mixed signal, digital, software, embedded software, and SOC design collaboration across multi-site and multi-geographic design teams, assuring full traceability of the use and reuse of important design assets for Functional Safety compliance with such standards as ISO26262 and DO-254. With Methodics, traceability is built into the design process – it’s not added on as an after thought.

Advanced IP distribution, cataloging, and workspace management ensure that no matter where designers are located they have full visibility into the IP available to them and can easily access the corresponding data.

And integration of IP Lifecycle Management with industry-standard data management solutions, such as Perforce, Subversion, Git and others makes designs more efficient and predictable, and with higher quality. This approach ensures data is safe, always available, and that the tools can take advantage of the latest advancements from the software configuration management community.

Our highly scalable and industry proven solutions are ideal for large multinational, multisite SoC design teams as well as for small, specialized design teams. www.methodics.com

Posted on

Webinar – AI/ML SoC Memory and Interconnect IP Perspectives

Webinar – AI/ML SoC Memory and Interconnect IP Perspectives
by admin on 10-08-2019 at 10:00 am
Categories: Events, IP

For decades development work on Artificial Intelligence (AI) and Machine Learning (ML) was done on traditional CPUs and memory configurations. Now that we are in the “hockey stick” upturn in deployment of AI and ML, the search is on for the most efficient types of processing architectures. The result is a wave of development for specialized SoCs that accelerate AI and ML operations, which tend to be highly parallel and require flexible interconnection. Specialized SoCs are going to be used everywhere from the data center to mobile devices. Regardless of where they will be used, AI and ML SoCs will need to be extremely efficient. Designers implementing them will have to use the latest IP for memory and interconnect to achieve the necessary efficiencies, bandwidth and performance.

Silvaco will be offering a webinar on the topic of “AI and Machine Learning SoCs – Memory and Interconnect IP Perspectives” to help viewers understand effective strategies for successful SoC development. The free webinar will be on October 24th at 10AM PDT. The webinar will cover the challenges of AI/ML SoC design including key requirements of memory and interconnect IPs. IP solutions from Silvaco, SIPware, will be discussed in this context.

The presenter is Ahmad S. Mazumder, Principal Field Engineer in Silvaco’s IP Engineering Division. He is an industry veteran on the development of high-speed memory, interface IPs, and many types of analog IPs. He has worked on cutting edge DDR, extreme high-speed SerDes, interfaces, ESD, and QoR for 24 years at various SoC companies (Intel, Broadcom, C-Cube Microsystems, etc).

This should be an invaluable webinar for academics, engineers and management who are looking for the optimal solutions for designing and implementing AI and ML SoCs. As is usual for Silvaco webinars, it should be very informative. Webinars are a great way to stay current and abreast of developments in the semiconductor design space.

About Silvaco, Inc.
Silvaco Inc. is a leading EDA tools and semiconductor IP provider used for process and device development for advanced semiconductors, power IC, display and memory design. For over 30 years, Silvaco has enabled its customers to develop next generation semiconductor products in the shortest time with reduced cost. We are a technology company outpacing the EDA industry by delivering innovative smart silicon solutions to meet the world’s ever-growing demand for mobile intelligent computing. The company is headquartered in Santa Clara, California and has a global presence with offices located in North America, Europe, Japan and Asia.

Posted on

Design Perspectives on Intermittent Faults

Design Perspectives on Intermittent Faults
by Bernard Murphy on 10-08-2019 at 5:00 am
Categories: EDA, FPGA, Synopsys

Faults

Bugs are an inescapable reality in any but the most trivial designs and usually trace back to very deterministic causes – a misunderstanding of the intended spec or an incompletely thought-through implementation of some feature, either way leading to reliably reproducible failure under the right circumstances. You run diagnostics, figure out what’s going wrong and either patch around the problem with software or correct the design flaw in the next spin.

But some bugs are not so accommodating. These appear intermittently and (seemingly) unpredictably. It might take a day for such a bug to appear, or two weeks, or years or even never in the lifetime of the product; you have no way of knowing. Yet the consequence of such bugs can be just as serious, in fact more so because the fault can’t be foreseen and there’s often no easy way to patch around this type of problem.

This class of problem invariably springs from asynchronous domain crossings, a signal crossing between two asynchronous clock domains or an asynchronous reset triggering a transition on a register with an active clock. In either case, a transition near the time the register clock switches can leave the register stuck in a metastable state, or a transition may drop or may be delayed from other related signals. In any event the design fails to operate as expected. How that affects system function can range from customer frustration to catastrophic failure (spontaneous failure in your car’s collision detection would be more than an inconvenience).

Synopsys recently put on a workshop on verifying the correct handling of domain crossings, in which most of the talks were given by designers from Xilinx, NVIDIA, Intel and Samsung. I have extracted some key points that struck me.

Static Analysis

Simulation is woefully incomplete for this kind of checking; production methods depend instead on signoff through static analysis which is very complete but always plagued by a high-level of false errors. You want the analysis to err on the side of pessimism to avoid missing any real errors, but even a little pessimism quickly explodes into hundred of thousand of “possible” errors which you then have to check one by one. In practice many designers throw in the towel, checking the ran-the-tool box but ignoring the output. Or they use waivers to suppress major groups of violations, ignoring the possibility that one or two real problems may lurk under all that noise.

That’s a problem because, according to one speaker, that decision is invariably justified by this defense: “Look, this design/block has been in production for years and we haven’t seen any problems”. He made this point: failure rates on synchronizer cells can certainly be pretty long – that’s the whole point. But sync problems are not always point failures; they can also result from weak design practices at the block or system level. Not seeing any problems so far is no guarantee you won’t see problems in the future, given relentless growth in switchable power domains, clock domains or new use-cases triggered by different applications.

The real value in that reduction is often in isolating crossings triggered by quasi-static signals, which can change but don’t do so very often; resets and configuration signals are examples. Agreeing these few asserted properties are safe is much easier and can eliminate huge numbers of violations at a stroke. And the reasoning is way more robust than blanket waivers. Several speakers emphasized the importance of constraints over waivers for exactly this reason.

Checking reset domain crossings (RDCs) is becoming a big topic, quite closely related to CDC checking but different in some important ways. The need for analysis arises thanks to the increasingly complex hierarchy of resets in large chips, from basic power-on-reset through brown-out resets, to system and sub-system soft resets. Turns out there are many more crossings in a design – places a reset can interact with an async clock – than there are CDCs. So the false error problem has to be managed even more carefully

Ironically the RDC problem can arise in an attempt to resolve lockups in software (or hardware), especially now in fail-operational requirements in ISO 26262, where if a system fails in some respect it must be able to recover without requiring a complete reset. The design fix is to use local resets which if incorrectly implemented can cause their own sync problems.

One user observed that they currently do the reset check in STA, which works but pushes analysis late in design. If they need a fix, it becomes an ECO which can be very painful as these accumulate. Checking from RTL onwards and rechecking at every checkin, regression and checkpoint minimizes ECO surprises (at least from this cause).

Several other points of note: One user observed that they have been doing reset checks in STA, but that necessarily happens late in design. Given increasing complexity of reset hierarchies, these fixes trigger complex and hard to manage ECOs. Going forward, they’re switching to checks from RTL onward to minimize the need for late-stage fixes on resets. Also CDC signoff continues to be important at gate-level, thanks to all the changes that can happen in implementation – clock gating muxes transforming into glitching AOI structures if you’re not careful, synthesis retiming optimizations around synchronizers, you get the idea. Finally, hierarchical analysis is becoming much more important. Full-flat analysis on billion gate designs is as problematic for domain crossing analysis as for STA and everything else. Progress is being made; more is probably needed in the challenging area of abstraction.

You can learn more about Synopsys support in all these areas through the SpyGlass platform HERE.

Posted on

5G Deployments – The Analysis Requirements are Ginormous

5G Deployments – The Analysis Requirements are Ginormous
by Tom Dillinger on 10-07-2019 at 10:00 am
Categories: 5G, Ansys, Inc., EDA
1 Comment

The introduction of 5G communications support offers tremendous potential across a broad spectrum of applications (no pun intended).  5G is indeed quite encompassing, across a wide range of frequencies – the figure below illustrates the common terminology used, from low-band, mid-band (“sub 6G”), and high-band (“mmWave”) frequency allocation.

The massive MIMO antenna configuration for 5G offers high user volume, seamless mobile connectivity between towers, and extremely high availability – the latter is crucial for many applications, to be discussed shortly.  The figures below illustrate a 5G antenna configuration, and specifically, the directed beam-forming radiation pattern as compared to the omnidirectional 4G pattern.

Although some commercial installations are already available in the mid-band spectrum, leveraging existing 4G LTE infrastructure, the promise of 5G is dependent upon the deployment of mmWave communications.  The key characteristics of mmWave 5G are:

    • ultra-reliability low latency communications (URLLC)
    • enhanced mobile broadband (EMB)

For industrial IoT (IIoT) applications, a private 5G network may be deployed in support of robotic automation, sensor-based process monitoring, or operator-assisted procedures leveraging augmented reality (AR).  These “fixed network” opportunities all rely on the URLLC features of 5G.

The majority of 5G development and capital investment is being applied to EMB applications, from consumer mobile telephony to the potential communication requirements of (Class 4/5) autonomous vehicles.  The URLLC latency target is sub-1 millisecond to establish a connection, to improve upon “human-like reflexes” in an autonomous vehicle.

Parenthetically, although the pursuit of autonomous vehicle technology and the deployment of 5G EMB communications are extremely symbiotic, the two industries will proceed (somewhat) independently, driven by market demand and opportunity.  On the one hand, autonomous vehicles may rely on local sensor data (LiDAR, radar, cameras) for real-time decisions, with vehicle logging and diagnostic data uploaded infrequently.  In the most collaborative environment with 5G EMB, a rich set of vehicle-to-vehicle (V2V) and metropolitan vehicle-to-infrastructure (V2I) applications are envisioned.  For example, a vehicle could communicate to the infrastructure the presence of a road hazard (e.g., road ice), an obstacle, or an approaching emergency vehicle, which would communicate that information to other vehicles for predictive decision making.

Note that the EMB applications envisioned for 5G are quite unique.  Whereas a typical mobile consumer seeks high download “streaming” throughput, the bandwidth and low latency of mmWave 5G technology will lead to upload-centric applications, as well.  The figure below illustrates the (potential) data transfer requirements for an autonomous vehicle, in full V2V and V2I communications mode.

Yet, the mmWave 5G transmission characteristics are drastically different than 4G LTE.  The environments have led to the introduction of a myriad of 5G antenna design configurations, as well as connections to mid-band (and 4G LTE) networks – see the figure below.

Perhaps the most daunting challenge of 5G deployments is the metropolitan configuration, needed to support the V2I communications mentioned above (and provide consumers with the motivation to upgrade to a 5G-enabled phone J).  Note that line-of-sight and non-line-of sight analysis is required for metropolitan mmWave 5G, accurately representing outdoor reflections.  The figures below illustrate a metro cell radiation analysis model.

One of the most aggressive municipalities embracing 5G is San Jose CA.  The city planning commission recently indicated a collaboration between the city and 5G carriers (especially, taxes and fees) with plans to establish 4,200 metro cells.  Assuming a 65×65 cell configuration and a 150 meter distance between cells from the table above, that would cover roughly a 10km x 10km grid.

Yet, where will these antennas be placed?  (There are both aesthetic and engineering criteria that will no doubt be part of this decision – I’ll focus on just the engineering aspects.)  How will the carriers verify the appropriate beam-forming range and coverage?

Recently, I had a most enlightening discussion with Wade Smith, Applications Engineering Manager, High Frequency Electromagnetics at ANSYS.  Wade impressed upon me the extensive amount of analysis required to evaluate 5G deployments, and how the breadth of ANSYS tools in the Multiphysics platform are applied to the problem.

“ANSYS has defined a full 5G analysis flow.”, Wade indicated – see the figure below.

Wade continued, “The scope of the analysis spans from the chip to a city.  Correspondingly, the breadth of analysis utilizes ANSYS expertise in a range of domains.”

    • chip element modeling (e.g., the RLC modeling tools from the recent Helic acquisition)
    • signal integrity analysis
    • electromagnetic radiation analysis (including specialized antenna radiation packages – i.e., SBR+)
    • structural analysis
    • thermal analysis

“The goal of the simulation is to evaluate the  radiation pattern and spectral energy, in support of multiple users.”, Wade said.  The figures below illustrate the beam-forming radiation pattern analysis from a base station to multiple mobile users.

“Structural analysis, too?”, I asked.

“To be sure.”, Wade replied.  “5G antennas are housed in a radome that will be mounted on a wide variety of supports in a city, such as streetlights, utility poles, and the tops of buildings.”

 “The mounting bracket will be subject to a number of mechanical forces, potentially exacerbated by weather conditions like high winds.  With the critical role of V2I communications, the structural integrity of these antenna installations is paramount.”

“Of course.”, I said sheepishly.  “What about the thermal analysis of the full chip-to-city model with ANSYS Icepak?”

Wade answered, “The ANSYS Multiphysics platform links Icepak and HFSS, for temperature-dependent antenna performance analysis.  Although the 5G antenna is relatively small, and will integrate power management features that adapt to the time-varying load, the peak internal dissipation and radiated power is substantial.  Icepak and HFSS will simulate the coupled electromagnetic and thermal solutions, and provide insights into the beam-forming radiation pattern and efficiency.”

“And, like the structural analysis, the antenna performance will be subject to external environmental conditions that need to be modeled.  That ranges from the direct summer sunlight on the radome in Dallas to a frigid winter in Minneapolis – a Multiphysics-driven analysis approach is required.” 

Wade showed some compelling examples on how the thermal analysis results were applied to the range calculations for typical antenna configurations.  The first figure below illustrates the thermal analysis of the antenna array (with and without a heatsink).  The second figure illustrates the effects of both the thermal analysis and external radiation interference on the 5G signal link margin – broadband interference noise will be present from over-the-air TV and radar signals.  The impact of these effects on the 5G performance is significant.

“There will be a 5G deployment cost optimization effort undertaken by the carriers and the municipalities.”, Wade added.  “The selection (with city approval) of the metro cell installations needs extensive Multiphysics analysis, to confirm the antenna radiation pattern margins.  There’s a big cost differential between placing, powering, and maintaining metro cell antennas every 100, 150, or 200 meters.”

Looking at Wade’s example diagrams above, and thinking about optimally locating and verifying the range of 4,200 antennas in a complex model of buildings and roads in a city like San Jose, the analysis task is immense.

I live in a medium-sized city – population of 91,000 – and I will venture to guess that our city planning department has given little thought to developing an analysis model and initiating discussions with carriers on antenna configurations.  It is early, I know, but I’ll attend an upcoming planning commission meeting to inquire.  If your city has already been actively engaged in 5G planning, please let me know how it’s going in the Comments below.

I also intend to delve deeper into the ANSYS Multiphysics flow for 5G analysis in the earlier figure, especially with regards to the models used – a good starting point will be the ANSYS link here.

A number of whitepapers are available at this link, as well.

-chipguy

 

Posted on

A Future Vision for 3D Heterogeneous Packaging

A Future Vision for 3D Heterogeneous Packaging
by Daniel Nenni on 10-07-2019 at 6:00 am
Categories: Events, Foundries, TSMC
3 Comments

At the recent Open Innovation Platform® Ecosystem Forum in Santa Clara, TSMC provided an enlightening look into the future of heterogeneous packaging technology.  Although the term chiplet packaging is often used to describe the integration of multiple silicon die of potentially widely-varying functionality, this article will use the term heterogeneous packaging.  The examples below illustrate integration of both large and small die, DRAM die, and a full high-bandwidth memory die stacks (HBM2), much richer in scope than would commonly be designated as a chiplet.  Dr. Douglas Yu, Vice President of Integrated Interconnect and Packaging at TSMC, provided a review of current TSMC heterogeneous packaging offerings, and a 3D package vision that could be best described as “More-than-More-than-Moore”.

Doug began with the well-understood realization that the pace at which the cost-per-transistor has improved with IC process technology scaling has slowed.

Figure 1.  The rate of cost-per-transistor improvements with process technology scaling has slowed.  (Source:  TSMC)

There are certainly ongoing product PPA benefits to scaling, but the ultimate cost for the total system functionality may drive system designers to pursue heterogeneous packaging alternatives.

CoWoS

The first heterogeneous packaging offering from TSMC was Chip-on-Wafer-on-Substrate ( CoWoS® ).  A cross-section of a CoWoS® package is illustrated below.

Figure 2.  CoWoS® package integration  (Source:  TSMC)

A silicon interposer provides the interconnects between the die, with through-silicon vias (TSV) to the substrate below.  Doug highlighted the recent advances in CoWoS® technology in production, specifically the ability to fabricate the interposer at 2X the max reticle size for wafer lithography.

Figure 3.  CoWo®S support for a silicon interposer greater than the single max-reticle size   (Source: TSMC)

InFO-PoP

Doug reviewed TSMC’s cost effective heterogeneous integration package, based on the Integrated FanOut (InFO) technology.  The original InFO offering provided (reconstituted) wafer-level redistribution layer connectivity to extended bump locations outside the die perimeter.  The newer InFO-PoP package cross section is illustrated below.

Figure 4.  InFO-PoP cross section  (Source:  TSMC)

The extension of the InFO molded package beyond the embedded die is used for Through-InFO vias (TIV) between the top die and the redistribution layer connections.

SoIC®

A more recent TSMC heterogeneous package innovation involves the transition from microbump connections between die and substrate to a bumpless (thermo-compression) bond between direct die connections – see the figure below for a comparison between microbump and bumpless attach. TSMC-SoIC® is an innovative frontend wafer-process-based platform that integrates multi-chip, multi-tier, multi-function and mix-and-match technologies to enable high speed, high bandwidth, low power, high pitch density, and minimal footprint and stack-height heterogeneous 3D IC integration.

Figure 5.  Comparison of bump and bumpless technology characteristics, and SoIC® package cross-section  (Source:  TSMC)

Through silicon vias provide connection to bumps, part of the final back-end package assembly flow.  The density and electrical characteristics of the bumpless attach technology are far superior.  (Here’s a previous semiwiki article that describes the TSMC SoIC® package technology – link.)

https://semiwiki.com/semiconductor-manufacturers/tsmc/8150-tsmc-technology-symposium-review-part-ii/

Future Vision

Doug provided a vision for heterogeneous packaging, which combines the unique advantages of the technologies described above.  The figure directly below depicts a bumpless SoIC® composite as part of a larger InFO or CoWoS® package, integrating additional die and/or HBM memory stacks.

The second figure below illustrates multiple levels of (thinned) die using bumpless attach for subsequent back-end package assembly.  Doug referred to this multi-level SoIC® solution as part of the transition from 3D system integration to full 3D system scaling.

Figure 6.  SoIC® integration in a subsequent InFO or CoWoS® package  (Source:  TSMC)

Figure 7.  Multi-level bumpless die integration à 3D system scaling  (Source:  TSMC)

The heterogeneous packaging technology vision presented by TSMC will truly provide system architects with great opportunities for continued scaling.  In addition to traditional monolithic die PPA considerations for technology selection, this vision offers additional opportunities for system-level functional integration and packaging cost optimizations.  It will be fascinating to see how these heterogeneous packaging offerings impact future system designs.