Bronco Webinar 800x100 1

Chapter 3 – Moore’s Law is Unconstitutional!

Chapter 3 – Moore’s Law is Unconstitutional!
by Wally Rhines on 07-26-2019 at 6:00 am

(Adapted from a presentation first given under this title in 1989 and subsequently expanded in presentations over a period of nearly thirty years)

In 1965, Gordon Moore, then R&D Manager for Fairchild Semiconductor, published a paper in “Electronics” magazine predicting the trend for semiconductors in the next ten years.  He showed a graph of the number of components in the largest chips in each of the last four years that followed a straight line when plotted with a Y-axis that was the base two logarithm of the number of components (transistors, capacitors, resistors or diodes) and the horizontal axis was time.  The number of components had doubled every year (Figure 1). This graph became known as “Moore’s Law” and has been extrapolated for more than fifty years.  It is not a “law”.  It is an empirical observation that became self-fulfilling after some adjustments.

Figure 1. First presentation of Moore’s Law in 1965

Ten years later, in 1975, Gordon Moore revised “Moore’s Law”, saying that the doubling of transistors per chip was now occurring every two years, instead of every year. Then, in 1997, Gordon Moore revised “Moore’s Law” once again, showing that the doubling of transistors was now occurring every 18 months.  These repeated revisions affirm that “Moore’s Law” was not actually a law of nature but an interesting, if temporary, phenomenon. In science and engineering, we have laws that predict outcomes when variables change, like the first and second laws of thermodynamics, Newton’s laws of motion or Maxwell’s equations.  They don’t change over time, unlike Moore’s Law (Figure 2). Even Dr. Moore pointed out, in his ISSCC keynote in 2003, that “no exponential is forever”.

Why did “Moore’s Law” take on such significance and work so well, despite the adjustments in time scale?  The answer is that “Moore’s Law” is based upon an actual law of nature called the “learning curve” (See Figure 1 in Chapter 1). Learning curves have been used over the last hundred years to predict the future cost per unit of products as diverse as airplanes, beer and transistors. They were used strategically by Texas Instruments in the 1960’s to “forward price” new semiconductor components in order to achieve a desired future market share and profitability.

The learning curve and Moore’s Law are actually the same when two conditions are met.  These are:  1) If most of the cost reduction for semiconductor chips comes from shrinking feature sizes and growing wafer diameters and 2) If the cumulative number of transistors manufactured by the semiconductor industry increases exponentially with time.  If these two conditions are met, then Moore’s Law and the learning curve become straight lines that predict the same trend (Figure 3).

If “Moore’s Law” is based upon a real law of nature, i.e. the learning curve, then why did it have to be adjusted from one year to two years and then back to eighteen months?  The answer comes from assumption number two above and is shown in Figure 4. Even though the number of transistors shipped each year has grown exponentially through most of the history of the semiconductor industry, there was a period when growth slowed and then later returned to the exponential trend.  That change in growth rate caused “Moore’s Law” to increase from one to two years and then back to eighteen months. Because the learning curve is a log/log graph, exponential growth of the cumulative number of transistors produces a straight line with time as well as with the cumulative number of transistors. Unlike Moore’s Law, the learning curve works well even if the exponential growth of units deviates.  Moore’s Law uses time as its horizontal axis so linearity is assured only if cumulative transistor growth is exponential.

Today, many people worry that the inevitable end of Moore’s Law will leave us with a stagnant semiconductor industry with no guideposts to drive new silicon technology directions. Fortunately, these people need not worry.  The learning curve is valid forever (when measured in constant currency, corrected for governmentally-induced inflation) as long as free market economics prevail, i.e. negligible trade barriers, no regulatory price controls, etc.

Figure 5 shows a learning curve for the electronic switch measured as revenue per MIP, beginning with vacuum tubes and progressing through germanium and quickly transitioning to silicon.  We use industry revenue for the vertical axis, instead of cost, because the data is more readily available but the two variables should be surrogates for one another.  The horizontal axis is the cumulative number of transistors shipped throughout history.  That number has been available from the Semiconductor Industry Association, as well as from other semiconductor analysts, for decades.

Of course, the learning curve for electronic switches doesn’t care whether the cost reduction is achieved with mechanical switches, vacuum tubes, transistors or even carbon nanotubes in the future. The learning curve is technology independent if a more generalized unit than transistors is measured. We therefore have a metric to track when the further improvements in cost or power are so difficult with silicon that we have to consider an alternative like carbon nanotubes or bio-switches. The important result of this information for the electronics industry is that the death of Moore’s Law doesn’t lead to random, unpredictable trends in semiconductor technology.  We have a road map.  As long as we can measure the growth rate of transistor shipments, we will know the cost or revenue per transistor of the semiconductor industry, or vice versa.

Figure 2. Moore’s “Law” evolved over time

Figure 3. Learning Curve and Moore’s Law are the same under certain conditions

Figure 4. Growth in cumulative number of transistors has not always been exponential with time

Figure 5. Cost per Function, or per MIP, transcends the transistor era

Read the completed series


The Wild, Wild SEMICON West TechTALK – Joe Costello Speaks Out

The Wild, Wild SEMICON West TechTALK – Joe Costello Speaks Out
by Randy Smith on 07-25-2019 at 10:00 am

On July 9, 2019, I attended the TechTALK session hosted by Dave Kelf of Breker Systems, Inc. titled, “Applied AI in Design-to-Manufacturing.” I was happy to hear what Dave had put together for this since it is a topic I am keenly interested in and because I have known Dave personally through music and charitable activities we have worked on together.

Dave’s intro was brief when he gave way to his first speaker Aki Fujimura, Chairman, and CEO of D2S, Inc. Again, I was having the pleasure of listening to a good friend as Aki and I were two of the co-founders of Tangent Systems when we were both relatively fresh out of college. Back then, we were working together on timing-driven place and route. We have both broadened technically since then. Aki has immersed himself in the manufacturing side of semiconductors while founding D2S in 2007. Aki’s title was a straightforward description of his talk, “Everything Needs a Digital Twin in the Deep Learning Era.” As I understood it, since there are relatively few defects to be found in actual mask designs, it is complicated to train a deep learning neural network on how to find them. Aki’s proposed solution is to create a digital twin, a simulated version of the real wafer or mask. At the same time, I thought it was deep, weird, and brilliant. I often had trouble keeping up with Aki and Steve Teig (another Tangent co-founder) when we worked together as they are both outstanding engineers. The concept of a digital twin will be something I want to follow through and study more.

