SemiWiki – Page 568 – The Open Forum for Semiconductor Professionals

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

February 6, 2017June 14, 2019

CTO Interview: Peter Theunis of Methodics

CTO Interview: Peter Theunis of Methodics
by Daniel Nenni on 02-06-2017 at 7:00 am
Categories: EDA, Perforce

Fascinated by computers at a very young age, Peter got his degree in Computer Science and was brought to the Bay Area via AIESEC Berkeley’s student exchange program to write his thesis. He has now more than 15 years of professional experience in software engineering, large scale systems architecture and data center engineering in Silicon Valley startups as well as with Yahoo! where he spent the last 9 years as a systems architect and principal engineer.

So how does a systems architect at Yahoo! find his way to an EDA IP lifecycle management company like Methodics?
After spending many years looking at system level issues across multiple industries, I realized that the semiconductor industry is on the verge of experiencing many of the challenges that I have seen before. Today’s SoC’s are in fact very complex systems with many of the challenges that other “systems” oriented industries have faced. Semiconductor companies need similar solutions as other industries to allow the complexity of a modern SoC to scale to the tools and methodologies that semiconductor design teams have at hand, but make the overall process much more efficient. Methodics had an excellent foundation to build solutions for the future of Semiconductor design that will scale with the challenges that they will face around complexity.

What type of solutions do you need to provide to design teams to allow them to realize these efficiencies?
As with any other complex system, it has always been a divide and conquer approach. As SoC’s became common place, many companies started to focus on “reuse”. The main goal was allowing portions of previous designs to be reused to reduce the amount of design effort needed in new designs. As reuse in design teams became commonplace, the need to reuse designs outside of the immediate team, as well as acquire pieces of the design from partners or third parties lead to the notion of IP and IP management. As SoC’s grew larger and more complex, the amount of data and metadata associated with IP’s grew astronomically, and better technology was needed to manage the lifecycle of IP and more complex digital asset management systems were needed.

I am familiar with IP within the SoC design process, but digital asset management is a new term, can you elaborate?
Digital assets are the natural progression to IP lifecycle management. Original design reuse strategies started just with design data. As methodologies formalized around design reuse, you began to see IP methodologies evolve with the formalization of techniques and methods at making designs reusable. Soon, verification IP was added to these flows and now you had to also map verification and design IP together, leading to a growth in information that needed to be managed as you added the meta data associated with these types of IP. Eventually design scripts were added to the mix, timing constraint files, DFT information, as well as other design artifacts leading to another explosion in data that needs to be managed. With this complexity, the relationships between all these different pieces of data also need to be managed, and now you quickly begin to lose the traditional notion of IP. Today, with requirements systems producing myriads of requirements for systems, issue and defect systems tracking all aspects of design, and the need to trace information throughout the entire process, there is much more that just traditional IP that needs to be managed. There’s a whole range of digital assets that need to be managed.

How is Methodics helping with digital asset management?
Methodics’ most recent solution provides a true digital asset management platform. It all starts with effective design data management. It has always been Methodics’ strategy to work with industry standards when they are available. For design data management, we build on Perforce which has been providing leading enterprise data management solutions to multiple industries for years. Then the platform allows the integration of other engineering systems to provide communication across all solutions and the design teams where none has been available. Given that there are many engineering systems in use for issue and defect tracking, requirements tracking and other management tasks, the Methodics platform allows the integration of systems like Jira and Bugzilla for issue and defect and Jama for requirements management, allowing it to work seamlessly in existing engineering environments. The goal of the platform is to link all design data, IP data and metadata, design artifacts, requirements and issue and defect data together into a cohesive information system, that allows designers to not only to search for and find IP, but also to find all possible data associated with that IP and how it is connected through the various engineering systems. Engineering teams can now be more productive by quickly searching for and finding IP, quickly being informed of issues with the IP being used and when to expect resolution to those issues, and the ability to track quality and grade IP being used. In addition, management can quickly compile reports of where IP is being used, outstanding issues with that IP, traceability of requirements and other pertinent design data. The platform provides efficiency in design by streamlining the management and communication of data from multiple disparate systems, and can scale with increasing complexity by tracking the convoluted web of interconnected information throughout designs and organizations.

What is unique to the Methodics technology that makes it able to provide solutions?
We recently re-architected our underlying object store to support a graph database. We made this decision because of the highly complex and hierarchical nature of having to manage IP and digital assets. Graph databases allow the storing of direct relationships of data, allowing it to be quickly retrieved, often with a single operation. Compare this to traditional relational databases where links between data are stored in the data itself. In order to retrieve complex hierarchical and interrelated data, you would need to make multiple expensive calls to extract the required information. Our graph database has made possible greater than 10x performance improvements in just handling hierarchical IP in SoC designs. It has also allowed us to create the digital asset management platform linking in other engineering systems that would not have been possible with a traditional relational database.

It seems that Methodics is investing in improving the efficiency of finding IP and critical information for SoC design, but designers still have to manage huge amounts of data itself in their workspaces. How is Methodics helping there?
You are correct. We are seeing user workspaces routinely exceed 10’s of GB, sometimes 100’s of GB. Regression runs, characterization runs, design and debug workspaces all put a great stress on Network Attached Storage (NAS), create NFS bottlenecks and cause significant project delays. This situation is only getting worse. Last year we introduced WarpStor, a Content Aware NAS optimizer and accelerator. It excels at dramatically reducing user workspace storage requirements and creation time. With WarpStor, our customers can see up to 90%+ reduction in storage requirements and corresponding reduction in network I/O for user workspaces, regression runs, characterization runs, and the like. Creation time for multiple large workspaces is also reduced from hours to seconds. We have been using this technology internally for sometime and now our customers are realizing these same results. We now have many reference customers for this technology that are willing to speak with companies that are interested in this technology.

