RVN! 26 Banner revised (800 x 100 px) (600 x 100 px)
Semiconductor Expert Forum

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.

Posted on

A Review of TSMC’s OIP Ecosystem

A Review of TSMC’s OIP Ecosystem
by Daniel Nenni on 10-06-2019 at 10:00 am
Categories: Events, Foundries, TSMC
1 Comment

Each year, TSMC conducts two events – the Technology symposium in the Spring and the Open Innovation Platform (OIP) ® Ecosystem Forum in the Fall.  Yet, what is the OIP ecosystem?  What does it encompass?  And, how does the program differentiate TSMC from other foundries?  At the recent OIP Forum in Santa Clara, Suk Lee, Senior Director, TSMC Design Infrastructure Management Division, presented a review of OIP, highlighting the breadth of technology and support available for TSMC process nodes.  Additionally, and very significantly, he described the extensive engineering investment made to develop and qualify new process design kit materials (PDK) and IP offerings.  Here are some of the highlights of Suk’s presentation.

Figure 1.  OIP partner overview  (Source:  TSMC)

OIP entails the collaboration between TSMC and numerous partners, spanning a range of technical facets of silicon foundry support:

  • EDA tool providers
  • IP developers
  • Design Center Alliance (DCA) providers, offering services ranging from system-level front-end design to back-end physical/test implementation
  • Value Chain Aggregators (VCA), additional service providers commonly offering a different set of capabilities, including assembly/test and supply chain management support

and, the newest aspect of OIP partnership, which was announced last year with the introduction of its OIP Virtual Design Environment (OIP VDE), lowering entry barriers of Cloud adoption for the customers of all sizes

  • Cloud service providers

To perhaps better distinguish between the DCA and VCA partners, Suk overlaid the previous chart on top of the Design Enablement and Process Development groups at TSMC – see the figure below.

 Figure 2.  OIP partner interactions with TSMC R&D  (Source:  TSMC)

Yet, these OIP designations are much more than companies enrolling with TSMC.  Suk emphasized the qualification requirements and ongoing monitoring to which each OIP partner is subjected, as illustrated below.

Figure 3.  Examples of OIP partner qualification requirements  (Source:  TSMC)

From TSMC’s own derivative of ISO9000 qualify management and assurance (aka, TSMC9000) to qualification of process interconnect technology definitions to ongoing certification of OIP service providers, there is a major emphasis on ensuring foundry customer success.

Perhaps the best illustration of OIP collaboration is the activity pursued with EDA partners during new process development.  This activity ensures new tool features and full methodology reference flow capabilities are qualified concurrently with initial process availability for IP developers and early end customer adopters.  Suk provided examples where new EDA tool attributes were defined, developed, and integrated into reference flows, driven by both process innovations (e.g., EUV lithography) and design reliability and manufacturability (e.g., via pillars, statistical analysis).  The figures below illustrate how the digital and custom design flows from EDA OIP partners were enhanced in support of these advanced process requirements.

Figure 4.  New EDA tool features addressing process requirements – digital flows  (Source:  TSMC)

Figure 5.  New EDA tool features addressing process requirements – custom implementation flows  (Source:  TSMC)

Engineers are skeptical by nature, seeking a silicon-proven demonstration of models, EDA tool features, and reference flows.  Suk highlighted the specific collaboration with ARM – for nearly a decade, TSMC and ARM have used leading ARM core IP as a testchip vehicle.  Full EDA (and IP) qualification reports are available at TSMC’s customer portal. On the day of OIP Forum, the two companies also announced the latest result of their collaboration, an industry-first 7nm silicon-proven chiplet system based on multiple Arm® cores and leveraging TSMC’s Chip-on-Wafer-on-Substrate (CoWoS®) advanced packaging solution.

 

Figure 6.  Screenshot of example EDA qualification reports on the TSMC portal   (Source:  TSMC)

With all the news relative to new process node announcements, it is easy to overlook the underlying activities and resources required to synchronize process availability with the companies supporting the related EDA, IP, and service provider ecosystem.  Suk’s presentation reminded the OIP Ecosystem Forum audience of the tremendous investment made as part of the effort to sustain Moore’s Law (for at least another node or two).  The focus that TSMC has applied to design enablement has truly been a differentiating characteristic of their corporate philosophy.