Next up was Jan Rabaey of both UC Berkley and IMEC. Jan spoke about “The Cognitive Edge.” We have heard multiple interpretations of what Cloud and IoT mean for a few years now. To me, the term most inconsistently used has been the Edge. What Jan adeptly pointed out is that there are a huge number of sensors and other devices in the world, generating an overwhelming amount of data. It is neither practical nor reasonable to send all of that data to “the Cloud” for processing. I appreciated Rabaey’s presentation, and I intend to talk much more about “the EDGE” in some upcoming blogs. The point here is adding intelligence at the edge of the IoT network is required because there is far too much data to send everything to the cloud. It is impractical and inefficient. What to do about it? That will be for several future blogs.

Finally, we get to the entertainment portion of the event, Jim Hogan’s panel titled, “Are we Experiencing a Renaissance in Chip Design and EDA?” From an investment point of view, EDA has seen a decrease in start-up investment since Mike Fister told the world Cadence was not going to rely on buying start-ups anymore in 2004. The statement was not prophetic because Cadence indeed completed some very significant acquisitions after that. But in the long run, it was self-fulfilling prophesy because investors started walking away from a market where successful exits were going to significantly harder to achieve given the drop in the competitiveness that would happen with Cadence as a buyer of EDA start-ups. Still, there has been a lot of new technology coming out of a smaller number of EDA start-ups, and they are affecting the EDA marketplace substantially (see Verification 3.0). There was also a strong panel of experts not from the EDA Big 3 there to discuss it.

The panel, which of course was moderated by Jim Hogan (Vista Ventures) consisted of (alphabetically) Simon Butler (Methodics), Joe Costello (Montana Systems), Simon Davidmann (Imperas), Adnan Hamid (Breker), and Doug Letcher (Metrics).   Jim’s premise, which was not refuted by the panel, was that three macro trends were powering this renewal in EDA:

  1. A new computing platform – infinite scalable compute capacity in the cloud along with cloud-native development tools like GitHub and Kubernetes, which enables a new SaaS business model that lets customers purchase exactly the amount of software cycles they need
  2. A customer demand for much higher simulation throughput driven by the increased size and complexity of chip design, coupled with high tape-out costs which means one must have the highest verification coverage to avoid any test escapes
  3. A new chip design opportunity – application or domain-specific processors that coupled with the cloud platform will enable startups and system companies to build specialized processors rather than the handful of giant companies building the enormously expensive general-purpose processors.

Each of these business leaders spoke on these premises supportively for a while before Joe Costello lit the fuse and declared that the big EDA’s were slowing this whole thing down by dragging their feet on truly addressing cloud-based licensing models. We need to remember that Joe was leading Cadence when they moved from perpetual licenses with maintenance fees to time-based license fees. Then, he saw what he felt his customers needed, he did it, and the rest of the industry followed. The issue today is how to provide an opportunity to scale compute power and licenses on an as-needed basis – to only pay for what you use on-demand. In Joe’s opinion, the EDA industry is not moving very quickly to this new model, or at least, the big EDA companies are not.

I have not heard much push back from Joe’s remarks, although there were many people in attendance. Maybe the conversation will start in the forum below this article? Feel free to post your remarks below.

As was mentioned above, Dave Kelf is VP, Marketing at Breker Systems. Breker Systems is holding a webinar in August titled “Eliminating Hybrid Verification Barriers Through Test Suite Synthesis.” You can read the blogabout the webinar here, or go straight to the registration page.


5G and V2X

5G and V2X
by Bernard Murphy on 07-25-2019 at 5:00 am

Amid the glamor of autonomous vehicles and hot new ADAS features, communication between vehicles and other vehicles, pedestrians, cyclists or infrastructure, generally labeled V2X, doesn’t get as much press, perhaps because adoption is still pretty early or because it’s technology under the hood (quite literally) and therefore not as immediately glamorous as other advances. That’s a shame because applications of V2X are likely to have important impact in safety and convenience long before full autonomy becomes a reality.

(Image Source: Synopsys)

Applications

Consider these potential applications of V2X. In communication between vehicles it can augment existing methods to help with left-turn assistance (for those of us driving on the right) emergency braking warnings and improved situational awareness at intersections. Extending Waze concepts, it can control or suggest speed adjustments to account for traffic congestion, also update your GPS map with real-time updates on lane closure and highway construction activity. V2X in some form is essential to support over-the-air (OTA) software updates for the now-extensive range of software-driven systems in your car, from map updates to bug fixes to security updates and more.

One really nice capability could be see-through vehicles. If your car can tap into the front-facing camera of that giant truck in front of you, you’ll be able to see what’s ahead of that truck. Kind of important if you’re tailgating and traffic ahead of the truck has come to a stop. Or if you want to pass but can’t see around the truck.

Another very interesting application is in support of platooning. This is a technique in which trucks and/or cars drive in coordinated groups. Platooning can reduce congestion since such groups can be more closely spaced than would be possible if they had to allow for human reaction times. The primary intent behind this idea is in support of self-driving vehicles on automated highways. This might be how autonomy takes off, long before it becomes universal. Reading a book or napping while you’re on a highway could be a reasonably near-term objective if we can implement the V2X infrastructure in cars and on the highways to support this. (There’s still a question of whether the lead vehicle needs a human driver. And how you exchange leads when the current lead wants to leave the platoon. But this still seems closer to feasible than grander goals.)

Technologies – Wi-Fi and Cellular

The ideal communication technology in support of V2X is a little contentious. Clearly any such technology must be extremely reliable under a very wide variety of conditions (weather, and interference from other EMI sources) and it must guarantee very low latency. You really don’t want to see a “buffering” spinning wheel in any of the applications I just described.

