SemiWiki – Page 583 – The Open Forum for Semiconductor Professionals

February 9, 2017

Intel Alternative Facts!

Intel Alternative Facts!
by Robert Maire on 02-09-2017 at 12:00 pm
Categories: Foundries, Intel Foundry, Semiconductor Advisors, Semiconductor Services

Brian Krzanich, CEO of Intel, announced a $7B investment in Fab 42 in Arizona in the oval office, next to Trump as evidence of a positive reaction to Trump’s new policies.

Alternative fact; Paul Otellini, then Intel’s CEO, made a similar promise about Fab 42 in the company of Obama in 2011, during a visit to Hillsboro, Oregon.

BK said that it would bring 3,000 new Intel jobs to Arizona as the states largest private employer. BK further said that these were not jobs returning to the US from overseas but that Intel was all about “growth”

Alternative fact; If you add the 3,000 jobs that may be hired in the future for Fab 42, to the 12,000 or so that Intel reduced last year, Intel is still negative 9,000 jobs…AKA “negative growth”

There was no mention, in the oval office, of the H1B visa program in which Intel joined with a 100 other silicon valley companies, this past weekend, to sue the government over.

Alternative fact; Intel asked the government for 14,523 H1B visas and green cards for foreign workers between 2010-2015 the years leading up to the 12,000 employee reduction of US workers following those additions.

Failed dinner consolation prize…
Perhaps the oval office photo op and announcement was done to make up for BK first setting up a dinner at his home for then candidate Donald Trump then being forced to cancel it due to the outcry in silicon valley. BK as one of the few Trump supporters in the valley will be expecting some payback in the form of tax and regulatory easements that were hinted at during the announcement today.

Fab 42’s long rumored resurrection…
After being put in “mothballs” several years ago it was only a matter of time before an appropriate use would be found at an appropriate time. With 10NM firmly in Israel it makes Fab 42 an easy choice for 7NM. When you add to the decision making process and the advent of EUV tools at 7NM or 5NM which require boatloads of electrical power along with gigantic, very expensive cranes to hoist the huge tools into the Fab, the only place that makes sense is Fab42 for 7NM. So the reality is that this was going to happen any way but Intel wanted to get some free political capital out of it

When is a dollar not a dollar? When its part of Intel’s CAPEX plan….
We have heard from many suppliers and tool makers in the semiconductor industry that are wondering who is getting all of the alleged spending on CAPEX from Intel. The numbers just don’t seem to add up. Intel’s announced CAPEX over the last couple of years does not seem to be proportionately translating into dollars spent at suppliers. Its almost as if $1 announced by Intel translates into 50 cents spent in real money. Its almost impossible to accurately measure this but our anecdotal evidence points to less spending than announced. Part of this may be “sandbagging” by management to make it easier for Intel to hit its financial targets but even still there’s a mismatch.

We have heard from a number of suppliers in the industry that Intel is not only no longer number one in spending, a title it lost long ago, but doesn’t even make it into the top 3 or 4 spenders anymore at many vendors.

Not all $7B goes to the US…
Given that the bricks and mortar are all done at Fab 42 and all that is needed is equipment move in we can assume that the $7B is all equipment. If we subtract spend on ASML, TEL, Hitachi and all other foreign vendors its likely that less than $5B actually “stays” in the US

Intel probably still spends more overseas than in the US on CAPEX…
If we look at Intel’s global footprint of fabs, especially the near term spend in Israel and China, the $7B spend in Fab 42 , especially when spread over several years it is in the minority. I am sure that BK could stand next to China’s Xi Jinping, in the equivalent of their oval office in China, for a similar photo op and claim a similar, if not larger amount of money that will be spent and jobs that will be created for memory production in China by Intel. We are also sure that Intel got some sweet political deals there as well…..

Intel the stock…
We view today’s announcement as not impactful either way for shareholders of the company, but we do applaud Intel’s ability to work both political sides of China versus U.S. and H1B versus foreigner bans. Intel hasn’t given up anything it would not have done anyway and in return it gets an IOU with Trump at a time when silicon valley is in open revolt against the new administration.

