webinar banner2025 (1)

Designing AI Accelerators with Innovative FinFET and FD-SOI Solutions

Designing AI Accelerators with Innovative FinFET and FD-SOI Solutions
by Daniel Nenni on 07-29-2020 at 10:00 am

Globalfoundries AI Webinar Hiren Majmudar

I had the pleasure of spending time with Hiren Majmudar in preparation for the upcoming AI Accelerators webinar. As far as webinars go this will be one of the better ones we have done. Hiren has deep experience in both semiconductors and EDA during his lengthy career at Intel and now with a pure play foundry. He is intelligent, personable, and a great speaker, absolutely.

Register HERE today and if you can’t make the broadcast on August 6th at 10am PDT we will send you the replay.

Designing AI Accelerators with Innovative FinFET and FD-SOI Solutions

Explosive data growth has led to significant power bottlenecks from the data center to the edge. Enter the Renaissance of Computing, featuring purpose-built accelerators that solve these problems, significantly speeding up AI applications such as training and model inferencing in the cloud and at the edge. Utilizing these and re-imagining architectures solves power issues that empower applications like audio, video and image processing, smart edge devices, and autonomous vehicles.

This webinar will highlight GLOBALFOUNDRIES’ unique AI solutions for both Cloud and Edge via dual FinFET (12LP and 12LP+) and FD-SOI (22FDX®) roadmap to address power bottleneck in training and inference applications. The FinFET platform features optimized standard cells and a single rail 0.55V Vdd bitcell. In contrast, 22FDX features 0.5V ULP and 1pA/cell ULL power options and eMRAM. Additionally, comprehensive IP for host communication via PCIe and memory via DDR / LPDDR / GDDR and HBM are available for both platforms to accommodate embedded or external memory AI architectures.

The speaker is Hiren Majmudar, Vice President and General Manager of the Computing Business Unit at GLOBALFOUNDRIES. In this capacity, he is responsible for P&L management of GF’s Computing Business with a focus on CPU, GPU, AI, FPGA, and Gaming customers.

Hiren has over 25 years of experience in the semiconductor industry. Before joining GF, he was Vice President of Corporate Business Development at SiFive. He has also served as Vice President and Managing Director at Intel Capital, where he led Corporate Venture Investments and M&A practice with focus on Semiconductor Design Sector. He has spent 20 years in technical and management leadership in Silicon Design, EDA & Software Development Tools, Technical Marketing, and Business Development.

This webinar is in partnership with SemiWiki and GLOBALFOUNDRIES

About GF

GLOBALFOUNDRIES (GF) is the world’s leading specialty foundry. GF delivers differentiated feature-rich solutions that enable its clients to develop innovative products for high-growth market segments. GF provides a broad range of platforms and features with a unique mix of design, development and fabrication services. With an at-scale manufacturing footprint spanning the U.S., Europe and Asia, GF has the flexibility and agility to meet the dynamic needs of clients across the globe. GF is owned by Mubadala Investment Company. For more information, visit www.globalfoundries.com.

Also Read:

Contact over Active Gate Process Requirements for 5G

Embedded MRAM for High-Performance Applications

Webinar on eNVM Choices at 28nm and below by Globalfoundries


DAC Panel: Cadence Weighs in on AI for EDA, What Applications, Where’s the Data?

DAC Panel: Cadence Weighs in on AI for EDA, What Applications, Where’s the Data?
by Mike Gianfagna on 07-29-2020 at 6:00 am

Drivers of Convergence in Computational Software

DAC was full of great panels, research papers and chip design stories this year, the same as other years. Being a virtual show, there were some differences of course. I’ve heard attendance was way up, allowing a lot more folks to experience the technical program.  This is likely to be true for a virtual event. I’m sure we’ll see more statistics on that in the coming days.

AI and EDA is a favorite topic of mine, so when I saw a panel on the subject I was definitely going to attend. The panel focused on the EDA applications that had opportunity for AI assistance and how to assemble the data needed to train these applications. This second part is particularly important and problematic.  More on that in a moment. Below is a summary of the panel focus. These are compelling topics.

This panel will discuss and debate two main questions that must be solved before machine learning can be successfully applied to computer-aided design of electronic systems. First, at what levels of abstraction is machine learning applicable? Potential applications include device optimization, circuit synthesis and optimization, logic synthesis, ESL, verification, and validation. The impact of machine learning at these levels of abstraction is up for debate.

Second, how do we manage the huge amounts of data required to apply machine learning? Does data need to be labeled; if so, who will provide labels? Can models be used to augment labeling? What intellectual property rights must be negotiated to obtain training data? Who will own the results of machine learning methods driven by outside data?

The panel was co-hosted by Jiang Hu from Texas A&M and Xiaoqing Xu from Arm. The panelists were:

  • Elias Fallon – Cadence Design Systems
  • Paul Franzon- North Carolina State Univ.
  • Raviv Gal- IBM Research
  • Sachin Sapatnekar – Univ. of Minnesota

Cadence has been quite active in the area of AI for EDA. I’ll cover the comments from Elias Fallon. First, a comment about the format of this particular panel. Most presentations and panels at DAC were pre-recorded, so on event day attendees are able to watch well-rehearsed presentations that flow quite smoothly. Due to some last-minute changes in the agenda, this panel was done live. It seems the panelists found out about this on event day. I have to say, a live event does have some spontaneity that provides an extra level of interest. All the panelists and the moderators did a great job keeping the session moving. Elias kicked off the panel. Here are some details of his comments.

Elias has 20 years of experience in EDA, mostly in analog IC design. He was originally at Neolinear, which was acquired by Cadence in 2004. Elias began with a broad observation about the convergence of drivers for computational software. Machine learning being applied to EDA problems so EDA can be applied to machine learning chip design is an example of this convergence. Cadence published a white paper on the topic of computational software that I covered on SemiWiki here. The diagram at the topic of this post is an example of how all this fits together provided by Elias.