Wi-Fi advocates have made a strong case that Direct Short Range Communication (DSRC), a subset of 802.11, is the real candidate for V2X. Work on this standard goes back a long way but it seems compelling need is only now starting to catch up. Nevertheless it is the prescribed standard in the US and the NHTSA has already started the process for a mandate that all cars in the US come equipped with DSRC.

However – the 3GPP standards group responsible for cellular standards is a relative late-comer to this domain but has been working hard on ultra-reliable low-latency communication, known as C-V2X, as one of the principal components of 5G. This supports 1ms latency end-to-end, in compliance with the NHTSA requirement, it provides improved reliability and it support bandwidth of up to 20Gbps, allowing for high-fidelity streaming if needed. Further, C-V2X seems to have a 2X+ range advantage over DSRC, meaning it will require less small/pico-cell stations to support a given area. Finally, chips and modules are expected to become available this year and to appear in vehicles in 2020.

(Image Source: Synopsys)

What Next?

Now the US Department of Transportation are hedging their bets on that mandate I mentioned earlier. When their review started, DSRC was the only option. Now C-V2X looks like a strong contender. Heidi King, deputy administrator at NHTSA has stated that “USDOT remains technology-neutral relative to communications protocols that support V2X technology.”  Some companies and region have already adopted DSRC for some applications (eg Cadillac, Singapore, Utah), C-V2X for some others (Ford, Las Vegas). It’s a race but important to realize that the race has barely started.

If I had to bet, I’d go with the cellular solution as the long-term winner. This has nothing to do with technology. My bet is based on infrastructure cost of ownership and dependability of support. Any Wi-Fi solution will demand wide deployment of access points, plus the back-haul from those access points to gateways, etc. Who is going to pay for and maintain that infrastructure – local government (unlikely) or new private ventures? Do we have to expect unreliable support until those private ventures mature? We already have matured companies vested in providing wireless support locally and worldwide. Not that they’re perfect or can’t improve but building on that existing business and physical infrastructure makes more sense to me than launching new businesses to support a new physical infrastructure.

Key enablers of C-V2X technology are obviously the 5G radio, SoC integration and other IP components required to complete a 5G C-V2X interface. Since such solutions must be certified to ISO 26262 standards, integrators need not only the right components from their IP supplier but also confidence in their capability, depth and track record in providing ISO 26262 safety packages and certification. The right choice must meet functionality, performance, quality, and reliability levels in down to the most aggressive FinFET feature sizes. You can learn more about the Synopsys Automotive IP Segment view of this domain HERE and read more about how they are supporting design in this area HERE.


#DAC56 – Optimizing Verification Throughput for Advanced Designs in a Connected World

#DAC56 – Optimizing Verification Throughput for Advanced Designs in a Connected World
by Daniel Payne on 07-24-2019 at 10:00 am

Cadence, DAC 56, Wednesday

It was the final day of DAC56 and my head was already spinning from information overload after meeting so many people and hearing so many presentations, but I knew that IC functional verification was a huge topic and looming bottleneck for many SoC design teams, so I made a last-minute email request to attend a luncheon panel discussion featuring some tier-one companies, like:

Fellow-Oregonian Brian Bailey was the panel moderator, and he did a fine job keeping the discussion focused and moving along. Brian started out by noting that 20 years ago the IC world was simpler with Verilog being used, code coverage goals as metrics and RTL entry, however today there are many languages to consider, plenty of EDA tools to choose from, formal techniques, emulation becoming common, and new standards like PSS.

Panel Discussion

Q: What does verification throughput mean to you?

Tran – Yes, we do have an infinite verification challenge. Each of our design cycles is for about 9-10 months, and this time frame doesn’t change much each new project. How efficiently can I verify, are these new cycles finding any new bugs? A faster speed of verification helps us, but uncovering more bugs is what we really need.

Raju – we need a more holistic picture from design verification to post-silicon. There are issues like build, resource utilization, run speed, and time to root cause. How fast can this HW fix get in (Build)? How fast are jobs launched? Are testbenches running effectively? For debug time, we want to know how fast can I find and fix a bug. These four verticals are the focus of our work.

Dale – how many jobs can I submit into emulation, iterate and debug, finding RTL bugs? Is build, run, testbench, AI scripting to triage any failures. We don’t have QA engineers wait for jobs to finish, so we need to make their time more productive.

Paul – you can only optimize what you can measure. Raw throughput metrics like time to see waveforms are important. Higher order metrics are time to root cause of bugs. We do have a cockpit to pull all of these analytics together in one place.

Q: How do different SoC designs use verification?

Dale – for GPU verification and development we have functional goals like RTL health, GPU performance, pre-validate GPU with drivers, where each team has their own test bench. Regression and debug tasks have different test benches.

Raju – we need our chips to run across multiple OSes, meeting the requirements.

Tran – across multiple products we like to reuse some parts of test benches to improve throughput.

Paul – there’s raw performance and also root cause rates, but at different levels of abstraction (transistor, gate, RTL, OS) we need to optimize throughput, then pick the right tool for the job.

Dale – as a verification engineer we just pick up the tools and use it, but didn’t think about how the tools work. Collaborating with the Paladium team I’ve learned of different approaches to get the best throughput.

Q: How do you assess each of the verification tools to use them in the right tasks?

Raju – collaborating with the EDA vendor and knowing their product roadmap helps us plan which vendor to work with.

Tran – we need help to understand the verification data that we are generating from the tools. Would like to use some ML to help us analyze our test data better.

Paul – formal is a great example that complements dynamic verification approaches. What are the test payloads gong through?

Q: Is time being spent in debug getting worse?

Raju – yes, Verification tasks and use is increasing dramatically. Debug techniques need to improve, so more automation is required. We can build more common debug approaches, and we can use ML and AI to help pinpoint verification bottlenecks.

Tran – debugging a system of systems, like verifying an autonomous vehicle is a big, new challenge. We have a lot of known unknowns to verify, it’s very complex for us to achieve.