Maybe BK read “The art of the deal”…..

February 9, 2017June 14, 2019

Notes from the Neural Edge

Notes from the Neural Edge
by Bernard Murphy on 02-09-2017 at 7:00 am
Categories: Automotive, Cadence, IoT, IP, Mobile

Cadence recently hosted a summit on embedded neural nets, the second in a series for them. This isn’t a Cadence pitch but it is noteworthy that Cadence is leading a discussion on a topic which is arguably the hottest in tech today, with this range and expertise of speakers (Stanford, Berkeley, ex-Baidu, Deepscale, Cadence and more), and drawing at times a standing room only crowd. It’s encouraging to see them take a place at the big table; I’m looking forward to seeing more of this.

This was an information-rich event so I can only offer a quick summary of highlights. If you want to dig deeper Cadence has said that they will post the slides within the next few weeks. The theme was around embedding neural nets in the edge – smartphones and IoT devices. I talked about this in an earlier blog. We can already do lots of clever recognition in the cloud and we do training in the cloud. But, as one speaker observed, inference needs to be on the edge to be widely useful; value is greatly diminished if you must go back to the cloud for each recognition task. So the big focus now is on embedded applications, particularly in vision, speech and natural language (I’ll mostly use vision applications as examples in the rest of the blog). Embedded application creates new challenges because it needs to be much lower power, it needs to run fast on limited resources and it must be much more accessible to a wide range of developers.

One common theme was need for greatly improved algorithms. To see why, understand that recent deep nets can have ~250 layers. In theory each node in each layer requires a multiply-accumulate (MAC) and the number of these required per layer may not be dramatically less than the number of pixels in an image. Which means you’ll need to process at billions of MACs per second in a naïve implementation. But great progress is being made. Several speakers talked about sparse matrix handling; many/most (trained) weights for real recognition are zero so all those operations can be skipped. And training downloads/update sizes can be massively reduced.

Then there’s operation accuracy. We tend to think that more is always better (floating point, 64 bit), especially in handling images, but apparently that has been massive overkill. Multiple speakers talked about weights as fixed-point numbers and most were getting down to 4-bit sizes. You might think this creates massive noise in recognition but it seems that incremental accuracy achieved above this level is negligible. This is supported empirically and to some extent theoretically. One speaker even successfully used ternary weights (-1, 0 and +1). These improvements further reduce power and increase performance.

Another observation was that general-purpose algorithms are often the wrong way to go. General-purpose may be easier in implementation, but some objectives can be much better optimized if tuned to an objective. A good example is image segmentation – localizing a lane on the road, or a pedestrian, or a nearby car. For (automotive) ADAS applications the goal is to find bounding boxes, not detailed information about an object, which can make recognition much more efficient. Incidentally, you might think optimizing power shouldn’t be a big deal in a car, but I learned at this summit that one current autonomous system fills the trunk of a BMW with electronics and must cool down after 2 hours of driving. So I guess it is a big deal.

What is the best platform for neural nets as measured by performance and power efficiency? It’s generally agreed that CPUs aren’t in the running, GPUs and FPGAs do better but are not as effective as DSPs designed for vision applications, DSPs tuned to vision and neural net applications do better still. And as always, engines custom-designed for NN applications outperform everything else. Some of these can get interesting. Kunle Olokotun, a professor at Stanford presented a tiled interleaving of memory processing units and pattern processing units as one approach, but of course custom hardware will need to show compelling advantages outside research programs. Closer to volume applications, Cadence showed several special capabilities they have added to their Vision P6 DSP, designed around minimizing power per MAC, minimizing data movement and optimizing MACs per second.