Where do you see Methodics research and development efforts going from here?
Since the complexity of SoC’s are only going to increase, we will continue to leverage our knowledge of solving systems challenges and adapting that for the semiconductor industry. There is a wealth of knowledge and methodology that can be adapted to the semiconductor industry and we will continue to do that. Likewise, the work we are doing around IP and digital asset management as well as workspace management can help other industries, so we will continue to synthesize across industries to bring solutions to those other industries as well. Stay tuned….

www.methodics.com

February 5, 2017June 14, 2019

SPICE Model Generation using Machine Learning

SPICE Model Generation using Machine Learning
by Daniel Payne on 02-05-2017 at 10:00 pm
Categories: EDA, Platform Design Automation

AI and machine learning are two popular buzz words in the high-tech daily news, so you should be getting used to hearing about them by now. What I hadn’t realized was that EDA companies are starting to use machine learning techniques, and specifically targeted at the daunting and compute intensive task of creating SPICE models that account for variability. I turned to my source at Platform DA in order to discover more about these new machine learning approaches that they are using to create SPICE models.

Statistical Variation of IC Processes
It’s no secret in our semiconductor industry that the spread in SPICE process corners like FF and SS is becoming larger as the node size gets smaller. Just look at the following chart which shows how normalized delays are changing when moving from 65nm (red line) to 40nm (blue line):

So where does all of this process variation come from? The sources of local random variability are numerous:

Random Dopant Fluctuation (RDF)
Line Edge Roughness (LER)

Another way to think about process variation is to know that we’re dealing with the intrinsic statistical physics of nature in our semiconductor materials.

In addition there are global statistical variation sources for a process node:

Die to die
Wafer to wafer
Lot to lot
Fab to fab

The IC manufacturing process is a complex set of steps that involve Temperatures, times, pressures, cleanliness and gas compositions. All of this in turn effects transistor characteristics like Vth, Tox, IDon, IDoff, etc. The accumulation of device parameter variability can be plotted as a set of distribution curves:

We can even look at variability by category, and notice the trends when moving from 65nm down to 28nm:

Using statistical corners for modeling is a conservative approach. Here’s an actual flow that accounts for variability when creating SPICE models:

One drawback that you quickly discover with this approach is that the results (blue dots) don’t correlate well with process corners (red):

A second drawback is that the results (blue dots) don’t correlate well with the design corners (red) either:

Any automatically generated SPICE models based on this first approach would require fixing to agree with measured results. What we really require is a fast statistical model generation along with a fast statistical model adjustment without changing our corners.

The traditional method in SPICE to work with variations is to use lots of Monte-Carlo simulations, however running Monte-Carlo takes too much time, so what we really want are faster Monte-Carlo simulations along with faster statistical optimizations.

Machine learning can be applied to this optimization approach because:

Current statistical models are based on corner specs
Some specs especially the design specs are highly nonlinear

Here’s a flow for how optimization is accomplished using cascaded machine learning:

Related blog – Are your transistor models good enough?

The extraction results (blue dots) from this cascaded machine-learning algorithm match the corners quite well (red):

Automatic model generation has a modeling flow for advanced statistical analysis of four steps:

[LIST=1]

Origin data

Corner model

Mismatch model

Statistical model

The key techniques to make these four steps happen efficiently are fast Monte-Carlo, a projection based method, cascaded machine-learning, and intelligent optimization. Take a look at how good the mismatch modeling is with this approach (red versus blue lines):

Look at how tight the data points are inside of each elliptical region for the fast generation and characterization of an 11-corner model:

Related blog – Is that PDK safe to use yet?

What does all of this wonderful technology mean to an IC designer? Well, an IC designer can now perform statistical analysis to identify issues, and they can fix design correlation without changing corner specs as shown below:

I hope that you learned something new today about automatic SPICE model generation, because the approach from Platform DA in their MeQLab tool looks very promising.

February 4, 2017

AMD vs Intel Update!

AMD vs Intel Update!
by Daniel Nenni on 02-04-2017 at 10:00 am
Categories: Foundries, Intel Foundry

Is it just me or has AMD just pulled off one of the most amazing semiconductor comebacks of the century? Let’s take a closer look.

Who doesn’t long for the days when Intel and AMD went head to head in the battle for microprocessor supremacy? Back then Intel, was still operating under the Andrew Grove mantra of “Only the Paranoid Survive” and ultimately pounded AMD into submission. The battle officially started when IBM required a second source for the IBM PC x86 chips Intel is now famous for.

Like Intel, the AMD founders also came from Fairchild and started AMD as a semiconductor second sourcing business for a variety of chips. It really was an epic semiconductor battle with Intel and AMD leap frogging down Moore’s Law. In fact, I remember buying motherboards with an AMD 40Mhz processor versus an Intel 36Mhz chip just to keep the second source dream alive.

Unfortunately, the Intel vs AMD battle officially came to an end in 2009 when AMD repeatedly failed to leap frog Intel and was forced to divest manufacturing giving birth to US based GlobalFoundries. Over the last 8 years fabless AMD has been very hard to watch with failure after failure at many different levels. But now all of that has changed with new management and the amazing Zen architecture. Or has it?

Zen was designed from the ground up by famed SoC architect Jim Keller. This was Jim’s second stint at AMD following his work at Apple that produced the first A4 and A5 SoCs for the iPhone and iPad launches. Jim returned to AMD in 2012 and left after Zen was taped out in 2015. Jim Keller and his core team now work for Tesla.

The first question you should be asking is: Why is Zen being released in 2017 when it taped out in 2015? Maybe the same reason why Jim Keller no longer works at AMD? How many spins can you do on a chip that size in two years? Two to three depending on how many masks were changed?

Fast forward to the most recent AMD investor call, where a ship date for Zen was finally announced causing AMD stock to jump once again. At the beginning of 2016 AMD traded for under $2 and is now trading for more than $12. Talk about an amazing comeback, absolutely.

Some semiconductor insiders however are calling it “AMD Delusional Disorder”. These delusions may seem believable at face value, and investors may appear normal as long as an outsider does not touch upon one of their delusional themes. Read the comments on articles critical of AMD for a more detailed description.

A recent delusional example is the Zen release strategy announced on the call that caused the stock to again rise:

“We’ll start by shipping Zen to boutique PC manufacturers and the channels that support Do-It-Yourself types.” In other words the “NOT INTEL” market.

The non delusional version is, “We could not get Zen into a major PC manufacturer such as HP, Dell, Acer, or Lenovo…”

On the manufacturing side, AMD has 14nm wafer agreements with Samsung and GlobalFoundries so there are no Zen capacity issues unless the chip is not yielding or it requires yet another spin.

The other interesting thing to note is that Intel does not seem to be paranoid of Zen at all. We will know more after the February 9[SUP]th[/SUP] analyst meeting but it seems that Intel will not accelerate their 10nm release schedule to compete with Zen nor did they mention potential margin erosion from a price war that AMD would lose.

Another problem for Zen is that Intel 14nm (13.4nm) was developed for and ramped by Intel CPU chips. Samsung 14nm (16.6nm) however was not developed for or ramped by Zen. Intel 14nm is also in its second generation with better design constraints resulting in a double digit performance increase and a cost reduction. GF 14nm however is first generation. Intel is also very close to their major customers (HP, Dell, Acer, Lenovo, etc….) and know what they are forecasting, Intel is probably not as close to “boutique PC manufacturers and the channels that support Do-It-Yourself types”.

On the bright side, GF 7nm is probably being developed with Zen in mind and will be one of the first chips to ramp. From what we know today GF 7nm (8.2nm) will arrive in 2019 while Intel 7nm (6.7nm) is expected in 2020. In the mean time however, GF 14nm Zen chips will be competing with Intel 10nm (9.5nm) chips starting in 2018.

Bottom line: AMD has zero chance of profitability before 7nm and at some point in time Wall Street will have to face financial facts and AMD stock will be back to single digits, my opinion.

February 3, 2017

Open-Silicon Update: 125M ASICs shipped!

Open-Silicon Update: 125M ASICs shipped!
by Daniel Nenni on 02-03-2017 at 12:00 pm
Categories: IoT, Open-Silicon, Semiconductor Services

As you all know I am a big fan of the ASIC business model. It was critical in the transformation of the fabless semiconductor industry and still plays a critical part in our success. In fact, the ASIC business model is leading the way for systems companies to make their own chips. Remember, Apple started with the ASIC business model through Samsung for their first iPhone SoCs that transformed the world, absolutely.

In 2015 Open-Silicon celebrated the shipment of their 100M ASIC and now less than two years later they are over 125M spread amongst 300+ designs. More importantly, their defective parts per million average (DPPM) is 30, resulting in very low RMAs. 30 DPPM is an excellent number for the ASIC business by the way. The DPPM ASIC numbers I have heard in the past were much higher.

“Our low RMA return is evidence of our excellence in design engineering. We prideourselves in reducing risk, lowering cost and delivering first-time working siliconthat is ready for volume production.” Asim Salim, Open-Silicon’s Vice President of Manufacturing Operations.

If you look at the Open Silicon website you will see a wide range of business models. Customers can engage with a design level specification, RTL, netlist, GDS2, production or design only. This reminds me of the start of the fabless business model where designs where sketched out on white boards or even cocktail napkins and taken from idea to chip by ASIC legends LSI Logic and VLSI Technology. Again, a systems company or an emerging IC company can get ideas transformed into proof of concept prototypes or even production quality silicon with reduced risk and minimal upfront cost.

The other part of the Open Silicon website you should see is the IoT ASIC page. My trusted sources say that by the year 2020 there will be more than 20B industrial/commercial internet connected devices installed. If you have an idea for one of these devices this is the page you want to spend time on, absolutely.

Open-Silicon also has an IP Page that talks about their High Bandwidth Memory IP, Hybrid Memory, Cube ASIC & FPGA Controller IP, Interlaken Controller IP, and Partner IP. Silicon proven commercial IP not only reduces design risk, it dramatically shortens design time so you definitely need to spend some time on this page as well, no matter what chip idea you have.

The other page you should spend time on is the Open-Silicon landing pageon SemiWiki. We have been working with Open-Silicon since the beginning of last year and have 12 blogs by 4 different bloggers/perspectives starting with A Brief History of Open Silicon.

Open-Silicon transforms ideas into system-optimized ASIC solutions within the time-to-market parameters desired by customers. The company enhances the value of customers’ products by innovating at every stage of design – architecture, logic, physical, system, software and IP – and then continues to partner to deliver fully tested silicon and platforms. Open-Silicon applies an open business model that enables the company to uniquely choose best-in-industry IP, design methodologies, tools, software, packaging, manufacturing and test capabilities. The company has partnered with over 150 companies ranging from large semiconductor and systems manufacturers to high-profile start-ups, and has successfully completed over 300 designs and shipped over 125 million ASICs to date. Privately held, Open-Silicon employs over 250 people in Silicon Valley and around the world. www.open-silicon.com

February 3, 2017July 18, 2025

Verifying Design for In-Car Networks

Verifying Design for In-Car Networks
by Bernard Murphy on 02-03-2017 at 7:00 am
Categories: Automotive, EDA, Synopsys

Once upon a time the role of electricity in a car was pretty modest: spark plugs, alternator, lighting, some simple instrumentation and maybe heating, all supported by an equally simple wiring harness (my wife has a 1962 Morris Minor, so I know exactly what the whole wiring harness looks like). How times have changed. Now most or all drivetrain systems are controlled by wire rather than mechanical linkages, driver assistance and safety is supported through proximity detectors and AI analysis of radar, infrared and light images, the cabin has sophisticated entertainment options, navigation and other features supported by voice control. There’s no obvious end to what could be added.

Obviously, this can’t be supported with a simple wiring harness. You might assume the logical solution would be to hook it all up through some form of Ethernet with bridges to actuators and sensors where needed, but you would be wrong. Or rather you would only be partly right. Cars present a much more hostile (electromagnetic interference, temperature, and vibration) environment for electronics than you would find in a home or office environment. And an acceptable level of safety in some systems is much less tolerant to latencies in the network than for other systems. Then there’s cost – do you need an Ethernet connection to control a side mirror?