Paul – the opportunity to use AI in the debug process is ripe, how can we guide the human to look in the best debug areas?

Dale – we have metrics to assess how verification tools help throughput, but engineers need to know tool limitations in order to be most efficient in test bench generation. Generating traces for 1 million cycles takes one day of run time, so use a different approach to find and fix the bugs.

Q&A

Q: Maxim – we use VIP and metric-driven verification approaches. But our designers and verification engineers have a different understanding of the same specs. Can you help our teams capture the specs correctly?

Raju – that’s a fantastic problem statement, because stale documentation causes differences between design and verification engineers. We’re trying to have standardized documentation requirements with frequent sign-off criteria, keeping specs up to date as design changes occur. Using PSS is going to help us document all of our requirements better.

Dale – making sure test and design specs meet the overall specs is important. Finding mistakes in interpretation of specs is important.

Paul – smart linting can catch mistakes earlier, some VIP can provide 100% coverage of known specifications.

Q: How much metric driven verification do you use?

Raju – we use functional and code coverage metrics in all verification flows to get signoff points. We have legacy coverage goals, and need to be smarter about finding and removing redundant testing.

Paul – coverage driven verification methodology is our goal (Formal, Simulation, Emulation), with a single dashboard.

Q: Are you using the right metric for your verification goals?

Raju – how can we improve our verification coverage with each tool: Formal, Simulatio, Emulation.

Q: Is there a standard way to use AI and ML, sharing across a verification environment?

Tran – AI is something very new, so we’re still learning how to use it during verification, trying to get a better understanding of our test data. We store and plot our test coverage metrics, but there’s no standard process that AI would automate.

Paul – we see lots of test data gathering going on now, and Cadence has a method to collect it, but there’s no industry standard out there for data gathering. What do you want us to do with this test data? How can we use this data improve our test goals?

Q: Is the cloud gong to help us in collecting data and applying AI for improving test?

Paul – you can do analytics anywhere.

Tran – the cloud is just a technique, the reasoning is the important point.

Paul – yes, the cloud will ensure that we gather more data.

Q:  Software in our systems is a large part of SOCs, how does that affect verification?

Raju – having verification drivers is important, getting to SW debug we often use FPGA for prototyping.

Dale – to get Android and Linux booting, we need prototyping sign-off to reach verification goals. Bugs happen between SW, HW, firmware and RTL, so we need emulation to reach our tape out goals.

Tran – to verify SW and OS we use FPGAs for prototyping, but SW verification has a lot of room for improvement.

Dale – SW developers start with virtual debugging, then eventually HW prototyping.

Paul – SW bring up is very expensive, so pre-silicon SW bring up is the goal.

Conclusion

The panelists were uniform in their replies on the topic of optimizing verification throughput, and they have an established approach to verification that now includes: formal methods, emulation, FPGA prototyping, PSS, and even ML to help wade through so many logfile results. Successful EDA vendors will continue to help automate more verification tasks in order to equip engineers in finding more bugs, quicker.


The Flash and the Taiwan ESD Seminar!

The Flash and the Taiwan ESD Seminar!
by Daniel Nenni on 07-24-2019 at 6:00 am

During my trip through Asia last week I attended the Taiwan ESD Workshop. Hsinchu is densely populated with some of the smartest semiconductor people in the world so it is well worth the trip, absolutely.  As it turns out ESD is one of the top concerns in semiconductor design and manufacture. The current rule based and simulation solutions are not scaling so the search is on for new ways to protect our chips from electrostatic discharge.

The DC Comics character the Flash (my personal favorite) received his super powers when he was struck by lightning in his lab. Sadly, in real life neither people nor electronic circuits are so lucky when they are hit with lightning. Even nature’s scaled down common electrostatic discharges can have devastating effects on modern integrated circuit chips. Far from imbuing them with super powers, electrostatic discharges (ESD) render chips useless, by destroying devices and melting metal interconnect, or more insidiously damaging them just enough to make it into a product that will mysteriously fail down the road.

To avoid this peril designers employ protection circuits that have to operate as fast as the Flash to intervene and prevent damage. Their ability to protect the circuit comes from having a lightning fast response to an incoming ESD event, harmlessly deflecting the high voltage current before it can cause any harm to the circuit. The actual behavior and performance of the ESD protection designed into a chip depends on many factors. Last week in Taiwan, Magwel’s CEO, Dundar Dumlugol, presented a well attended seminar on the topic of ESD protection simulation, where he talked about many of the specific factors that play a role in determining ESD protection effectiveness.

In the case of HBM, Dundar suggested that despite a few minor disadvantages, a static simulation based approach offers both high throughput and very high accuracy for ESD simulation. When done properly, static simulation can tell designers about voltage build up over devices and also parasitic resistances. It is also good at determining voltage build up over protected devices, parasitic currents in sneak paths, non-uniform triggering of parallel power clamps and non-uniform triggering in fingers of ESD devices. Finally, one of the most important pieces of information that it can provide is the result of competitive triggering between ESD devices and protected devices. This would make the Flash proud, because his mission is to protect those in danger.

Dundar also spoke about how Magwel’s ESDi, used for HBM simulation, takes advantage of reduced order modeling (ROM) to make simulation of large power and ground net resistive networks feasible. Without this approach complete simulation of all the pad pairs in a large design could take many times longer. Using their simulation approach, Magwel’s ESDi can help find the following issues:

  • Missing / undersized vias (via burnout)
  • Current crowding in metal / vias
  • Excessive bus resistance
  • Excessive voltage stress over protected devices
  • Wrong/missing ESD devices
  • ESD device burnout (It2, Vt2 limit check)
  • Imbalanced current distribution over the fingers inside ESD devices
  • Protected device triggering before parallel ESD device
  • Parasitic junction/ Bipolar triggering/ break-down
  • Protected device damage (oxide breakdown, junction / device burnout) due to voltage stress & parasitic currents