Another problem that got quite a bit of coverage was software development productivity and building a base of engineers skilled in this field. Google, Facebook and similar companies can afford armies of PhDs, but that’s not a workable solution for most solution providers. A lot of work is going into democratizing recognition intelligence through platforms and libraries like OpenCV, Vuforia and OpenVX. Stanford is working on OptiML to intelligently map from parallel patterns in a re-targetable way onto different underlying hardware platforms. As for building a pool of skilled graduates, that one seems to be solving itself. In the US at least, Machine Learning is apparently the fastest-growing unit in undergraduate CS programs.

Pixel explosion in image sensors

AI was stuck for a long time in cycles of disappointment where results never quite rose to expectations, but neural nets have decisively broken out of that trap, generally meeting or exceeding human performance. Among many examples, automated recognition is now detecting skin cancers with the same level of accuracy as dermatologists with 12 years training and lip-reading solutions (useful when giving commands in a noisy environment) are detecting sentences at better than 90% accuracy, compared to human lip-readers at ~55%. Perhaps most important, recognition is now going mainstream. Advanced ADAS features such as lane control and collision-avoidance already depend on scene segmentation. Meanwhile the number of image sensors already built surpasses the number of people in the world and is growing exponentially, implying that automated recognition of varying types must be growing at similar speeds. Neural net-based recognition seems to have entered a new and virtuous cycle, driving rapid advances of the kind listed here and rapid adoption in the market. Heady times for people in this field.

You can learn more about Cadence vision solutions HERE.

FPGA Design Gets Real

FPGA Design Gets Real
by Tom Simon on 02-08-2017 at 12:00 pm
Categories: EDA, FPGA, Synopsys

FPGA’s have become an important part of system design. It’s a far cry from how FPGA’s started out – as glue logic between discrete logic devices in the early days of electronic design. Modern day FPGA’s are practically SOC’s in their own right. Frequently they come with embedded processor cores, sophisticated IO cells, DSP, video, audio and other types of specialized processing cores. All of this makes them suitable, even necessary, for building major portions of systems products.

Early FPGA’s were tiny compared with their contemporaneous ASIC’s. The tools for implementing designs were often cobbled together by the FPGA vendors themselves, or there were a few commercial offerings that offered advantages over the vendor specific solutions. Nevertheless, these tools always took a back seat in terms of capacity, performance and sophistication when compared to the synthesis, and place and route flows for custom ASIC’s.

In today’s market, the previous generation of FPGA tools would not stand a chance. Requirements and expectations are much higher. Good thing there has been significant innovation here. Actually, it’s astounding how far FPGA tools have come.

I was reading a white paper published by Synopsys that delves into the state of the art for FPGA design. It makes a good read. It is written by Joe Mallett, Product Marketing Manager at Synopsys for FPGA design. The title is “Shift Left Your FPGA Design for Faster Time to Market”.

Just as is true for ASIC’s, FPGA designs rely a lot on 3rd party IP. These come with RTL and constraint files. FPGA tools need to digest these easily. The same is true for application specific RTL and constraints developed on a per project basis. FPGA’s also have evolved complex clock structures – in large part to meet the power and performance requirements for the designs they are used on. Designers need tools that easily handle multicycle and false path definition.

Once the baseline design specification is in place, the design can move to First Hardware. While it is certain to not meet all the performance requirements of the final design, it is a significant milestone that leads to further optimization heading toward the final deliverable.

In the Synopsys White Paper, Joe talks at length about the ways their Synplify tool can accelerate each step in the FPGA design flow. The initial step being getting to First Hardware. Joe discusses initial design set up and mentions acceleration of synthesis through automatic partitioning and execution with mutli-core and/or compute farm compute resources. There are a lot of benefits in this approach, from lower per machine memory footprint to incremental design.

The next milestone is debug. Synopsys has developed extremely clever ways of adding high design visibility, which greatly accelerates debug. What’s even better, and is a unique advantage of FPGA’s is that the debug can run in real-time and at-speed, in the system level environment. The incremental design capabilities shorten turnaround time at this stage too.