The picture is further complicated by needs for autonomous and semi-autonomous control, requiring real-time response to video, audio and data from camera, wireless and sensor interfaces. Overall there is quite a wide spectrum of communication options, some held to very high safety standards and reliability expectations given high recall costs and much longer in-service lifetimes.

Let’s start with protocols for “standard” needs. These include:

LIN (local interconnected network) – low cost, single wire, 40kb/s, used primarily for mirrors, door locks, power seats, wiper controls, climate control and similar functions). Very simple master/slave protocol, one slave responds to each message, so no arbitration or collision detection required.
CAN (controller area network) – middling cost, 2 wire (twisted pair), 1MB/s, used primarily for powertrain (engine timing, transmission, ABS). Protocol more like a standard bus bit multiple message types, arbitration, etc. There can be multiple CAN networks in a car.
FlexRay – higher cost, 2 or 4 wire (twisted pair, single or dual channel), 10Mb/s, high performance powertrain and safety applications (drive-by-wire, active suspension, adaptive cruise control). Protocol offers support for static and dynamic frames with a preset communication cycle allowing an option for deterministic data arrival where needed or CAN-like dynamic event-driven delivery.
Ethernet (no explanation needed) – this has been primarily for diagnostics
MOST (media-oriented systems transport) – widely used for multimedia today, time-sensitive traffic support, but a protocol and architecture specialized to automotive applications. There is enthusiasm in the industry to eventually replace this (and perhaps other standards listed here) with Ethernet-based approaches.

Then we have protocols for autonomous/semi-autonomous needs:

Ethernet-AVB (audio/video bridging) – a competing standard to MOST, also used for multimedia. Builds on the Ethernet standard to offer time-sensitive behavior where privileged data can be prioritized over non-privileged data. Important in e.g. cabin surround-sound where differing latencies to different speakers due to best effort behavior of the network may compromise listener experience.
Time Sensitive Networking (TSN) – AVB extended to AVB TSN for application to control systems. TSN is used across the systems of an autonomous car for transmission of data ranging from ADAS and control traffic to infotainment and internet, ensuring precise, synchronized, deterministic and timely delivery of data with minimum latency.
MIPI – there are several relevant sub-sections:
- CSI-2 – In a typical mobile application, an application processor uses MIPI CSI-2 to provide high bandwidth, low-power, and low cost interfaces to cameras. The same architecture carries over into the automotive world for intelligent rear-view mirrors and radars for parking assist, wing mirrors, cameras for gathering information about objects around the car, and even surround-view systems.
- DSI – MIPI DSI is aimed at reducing the cost of display controllers and commonly used for dash, infotainment, and any other display in the car. The DSI specification defines a high-speed serial interface between a peripheral, such as an active-matrix display module, and a host processor.
- I3C – The need for a faster, lower power, scalable sensor connectivity with efficient architecture is essential for an autonomous car with myriad of sensors. The MIPI I3C standard has become the ideal solution for today’s sensor interface requirements due to its faster speeds of 12.5Mhz and fewer pin counts as compared to other existing solutions like I2C and SPI. Sensors for accelerometer, proximity, touch screen, compass, and more are used in advanced driver assistance systems (ADAS) and in-vehicle infotainment (IVI) applications, creating more opportunity to deploy the technological advantages of I3C in automobiles.

Synopsys has verification IP (VIP) for all traditional protocols used in vehicles (Ethernet/LIN/CAN/FlexRay), except for MOST. On top of this they have added Ethernet AVB/TSN and MIPI protocols for autonomous/semi-autonomous support. All of these are available in SystemVerilog/UVM.

Why not support MOST? I couldn’t get a response on this from Synopsys, but Googling around I couldn’t find any other VIP (or IP) vendor, even the small ones, providing MOST support either. I guess the design/verification eco-system doesn’t have a lot of confidence in the future of MOST or, perhaps more important, aren’t getting signals from the automotive industry that MOST is a good area to invest.

One of the nice things about protocol verification in the Synopsys suite is protocol-aware debug in Verdi. Some of us get a chance to become proficient in certain protocols but most of us have too many bases to cover to be experts at everything, so we need a little help. This is especially true in protocol debug where root-cause analysis of misbehavior and bottlenecks needs more than basic waveform analysis. Each of these automotive VIPs supports protocol-aware debug in Verdi.

Automotive VIPs come with a configurable test-suite and test plan so you don’t have to build the protocol tests from scratch; this include the test plan for complex sequences which can be quite difficult to derive from the specification.

This is complex stuff. Each standard supports many options – different network topologies, different frame-types, different modes, different rates. Building a comprehensive test-suite for each protocol can be challenging. Naturally the demands of this domain leave no room for error so you are quite likely to complement testing based on the Synopsys VIPs with your own testing. A very understandable strategy, starting with a strong out-of-the-box verification using Synopsys VIPs. You can see the Synopsys press release HERE and get more detail on the automotive VIPs HERE.

On-Chip Power Distribution Networks Get Help from Magwel’s RNi

On-Chip Power Distribution Networks Get Help from Magwel’s RNi
by Tom Simon on 02-02-2017 at 12:00 pm
Categories: EDA, Magwel

Counting squares is a useful tool for calculating simple resistance in wires, but falls short in reality when wires deviate from ideal. Frequently the use of RC extraction tools for determining resistance in signal lines in digital designs can be effective and straightforward. However, there are classes of nets in designs that confound extraction tools. Good examples of these are found in power distribution networks. Also, nets found in memory designs are excellent candidates for deeper analysis.

At one end of the spectrum of solutions we find full wave solvers. While they are the most accurate method for analysis of electrical properties in all kinds of metal structures, they are troublesome to apply to complex on chip metal structures. Full wave solvers are difficult to set up, run slowly and output S-parameters, which are vexing to use for subsequent interpretation. Consequently, use of full wave solvers is often limited to analysis of on-chip inductors and capacitors.