CDM is a different animal altogether, due to much faster ESD impulses and the potential for damage almost anywhere in the chip. Given this complexity, it seems like the skills of a super hero are needed to predict the outcome of an ESD event. For CDM it turns out that dynamic simulation is the best approach. According to Dundar, you still need a very accurate extracted model for the large nets in the design. This is where the charge is stored prior to a discharge event. The dynamic simulation needs to take into consideration this charge and how it flows through the wire towards the port that is zapped. The voltage drop along the connected nets caused by IR drop can damage protected devices, unless there is sufficient ESD protection designed into the circuit.

Dundar covered one example of an RF LNA circuit test chip provided by Qorvo where the lack of protection diodes caused the discharge to trigger and then pass through an output NFET, leading to its failure. Magwel’s CDMi product predicted this failure, which was confirmed in silicon. Resimulating with added protection diodes shows how the ESD current flows safely to ground. Using this method, it is possible to add only the needed number of protection diodes, preserving output performance.

To learn more register for this webinar replay: Avoiding CDM (Charged Device Model) ESD Failures

About Us
Magwel® offers 3D field solver and simulation based analysis and design solutions for digital, analog/mixed-signal, power management, automotive, and RF semiconductors. Magwel® software products address power device design with Rdson extraction and electro-migration analysis, ESD protection network simulation/analysis, latch-up analysis and power distribution network integrity with EMIR and thermal analysis. Leading semiconductor vendors use Magwel’s tools to improve productivity, avoid redesign, respins and field failures. Magwel is privately held and is headquartered in Leuven, Belgium. Further information on Magwel can be found at www.magwel.com


Synopsys and Synaptics Talk About Securing the Connected Home

Synopsys and Synaptics Talk About Securing the Connected Home
by Tom Simon on 07-23-2019 at 10:00 am

Like many people, I have been adding automation to my home, and the number of connected devices I use has slowly but steadily increased. These include light bulbs, cameras, switches, a thermostat, a voice assistant, etc. Between them, they know when I am home or away, and have the ability to record images and sound. In addition to privacy concerns, if they were hacked, they could turn off my security system, hijack my heat or air conditioning, and potentially control home appliances such as ovens and refrigerators. It should be clear that connected home devices can cause real harm if they are compromised. As a consumer I need to trust that the embedded systems in the devices are secure.

 

What are the best practices for designing home automation hardware so it is secure? According to Synopsys and Synaptics in their recent webinar on “Securing Connected Home Devices Using OTP NVM IP”, it starts with creating a trusted execution environment (TEE). Krishna Balachandran, Product Marketing Manager for NVM IP at Synopsys, and Jingliang Li, ASIC Architect in the IoT Department at Synaptics, describe how one-time programmable (OTP) non-volatile memory (NVM) is an excellent choice for creating the foundation for a TEE.

Indeed, they point out that more is at stake here than just the security of your home. Also, incoming data streams such as copyrighted media also pass through the connected home in the form of music, video, and images. In their webinar they discuss how the starting point for TEE is firmware in ROM and secure keys. With this the firmware can be validated and the keys can be verified. The unique keys are created and then stored in the device using NVM OTP that is programmed when the device is manufactured.

OTP NVM can be programmed at the time of manufacture using an externally provided voltage programming supply or it can optionally be programmed later using the chip’s supply voltage with a built-in charge pump. It is possible to permanently disable programming once the desired contents are written, adding further security.

A big advantage of NVM OTP IP from Synopsys is that they have implemented critical features to ensure security. Krishna talked about how the data is stored in complementary bit cells so that it is not possible to detect data values by monitoring fluctuations in supply voltage. They have also implemented detection for supply voltage tampering, which is sometimes used to compromise on-chip security.

During the webinar Jingliang talked about how Synaptics has used Synopsys NVM OTP IP for many generations of products. Krishna reviewed the process nodes that are supported, and those that are in the qualification process. Even though OTP NVM works on standard CMOS processes using foundry design rules, there is an extensive qualification process, where Synopsys works with the foundry to verify the yield and operation of the OTP NVM.

What was also interesting to learn is that Synopsys OTP NVM IP is useful for more than just key storage. They have several families, each targeted at a specific application. For up to 128Kb, they offer the XBC family. For larger sizes, which would be suitable for code storage, they offer the XHC family for 256Kb up to 1Mb. They have a specialized security-oriented family called XCS. In all they cover 180nm to 7nm, with operating voltages from 1.8V up to those of BCD and HV nodes.

Webinars that include product users are always much more informative. Synaptics has a long and deep history of working in the smart home area. They are the main supplier of Android based TV platforms. They also work with Google on a range of connected home products. So, it is good to hear their perspective on effective methods to add security. If you want to watch the entire webinar replay it is available on the Synopsys website.


PSS and Reuse: Great Solution But Not Hands-Free

PSS and Reuse: Great Solution But Not Hands-Free
by Bernard Murphy on 07-23-2019 at 6:00 am

If you’re new to PSS you could be forgiven for thinking that it automagically makes stimulus reusable, vertically from IPs to systems, horizontally between derivatives and between hardware-based and software-based testing. From a big-picture point of view these are certainly all potential benefits of PSS.

What PSS does provide is a standardized way to describe test intent declaratively. The declarative part is important; this means that you describe what should be tested rather than the detailed mechanics of how it should be tested. This abstracts the test intent from the test implementation, providing that standardized mechanism which should cover the needs of many possible types of testing.

This is not unlike the benefits that derive from object-oriented programming. Through complexity-hiding in classes you can hide the details of how something is implemented, say rotating a graphical image, so that an object based on such a class can easily be rotated without a user of that class having to worry about the details. Object-oriented programming (OOP), in languages like C++ or Java, gives you the mechanisms to do that hiding, but there’s nothing magical in delivering the underlying methods. You (or someone) still has to flesh out the implementation; it’s just more easily reusable across applications. If you don’t think carefully about reusability, there can be limited gain in using OOP. You may benefit in your own code but no-one else will.

The same applies to PSS, but hardware verification is an inherently very collaborative exercise so reuse across multiple applications is even more important, vertically, horizontally and between hardware-driven and software-driven testing. This means that the implementation layer – the connection between PSS models/scenarios and the various testing targets (IP/subsystem/SoC or UVM/C++) must be designed with reuse in mind, tuned to your verification methodology and between these targets.