Elias pointed out that AI is a new tool in the toolbox that can be used to advance the capabilities of EDA. Given the difficulty and scale of the problems EDA tries to solve, a new tool like AI can have a significant impact. To illustrate the data challenges associated with AI for EDA, Elias used an example problem – physical grouping of transistors for optimal performance in an analog IC layout. Elias explained that this problem has been the subject of a lot of research. He went on to point out that, in spite of it sounding simple, the ways to group and interdigitate transistors in an analog layout is highly context-dependent. Things like technology, application, yield learning and prior trial-and-error efforts to get it “just right”. All that makes this problem difficult to automate. So, can machine learning be applied to this problem to utilize good past results to achieve better future results.

The next point was shared by others on the panel as well. There just isn’t that much public data available on chip design. Commercial design details are sensitive from a competitive point of view. Even data assembled by the research sector is difficult to share due to the foundry process details it contains. All told, if one can assemble the details of five or six past analog layout designs, that’s about all you can get. The trick is decomposing the machine learning problem down into pieces that can be trained with less data.

Another interesting aspect of this lack of standardized data is that EDA algorithms will likely need to be able to perform autonomous training in the field, leveraging all the unique conditions that the tool encounters. Yet another challenge for EDA to solve.

If you have a pass for DAC, I highly recommend you listen to the entire panel. I believe the DAC presentations will continue to be available for a while. You can find this panel on AI, EDA and the data needed here.

Also Read

#57DAC – Panel Discussion of High Level Synthesis

Cadence Defines a New Signoff Paradigm with Tempus PI

Using AI to Locate a Fault. Innovation in Verification


#57DAC – Panel Discussion of High Level Synthesis

#57DAC – Panel Discussion of High Level Synthesis
by Daniel Payne on 07-28-2020 at 10:00 am

sean dart, Cadence

Presenters took a trip down memory lane at DAC this year by having a panel discussion on HLS (High Level Synthesis) spanning from 1974 to 2020, and that time period aligns with when I first graduated from the University of Minnesota in 1978, starting chip design at Intel, then later transitioning into EDA companies by 1986. Marilyn Wolf from the University of Nebraska organized the panel, but then at the last minute had Yuan Xie from UCSB moderate. Using Zoom for the live panel had a few glitches, but Yuan kept things moving when a presenter sporadicly disappeared.

Bryan Bowyer from Mentor was the first to present, and the earliest High Level Synthesis tools like Monet were only well-suited for datapath architectures. The first languages were VHDL and Verilog, then eventually moved into C++ and SystemC code. Today with open-source class-based libraries the HLS world is quite changed and simpler than ever to use, practical for processors, NOC, bus interfaces, even RISC-V chips. Mentor’s HLS tool is Catapult.

Deming Chen, a professor at UIUC also works at a startup called Inspirit IoT. He saw how HLS came to the rescue offering 10X code reduction and 1,000X simulation speed ups. RTL thrived during 1985-2010, however HLS came into it’s own in 2000 with Forte, followed by tools from Cadence, Mentor, even NEC by 2005 and Synopsys in 2009. Here’s a sneak peek into the approach with Inspirit IoT:

From Cadence was Sean Dart who showed how High Level Synthesis tools started in 1996 with DASYS RapidPath, 2001 with Forte Cynthesizer, 2007 saw Cadence C-to-Silicon, and by 2015 the Stratus HLS tool which combined the best features of Cynthesizer and C-to-Silicon. Present day HLS tools are being used for quite a wide range of SoCs, like: AI, 5G, auto vision, WiFie, Imaging, cameras, networking, GPU and more. Dart believes that HLS tools have to solve meaningful problems, include a world-class scheduler, have QoR comparable to hand-coded RTL, integrate with physical implementation tools, be easy to use for engineers, and have existing tool flow support.

The presenter from Synopsys was Pierre Paulin, joining them in 2013, Issues with HLS started right away, because in the 90s there was no standard input language. Application Specific Instruction set Processors (ASIP) came about around 2000 using standard cores plus extensions. By 2015 AI was being applied to HLS using Convolutional Neural Network (CNN) graphs, then TensorFlow and ONNX graphs became standards. Domain-specific accelerators for AI and neural networks have just exploded since 2017, powered by HLS tools.

Wakabayashi-san from the University of Tokyo gave a history of how the CyberWorkBench tool emerged from inside of NEC to become a commercial High Level Synthesis tool. NEC did a commercial chip for SONET controller back in 1994, and by 1999 they had a cycle-accurate HLS ability and designed a NIC. C-based verification came out in 2000, and an automatic pipeline featured debuted in 2002. Visitors to DAC in 2006 heard about CyberWorkBench for the first time.

Q&A

Q: What is the benefit of using HLS versus traditional RTL design?

Wakabayashi: The total quality is good with HLS.

Dart: A CDNLive user said, “Our company has zero tolerance for PPA that is worse than hand-coding.”  With HLS you have enough time to actually explore alternative architectures.

Bowyer – Over the past 20 years we’ve added the best HW design experience to our HLS tools, so the area results are matching hand-coded designs. For low power designs HLS results are better than hand-coding.

Paulin – Exploration is the key benefit of HLS.

Chen – Exploration and migration are huge benefits of HLS, our startup is even using ML to get better HLS results

Q: What key domains are HLS tools being used in?

Dart – We see HLS being used in AI, WiFi, 5G, modems, image processing, cameras.

Bowyer – Hardware accelerators are good HLS applications, DSP, AR< 5G, WiFi.

Wakabayashi – The H.265 standard, and any complex algorithm are ideal for HLS approach.

Chen – Accelerator chips do best in HLS methodology.