The output of RC extractors fall short when complex nets are involved. A typical power or ground net may have thousands or more end points. What matters to the design is the actual resistance at each of these end points. To further complicate solving this problem these nets are often highly interconnected to themselves. The best example of this is a mesh style power or ground net. There are many parallel current paths in these nets, which can greatly complicate the effective resistance between any two points on the network.

Fortunately for designers who need to tune and optimize endpoint resistances in large complex nets, such as power distribution networks, there is an easy to use solution available from Magwel. Their Resistance Network Integrity (RNi) tool provides an intuitive and easy to use approach that provides comprehensive analysis and an interactive interface for finding high resistance segments and endpoints.

Magwel’s RNi uses solver technology that can handle complex interconnect without the difficult set up typically required for other solvers. RNi reads in the layout in GDS and allows the user to select a pad or create a contact point to use as a reference point for the resistance calculation. The RNi technology file comes from information found in foundry supplied ITF files. Once the solver is started, results are available quickly.

The solver extracts the entire net, including vias and metal on all layers. Another benefit is that no stimulus is needed and the design does not have to be LVS clean. It is extremely valuable to be able to plan power distribution networks as early as possible in the design cycle.

RNi calculates the total resistance to all points on the selected net from the contact point or pad that was set at the beginning of the run. It’s easiest to view the results in the tool’s field view. This is a graphical view that uses color to visualize the resistance values. Also, moving the mouse over any point in the net will display the resistance value to that point as a number. Of course, in a large chip, finding a high resistance point can be like finding a needle in a haystack. RNi will quickly list the top values and allows the user to zoom in on the view each of them with a single click on the mouse.

RNi is a natural addition to Magwel’s product line up. Accurate resistance extraction is an absolute necessity for ESD induced voltage drop during discharge events. Magwel is applying its solver based resistance extraction to this problem in its ESDi product. The same technology comes into play during power device gate, source and drain network simulation and analysis in their PTM product family. For more information on Magwel and their solutions for improving design efficiency, reducing power, and increasing reliability, refer to their website here.

February 2, 2017January 2, 2024

An Easy Path to Bluetooth 5-enabled SoC Design

An Easy Path to Bluetooth 5-enabled SoC Design
by Bernard Murphy on 02-02-2017 at 7:00 am
Categories: Ceva, IoT, IP, Mobile

Bluetooth (BT) was never a bit-player in communication but what surprised me is that is already dominating the market, at least as measured by radios sold, and is likely to extend that lead over the next 5 years. Particularly impressive is that BT already leads cellular and WiFi. This strength is certainly influenced by sales into IoT applications but also by what CEVA labels as IoD (internet of digital, that is non-IoT) devices where BT already plays an important role.

You can see where this strength is coming from in a forward-looking survey of applications. By 2021, smartphone applications will still contribute the largest component of volume, but after that, even when you drop PC-related categories there are applications for automotive, home automation, residential lighting, robotics, healthcare and many more. None of taken individually will be a major component of total volume, but there are so many active and growing applications that together they could amount to 50% of total volume.

Let’s start with a little terminology. The BT5 spec (in fact BT specs since 4.0) covers BT classic and BT low-energy (BLE). You can operate in pure classic mode, pure BLE mode or dual-mode. Classic is what made earpieces, speakers, wireless mice and other options so popular. BLE is a big part of what made BT a serious player in IoT. Dual-mode offers access to both options and is now common in smartphones, Bluetooth headsets/earbuds and speakers. An interesting point that initially confused me is that many of the features are optional per the standard, leading to potential confusion about what makes up BT5. In what follows, I will use the term to mean the full spec with all options.

The appeal of BT and the reason for this growth is in part that it offers low infrastructure cost because it can leverage existing hubs like smartphones, laptops, tablets and digital TVs (particularly where dual mode is supported in those hubs). It is low power (under 10mW at peak, down to uW in standby) and it offers robust and secure communication through frequency-hopping and built-in security/privacy features. BT5 builds on these existing strengths through even longer range (up to 1km line of sight), lower power and improved frequency-hopping through a more pseudo-random approach, supporting more devices communicating at the same time in a denser environment.

CEVA (Franz Dugand, Director connectivity BU) jointly presented with CSEM (Nicholas Raemy, head analog/RF design) in a webinar last week their joint solution for easy BT5 integration for BLE use-models. CEVA in their RivieraWaves product line-up provides the baseband controller and software. They also provide modem and RF blocks optimized for dual-mode use. The CSEM package adds modem and RF components optimized to BLE use. In either approach you can adopt the whole solution as a turnkey package or mix and match with your own or other IPs of your choice.

But if you do mix and match, CEVA advise you check specs carefully. Since many of the features are optional, an IP vendor can legitimately claim compliance with the standard without supporting all features. Naturally the solution offered here supports all features, including the optional ones, including among these all performance options and co-existence with 802.15.4 (ZigBee/Thread) and Wi-Fi.

The RivieraWaves baseband IP supports Bluetooth Low Energy, Bluetooth Classic and Bluetooth dual-mode and includes AES 128-bit encryption. Riviera Waves BT has a pretty impressive pedigree, licensing since 2000 and including Renesas, NXP, Spreadtrum and Atmel as customers, with 70+ design wins in PC, mobile, medical, automotive wearable and other applications.

The CSEM icyTRX IP offers a BLE solution for the modem and RF sections. This claims lowest power consumption in the market and a tiny form-factor, available in 65 or 55nm processes from several foundries. It is designed for a very simple interface with the CEVA baseband IP (9 signals) and can operate in low energy (1/2 Mbps) and long-range (500/125kbps) modes. CEVA and CSEM already have 6 customers for the joint solution.

Several general questions on the standard came up. I found the answers educational so I’ll add them here. One was on target applications for 2Mbps. Franz said that a big application will be firmware update over air, another would be for audio, e.g. for hearing aids. He also made an interesting comment on mesh support, noting that this is not directly part of the BT5 spec and can be done with existing chipsets. Smart mesh support is yet to be finalized in the standard and should be more efficient and provide better power management.