Matthew Ballance (PE and PSS technologist at Mentor) has written a very nice white-paper on this topic. As a sidebar, I write quite a lot so I’m always working at improving my skills. I also read a lot of material written by others. Quite a lot of what I read gets the job done but can be challenging to absorb because it feels like it was written by someone for whom writing does not come naturally. I have to tip my hat to Matthew as a polished writer, easy to read and to get his point across in one pass.

But I digress. Advice in the paper breaks down into a few main sections: Identifying opportunities for reuse in existing testing code (SV or C++), building reusable PSS libraries, reusable data generation and checking, and making test realization reusable. In the first section he suggests looking at constraints, certainly SV constraints which have a global nature such as for configuration classes and operation modes. He also suggests looking at memory maps which can equally provide a source of PSS constraints. In test realization (the implementation topic above), you’re very likely to have standard UVM routines to perform basic operations on an IP such as configuration, and read and write. These can be reused in the PSS test realization. He also shows an example for a similar C++ access function.

(Tricky question here. Do you move that function to PSS? Probably not, because you may still need to use it in standalone UVM. So you have a wrapper in PSS and reference the UVM function. But then how do you ensure someone doesn’t change the function in UVM and break the PSS dependency? Clearly you need careful configuration management here.)

On building reusable PSS libraries, he points out that the standard is too new to provide already a library of predefined types and other objects. Those will presumably come in time; for now he makes some suggestions on some basic types you should consider. For checking he suggests something that seems self-evident, but will no doubt require care in design. When you’re building checks for an IP, separate those that will be globally meaningful from those that only have local relevance. The global checks are the ones you will want to use at the SoC level.

The last and longest section is on reusable test realization. Here he suggests you first focus on a common API that can be reused at the SV level and at the C++ level. Mentor offers a Micro-Executor (UEX) API at the C-level to simplify this task. The goal of this package is to provide a standardized realization interface to memory management, interrupt handling and thread handling, with realizations for SV/UVM and C at bare-metal and OS levels. This makes sense to me – not trying to bridge the whole gap between hardware-driven and software-driven interfaces in a standard library but rather bridging part of that gap.

This is obviously a complex topic that can’t be boiled down to a short how-to guide, but this seems like a good starting point. You can download the white-paper HERE.


eSilicon’s Latest SerDes Solution is Here – And It Took A Village

eSilicon’s Latest SerDes Solution is Here – And It Took A Village
by Randy Smith on 07-22-2019 at 10:00 am

I recently watched a webinar given by eSilicon about its project to enhance its licensable solution for 56 and 112 Gigabit per second PAM4 & NRZ DSP-based SerDes family in 7nm. I am sure it was complicated enough to coordinate a webinar with a host, a moderator, and three different technical presenters – however when we are talking about 56 Gigabits per second and beyond in performance, in comparison, the webinar is as easy as a walk in the park. In some systems the number of SerDes lanes is approaching 300, system power is exploding, and legacy backplanes simply won’t work. This was never going to be easy.

Mike Gianfagna, eSilicon’s VP, Marketing was the host and opened the webinar. Dan Nenni of SemiWiki then acted as moderator and gave some opening comments. Following that was Al Neves, CTO of Wild River Technology, who was responsible for designing the test board to measure and deliver the needed performance and compliance.  Then came Matt Burns, Product Marketing Manager–High Speed for Samtec, who discussed what was done to deliver the required connectivity. After that was Tim Horel, Director of Field Applications from eSilicon, who talked about putting it all together with eSilicon’s SerDes. To wrap it up there was a Q&A session where I imagine not all questions could be handled during the webinar, but I would expect eSilicon, given their high customer service standards, to follow up on any remaining questions offline. Though the session was not short, it moved quite quickly given all the information to cover.

Wild River Technology implemented the test board design. Al Neves spoke about the challenges to be faced in this area. Al and Wild River are the world’s experts when it comes to signal and power integrity for high-speed designs. They have been delivering high-speed designs to many companies for a long time and they have not lost their touch. Moreover, prior experience with these exotic waveforms is critical to solving the challenges that come up in this area, especially if you intend to deliver on time. Clearly, Wild River Technology had delivered.

Samtec also brought a lot to the table. eSilicon had determined to build the core of the design around Samtec’s Bulls Eye® Test Point System. This advanced cabling solution met the necessary high signal and power integrity requirements. Importantly, Samtec and Wild River made a great team as the project required a close working relationship between the cable solution provider (Samtec) and the board designer (Wild River). Samtec’s models also proved to be quite accurate, enabling a more predictable schedule.

As Tim Horel got into the specifics of the project, including utilizing some ideas Al Neves had proposed on how to run the project to develop this solution, I must admit I was having a hard time keeping up. This stuff is simply hard. Experts are needed. It shows how semiconductor IP has accelerated the semiconductor market. Few companies, maybe none really, can have all the expertise in every area in-house. Buying or licensing proven IP is the best solution for both making schedule and staying under budget.

If this stuff interests you, or if you simply want to learn more about this bleeding-edge technology, the webinar replay, and a white paper is available by going here. eSilicon has edited down the replay to 30 minutes, so you can learn a lot with a small investment of time. The eSilicon product description of eSilicon’s 56G & 112G PAM4 & NRZ DSP-Based Long-Reach SerDes Family in 7nm can be found here. Interesting and educational – have fun!


Fairchild’s Death March

Fairchild’s Death March
by John East on 07-22-2019 at 6:00 am

Death of Fairchild

The “20 Questions with John East” series continues

How did it end for Fairchild?  Badly!!!

In 1966 Fairch was the number one supplier of integrated circuits.  That was as it should have been.  After all,  Fairch had invented the IC.  But in 1967 TI passed them.  Still, Fairch remained a strong #2.  By the time that the mid-seventies arrived,  though, they were fading.  Motorola and some others had passed them in sales by then. Fairch was clearly struggling and beginning to look like an acquisition target.