Posted on

SiFive Continues to Foster RISC-V in the Middle East With Tech Symposiums

SiFive Continues to Foster RISC-V in the Middle East With Tech Symposiums
by Swamy Irrinki on 10-05-2019 at 8:00 am
Categories: IP, RISC-V, SiFive

Workshops Coming to Istanbul, Amman, Cairo and Abu Dhabi

SiFive is continuing its tour through the Middle East with highly educational RISC-V Tech Symposiums and Workshops in the key locations of Istanbul, Amman and Cairo. These cities are some of the most technologically advanced in the region, and we are eager to collaborate with our co-hosts and partners to foster the growth of the RISC-V ecosystem. Attendance at these workshops is free, but registration is required. Here is a glimpse of what’s happening in each city. You can also visit https://sifivetechsymposium.com to learn more about these workshops and the SiFive Tech Symposiums being held throughout the world.

Istanbul – Tuesday, October 8

We are pleased to have Turkey’s TÜBİTAK BİLGEM as our co-host. This RISC-V Tech Symposiums and Workshop will feature a keynote presentation by Shafy Eltoukhy, senior vice president of operations and general manager of the Silicon Business Unit at SiFive. In addition, Tufan Karalar, associate professor at Istanbul Technical University will also be a featured speaker. Other speakers include Soheila Lighvani, director of IP strategic alliances at SiFive, and many more. Rajesh Varadhrajan, director of IP engineering at SiFive, will lead the hands-on workshop portion of the event. There will also be a hands-on workshop where attendees will have the unique opportunity to configure their own RISC-V core and bring up on an FPGA. To view the full agenda and to register to attend, please visit https://sifivetechsymposium.com/agenda-istanbul/

Amman – Thursday, October 10

With the University of Jordan and IEEE Jordan Section as our co-hosts, this will be a powerful event. There will be keynote presentations by Shafy Eltoukhy, senior vice president of operations and general manager of the Silicon Business Unit at SiFive, as well as a keynote presentation by Jamil AlKhatib, founder of IBTECAR. Ramzi Saifan, chairman of the Computer Engineering Department at the University of Jordan, will all be a featured speaker. In addition to these and other presentations, there will be a hands-on workshop where attendees will have the unique opportunity to configure their own RISC-V core and bring up on an FPGA. To view the full agenda and to register to attend, please visit https://sifivetechsymposium.com/agenda-amman/

Cairo – Saturday, October 12

Our co-hosts will be Mentor Graphics, the Egyptian Information, Telecommunications, Electronics, and Software Alliance (EiTESAL), and The American University in Cairo. This event will be highly educational and powerful. There will be a keynote presentation by Hazem El Tahawy, managing director of the MENA region for Mentor Graphics, about the Impact of AI on Semiconductor and EDA. There will also be a keynote presentation by Mohamed Shedeed, managing director of EiTESAL, about the first incubation specialized hardware based on IoT in the Middle East. A third keynote presentation will be given by Shafy Eltoukhy, senior vice president of operations and general manager of the Silicon Business Unit at SiFive, about the design revolution that is taking place in the semiconductor industry. There will also be a presentation by Mohamed Kassem, CTO of Efabless about a RISC-V based microcontroller. In addition to these and many other presentations by industry veterans, ecosystem partners and academic luminaries, there will be a hands-on workshop where attendees will have the unique opportunity to configure their own RISC-V core and bring up on an FPGA. To view the full agenda and to register to attend, please visit https://sifivetechsymposium.com/agenda-cairo/

Abu Dhabi – Tuesday, November 5

Our co-host for this workshop is the Khalifa University of Science and Technology, a leading independent research university , a leader among research intensive universities of the 21st century and catalyzing the growth of Abu Dhabi and the UAE’s rapidly developing knowledge economy. There will be keynote presentations by Naveed Sherwani, CEO of SiFive. In addition to these and many other presentations by industry veterans, ecosystem partners and academic luminaries, there will be a hands-on workshop where attendees will have the unique opportunity to configure their own RISC-V core and bring up on an FPGA. To view the full agenda and to register to attend, please visit