Applications for long-range support are particularly around home-automation, including long-range lighting, window/door control, temperature sensors and should be able to cover the outside area also, e.g. for watering controls. One other question was on whether smartphone vendors are offering BT5 yet. Franz said that those vendors are likely to be followers rather than leaders in this space since they will look for ecosystem support (which is one reason why dual-mode support continues to be an valuable option). He thought we may start to see smartphone options by the end of the year.

You can watch the Webinar HERE.

February 1, 2017July 18, 2025

SPIE Advanced Lithography and Synopsys!

SPIE Advanced Lithography and Synopsys!
by Daniel Nenni on 02-01-2017 at 7:00 am
Categories: EDA, Events, Intel Foundry, Samsung Foundry, Synopsys, TSMC

SPIE is the premier event for lithography held in Silicon Valley and again Scotten Jones and I will be attending. EUV is generally the star of the show and this year will be no different now that TSMC has committed to EUV production in 2019.

Last year at SPIE, TSMC presented the history of EUV development from the beginning in 1985 as Soft X-Ray to the name change to EUV in 1993. TSMC forecasted that they will “exercise” EUV at 7nm and will introduce EUV for production use at 5nm. TSMC now says they will in fact insert EUV into 7nm in the second year of production (2019) in preparation for EUV at 5nm in 2020. So finally we will have EUV in production after more than 30 years of R&D and so many false starts!!!!!

This year Intel will again keynote SPIE and present “EUV readiness for HVM” and Samsung will again present “Progress in EUV Lithography toward manufacturing”. Scott will do thorough blogs on the conference as he has in the past. You can read Scott’s very technical event related blogs HERE. If you are attending SPIE it would be a pleasure to meet you, absolutely.

A new event at this year’s SPIE is the Synopsys Technical Forum where you will learn the latest on Synopsys Manufacturing’s mask synthesis, mask data prep and lithography simulation solutions. The Tech Forum is peer-to-peer, giving you the opportunity to hear how your lithography colleagues have addressed the challenges of 10nm and 7nm.

Overview
Synopsys provides industry-proven EDA solutions to meet the demands of today’s advanced IC manufacturing processes while setting the standard in platform flexibility to enable innovative and custom solutions for next-generation technology nodes. Synopsys’ comprehensive Mask Synthesis, Mask Data Preparation, TCAD, and Yield Management tools provide leading edge performance, accuracy, quality, and cost of ownership for all your production and development needs.

Synopsys Technical Forum Agenda

Visit Synopsys at Booth #206
Tuesday, February 28: 10:00 a.m. to 5:00 p.m.
Wednesday, March 1: 10:00 a.m. to 4:00 p.m.

Location
San Jose Convention Center
Directions

Synopsys Technical Program

Security applications for direct-write lithography(Keynote Presentation)
Mike Borza, Synopsys Inc. (Canada) [10144-3]

Correlation of experimentally measured atomic scale properties of EUV photoresist to modeling performance: an exploration
Yudhishthir Kandel, Synopsys, Inc. (USA); Jonathan Chandonait, SUNY Polytechnic Institute (USA); Sajan Marokkey, Lawrence S. Melvin III, Qiliang Yan, Benjamin D. Painter, Synopsys, Inc. (USA); Gregory H. Denbeaux, SUNY Polytechnic Institute (USA) [10143-7]

Modeling EUVL patterning variability for metal layers in 5nm technology node and its effect on electrical resistance
Weimin Gao, Synopsys GmbH (Belgium); Lawrence S. Melvin III, Synopsys, Inc. (USA); Itaru Kamohara, Synopsys GmbH (Germany); Vicky Philipsen, Vincent Wiaux, Eric Hendrickx, Ryoung-Han Kim, IMEC (Belgium)[10143-14]

Advanced fast 3D DSA model development and calibration for design technology cooptimization
Kafai Lai, IBM Thomas J. Watson Research Ctr. (USA); Balint Meliorisz, Thomas Mülders, Hans-Jürgen Stock, Synopsys GmbH (Germany); Sajan Marokkey, Synopsys, Inc. (USA); Wolfgang Demmerle, Synopsys GmbH (Germany); Chi-Chun Liu, Cheng Chi, Jing Guo, Albany NanoTech (USA)[10144-16]

Experimental characterization of NTD resist shrinkage
Bernd Küchler, Thomas Mülders, Synopsys GmbH (Germany); Hironobu Taoka, Nihon Synopsys G.K. (Japan); Weimin Gao, Synopsys NV (Germany); Ulrich Klostermann, Synopsys GmbH (Germany); Sou Kamimura, FUJIFILM Corp. (Japan); Grozdan Grozev, FUJIFILM Corp. (Belgium); Masahiro Yoshidome, Michihiro Shirakawa, FUJIFILM Corp. (Japan); Waikin Li, IMEC (Belgium)[10147-14]

Modeling of NTD resist shrinkage
Thomas Mülders, Hans-Jürgen Stock, Bernd Küchler, Ulrich Klostermann, Wolfgang Demmerle, Synopsys GmbH (Germany)[10146-21]

Source defect impact on pattern shift
Artak Isoyan, Chander Sawh, Lawrence S. Melvin III, Synopsys, Inc. (USA) [10147-21]
Cost effective solution using inverse lithography OPC for DRAM random contact layer
Jinhyuck Jeon, Jae-Hee Hwang, Jaeseung Choi, Seyoung Oh, Chan-Ha Park, Hyun-Jo Yang, SK Hynix, Inc. (Korea, Republic of); Thuc Dam, Synopsys, Inc. (USA); Munhoe Do, Dongchan Lee, Synopsys Korea Inc. (Korea, Republic of); Guangming Xiao, Jung-Hoe Choi, Kevin Lucas, Synopsys, Inc. (USA)[10148-8]