Q: Today we see C, C++ and SystemC used for HLS, but what about other languages?

Bowyer – We’ve just recently standardized on SystemC, so it’s kind of early and impractical to talk about using newer languages.

Dart – I agree, it’s not just the HLS language, it’s the whole tool environment, debug, verification, so all of those need to be connected, design and verification flows.

Chen – Even C code can embed assembly code, so with HLS it’s possible to go higher than C++ and SystemC. A Python driven HLS tool could happen.

Wakabayashi – Python could be used for HLS, but then you need new libraries to really be efficient. In HLS the linked list is not handled well now, but it’s a good research area.

Chen – We’re not a big three EDA vendor, so we’re focusing FPGA devices, doing some ML code analysis, have multi-cycle support, and are working with customers to make them happy first. We’re looking to be acquired by a bigger company.

Q: What are new research directions in HLS for those graduate students listening?

Chen – Dealing with very large designs, because HLS is kind of domain-specific and used more at block-level.

Bowyer – HLS research for AI like data flow at a higher level of abstraction.

Paulin – HLS should try TensorFlow as an input language, then compile that into both HW and SW.

Wakabayashi -We want intelligent, automatic exploration across the entire PPA space.

Dart – HLS could improve on scalability and power. Being able to optimize across an entire design is a good research area. Oh, and any kind of HLS training that students have in school will make for a bright career right now.

Summary

In my IC design career I’ve witnessed transistor-level full-custom design, gate-level design, RTL design, and more recently HLS design. The shift towards HLS design methodology is growing steadily, because it works while providing outstanding productivity, and there’s a robust commercial marketplace with multiple vendors to choose from. The bigger the EDA vendor, the more likely that they’ve integrated HLS with physical implementation tools, something quite important for the smallest node designs.

If you registered for DAC and have access to the archived videos, find this panel presentation that runs for 1 hour and 13 minutes.


Low Power and RISC-V Talks at DAC2020, Hosted by Mentor

Low Power and RISC-V Talks at DAC2020, Hosted by Mentor
by Bernard Murphy on 07-28-2020 at 6:00 am

low battery

I’m going to get to low power and RISC-V, but first I’m trying out virtual DAC this year. Seems to be working smoothly, aside from some glitches in registration. But maybe that’s just me – I switched email addresses in the middle of the process. Some sessions are live, many pre-recorded, not quite the same interactive experience as live talks. There’s a live Q&A chat window during the recordings, continues on after you’ve watched the recording. Slightly strange experience if you listen to multiple papers in a session, watching Q&A chats running asynchronously from the videos you’re watching. Then again, being able to go back and replay pre-recorded sessions is very cool.

Machine learning for building power models

This was a very good session. Dave Rich from Mentor chaired a mixed group of topics, some on low power, some on innovative directions around RISC-V. He kicked off with a presentation from Caaliph Andriamisaina of CEA-LIST on learning-based power modeling. Power models are useful in a variety of contexts: for IPs/subsystems to accelerate estimation in larger systems, for power distribution network design and for thermal modeling. The challenge of course it to extract a sensible and accurate model from hundreds of gigabytes of detailed power analysis at the RTL level. Caaliph does this through machine learning on the simulation traces, using K-means clustering to group windows on the data into similar profiles. From this he extracts ~2% of the signals to come up with a model which demonstrates 95% accuracy versus the original power data.

Retention verification

Next up was Lakshamanan Balasubramanian from TI to talk about accurately verifying retention behavior in low power designs. This can be quite complex, especially in sequence dependencies between state retention, clock and reset controls, eg on wakeup. According to Lakshamanan, these behaviors are not handled thoroughly in standard low power verification flows. TI have built a simulation overlay to handle verification more comprehensively. They found this flow enabled them to address potential retention issues early in the design flow.

UPF macro models

Rohit Sinha from Intel followed with a discussion on using Hard IP power models to simplify hierarchical design. The guts of UPF far exceed my meagre understanding, but one thing I do get, at least intuitively, is the massive complexity of creating and managing UPF for very large SoC designs. Rohit talked about more than 2000 IPs, both soft and hard, 30-40 power domains and 4 main levels of hierarchy from IPs up to the SoC. His point is that power macro models for hard IPs can greatly reduce this complexity, reducing chance for errors and reducing simulation time. Please check out the replay of his talk for a more intelligent understanding than I can provide.

Google testbench generator for RISC-V

Tao Liu presented next on an open-source configurable testbench generator for RISC-V-based systems. This aims to provide full-feature support, an end-to-end flow integrated with mainstream simulators, and a standalone functional coverage model. Testbenches are generated in SV/UVM (no plans so far for PSS support) as complete programs with randomization. Google first released this to Github in the first half of 2019, in 2020 they have already formed a working group under Chips Alliance, together with a bunch of companies. No details provided on how well this integrates with standard verification flows. Nevertheless, an interesting direction.

Post-quantum cryptography

Markku-Juhani Saarinen of PQShield in Oxford followed to talk about prototyping accelerator architectures for post-quantum cryptography (PQC). As Markku was quick to point out, these are not based on quantum computing. They use conventional computing methods to design cryptography algorithms which are quantum resistant. I wrote about this some time ago. These algorithms use new mathematical approaches, such as lattice-based methods. And like more conventional crypto algorithms, they can benefit from acceleration. The trick is to figure out architectures for those accelerators. Markku uses RISC-V software emulators as a starting point, since the emulator allows for near-real-time performance. When the architecture is reasonably settled, they move to an FPGA implementation with multiple algorithms embedded, ranging from ISA extensions in the RISC-V core to dedicated accelerators. Well-timed development, since NIST standards for PQC are expected to be released this year.

Advanced Security support