Last we are left with tuning and optimization. Not surprisingly the means to accomplish this are at every stage of the design process. Highly optimized timing needs to be coupled with design size optimization. Synthesis, placement and routing all play a role in the final outcome. Rather than spoil the details, I recommend reading the white paper here. There is also companion paper on distributed synthesis in Synopsys’ Synplify FPGA design tool that I found very interesting.

February 8, 2017

Machine Learning for Dummies

Machine Learning for Dummies
by Kartik Hosanagar on 02-08-2017 at 7:00 am
Categories: General
1 Comment

I write a lot about data-driven algorithms, in particular those informed by Machine Learning. I thought it would be nice to give the low-down on machine learning for the uninitiated. Below, I discuss four essential questions. The answers are based, in part, from a recent discussion with Pedro Domingos, author of The Master Algorithm.

1. Should we care about artificial intelligence and machine learning?
Machine learning and AI touch your life every minute of every day, from applications you use at work to how you choose products to buy (Amazon recommendations). Even who you marry or date (Match.com, Tinder recommendations). A third of all marriages start on the internet and the matches are created by algorithms. As a citizen, consumer, and professional, you don’t need the the gory details of how machine learning works, but you do need the big picture.

2. What’s the distinction here between AI and Machine Learning?
AI means getting computers to do all the things that it takes human intelligence to do like reasoning, understanding language and the visual world, navigating, and manipulating objects. Machine learning is a sub-field of AI that deals with the ability to learn. Learning is the one thing that underlies all the others. If you had a robot that was as good as humans at everything, but couldn’t learn, five minutes later it would have fallen behind.

3. Let’s look at the history of AI – how did we get here, and what was the most important turning point?
If we rewind back to the early days of the field, one of the interesting aspects was that the field got named artificial intelligence. The runner up was complex information processing, which of course sounds incredibly boring. Calling it AI made it extremely ambitious which has been partly responsible for a lot of the progress. At the same time, it also created these very inflated expectations which were premature. Intelligence seems like an easier problem than it really is because we are intelligent, and we take it for granted. But evolution spent 500 Million years making us intelligent.

People believed that the way to really build intelligent systems was to have them learn. Initially both the understanding of the problem and the computing resources were not up to the test. Your brain is the best supercomputer on earth and people were trying to do this through the computers that they had back then. They ran a little bit ahead of themselves. In the eighties, there was a shift towards so-called knowledge systems. In these systems, you provide the system as much knowledge as possible. This allowed systems to do seemingly intelligent things like play chess and diagnose diseases. But the moment the system encountered a situation outside the knowledge base, the system failed. In the end, the systems were too brittle. They didn’t learn.

Then, what happened led to the present explosion of AI. People went back and said that learning is actually essential — we’re never going to be able to have intelligence without learning. Within learning, the most recent success is based on algorithms that emulate the brain on tasks like vision and speech recognition (techniques known as neural networks and deep learning).

4. What does a machine learning algorithm “look” like?
There isn’t just one algorithm. We have many algorithms and approaches today – based on statistical approaches (e.g. Bayesian learning), evolutionary techniques (genetic algorithms), logical induction (association rules) and approaches that mimic the brain (neural nets). No one algorithm is good at everything. In practice, one chooses from these. The question is whether there is a master algorithm that can learn an infinite variety of things. That’s a separate topic I’ll discuss in the future and that Pedro discusses in detail in his book.

–Kartik Hosanagar is a Professor of Technology & Digital Business at The Wharton School.

February 7, 2017

Scott Jones ISS Talk – Moore’s Law Lives!

Scott Jones ISS Talk – Moore’s Law Lives!
by Scotten Jones on 02-07-2017 at 12:00 pm
Categories: Events, Foundries

I was invited to give a talk at this year’s ISS conference, the talk seemed to be very well received and I was asked to blog about it for SemiWiki. Parts of the talk will be familiar to SemiWiki readers from some of my previous blogs but I also went into more detail around some scaling challenges. The following is a summary of what I presented.
Continue reading “Scott Jones ISS Talk – Moore’s Law Lives!”