After some near-deals, Schlumberger bought Fairchild in 1979 for $425 million. Schlumberger was a very successful supplier to the oil and gas exploration industry.  Over the years I’ve been really impressed with the way they’ve done business, but in this instance their past successes led to a terminal case of hubris. They put Tom Roberts, a financial type with no experience as a CEO and no semiconductor background either, in charge.  He fared badly.  Very, very badly!!  The death march had begun! In 1985 Don Brooks, a well regarded TI executive, replaced Roberts as CEO, but the damage had already been done.  Revenues continued to decline. Eventually, Schlumberger decided to sell.  A Schlumberger spokesman explained,  “Silicon Valley ain’t the oil business!”   In came an offer from Fujitsu.  The offer was for only $245 million  – a small amount for a company with sales of $400 million annually,  but Fairch jumped at it.  Terms were agreed to  — all that remained was government approval.  It never came.  The US government refused to approve the deal arguing that the sale of a technology company to a foreign entity was not in the best interests of the United States.  In the end,  Fairch agreed to sell themselves to National Semiconductor at the shockingly low price of $122 million.  To put that in perspective, today TI is valued at $110 billion and Intel at $210 billion.   — at its death bed,  Fairchild was worth about 1/2000 the value of Intel today.

Fairchild started out as the king of the hill.  The darling of Wall Street. They ended up virtually worthless.

Note:  National spun out a “new” Fairchild in 1997.  It wasn’t the real Fairchild.  They got out of the traditional IC rat race and into new product categories.  Power devices. Power discretes. Power analog. High voltage. Opto couplers etc.  They were quite successful — this new “Fairchild” was a winner.  The new management did a wonderful job!!  But it was Fairchild in name only.  It wasn’t even close to “our Fairchild”. The traditional IC inventor and powerhouse Fairchild was dead.  It had died a slow and painful death. 

Why?  What happened?  In my view there were three major causes.

#1.  The exodus

Fairchild could never keep their most important people.  Not long after the invention of the integrated circuit, internal strife broke out between some of the traitorous eight.  The result was that four of them left in 1961 to found Amelco.  Then,  of course,  Moore and Noyce left in 1968 to found Intel.  The last of the eight to leave was Julius Blank in 1969.  You’d think that there would have been great fanfare.  There wasn’t.  One day he was just gone.

The real personnel pirate when I first got there, though, was National Semiconductor.  In 1966 Charlie Sporck left his job at Fairchild to head up National.  A short while later Charlie recruited a trio of top Faichild managers including Pierre Lamond.  (Pierre eventually became a huge success in the venture capital field.  Today he’s a partner at Eclipse Ventures.  Pierre is 88 years old,  but has a ton of energy!!) Over the next couple of years, many key managers and engineers left Fairchild to go to National.  So  —– Intel wasn’t public enemy number one when I got to Fairch  — National was.  But then Intel took their turn at raiding  —  and they did an excellent job of it!!  Volumes of wonderful engineers and scientists made the jump to Intel.  Eventually even AMD took a turn.  Jerry Sanders and John Carey, of course, had been fired when Les Hogan came in  — victims of “Off with their heads.”  They went on to found AMD and, I’d imagine, took great delight when their turn came.

The bottom line  — Fairchild just couldn’t hang on to their most important employees.  The key Fairchild engineers usually ended up making huge contributions.  —  But – not at Fairchild.

#2 MOS happened

Fairchild started out using bipolar transistor technology.  No surprise there. MOS was technically very conceivable in the early days, but in the real world it couldn’t be made profitably.  The potential benefits of MOS were known, but always just out of reach.

In those days Fairch didn’t really understand mobile ion contamination.  Or work functions.  Or surface states.  Or oxides.   To grossly oversimplify, no one knew how to control the thresholds which moved substantially during life test. You couldn’t reliably turn off N-channel transistors.   So  — MOS at Fairchild in the early days was P-channel.  And sadly,  P-channel MOS was slow! There was one beautiful thing, though.  PMOS was a five mask process.  PMOS wafers were really cheap and easy to make so long as you didn’t mind bad sort yields and slow, unreliable parts.

CMOS had been conceptualized,  but it seemed totally out of reach in those days. It was widely recognized at the Fairchild R&D facility in Palo Alto that there were solutions to these problems and that the upside of MOS (Particularly CMOS) greatly eclipsed that of bipolar.  The roadmap was pretty clear:    Get rid of the contamination. Make silicon gate work. Switch to CMOS. And finally, scale like crazy!!  Scaling helps MOS greatly but helps bipolar only a little.  The good news:  that roadmap was followed and the problems were solved.  The bad news:  It didn’t happen at Fairchild.  It happened at Intel. And AMI. And Micron. And Mostek. And many other companies.  But Fairchild never really succeeded on the MOS battleground.

Somewhere around 1974, though, Fairchild came up with a counter-punch.  The Isoplanar process.  A team working under Doug Peltzer developed a new process for making bipolar ICs.  The new process used oxide sidewall isolation instead of the traditional reverse-biased junctions.  That would make the die a lot smaller and the parasitic capacitance a lot lower if only they could get the yields to a respectable point.  After some tough battles with Iceo – the traditional bane of bipolar transistors — they did it.  Ergo  — faster and cheaper!!  By quite a bit! Isoplanar bipolar technology staved off the MOS hoards for probably ten years longer than would have been the case otherwise.  But the fabs kept scaling.  Two microns went to 1.2, then to 1.0, then .8 then .5 etc etc.  MOS kept getting better and better.  Bipolar couldn’t keep up.  Today for the most part bipolar is a thing of the past.

(Note:  I was a bipolar transistor circuit designer.  Guess that explains why I’m having such a hard time getting a job.)

#3.  Product planning

In the late 90s we hired a consulting company at Actel.  (Name withheld to protect the guilty.)  After the normal lengthy and expensive consulting process, the consultants concluded that Actel was too focused on products. I grudgingly accepted that at the time, but I was wrong.  The fact was, we weren’t focused enough on products.  In the non-commodity IC world, your product is all that matters.  Branding works well for Apple!!  People will go out and buy a product just because it’s an Apple product.  But, when you’re selling to Cisco, what they want is the best product for the job they’re trying to do.  What does this have to do with Fairchild?  Fairchild never put together a product planning system that really worked.  Other than Isoplanar bipolar memories and a relatively small line of ECL products, they never seemed to innovate products that customers needed.