Professor Sylvain Guilley, CTO at Secure-IC wrapped up (he also holds academic positions at Paris TELECOM and elsewhere). He introduced their Cyber Escort system, a module that sits to the side of the main processing path, monitoring both software and hardware behaviors. Sylvain particularly called out the DARPA System Security Integration Through Hardware and Firmware (SSITH) program as a model with which they aim to align. That program is ambitious, targeting anomalous state detection, meta-data tagging, and churning of the electronic attack surface. Secure-IC already has a partnership with Andes technology (hence the RISC-V connection).  They are already in the Root of Trust for a number of automotive-grade chips for car-to-car V2X communication.

Quite a broad span of topics! If you have access to the DAC 2020 site, you can lean more HERE.


A SoC Design Flow With IP-XACT

A SoC Design Flow With IP-XACT
by Ranjit Adhikary on 07-27-2020 at 10:00 am

soc flow with ipxact

Taping out a SoC is never easy. The physical dimensions of the chip often belie the work which has been done to get to the tapeout stage. And it is still not a done deal as the hardware and software development teams await the arrival of the test chip from the foundry to complete the post silicon bring-up and validation. The pressure on the design team is telling, more so due to the possibility of the chip not functioning as desired. A failing test chip brings up the prospect of potentially missing the market window and taking a hit on the cost incurred owing to the high NRE cost in the case of lower process nodes and missed schedules.

In most cases, the development of the SoC or IP is the handiwork of dedicated design teams spread across multiple locations, and collaborating using in-house design flows for their EDA tools. The efficiency of design flows employed within the design companies plays a very critical part to successful tapeouts. Enterprises which have this secret sauce manage to successfully tapeout time and again. These design companies have integrated their design tool flow between the EDA tools, with flow automation and efficient design handoffs. Seamless exchange of the design data between the software, hardware and verification teams enables the engineers to work in tandem and engage in productive collaboration. Ensuring reusablity and using a single source to automatically generate the desired correct-by-construction collateral consumed in various formats by different team members pays rich dividends and helps shorten the design development cycle. An additional benefit of this approach is that it mitigates the possibility of mis-interpretation of data or developing code based on an incorrect version of the collateral such as the memory map. It also reduces the effort otherwise spent on manually developing the desired code and verifying the same.

The importance of a good flow and efficient collaboration between the different teams becomes even more significant today during the current pandemic and a potential economic downturn rivaling the Great Depression. Setting up a design flow and automating as far as possible helps in performing well defined, potentially mundane tasks which are prone to human error. These include for example, virtual prototyping, generation of structural RTL for top level wiring, insertion of test logic, documentation, design handoffs and creation of testbench and test vectors to verify the design. So, what are some of the key ingredients of developing a flow, which increases the possibility of successful tapeouts?

One of the key ingredients for most of the recipes deployed by companies in developing a successful design flow is a good data model, malleable enough to be used for automating the different nuances of the complex design flows of today. While some companies prefer using proprietary data models alongside Perl/Tcl/Python scripts, a number of companies have opted for using IP-XACT. There are a number of advantages of using IP-XACT as a base for the design flows. Some of these are listed below:

  • It is an IEEE standard which implies it is open and accessible to all. Dependence on proprietary methods to develop design flows, can impose restrictions in modifying them as and when needed.
  • It comes equipped with a standard API which can be used to customize solutions by complimenting the IP-XACT description with a layer of software.
  • Using the API, embellishes the value proposition of the generators. It can be used to capture the configuration intelligence within the generators to automatically generate the final configured IP-XACT description of an IP.
  • It is extremely flexible, works with huge legacy systems and yet can be applied to projects that have no legacy IP.
  • IP-XACT standardizes a number of different meta-data specifications and provides a tight generator interface (TGI) to provide programmability.
  • Distributed software and hardware teams can use IP-XACT to collaborate more efficiently and exchange design information quickly between different design environments.
  • It pulls together different EDA tools from multiple vendors into a single integrated design and verification environment.

It is a given for most chips developed these days to have a software component associated with it, to control and manage its operation. The first step in any SoC development cycle involves the creation of the design specification. But with the growing importance of safety critical systems in industries such as automotive, aerospace, defense etc., a number of designs have an associated set of requirements typically captured using ReqIF (Requirements Interchange Format) where put simply, every requirement should be tied to a specific part of the design. This set of requirements defined using ReqIF, is then used to automatically seed the design specification. The associated documentation that is generated as a result, eventually feeds into the overall design documentation. This brings into play, the notion of design traceability, something which is growing in relevance in the SoC designs of today and maintained throughout the design flow.

Along with the crystallization of the design specification seeded through a set of requirements, the reality is that the hardware-software memory map also gets developed in tandem. This memory map along with the architectural specifications forms the common source for the starting point in the design flow. Different outputs such as structural RTL, C header files, System C files are generated automatically to ensure that the design prototype is verified and confirmed to work as expected. This is an iterative flow and any changes required downstream in the design cycle is validated in the prototype and the necessary outputs generated for use downstream. This approach ensures that all the teams are using the same version of the outputs generated leaving little scope of misinterpretation of specifications. An additional benefit of this approach is that it enables the verification team to validate the results at different stages of the flow and ensures that the results are consistent across the flow.

While everyone agrees with the benefits of a good design flow, it is useful to consider the importance of flow automation from another perspective. Aberrations in any SoC development cycle is often caused due to design modifications such as changes to the functionality, modifications to memory map etc. or due to problems which can creep in at any step of the design flow. With increased design complexity and dispersed design teams, it becomes important to keep everyone in sync, something which is critical in keeping a design on track. Design engineers have often been guilty of making the necessary design changes locally, and then failing to inform other engineers about the changes made to the design. The ramification of this faux pas is often felt late in the design cycle. To resolve this issue, it becomes important to ensure that the changes are made at the design architecture stage and post validation, proliferated to all the teams to keep the numerous models – architectural, TLMs, software, power and RTL, documentation etc. in sync.