Resist 3D aware mask solution with ILT for resist failure hotspot repair
Guangming Xiao, Kosta S. Selinidis, Kevin Hooker, Synopsys, Inc. (USA); Wolfgang Hoppe, Synopsys, Inc. (Germany); Thuc Dam, Kevin Lucas, Synopsys, Inc. (USA)[10147-25]
New methodologies for lower-K1 EUV OPC and RET optimization
Kevin Hooker, Yunqiang Zhang, Kevin Lucas, Aram Kazarian, Joshua P. Tuttle, Guangming Xiao, Synopsys, Inc. (USA)[10143-45]

Exposure source error and model source error impact on optical proximity correction
Lawrence S. Melvin III, Artak Isoyan, Chander Sawh, Synopsys, Inc. (USA)[10147-32]

Guiding gate-etch process development using 3D surface reaction modeling for 7nm and beyond (Invited Paper)
Derren N. Dunn, IBM Research (United States); John R. Sporre, Univ. of Illinois at Urbana-Champaign (United States); Ronald Gull, Synopsys Switzerland, LLC (Switzerland); Peter Ventzek, Tokyo Electron America, Inc. (United States); Alok Ranjan, TEL Technology Ctr., America, LLC (United States) [10149-36]

Synopsys Posters

Compact modeling for the negative tone development processes
Lawrence S. Melvin III, Synopsys, Inc. (USA); Chun-Chieh Kuo, Synopsys, Inc. (Taiwan); Jensheng H. Huang, Synopsys, Inc. (USA)[10147-63]

Addressing optical proximity correction (OPC) challenges from highly nonlinear OPC models
Stephen Jang, Synopsys, Inc. (USA) [10147-64]

Stitching-aware in-design DPT auto fixing for sub-20nm logic devices
Soo Han Choi, David Pemberton-Smith, Sai Krishna K.V.V.S, Synopsys, Inc. (USA)[10148-46]
Using pattern matching to increase performance in hotspot fixing flows
Bradley J. Falch, Synopsys, Inc. (USA) [10148-49]

January 31, 2017June 14, 2019

Finding Transistor-level Defects Inside of Standard Cells

Finding Transistor-level Defects Inside of Standard Cells
by Daniel Payne on 01-31-2017 at 12:00 pm
Categories: EDA, Siemens EDA

In the earliest days of IC design the engineering work was always done at the transistor-level, and then over time the abstraction level moved upward to gate-level, cell-level, RTL level, IP reuse, and high-level modeling abstractions. The higher levels of abstraction have allowed systems to be integrated into an SoC that can use billions of gates. All of that is wonderful and a powerful part that enables our global semiconductor economy, however if you are concerned about the quality and reliability of your SoC then keeping the Defects Per Million (DPM) very low is a key metric that must be adhered to. Having cell-aware diagnosis is essential to finding any manufacturing flaws at the transistor level, inside of standard cells, the basic building blocks of semiconductor IP libraries.

I connected with my contacts at Mentor Graphics to see what they are doing in this area of cell-aware diagnosis. Geir Eide has written a White Paper titled: Expose Transistor-Level Yield Limiters with Cell-Aware Diagnosis. I’ll share what I found it from this seven page document.

Like with any type of testing, you must first have a model of your standard cell library. In this case it starts with a transistor-level model that includes layout information plus the SPICE netlist. Many manufacturing defects occur based upon how the IC layout is arranged, just think about adjacent metal wires that potentially could short circuit. Taking a look at a diagram will help explain this new approach:

Starting at the bottom of the diagram we see that both a SPICE netlist and GDSII layout are inputs to the Cell-aware fault model generation step, this is where fault models are created by analog simulation for each of the potential defects extracted from the cell layout – think about shorts, opens and resistive shorts. In the diagram there’s an open circuit at node D71, which is inside of a particular standard cell. During the fault model generation a SPICE circuit simulator has predicted the behavior of having an open at node D71, so when we run our ATPG patterns then this particular fault can be detected, and during the diagnosis phase it will pinpoint the open circuit to be inside this cell instance at the specific XY coordinates. Think of how much time this approach will save your engineers that are performing Physical Failure Analysis (PFA) in order to improve the yield for a new SoC.

Related blog – New Frontiers in Scan Diagnosis

Product engineers are going to love this new ability, because it will make their jobs much more productive. So instead of just knowing that one cell instance has a defect somewhere, they now would now that inside of this cell instance at a specific coordinate, there is a defect, like an open or a short. Having this cell-aware diagnosis the yield problems can be quantified over a number of chips so that you can concentrate on PFA based upon the highest percentage issues found first.

Fault Model Creation
Now that we’ve seen kind of the big picture, let’s take a closer look at each of the steps starting with fault model creation. You create cell-aware fault models once per technology. During fault model generation the probability of an open or short between layers is determined, so for example in the following figure we know that bridging defect D45 has a high probability while defect D46 has a very low probability:

An analog simulator like Eldo is then used to simulate each of the potential defects against an exhaustive set of inputs to see if any input combination will produce an output result different from a good circuit. This data about which cell inputs can detect internal faults becomes part of the new fault model.

Diagnosis
During cell-aware diagnostics we see that the inputs are the SPICE netlist, layout, fault library, ATPG patterns and tester fail data:

Every failing pattern is traced to find initial candidates using pattern matches. The best matching symptoms are identified and reported in the right-hand side. For me the biggest wow factor is the diagnostic ability to pinpoint the XY coordinates of each defect like opens and shorts between metals or poly layers. As you click on a text failure name, then you can see in the layout where this defect happened:

Silicon Results
Up until now this all sounds so theoretical and practical, yet does it really correlate to actual silicon failure mechanisms in wafers? The short answer is Yes, according to a range of companies doing silicon designs from 160nm planar CMOS down to 14nm FinFET. One big name that uses this cell-aware diagnosis is AMD and here’s where they found an open contact defect inside of a full adder circuit:

This one particular cell used 24 transistors and had 277 internal faults that could be tested based upon the extracted defects. In the old approach you would only know that this cell had a failure, while with the cell-aware approach now available you will know that four cell internal suspects would cause this particular failure. In the top-down view of the IC layout on the left we see all four of these suspects highlighted. The photo on the right shows a cross-sectional view of where the un-landed contact was pinpointed during failure analysis. You can quickly conclude that using this cell-aware approach is a great boon for PFA.