February 7, 2017November 20, 2019

Aspirational Congruence

Aspirational Congruence
by Bernard Murphy on 02-07-2017 at 7:00 am
Categories: Cadence, EDA, Prototyping

When talking to suppliers about their products, conversation tends to focus heavily on what they already have and why it is the answer to every imaginable need in their space. So it’s refreshing when a vendor wants to talk about where customers want to go without claiming they already have the answer wrapped up in a bow. I recently had such a conversation with Frank Schirrmeister of Cadence on the topic of congruence in hardware modeling through the ever-squeezed hardware and software development cycle.

The root of the problem is well-known – product teams are aggressively compressing development cycles to meet fast-moving market windows. One especially long pole in this effort is getting software ready as soon as possible after silicon. Virtual prototyping is a great way to accelerate development of higher-level software, but when you get closer to the hardware or you need to check performance, you have to turn to hardware modelling on emulation or prototyping systems.

There’s no question that simulation still plays a dominant role in hardware development and verification, but it is wildly impractical as a platform for developing/verifying software. Simulation also struggles with debug and regression in big, long and complex tests, particularly when trying to isolate root-cause problems over millions or billions of cycles. This is why emulation, running orders of magnitude faster than simulation, has become so popular. Emulation doesn’t compile as fast as simulation but at 140-150M gates compiling/hour, you can get 5-6 turns a day, making this approach a practical alternative even in relatively early stages of system development.

When it comes to software development and validation, emulation is arguably the best platform for bare-metal software (firmware and drivers for example) but is far too slow to practically support develop/debug cycles in middleware. That’s where you want to use FPGA prototypes which can run at least another order of magnitude faster and be able to develop/debug in the context of a larger system. This is closer to the expectations of software developers who want to work with what Frank calls “cup of coffee interactivity” – they’re OK to go for a cup of coffee wait for a run to complete, but they’re not OK with having to wait until the next day.

All of this is great, but how does it help software developers start earlier? FPGA prototypes are fast but bringup can take weeks, not an investment you want to make when the design micro-architecture is still being refined. So is early software development a Catch-22? Not if you have emulation/prototyping congruence. Imagine if, starting from an emulation build, prototype bringup could be reduced to a push-button step which would complete in limited time (perhaps a few days) and cycle-level correspondence could be guaranteed between emulation and prototype behavior, then software developers could start much earlier, even at mid-stage RTL. After all they don’t care about detailed hardware behavior (and especially not hardware debug), they just need enough to get started.

This goal is partly achieved today and partly aspirational. Congruence in modeling behavior is already available at cycle-level accuracy and RTL compile is already common between the two platforms. You want clock-tree transformation, gated clock handling and partitioning to the prototype to be transparent, which is largely in place today. But the back-end flow, into Vivado P&R for Protium, still requires some hands-on involvement which could be greatly reduced or even eliminated with maybe some compromise in modeling performance. For a software developer who doesn’t want to or need to know about FPGA tooling, this may completely be acceptable for early software validation/development. And reuse of previously compiled partitions/blocks with hands-free dependency management can further reduce compile times.

So to recap, the aspiration is to be able to start software development and validation while the RTL for the design is still in some level of flux. To do this it is essential to have congruence between emulation and prototyping, in setup and in modeling. Prototype setup should approach a push-button step given a functioning emulation and should compile as fast as possible (within as little as a day if feasible) to support software development staying nearly in sync with hardware evolution. And in modeling the models the hardware team and the software team are using should be congruent in behavior.

Some of this stuff is aspirational, some is already covered in Cadence prototyping (see here), however I’m sure Frank didn’t share this with me simply to admire the problem. I expect that Cadence is cooking more solutions to congruence as I write. For more info, watch for news in this area from Cadence.

On a final note, I chose the title of this piece partly because I thought it would make a great German compound-word, Aspirierendkongruenz as near as I can tell, based on Google translate (Frank can comment). Idle play of an idle mind.

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