The next step in most design flows involves defining the top level of the SoC along with the power and timing constraints. Defining the top-level partitions, their pins, and their interconnect is something which can be done using several methods instead of a manual approach. A number of companies use different approaches for this, but a common thread involves using custom Tcl, Python or Perl scripts along with a proprietary data model to define the interconnect. While custom scripts have helped to considerably boost the automation of design flows, their productivity gets severely limited when design teams have to modify the scripts in order to adapt to different design constraints or integrate with unfamiliar 3rd party IPs. As a result, of late, a number of companies have abandoned this approach and are migrating to using IP-XACT. This approach eases the pain involved in manually creating the interconnect, making modifications, ECOs and eliminating connectivity errors while retaining the flexibility to automatically generate the RTL in different languages. For each of the partitions defined at the top level, the IPs – either 3rd party or internal IPs are packaged if needed, qualified and wired either to other IPs or to black boxes (any yet-to-be-developed design module) using methods similar to the integration of the top level as described above. Using IP-XACT solutions instead of custom scripts, provides the ability for designers to integrate IPs from multiple suppliers and verify that IP in-situ with a variety of leading edge verification tools, such as protocol checkers, design rule checkers, clock & reset domain crossing analysis, static timing and formal verification tools, embedded software testing etc.. A large part of the outputs needed for these tasks are automatically generated thereby ensuring a common reusable flow.

Having a reusable connectivity solution provides design teams with several benefits. Some of them are captured below.

  • Quickly build a correct-by-construction platform-based design by adding the necessary components and interfaces, making modifications easily as needed.
  • Flexibility in implementing design through a bottom-up design or top-down design flow or a combination of both.
  • Easily package legacy RTL as an IP-XACT compliant IP and wire as needed in your design.
  • Provides a method to keep track of the various versions of an IP being used in the design, and if the latest version does not work, always fall back to an older version.
  • Ability to connect design instances by using a common bus or a custom interface thereby reducing the total number of connections in a design.
  • Minimize the scope of making errors while connecting IP instances.
  • Manage modifications to logical design hierarchy based on the physical design requirements while considering timing and power constraints.
  • Manage IPs, SoCs configurations/re-configurations easily as needed and netlist the design in the desired format such as Verilog, VHDL, System Verilog or System C.
  • Create better workflows through efficient design handovers in-between design teams.
  • Generate documentation automatically in different formats such as pdf, MS Word, Dita, html etc. This becomes particularly important as a number of things change in the design cycle during the hardware-to-software iterations which often causes the design documentation to be out of sync with the changes made. Automatic document generation ensures that the documentation is always current and in-sync with the design changes.

Each of these partitions or blocks defined at the top level, comes with its timing budget and power estimates which needs to be met and serve as guidelines for the construction of the design partition or top-level blocks. These constraints may change due to roadblocks found during design implementation or architectural changes, but a flow such as this enables a quick iteration by making changes at the design specification stage and then automatically generating the outputs needed for the downstream flow and tools.

Talking about the design flow with IP-XACT would be incomplete without mentioning about the PPA (Power-Performance-Area). Meeting the PPA is a critical requirement for all designs and is often prone to long iteration cycles from manually modifying the RTL to long tool runtimes. To find a suitable solution, successful design flows empower design teams to try various what-If scenarios to create the design hierarchy best suited to meet the PPA during physical implementation. Some of the features included in such flows are

  • Ability to modify logical hierarchy while automatically generating RTL in the desired language. Logical restructuring features include
    • Grouping instances at the same level of hierarchy into a new hierarchy or ungroup a hierarchy as needed.
    • Moving an IP or sub-system from one hierarchy to another.
    • Creating feedthroughs or re-route nets as needed while preserving existing connections and memory maps during hierarchy manipulation.
  • Define multiple design hierarchies without actually modifying the actual design hierarchy.
  • Manage timing and power constraints effectively for the different hierarchy.
  • Select which hierarchy produces the best results for timing closure.

To hasten the process of developing the SoC or IP using well defined flows, it becomes necessary to use solutions which are tried and tested and is part of a production flow in several companies. For more information on how to automate your design flows and build your designs faster, visit www.magillem.com.

Magillem customers include the top 20 semiconductor companies worldwide.

Magillem is a pioneer and the leading provider of IP-XACT based solutions aimed at providing disruptive solutions by integrating specifications, designs & documentation for the semiconductors industry. Using the solutions provided by Magillem, design companies can automate their design flows and successfully tape-out their designs faster at a reduced cost.

Magillem is one of the leading authorities on IP-XACT standard. It is also the Co-chair of the IP-XACT 2021 Accellera committee and an active member since the inception of the IP-XACT standard.


Synopsys Webinar: A Comprehensive Overview of High-Speed Data Center Communications

Synopsys Webinar: A Comprehensive Overview of High-Speed Data Center Communications
by Mike Gianfagna on 07-27-2020 at 6:00 am

Screen Shot 2020 07 25 at 8.43.22 PM

High-speed communication is a critical component for many applications, most notably in the data center. The serializer/deserializer physical interface, or SerDes PHY is the backbone of many different forms of high-speed communication for this application. Use cases include on chip, between chips, between boards and racks and across and between data centers. The requirements run from long reach to ultra-short reach. Satisfying all these requirements demands outstanding engineering and attention to detail.

I was able to preview a webinar from Synopsys recently that does a great job taking the viewer on a tour of all these applications. The webinar is presented by Manmeet Walia and Manuel Mota, both senior product marketing managers at Synopsys. These gentlemen have both been at Synopsys for more than 11 years and both have over 20 years of industry experience, so you’re in good hands for the tour.