A second example shows how cell-aware analysis of a 160nm automotive chip pinpointed an open circuit on a Poly layer:

The IC layout is shown on the left in top view, then the middle is the silicon layout top view, finally the rightmost photo zooms into the missing Poly defect.

Conclusion
The goal of silicon manufacturing is to produce perfect chips, every time, however when there is a manufacturing flaw then the burden shifts to the product and yield engineers to quickly pinpoint the source of the failure in order to understand the root cause and propose a remedy or yield improvement approach. By using a cell-aware tool that models transistor-level defects inside of cells, the analysis work greatly speeds up, providing swift feedback about failures and yield. You could use this kind of a tool for both single-part diagnosis or yield analysis.

Read the complete 7 page White Paper here.

January 31, 2017

Computability 2.0?

Computability 2.0?
by Bernard Murphy on 01-31-2017 at 7:00 am
Categories: General

There’s muttering among computing fundamentalists that perhaps we ought to revisit the definition of computability given recent advances in methods of computing, especially machine learning and quantum computation.

Computability is about what can and cannot be computed, either by a human or non-human computer. This is a topic most of us associate with Alan Turing, the Turing machine and the Halting problem but the correspondence with human calculators is better expressed in the (related) Church-Turing thesis. It’s a thesis (hypothesis) because we don’t have a formal definition for what a human can and cannot calculate, but it’s widely believed to hold – that there is a potentially exact correspondence, in principle, between what a human and a Turing machine can calculate (though typically at very different speeds).

Can quantum computing or deep learning somehow transcend these bounds? Some theorists have proposed that hyper-computation – computation able to solve problems unsolvable by a Turing machine – should be possible at least in principle.

One such case was made in 1995 for a hypothesized neural net. The author of that paper starts by restricting the weights on nodes to be integers, which is of course possible. This is then relaxed to allow rational numbers – also possible. The theoretical range of problems that could be solved by such machines is countably infinite since integers and rationals are both countably infinite. This is still no more capable than a Turing machine, but then the author takes the next step, making the weights real numbers. As a limit to progressively more accurate approximations, this is still possible.

An interesting thing about reals is that there are vastly more than there are countable numbers, such as integers or rationals. Some are real representations of integers and rationals, some are irrational, like √2 or pi or e, and each of these is computable on a Turing machine to arbitrary accuracy using a finite algorithm. There is a countable infinity of these computable numbers because finite algorithms can be listed in some order, which makes them countable, and even if each can generate a countably infinite set of numbers, the total set of numbers that can be generated is the product of two countable infinities, which is still countably infinite.

The total set of reals is uncountable, which means that almost all reals are uncomputable numbers for which no finite algorithm is possible (an infinite algorithm for a given real is always possible – simply list out the digits in whatever base you use to express the number). Now suppose you use uncomputable numbers as weights in the neural net. Then in principle it would be possible for the net to calculate an uncomputable (in Church-Turing terms) result which could not possibly be calculated by a Turing machine. Does this hold out the promise that you could possibly, at least in theory, build a machine that could solve problems like the Halting problem?

Unfortunately no, because the argument is flawed. You can only compute an uncomputable result if you start with uncomputable weights. Either those must be computed on a Turing-like machine – which is not possible because Turing machines can only generate computable numbers – or you must assume the existence of a machine which can generate uncomputable numbers – which is circular reasoning. There is one other option – it is possible in principle to generate uncomputable random numbers (after all, you want random numbers to be uncomputable). The problem here is that while the weights and the result may be uncomputable, they will also be unusable – you have no control over what the net will calculate.

A different case has been made for quantum computing but this is primarily a performance argument rather than a feasibility argument (which is the substance of Church-Turing). It is true that for a narrow range of problems, quantum computing can be as much as exponentially faster than traditional/Turing computing but Church-Turing only cares if computation completes in finite time (using a finite algorithm on a finite machine), not how quickly it completes.

However one theoretical suggestion uses an infinite superposition of quantum states, which could in principle transcend the countability limit. There are obviously some physical problems in the proposal, but the idea is intellectually appealing in at least one sense. Combining a superposition of a countable infinity of quantum states with exponential performance allows (in principle) access to 2 [SUP]countable infinity[/SUP] states which is precisely the size of the set of reals. The machine could in theory access that complete set, though sadly you still must provide algorithms and inputs to do something useful, which would still limit calculations to a countable set.

Another physical assist requires that a (Turing) computer orbit a spinning black hole. It seems that relativistic time dilation around that massively warped space-time can be organized such that a programmer can interact with the machine in finite time but the computation in the frame of the machine can evolve in infinite time, allowing an infinite computation to complete in finite time for the programmer. However this is an approach unlikely to be tested any time soon.

One final apparent counter-argument. Humans can reason about infinite objects in quite constructive ways. For example, proof of the Goldstein theorem depends on this kind of reasoning. So if humans can do this, can machines also perform the same kind of reasoning? There’s no obvious reason why not. Does this break the Church-Turing thesis? No. Because these cases use finite algorithms which complete in a finite number of steps, reasoning about abstract infinite objects. But solving an uncomputable problem requires an infinite number of steps. You can’t reason about infinity – you must go there.

None of this means that novel forms of computing aren’t exciting and (for some problems) very useful. They can certainly dramatically improve efficiency – that’s all part of advancing technology. But we should temper our expectations to what is asymptotically achievable; physical and mathematical limits don’t bend to enthusiasm. And there is a corollary – if humans can’t even conceivably compute a certain result (allowing for multiple people and a countable number of generations working on the problem) then it is quite likely that machines can’t conceivably do it either. And vice-versa. Church-Turing remains the upper bound for computability and at least in principle machines can never be fundamentally smarter than us (though they can certainly be much faster).

You can read more and peruse a challenging list of references HERE. I found a very nice critique of hyper-computation HERE (from which my neural net discussion is derived).