Proof of that came when Schlumberger took over Fairchild.  They put a ton of capital into the company —  rumors had it that Schlumberger invested the better part of a billion dollars after they bought the company.   They bought better fab equipment and better testers.  They improved their assembly lines. They also put more money into marketing and selling.  But they didn’t have a significant product that the world needed.  The capital spending was to no avail.  Sales didn’t rise at all.  In fact, they fell.  No good products – no sales!

Long story short?  Fairchild invented the integrated circuit and kicked off an industry that today hovers at around $400 billion annually.  They were at the root of the creation of probably hundreds of successful companies and many thousands of millionaires.  Along the way they helped create probably a few dozen billionaires as well.  But,  when the dust settled,  Fairchild  had failed.  They were worth next to nothing and the dregs that had some minuscule value lay in the hands of their once most despised competitor.

And Sherman Fairchild turned over in his grave.

Next week:  AMD and some Jerry Sanders stories.  (TJ Rodgers too!!)

See the entire John East series HERE.


Great, early signs of a recovery in logic, not memory

Great, early signs of a recovery in logic, not memory
by Robert Maire on 07-21-2019 at 12:00 pm

A “Logic Lead” recovery confirmed- Memory still mired, 3400C = “Third times a charm”. EUV finally accelerates as all ducks now in a row.

ASML posted a good quarter with great orders and capped off with a strong outlook for the current quarter.  Logic demand is sparking a recovery while memory remains essentially dead in the water.

ASML reported EUR2.6B in sales and EUR1.13EPS easily beating street earnings estimates even though revenue was in line. More importantly, guidance is for Q3 revenues of EUR3.0B with GM of 43-44%. Logic was a strong 61% of business, doubling from earlier levels. Memory demand which was expected to be down 20% is now expected to be down 30%.  Bookings were EUR2.8B and 10 EUV systems. Two thirds of bookings were for logic.

Logic comes to life first ….. Memory still dead

In our note last week, from Semicon West, we said that logic would likely lead the recovery, lead by 5G demand, while memory will remain dead for the foreseeable future. That is exactly what ASML said today.  ASML’s report is proof of our view of a different kind of recovery and a new normal of weaker memory.

ASML said that memory is now expected to be down 30% rather than the earlier 20% which suggests it may get worse before it gets better.

We had suggested that 5G would be the tip of the spear of a logic lead recovery and ASML also pointed out 5G as the driver of new technology nodes. (maybe ASML is reading our notes…)

3400C – Alpha, Beta now “production”….

“Third times a Charm”

We think that aside from the view that EUV is finally accelerating in the market, ASML finally, coincidentally has a tool thats truly ready for prime time and that is the 3400C.

The first 3400 version was likely more of an “alpha” stage tool, followed by an improved “beta” tool and now the 3400C has incorporated many fixes and improvements that make it a true “production” tool that customers can use in high volume production.  The increase in orders seems to support this view and customers we have spoken to seem to view the 3400C as a production ready tool that has key, needed improvements.  Its likely that this version could turn out to be a big seller.

It seems to us that EUV now has most all of its ducks in a row to accelerate into production.  This does not mean that there isn’t a ton of work still to be done but we think its safe to plow ahead and go into full production as we are past the point of no return.

A longer, deeper, memory downturn???

We think there is one very key piece of evidence that points to a deeper and different memory down cycle compared to prior down cycles.  In prior downturns, memory makers just idled in place, turning out chips waiting until demand picked up to suck up excess capacity and restore the supply/demand imbalance thus restoring pricing.

This cycle is very different in that memory makers are actively cutting wafer starts to artificially reduce supply to try to bring back a supply/demand balance rather than hope that demand recovers.

This means that memory makers will have a lot of idle semiconductor equipment sitting in their fabs turned off, wafer for memory demand to get back in balance.  It also means that memory makers will have a lot of excess capacity sitting off line that can be brought on line very quickly which could further dampen a recovery.  It also means that it will take, much, much longer for memory makers to start buying capacity related tools as they already are sitting on idle tools.  We would point out that this is not necessarily true of litho purchases as litho purchases are technology driven, not capacity driven as the memory industry looks at transitioning to EUV at some point in the future unrelated to the glut in capacity.

Winners are different in a logic led recovery

As we clearly pointed out in last weeks note, a logic led recovery does not equally raise all boats in the semiconductor equipment industry. Lam is the poster child of the memory industry spending spree, followed not too far behind by Applied.  ASML is clearly the leading indicator of logic as EUV isn’t currently used in memory (even though ASML still sells a lot of DUV tools into memory). KLA has historically been a logic/foundry house that closely follows the litho lead into new geometries.

Just as important we would point out the timing differences.  ASML has lead times of up to 18 months on EUV systems while process equipment makers tend to be a “turns” business. This means that the orders being seen currently by ASML may not be seen by Lam or Applied for another year, until the litho systems get installed and working.  KLA will likely slightly lag ASML tools as KLA also has longer lead times and you need to get your process worked out before you order a lot of process tools to fill out the fab.

The bottom line is that this early ASML, logic driven recovery does not immediately translate into better business for all in the equipment industry….but its not a bad omen…its a good start.

The stocks

We think this news is more ASML specific but will obviously have some positive collateral impact across the chip sector. The good ASML news is coupled with the somber fact that memory still sucks and the Sword of Damocles that is China trade is still swinging over the industry’s heads.  Given that 5G is both at the center of the logic recovery and the center of the Huawei dispute makes for an interesting dynamic.

In general, we would want to be long ASML and KLAC while potentially flat or short LRCX and AMAT. This could be an interesting “pair trade”.  ASML said in essence that their view of memory had deteriorated from down 20% to down 30% and that type of report would certainly be a net negative for AMAT and LRCX in their upcoming earnings.