The webinar begins with an overview of the various communication regimes – inside the box, box-to-box and enterprise, data center and telco applications. The technical requirements and interface standards relevant to each area are discussed. At an application level, the required IP components for a computing and networking SoC are discussed. It turns out there are four key “pillars of technology” that must work together to address the demands of these applications. Synopsys presents a nice diagram that summarizes this.

The presenters next examine some of the integration and layout requirements for these types of SoCs. The specifications that define requirements from ultra-short reach to long reach applications are also reviewed. The move from NRZ to PAM4 encoding has had a huge impact on data communications. The specific requirements and challenges of PAM4 are discussed in detail as well, along with eye diagrams to illustrate the points discussed. Various architectural approaches to implement the required technology are also reviewed, along with a discussion of which architecture delivers the best performance from a low-latency point of view.

Many high-end SoCs for large data center applications will integrate hundreds of SerDes lanes. This creates significant packaging and signal integrity design challenges. These are discussed during the webinar as well. Crosstalk and jitter are discussed in detail with example data presented. Methods for performing lab measurements and the use of eval boards are also discussed.

The webinar then turns to die-to-die communications. The design challenges and standards efforts underway are reviewed in detail. There are basically four primary use cases for die-to-die technology:

  • Various configurations of homogenous dies for to serve different markets
  • Split very large (reticle size) die into multiple parts for yield enhancement
  • Aggregate multiple functions from different process nodes to reduce power and improve form factor
  • Disaggregate a large SoC to facilitate migration of core functions to a new process node

Example design are discussed. The various multi-chip packaging options available today are also reviewed in detail. The different approaches to implement ultra-short, very short and medium/long reach communication are also presented with the benefits and challenges of each. Design and validation flows for multi-die connectivity are discussed, along with diagnostic approaches.

The webinar concludes with an overview of Synopsys products and support for 56G and 112G applications. There is also a short Q&A session. If high-speed communication is part of your design requirements, I urge you to register for this webinar, you will likely learn something new. The webinar will be broadcast on August 4, 2020 from 10AM – 11AM PDT. You can register for the High-Speed SerDes PHY IP for Up to 800G Hyperscale Data Centers webinar here.

Also Read:

Accelerating High-Performance Computing SoC Designs with Synopsys IP

Quantifying the Benefits of AI in Edge Computing

Synopsys Introduces Industry’s First Complete USB4 IP Solution


VLSI Symposium 2020 – Imec Buried Power Rail

VLSI Symposium 2020 – Imec Buried Power Rail
by Scotten Jones on 07-26-2020 at 10:00 am

thl61591895083576 Page 04

The 2020 VLSI Technology Symposium was held as a virtual conference from June 14th through June 19th. At the symposium Imec gave an interesting paper on Buried Power Rails (BPR) and I had a chance to interview one of the authors, Anshul Gupta.

As logic devices continue to scale down metal pitch is reaching a limit. Imec defines a pitch of 21nm for N4 then 16nm at N3, 16nm is challenging. The height of a standard cell in logic is the metal pitch multiplied by the number of metal tracks, a recent trend in device scaling is to reduce the track height. The current state-of-the-art is a 6-track cell. One thing limiting track height is the power rails that are typically double width due to resistance issues. If you bury the power rials in the substrate you can reduce the track height to 5 tracks and relax the metal pitch requirement back to 21nm for N3.

Figure 1. Conventional scaling cliff.

BPR also enable novel architectures such as CFETs and back-side power distribution.

Figure 2. BPR technology.

The challenges with BPR are that you need a low resistance and reliable metal line that does not contaminate the Front End Of Line (FEOL). BPR is inserted early in the process flow and must stand up to all the heat of the device formation steps.

Figure 3. BPR process.

A lot of work on BPR has been done with Ruthenium (Ru) because it has low resistance for narrow lines and is very stable, but Ru is very expensive. This work looks at Tungsten (W) as an alternative. I ran some numbers on Ru versus W for cost and for the same film thickness I estimate Ru is approximately 40x the cost of W. There is a lot more experience with W and the cleans are well known so contamination shouldn’t be an issue. Ru has better line resistance for very narrow lines but W meets the target of 50ohms/µm with a CD around 32nm and an aspect ratio of around 6.

The process to integrate the W BPR starting once the trench is etched is:

  1. Deposit a 7nm silicon nitride (SiN) barrier to prevent metals migrating out of the trench.
  2. Deposit 4nm titanium nitride (TiN) liner.
  3. Deposit the W with 5nm of Atomic Layer deposition (ALD) and then fill with Chemical Vapor Deposition (CVD) plus silicon dioxide (SiO) CVD to form an oxidation barrier.
  4. Chemical Mechanical Planarization (CMP) of the SiO.
  5. Dry etch recess the SiO and W-TiN sidewalls to prevent shorting.
  6. Deposit a 7nm SiN plug barrier.
  7. SiN fill using a Floable CVD (FCVD) process + anneal and CMP.

Figure 4. Full integration.

Figure 4 shows BPR integrated with W metal 0 but Imec has also shown good results when M0 is Ru with a Ru via connecting to the buried W.

The electrical results from the process show no degradation in the device performance and good electromigration. BPR can provide a 20% scaling boost and the addition of a backside power distribution can provide another 30%. In summary the Imec work presents a promising alternative material for BPR with lower cost.

Also Read:

Key Semiconductor Conferences go Virtual

Effect of Design on Transistor Density

Cost Analysis of the Proposed TSMC US Fab


The 10 Worst Cybersecurity Strategies

The 10 Worst Cybersecurity Strategies
by Matthew Rosenquist on 07-26-2020 at 8:00 am

The 10 Worst Cybersecurity Strategies

Counting down to the absolutely worst cybersecurity strategies. Sadly, these are all prevalent in the industry. Many organizations have failed spectacularly simply because they chose to follow a long-term path that leads to disaster. You know who you are…