https://sifivetechsymposium.com/agenda-abu-dhabi/

We look forward to seeing you!

Posted on

Workflow Automation Applied to IP Lifecycle Management

Workflow Automation Applied to IP Lifecycle Management
by Daniel Payne on 10-04-2019 at 10:00 am
Categories: EDA, Perforce

Methodics, Flowable

I often blog about a specific EDA tool, or an IP block, but the way that SoC design teams approach their designs and then use tools and IP can either be a manual, ad-hoc process, or part of something that is well-documented, following a design methodology. Back in the 1980’s while at Intel our team first created a design methodology document in order to communicate with all team members how we were going to build a graphics chip for the emerging IBM-based PC market, but this was a paper document with no automation or enforcement, so our implementation was fraught with inconsistencies and too much manual effort.

WEBINAR: Concerned about IP security threats for your SoCs?

Today there are products for workflow automation like Flowable, also called a Business Process Model Notation (BPMN) platform. Think of a workflow as steps in the process of designing, testing or deploying a product. A workflow for IP Lifecycle Management enables an IP designer to create IP that follows best practices, quality standards and company policies..

Two specific examples of workflows in this context include:

  • IP development and release – IP has to meet a requirements check against specifications.
  • IP maturity classification – IP passes through multiple steps towards production readiness.

Some products need to meet a Functional Safety (FuSa) compliance, so they include traceability of the entire IP design flow – tools used, design process certification, verifying specifications are met for each stage. Using workflow automation is a big benefit to meeting FuSa compliance.

Methodics provides a tool for IP Lifecycle Management named Percipient, and it has features that workflows can use to automate projects:

  • Server hooks – a script attached to an IP that runs an action after IP creation or changes are made, checking the quality.
  • Client hooks – check an IP for quality within the user workspace, prior to allowing it into the Percipient server.
  • Events platform – receive real-time updates for any change to IP data.
  • Public API – used with the Events platform to work on data object.
  • Custom properties and attributes – a way to extend the data model for any IP.

So the Percipient tool has these features that allow for workflow automation, and then for more complex workflow automation you should use a workflow engine, like the open-source tool Flowable.

As an example, consider a workflow for the planning Bill of Materials (BoM) where you want to plan out each IP design block and the design schedules, creating a planning manifest for the whole project.

Using the Flowable Workflow Engine you can model this workflow, saved in the standard BPMN 2.0 format:

Main workflow
Component schedule

For this project IP we use multiple resource IPs, and the project schedules are created in Microsoft Project. Let’s look into each workflow step:

  • Start Event – the circle with triangle icon, creates a new IP with project Label, sending a request to the Flowable REST API.
  • New IP Notification – a user is notified about a new IP.
  • Planning IP Designation – notification sent to planning IP manager for review and classification.
  • Retrieve Resource IP schedules – the top IP has dependent IPs, which use the sub-process workflow in the second diagram, component schedule.
  • Generate IP Schedule Manifest – top-level IP has a manifest of all resource IP schedules.
  • IP BoM Approval – a user approves the planning BoM, while a project manager reviews the complete Bill of Materials.

The Percipient tool integrates with the Flowable modeling tool by defining a new IP attribute in Percipient, and setting a JSON object for that property.

A workflow instance is made for a workflow model, linking the instance to a specific IP version. Version identifiers are used and passed as variables using the Percipient REST API. Attributes and properties can also be set or updated after a specific workflow operation.

If a workflow requires human interaction then in Flowable you use a Forms application to design and process forms. Another way to get user input is through IP attributes with the Percipient REST API.

Summary

The combination of Percipient for IP Lifecycle Management and Flowable for workflow automation makes the IP and SoC design process more consistent and comply with FuSa and security standards. This blog has introduced the concepts of workflow automation, events platform, REST APIs, hooks and the Flowable tool for workflow modeling.

Why approach your design methodology in an ad-hoc method, when you can define and enforce how the project should follow best practices?

Vadim Iofis, VP of Engineering at Methodics has written a 10 page White Paper which you can read now after a brief registration process.

Related Blogs

Posted on

The GF Pivot, Specialization Defined