Let’s count them down.

10. Cyber-Insurance

No need for security, just get insurance. Transferring risk is better than mitigating it!

Famous Last Words: Sure, it should be covered

9. Audit Confidence

Conducing a comprehensive security audit. …and ignoring the results

Famous Last Words: We will close those gaps later…

8. Best Tools, Left Unmanaged

Deploying several good tools, set to autopilot. No need to manage or maintain anything

Famous Last Words: Security is not that difficult…

7. Regulatory Compliance

Meeting the minimum requirements (defined 2 years ago)

Famous Last Words: Relax, we are compliant!

6. One Good Tool

We just need one good tool (ex. AV) and we are set.

Famous Last Words: That should do it.

5. IT Dependence  

Cybersecurity is a tech problem, its IT’s responsibility.

Famous Last Words: The IT dept has it covered.

4. Security by Marketing  

Believing the snake-oil (deceptive marketing) salesperson that will ‘solve‘ your security problems

Famous Last Words: We are totally protected now! (or similar derivative from the sales brochure)

3. Default Security Settings

Products and services come with security built in!

Famous Last Words: It’s new, shiny, and looks secure. Don’t worry, we should be fine!

2. Security by Obscurity

Nobody knows or cares about us. We are too small to be targeted.

Famous Last Words: We haven’t been attacked yet…

1. Hope, as a Strategy

I hope we don’t get attacked. Let’s move on with more important things.

Famous Last Words: <meek inner voice>> Just don’t think about security because it is too scary, expensive, and complex!

This is the menu that evokes anger, frustration, and pity among cybersecurity professionals around the globe. Eventually it always ends in despair, blame, and a side of tears.

A solid long-term strategic plan is a necessity for an efficient and capable cybersecurity capability. Cybersecurity fails without a proper strategy.

Interested in more? Follow me on LinkedInMedium, and Twitter (@Matt_Rosenquist) to hear insights, rants, and what is going on in cybersecurity.

Matthew Rosenquist is an industry-recognized pragmatic, passionate, and innovative strategic security expert with 30 years of experience. He thrives in challenging cybersecurity environments and in the face of ever shifting threats. A leader in identifying opportunities, driving industry change, and building mature security organizations, Matthew delivers capabilities for sustainable security postures. He has experience in protecting billions of dollars of corporate assets, consulting across industry verticals, understanding current and emerging risks, communicating opportunities, forging internal cooperation and executive buy-in, and developing practical strategies.

Matthew is a trusted advisor, security expert, and evangelist for academia, businesses, and governments around the world. A public advocate for best-practices, and communicating the risks and opportunities emerging in cybersecurity. He delivers engaging keynotes, speeches, interviews, and consulting sessions at conferences and to audiences around the globe. He has attracted a large social following of security peers, is an active member on advisory boards, and quoted in news, magazines, and books. Matthew is a recognized industry expert, speaker, and leader who enjoys the pursuit of achieving optimal cybersecurity.


Cars and COVID-19 Uncertainty

Cars and COVID-19 Uncertainty
by Roger C. Lanctot on 07-26-2020 at 6:00 am

Cars and COVID 19 Uncertainty

A funny thing happens when you let car makers make cars and car dealers sell cars – people start buying cars. With the U.S. economy at least partially re-opening nationwide car buyers have returned to the market and, finding a limited supply of new cars and disappointing incentives, have turned, in part, to used cars. This remarkable outcome stands in stark contrast to the demise of cars messaging arising from transportation visionaries and surveys of remote workers.

Welcome to the world of COVID-19 uncertainty. In this world, all potential current and future realities are true simultaneously. It’s a big reason why a V-shaped recovery may be out of reach for the United States as economists, investors, car dealers, and car buyers have been left scratching their heads as stimulus measures wane and unemployment continues to climb. What will happen to vehicle demand?

In the midst of the uncertainty, visionaries have tried to grasp at wisps of good news wafting on the winds of change. There are multiple threads for the hopeful to pull. The two most prominent are A) The end of cars (in cities)!; and B) U.S. workers want to stop commuting and work from home!

The New York Times drove the “end of cars” narrative with a special section two weeks ago painting a picture of cityscapes ruled by pedestrians with lanes for cars narrowed or eliminated and on-street parking banished in favor of two-wheeled transportation and public transit.

The New York Times; “The End of Cars”

Morning Consult, meanwhile, published a survey purporting to show that one third of remote workers will not return to the office until a COVID-19 vaccine is made available – in the context of an overwhelmingly positive assessment of and preference for remote working. The “obvious” conclusion of journalist responses to the survey being that the shift to remote working will have a dramatic downward impact on commuting.

Morning Consult: “How the Pandemci Has Altered Expectations of Remote Work”

These two narratives combine to paint a picture of fewer cars, less traffic, fewer highway fatalities and clearer skies. Not surprisingly, reality is something quite different – both the reality we are living and the reality we can anticipate – even with a large dollop of uncertainty.

The car-free city is about as likely as the paperless bathroom. Cars are broadly being discouraged and de-prioritized in many European cities, but the dependence on individual vehicles for mobility is likely to endure indefinitely. It is possible that self-driving cars will emerge during the next five to 10 years, but forbidding the use of cars in cities is unlikely. Sanctioning and limiting, yes, but complete removal, no. In fact, cities are increasingly collaborating with ride hailing operators to fill in gaps created by public transit cutbacks – and car sharing services are thriving.

As for remote working, the early returns suggest that productivity is up along with overall employee well-being – though not without exceptions. But the calls to return to the office are already going out – vaccine or no. Workers hesitant to return out of health concerns will likely face hard choices, not unlike those faced by workers in meat processing facilities, health care, and automotive plants: Get back to work or stay home…permanently and unemployed.

The underlying problem is the COVID-19 Uncertainty Principle – which applies with particular force to the ever-so-essential automotive industry. It is best embodied in the analysis of rising used vehicle values – as noted by used car auction operator Manheim.

The Automotive News reports spiking used car prices and plunging used car inventory as car buyers have flooded back into the market. While some of the demand is attributable to limited new car inventory and incentives – the rise in interest in used cars reflects buyers with a need for transportation – in other words, not those making a discretionary purchase.

Automotive News: “Tough Time for Dealers Seeking Inventory as Wholesale Values Soar”

What’s happening? Is there an enduring trend here?

Dealers and wholesalers tell the Automotive News that the slide in used car prices and jump in inventory that occurred in April has been completely reversed as the economy has re-opened. But some counseled caution. Asbury Automotive Group’s CEO said his organization didn’t sell into the fire sale pricing in April and refuses to overpay in July.

Trying to make sense of market trends is a challenge for all. Multiple indicators are pointing toward increased vehicle demand including people moving out of cities and public transit operations shedding passengers. Remote workers may not be commuting, but there’s a good chance that the old commute was on public transit – remote workers may find they need to add a car or two.

COVID-19 may have temporarily emptied cities revealing a deserted transportation landscape suitable to be reconceived in favor of two wheel and two leg options – but it makes no difference if the tax base has moved to the suburbs. Trees may be favored over traffic lights, but the real world will continue to lean toward four wheels. Sadly, the funds for reconceiving transportation infrastructure on a massive scale simply don’t exist – especially after the devastation of the coronavirus.

What is vastly underestimated by the visionaries anticipating a car-less wonderland is the mounting wanderlust building among cooped up consumers and workers. We’ve seen the ill-advised gatherings at beaches and parks and bars and restaurants. People are dying to get out (no pun intended) and nothing is associated more intensely with escape than the personally owned car.

In fact, the organizations most committed to eliminating personal car ownership and use – ride hailing operators like Uber, Lyft, and Yandex – are struggling to restore revenue and operations to pre-COVID-19 levels. Here, too, consumers may be opting for personally owned transportation over a shared transit solution.

It seems clear that predictions regarding the demise of the automotive industry will once again prove premature. The industry is changing – for sure. Internal combustion vehicles will be replaced by electric vehicles. Human driven vehicles may some day be entirely replaced by robot drivers. Owned cars may be replaced by shared cars. But, in the end, there will be cars. Get used to them. And get used to uncertainty for the foreseeable future.


How yieldHUB Helps Bring a New Product to Market

How yieldHUB Helps Bring a New Product to Market
by Mike Gianfagna on 07-24-2020 at 10:00 am

Screen Shot 2020 07 14 at 4.01.42 PM

 

Collecting and analyzing semiconductor test data is a subject that holds a special place for me. Developing a factory data collection and analysis system was my first job out of school. The company was RCA, and the factories were in Findlay, Ohio (analog/mixed signal) and West Palm Beach, Florida (digital). There was a pilot manufacturing line in Somerville, New Jersey as well. The chips built by these fabs were used, among other things, to build RCA television sets in Bloomington, Indiana.

The world has changed a lot in a seemingly short period of time.  The work going on back then at RCA is no longer done in this country for the most part. The data analysis system I worked on was based on IBM mainframe technology, dedicated communication lines for data access and batch processing for results. A lot has changed here as well. Recently, Dan Nenni published an interview with John O’Donnel, the CEO of yieldHUB. The company offers a contemporary, cloud-based technology to gather real-time data from semiconductor manufacturing and test, validate and clean the data and then provide actionable insights into the devices being tracked. I only dreamed about this kind of capability at RCA.

The yieldHUB platform offers several use models, including NPI, Production, Advanced Production and Custom. I’d like to focus in this post on NPI, or new product introduction. This is the process of bringing up a new design in the target system with the goal of validating its readiness to move to volume manufacturing, the stage where everyone starts making money.

There are many capabilities offered in the NPI use model from yieldHUB.  Here is a list of them:

Bin analysis

Bin galleries, stacking of wafer maps, trends

Calculated Tests/Multivariate analysis

Create tests from other tests, e.g., test1/test2 or test1 with different set of limits. Done virtually in the database

Characterization

Fully understand the variations in behavior of your new silicon due to changes in material or test conditions

Gage R&R

Make your program insensitive to setup with a highly visual gage R&R tool

Indexed correlation/drift analysis

Population drift analysis and per die drift analysis across wafer sort or packaged test strips

Parametric analysis

Analyze parameters and tests in detail, including and applying filters

Sensitivity analysis

Which tests are most sensitive to a change in test program? Might reveal something unexpected

Test time analysis

Do you store test time in your data logs?

Virtual Re-rest

Tweak test limits in simulation mode and investigate the effect on yield

The Gage R&R item may not familiar to some readers.  Here is a description of it from the yieldHUB website:

Gage R&R has been used for many years in the semiconductor industry to measure variation during test for repeatability and reproducibility. These measurements are then used to assess the suitability of the test for production. But often the focus is on qualifying tests on one site, only leaving issues for production when multi-site testing is used.

The write-up goes on to show an example of a parameter where the site 2 measurements are different from the other sites and give many false fails. This example would fail Gage R&R.

yieldHub also did a webinar to provide more detail on how to perform new product introduction.  In 25 minutes, this webinar covered a lot of ground. It is presented by John O’Donnel, Founder and CEO and Kevin Robinson, Director of Customer Success. After a short overview of yieldHUB, the details of NPI are discussed. The primary goals of NPI are stated as:

  • Fastest time to market
  • Tightest specs
  • Highest yield

This sums it up quite well. Characterization is a key part of NPI and the webinar’s definition of this step is worth repeating:

“The goal of characterization is to make sure that the variation in parametric behavior due to allowed changes in material or test conditions is understood early.”