The GF Pivot, Specialization Defined
by Randy Smith on 10-04-2019 at 6:00 am
Categories: Events, Foundries, GlobalFoundries
2 Comments

On August 27, 2018, GLOBALFOUNDRIES (GF) announced that they were no longer going to compete in the race to the next smaller semiconductor node, at that time, the 7nm node. While surprising to some, on further analysis this move made sense. TSMC had announced its plan to invest around $25B in the 5nm technology node. GF revenue is about $6B annually. Easy decision. Winning in semiconductor manufacturing is like most businesses – you must deliver value. Since GF wasn’t going to deliver the most advanced nodes how was it going to stand apart as a supplier? The answer at that time was stated as “Differentiated Offerings.” At GF’s recently held Global Technology Conference 2019 in Santa Clara, CA, we got a chance to see how that pivot was working. From what I heard, it appears to be going quite well.

After the keynote speeches, three GF senior vice presidents (SVPs) spoke about their team’s efforts to deliver differentiated solutions to their markets. First up was Bami Bastani, SVP and GM, Mobile and Wireless Infrastructure SBU. A recurring theme was seen right away. In the keynotes we learned that GF’s definition of the Innovation Equation – (platforms) x (application features) x (IP) = (specialized application solutions). So, to succeed in any market GF was going to specialize in, it would need to deliver advanced solutions for each of these areas for the applications in those markets.

Bami’s area is mobile and wireless, where low power is the dominant concern. Here, GF has a terrific platform with 22FDX®, a very low power Fully-Depleted Silicon-On-Insulator (FD-SOI) process with the industry’s only body-bias ecosystem. This process supports good speeds with excellent results for lower power and lower leakage. GF’s 22FDX also supports an eMRAM-F low power embedded memory. This type of low power on-chip memory will be critical for AI/ML at the Edge as it provides a nice combination of power/performance/density combination for IoT devices. If you need higher performance than could be achieved in 22FDX while still maintaining lower power consumption, then there is GF’s 12LP+. Here there are ongoing advanced techniques including 2.5D/3D packaging and an AI reference package. Bami also brought up GF AutoPro™ which brings features in support of ADAS, infotainment, powertrain, and other automotive subsystems.

You can’t discuss GF processes without talking about its work in wireless. Building on that expertise is the 22FDX® 77GHz radar transceiver. Radar usage will be growing in the automotive area, but we also cannot overlook the impact of 5G on automotive and many other application areas. While GF may not plan on building the big processor chip on the latest node, it looks like GF will provide very competitive solutions for much of the remaining electronics in 5G handsets. GF will be supporting the likely processes for wireless charging, NFC, display interfaces, and more. Of course, they will also be supporting the processes that will dominate in the base station radio and digital (baseband) components. There is clear differentiation provided by GF for these markets.

If you want to economically provide leveraged differentiation, you look for things you can do that will provide value to several different application areas. Gregg Bartlett, GF’s SVP, Engineering, Technology, and Quality was up next to discuss these types of efforts at GF. As Gregg pointed out, we are moving into an era of high specialization. Generalized solutions are inefficient, both in speed and in power. This shift has led to many advances in application-specific processors. What GF is showing is that it also leads to specialized technologies – different processes for different applications. They can now show this across many different markets. The slide below is a small but interesting subset of the markets served. The number of unique processes support by GF very large.

The final speaker of the morning was Mike Cadigan, SVP, Customer Design Enablement. Mike first went through the various partnership models GF uses to support its customers. These relationships include infrastructure areas such design technology co-optimization (DTCO), process design kits (PDKs), reference designs, IP/EDA ecosystem support, tape out services, and post-fab services. These are required services to enable customer success. GF has hundreds of participating partners to enable customer designs. However, GF goes further, such as its 22FDX® Body Bias solutions and use models developed with Dolphin Integration. GF has many companies supporting IoT and wearables design on its platforms. There are also collections for partners for supporting automotive designs. Quite noticeable were the prior and new solutions attributed to ARM. More on that in an upcoming blog.

It looks like the transformation of GF is going quite well, and the fruits of the transition are quite visible.  If you are looking for a semiconductor partner anything RF, wireless, low power, automotive, or wearables you should check out what GF has to offer now.