Mediaboss Marketing

It is much easier to apologize than it is to get permission.

jamesnoellert.com

The hacking culture has been the lifeblood of software engineering long before the move fast and break things mantra became ubiquitous of tech startups [1, 2]. Computer industry leaders from Chris Lattner [3] to Bill Gates recount breaking and reassembling radios and other gadgets in their youth, ultimately being drawn to computers for their hackability. Silicon Valley itself may have never become the worlds innovation hotbed if it were not for the hacker dojo started by Gordon French and Fred Moore, The Homebrew Club.

Computer programmers still strive to move fast and iterate things, developing and deploying reliable, robust software by following industry proven processes such as test-driven development and the Agile methodology. In a perfect world, programmers could follow these practices to the letter and ship pristine software. Yet time is money. Aggressive, business-driven deadlines pass before coders can properly finish developing software ahead of releases. Add to this the modern best practices of rapid-releases and hot-fixing (or updating features on the fly [4]), the bar for deployable software is even lower. A company like Apple even prides itself by releasing phone hardware with missing software features: the Deep Fusion image processing was part of an iOS update months after the newest iPhone was released [5].

Software delivery becoming faster is a sign of progress; software is still eating the world [6]. But its also subject to abuse: Rapid software processes are used to ship fixes and complete new features, but are also used to ship incomplete software that will be fixed later. Tesla has emerged as a poster child with over the air updates that can improve driving performance and battery capacity, or hinder them by mistake [7]. Naive consumers laud Tesla for the tech-savvy, software-first approach theyre bringing to the old-school automobile industry. Yet industry professionals criticize Tesla for their recklessness: A/B testing [8] an 1800kg vehicle on the road is slightly riskier than experimenting with a new feature on Facebook.

Add Tesla Autopilot and machine learning algorithms into the mix, and this becomes significantly more problematic. Machine learning systems are by definition probabilistic and stochastic predicting, reacting, and learning in a live environment not to mention riddled with corner cases to test and vulnerabilities to unforeseen scenarios.

Massive progress in software systems has enabled engineers to move fast and iterate, for better or for worse. Now with massive progress in machine learning systems (or Software 2.0 [9]), its seamless for engineers to build and deploy decision-making systems that involve humans, machines, and the environment.

A current danger is that the toolset of the engineer is being made widely available but the theoretical guarantees and the evolution of the right processes are not yet being deployed. So while deep learning has the appearance of an engineering profession it is missing some of the theoretical checks and practitioners run the risk of falling flat upon their faces.

In his recent book Reboot AI [10], Gary Marcus draws a thought provoking analogy between deep learning and pharmacology: Deep learning models are more like drugs than traditional software systems. Biological systems are so complex it is rare for the actions of medicine to be completely understood and predictable. Theories of how drugs work can be vague, and actionable results come from experimentation. While traditional software systems are deterministic and debuggable (and thus robust), drugs and deep learning models are developed via experimentation and deployed without fundamental understanding and guarantees. Too often the AI research process is first experiment, then justify results. It should be hypothesis-driven, with scientific rigor and thorough testing processes.

What were missing is an engineering discipline with principles of analysis and design.

Before there was civil engineering, there were buildings that fell to the ground in unforeseen ways. Without proven engineering practices for deep learning (and machine learning at large), we run the same risk.

Taking this to the extreme is not advised either. Consider the shift in spacecraft engineering the last decade: Operational efficiencies and the move fast culture has been essential to the success of SpaceX and other startups such as Astrobotic, Rocket Lab, Capella, and Planet.NASA cannot keep up with the pace of innovation rather, they collaborate with and support the space startup ecosystem. Nonetheless, machine learning engineers can learn a thing or two from an organization that has an incredible track record of deploying novel tech in massive coordination with human lives at stake.

Grace Hopper advocated for moving fast: That brings me to the most important piece of advice that I can give to all of you: if you've got a good idea, and it's a contribution, I want you to go ahead and DO IT. It is much easier to apologize than it is to get permission. Her motivations and intent hopefully have not been lost on engineers and scientists.

[1] Facebook Cofounder Mark Zuckerberg's "prime directive to his developers and team", from a 2009 interview with Business Insider, "Mark Zuckerberg On Innovation".

[2] xkcd

[3] Chris Lattner is the inventor of LLVM and Swift. Recently on the AI podcast, he and Lex Fridman had a phenomenal discussion:

[4] Hotfix: A software patch that is applied to a "hot" system; i.e., a fix to a deployed system already in use. These are typically issues that cannot wait for the next release cycle, so a hotfix is made quickly and outside normal development and testing processes.

[5]

[6]

[7]

[8] A/B testing is an experimental processes to compare two or more variants of a product, intervention, etc. This is very common in software products when considering e.g. colors of a button in an app.

[9] Software 2.0 was coined by renowned AI research engineer Andrej Karpathy, who is now the Director of AI at Tesla.

[10]

[11]

Read the rest here:
Machine Learning Is No Place To Move Fast And Break Things - Forbes

Microsoft has announced a new application, Dynamics 365 Project Operations, as well as additional AI-driven features for its Dynamics 365 range.

If you are averse to buzzwords, look away now. Microsoft Business Applications President James Phillips announced the new features in a post which promises AI-driven insights, a holistic 360-degree view of a customer, personalized customer experiences across every touchpoint, and real-time actionable insights.

Dynamics 365 is Microsofts cloud-based suite of business applications covering sales, marketing, customer service, field service, human resources, finance, supply chain management and more. There are even mixed reality offerings for product visualisation and remote assistance.

Dynamics is a growing business for Microsoft, thanks in part to integration with Office 365, even though some of the applications are quirky and awkward to use in places. Licensing is complex too and can be expensive.

Keeping up with what is new is a challenge. If you have a few hours to spare, you could read the 546-page 2019 Release Wave 2 [PDF] document, for features which have mostly been delivered, or the 405-page 2020 Release Wave 1 [PDF], about what is coming from April to September this year.

Many of the new features are small tweaks, but the company is also putting its energy into connecting data, both from internal business sources and from third parties, to drive AI analytics.

The updated Dynamics 365 Customer Insights includes data sources such as demographics and interests, firmographics, market trends, and product and service usage data, says Phillips. AI is also used in new forecasting features in Dynamics 365 Sales and in Dynamics 365 Finance Insights, coming in preview in May.

Dynamics 365 Project Operations ... Click to enlarge

The company is also introducing a new application, Dynamics 365 Business Operations, with general availability promised for October 1 2020. This looks like a business-oriented take on project management, with the ability to generate quotes, track progress, allocate resources, and generate invoices.

Microsoft already offers project management through its Project products, though this is part of Office rather than Dynamics. What can you do with Project Operations that you could not do before with a combination of Project and Dynamics 365?

There is not a lot of detail in the overview, but rest assured that it has AI-powered business insights and seamless interoperability with Microsoft Teams, so it must be great, right? More will no doubt be revealed at the May Business Applications Summit in Dallas, Texas.

Sponsored: Detecting cyber attacks as a small to medium business

Excerpt from:
Buzzwords ahoy as Microsoft tears the wraps off machine-learning enhancements, new application for Dynamics 365 - The Register

The report on the global machine learning as a service market provides qualitative and quantitative analysis for the period from 2016 to 2024. The report predicts the global machine learning as a service market to grow with a CAGR of 38.

New York, Feb. 20, 2020 (GLOBE NEWSWIRE) -- Reportlinker.com announces the release of the report "Machine Learning as a Service Market: Global Industry Analysis, Trends, Market Size, and Forecasts up to 2024" - https://www.reportlinker.com/p05751673/?utm_source=GNW 5% over the forecast period from 2018-2024. The study on machine learning as a service market covers the analysis of the leading geographies such as North America, Europe, Asia-Pacific, and RoW for the period of 2016 to 2024.

The report on machine learning as a service market is a comprehensive study and presentation of drivers, restraints, opportunities, demand factors, market size, forecasts, and trends in the global machine learning as a service market over the period of 2016 to 2024. Moreover, the report is a collective presentation of primary and secondary research findings.

Porters five forces model in the report provides insights into the competitive rivalry, supplier and buyer positions in the market and opportunities for the new entrants in the global machine learning as a service market over the period of 2016 to 2024. Further, IGR- Growth Matrix gave in the report brings an insight into the investment areas that existing or new market players can consider.

Report Findings1) Drivers Increasing use in cloud technologies Provides statistical analysis along with reduce time and cost Growing adoption of cloud based systems2) Restraints Less skilled personnel3) Opportunities Technological advancement

Research Methodology

A) Primary ResearchOur primary research involves extensive interviews and analysis of the opinions provided by the primary respondents. The primary research starts with identifying and approaching the primary respondents, the primary respondents are approached include1. Key Opinion Leaders associated with Infinium Global Research2. Internal and External subject matter experts3. Professionals and participants from the industry

Our primary research respondents typically include1. Executives working with leading companies in the market under review2. Product/brand/marketing managers3. CXO level executives4. Regional/zonal/ country managers5. Vice President level executives.

B) Secondary ResearchSecondary research involves extensive exploring through the secondary sources of information available in both the public domain and paid sources. At Infinium Global Research, each research study is based on over 500 hours of secondary research accompanied by primary research. The information obtained through the secondary sources is validated through the crosscheck on various data sources.

The secondary sources of the data typically include1. Company reports and publications2. Government/institutional publications3. Trade and associations journals4. Databases such as WTO, OECD, World Bank, and among others.5. Websites and publications by research agencies

Segment CoveredThe global machine learning as a service market is segmented on the basis of component, application, and end user.

The Global Machine Learning As a Service Market by Component Software Services

The Global Machine Learning As a Service Market by Application Marketing & Advertising Fraud Detection & Risk Management Predictive Analytics Augmented & Virtual Reality Security & Surveillance Others

The Global Machine Learning As a Service Market by End User Retail Manufacturing BFSI Healthcare & Life Sciences Telecom Others

Company Profiles IBM PREDICTRON LABS H2O.ai. Google LLC Crunchbase Inc. Microsoft Yottamine Analytics, LLC Fair Isaac Corporation. BigML, Inc. Amazon Web Services, Inc.

What does this report deliver?1. Comprehensive analysis of the global as well as regional markets of the machine learning as a service market.2. Complete coverage of all the segments in the machine learning as a service market to analyze the trends, developments in the global market and forecast of market size up to 2024.3. Comprehensive analysis of the companies operating in the global machine learning as a service market. The company profile includes analysis of product portfolio, revenue, SWOT analysis and latest developments of the company.4. IGR- Growth Matrix presents an analysis of the product segments and geographies that market players should focus to invest, consolidate, expand and/or diversify.Read the full report: https://www.reportlinker.com/p05751673/?utm_source=GNW

About ReportlinkerReportLinker is an award-winning market research solution. Reportlinker finds and organizes the latest industry data so you get all the market research you need - instantly, in one place.

__________________________

Story continues

Clare: clare@reportlinker.comUS: (339)-368-6001Intl: +1 339-368-6001

Read more here:
Global machine learning as a service market is expected to grow with a CAGR of 38.5% over the forecast period from 2018-2024 - Yahoo Finance

To print this article, all you need is to be registered or login on Mondaq.com.

This article is the second in a five-part series. Each of thesearticles relates to the state of machine-learning patentability inthe United States during 2019. Each of these articles describe onecase in which the PTAB reversed an Examiner's Section-101rejection of a machine-learning-based patent application'sclaims. The first article of thisseries described the USPTO's 2019 Revised Patent Subject Matter Eligibility Guidance (2019PEG), which was issued on January 7, 2019. The 2019 PEG changed theanalysis provided by Examiners in rejecting patents under Section 1011 of thepatent laws, and bythe PTAB in reviewing appeals from theseExaminer rejections. The first article of this series alsoincludes a case that illustrates the effect of reciting AIcomponents in the claims of a patent application. The followingsection of this article describes another case where the PTABapplied the 2019 PEG to a machine-learning-based patent andconcluded that the Examiner was wrong.

Case 2: Appeal 2018-0044592 (Decided June 21,2019)

This case involves the PTAB reversing the Examiner's Section101 rejections of claims of the 14/316,186 patent application. Thisapplication relates to "a probabilistic programming compilerthat generates data-parallel inference code." The Examinercontended that "the claims are directed to the abstract ideaof 'mathematical relationships,' which the Examiner appearsto conclude are [also] mental processes i.e., identifying aparticular inference algorithm and producing inferencecode."

The PTAB quickly dismissed the "mathematical concept"category of abstract ideas. The PTAB stated: "the specificmathematical algorithm or formula is not explicitly recited in theclaims. As such, under the recent [2019 PEG], the claims do notrecite a mathematical concept." This is the same reasoningthat was provided for the PTAB decision in the previous article,once again requiring that a mathematical algorithm be"explicitly recited." As explained before, the 2019 PEGdoes not use the language "explicitly recited," so thePTAB's reasoning is not exactly lined-up with the language ofthe 2019 PEG however, the PTAB's ultimate conclusion isconsistent with the 2019 PEG.

Next, the PTAB addressed and dismissed the "organizinghuman activity" category of abstract ideas just as quickly.Then, the PTAB moved on to the third category of abstract ideas:"mental processes." The PTAB noted the following relevantlanguage from the specification of the patent application:

There are many different inference algorithms, most of which areconceptually complicated and difficult to implement at scale.. . .Probabilistic programming is a way to simplify the application ofmachine learning based on Bayesian inference.. . .Doing inference on probabilistic programs is computationallyintensive and challenging. Most of the algorithms developed toperform inference are conceptually complicated.

The PTAB opined that the method is complicated, based at leastpartially on the specification explicitly stating that the methodis complicated. Then, in determining whether the method of theclaims is able to be performed in the human mind, the PTAB foundthat this language from the specification was sufficient evidenceto prove the truth of the matter it asserted (i.e., that the methodis complicated). The PTAB did not seem to find the self-servingnature of the statements in the specification to be an issue.

The PTAB then stated:

In other words, when read in light of the Specification, theclaimed 'identifying a particular inference algorithm' isdifficult and challenging for non-experts due to theircomputational complexity. . . . Additionally, Appellant'sSpecification explicitly states that 'the compiler thengenerates inference code' not an individual using his/her mindor pen and paper.

First, as explained above, it seems that the PTAB used theassertions of "complexity" made in the specification toconclude that the method is complex and cannot be a mental process.Second, the PTAB seems to have used the fact that the algorithm isnot actually performed in the human mind as evidence that it cannotpractically be performed in the human mind. Footnote 14 of the 2019PEG states:

If a claim, under its broadest reasonable interpretation, coversperformance in the mind but for the recitation of generic computercomponents, then it is still in the mental processes categoryunless the claim cannot practically be performed in the mind.

Accordingly, the fact that the patent application provides thatthe method is performed on a computer, and not performed in a humanmind, should not be the sole reason for determining that it is nota mental process. However, as the PTAB demonstrated in thisopinion, the fact that a method is performed on a computer may beused as corroborative evidence for the argument that the method isnot a mental process.

This case illustrates:

(1) the probabilistic programming compiler that generatesdata-parallel inference code was held to not be an abstract idea,in this context;(2) reciting in the specification that the method is"complicated" did not seem to hurt the argument that themethod is in fact complicated, and is therefore not an abstractidea;(3) reciting that a method is performed on a computer, though notalone sufficient to overcome the "mental processes"category of abstract ideas, may be useful for corroborating otherevidence; and(4) the PTAB might not always use the exact language of the 2019PEG in its reasoning (e.g., the "explicitly recited"requirement), but seems to come to the same overall conclusion asthe 2019 PEG.

The next three articles will build on this background, and willprovide different examples of how the PTAB approaches reversingExaminer 101-rejections of machine-learning patents under the 2019PEG. Stay tuned for the analysis and lessons of the next case,which includes methods for overcoming 101 rejections where the PTABhas found that an abstract idea is "recited,"and focuses on Step 2A Prong 2.

Footnotes

1 35U.S.C. 101.

2 https://e-foia.uspto.gov/Foia/RetrievePdf?system=BPAI&flNm=fd2018004459-06-21-2019-1.

The content of this article is intended to provide a generalguide to the subject matter. Specialist advice should be soughtabout your specific circumstances.

POPULAR ARTICLES ON: Intellectual Property from United States

Global Advertising Lawyers Alliance (GALA)

While my seats afforded me only a so-so sight-line to the stage, I had no trouble seeing the ocean of cell phones, in the hands of adoring fans, simultaneously recording (without authorization)...

Weintraub Tobin Chediak Coleman Grodin Law Corporation

Generally, the title to a single motion picture is not entitled to trademark protection. This is the same for the title to single books, songs and other singular creative works

Cowan Liebowitz & Latman PC

What can you do to protect your goodwill if you unknowingly select an unfortunate brand name, or through no fault of your own...

Read the original post:
Machine Learning Patentability In 2019: 5 Cases Analyzed And Lessons Learned Part 2 - Mondaq News Alerts

If it wasnt bad enough that Moores Law improvements in the density and cost of transistors is slowing. At the same time, the cost of designing chips and of the factories that are used to etch them is also on the rise. Any savings on any of these fronts will be most welcome to keep IT innovation leaping ahead.

One of the promising frontiers of research right now in chip design is using machine learning techniques to actually help with some of the tasks in the design process. We will be discussing this at our upcoming The Next AI Platform event in San Jose on March 10 with Elias Fallon, engineering director at Cadence Design Systems. (You can see the full agenda and register to attend at this link; we hope to see you there.) The use of machine learning in chip design was also one of the topics that Jeff Dean, a senior fellow in the Research Group at Google who has helped invent many of the hyperscalers key technologies, talked about in his keynote address at this weeks 2020 International Solid State Circuits Conference in San Francisco.

Google, as it turns out, has more than a passing interest in compute engines, being one of the large consumers of CPUs and GPUs in the world and also the designer of TPUs spanning from the edge to the datacenter for doing both machine learning inference and training. So this is not just an academic exercise for the search engine giant and public cloud contender particularly if it intends to keep advancing its TPU roadmap and if it decides, like rival Amazon Web Services, to start designing its own custom Arm server chips or decides to do custom Arm chips for its phones and other consumer devices.

With a certain amount of serendipity, some of the work that Google has been doing to run machine learning models across large numbers of different types of compute engines is feeding back into the work that it is doing to automate some of the placement and routing of IP blocks on an ASIC. (It is wonderful when an idea is fractal like that. . . .)

While the pod of TPUv3 systems that Google showed off back in May 2018 can mesh together 1,024 of the tensor processors (which had twice as many cores and about a 15 percent clock speed boost as far as we can tell) to deliver 106 petaflops of aggregate 16-bit half precision multiplication performance (with 32-bit accumulation) using Googles own and very clever bfloat16 data format. Those TPUv3 chips are all cross-coupled using a 3232 toroidal mesh so they can share data, and each TPUv3 core has its own bank of HBM2 memory. This TPUv3 pod is a huge aggregation of compute, which can do either machine learning training or inference, but it is not necessarily as large as Google needs to build. (We will be talking about Deans comments on the future of AI hardware and models in a separate story.)

Suffice it to say, Google is hedging with hybrid architectures that mix CPUs and GPUs and perhaps someday other accelerators for reinforcement learning workloads, and hence the research that Dean and his peers at Google have been involved in that are also being brought to bear on ASIC design.

One of the trends is that models are getting bigger, explains Dean. So the entire model doesnt necessarily fit on a single chip. If you have essentially large models, then model parallelism dividing the model up across multiple chips is important, and getting good performance by giving it a bunch of compute devices is non-trivial and it is not obvious how to do that effectively.

It is not as simple as taking the Message Passing Interface (MPI) that is used to dispatch work on massively parallel supercomputers and hacking it onto a machine learning framework like TensorFlow because of the heterogeneous nature of AI iron. But that might have been an interesting way to spread machine learning training workloads over a lot of compute elements, and some have done this. Google, like other hyperscalers, tends to build its own frameworks and protocols and datastores, informed by other technologies, of course.

Device placement meaning, putting the right neural network (or portion of the code that embodies it) on the right device at the right time for maximum throughput in the overall application is particularly important as neural network models get bigger than the memory space and the compute oomph of a single CPU, GPU, or TPU. And the problem is getting worse faster than the frameworks and hardware can keep up. Take a look:

The number of parameters just keeps growing and the number of devices being used in parallel also keeps growing. In fact, getting 128 GPUs or 128 TPUv3 processors (which is how you get the 512 cores in the chart above) to work in concert is quite an accomplishment, and is on par with the best that supercomputers could do back in the era before loosely coupled, massively parallel supercomputers using MPI took over and federated NUMA servers with actual shared memory were the norm in HPC more than two decades ago. As more and more devices are going to be lashed together in some fashion to handle these models, Google has been experimenting with using reinforcement learning (RL), a special subset of machine learning, to figure out where to best run neural network models at any given time as model ensembles are running on a collection of CPUs and GPUs. In this case, an initial policy is set for dispatching neural network models for processing, and the results are then fed back into the model for further adaptation, moving it toward more and more efficient running of those models.

In 2017, Google trained an RL model to do this work (you can see the paper here) and here is what the resulting placement looked like for the encoder and decoder, and the RL model to place the work on the two CPUs and four GPUs in the system under test ended up with 19.3 percent lower runtime for the training runs compared to the manually placed neural networks done by a human expert. Dean added that this RL-based placement of neural network work on the compute engines does kind of non-intuitive things to achieve that result, which is what seems to be the case with a lot of machine learning applications that, nonetheless, work as well or better than humans doing the same tasks. The issue is that it cant take a lot of RL compute oomph to place the work on the devices to run the neural networks that are being trained themselves. In 2018, Google did research to show how to scale computational graphs to over 80,000 operations (nodes), and last year, Google created what it calls a generalized device placement scheme for dataflow graphs with over 50,000 operations (nodes).

Then we start to think about using this instead of using it to place software computation on different computational devices, we started to think about it for could we use this to do placement and routing in ASIC chip design because the problems, if you squint at them, sort of look similar, says Dean. Reinforcement learning works really well for hard problems with clear rules like Chess or Go, and essentially we started asking ourselves: Can we get a reinforcement learning model to successfully play the game of ASIC chip layout?

There are a couple of challenges to doing this, according to Dean. For one thing, chess and Go both have a single objective, which is to win the game and not lose the game. (They are two sides of the same coin.) With the placement of IP blocks on an ASIC and the routing between them, there is not a simple win or lose and there are many objectives that you care about, such as area, timing, congestion, design rules, and so on. Even more daunting is the fact that the number of potential states that have to be managed by the neural network model for IP block placement is enormous, as this chart below shows:

Finally, the true reward function that drives the placement of IP blocks, which runs in EDA tools, takes many hours to run.

And so we have an architecture Im not going to get a lot of detail but essentially it tries to take a bunch of things that make up a chip design and then try to place them on the wafer, explains Dean, and he showed off some results of placing IP blocks on a low-powered machine learning accelerator chip (we presume this is the edge TPU that Google has created for its smartphones), with some areas intentionally blurred to keep us from learning the details of that chip. We have had a team of human experts places this IP block and they had a couple of proxy reward functions that are very cheap for us to evaluate; we evaluated them in two seconds instead of hours, which is really important because reinforcement learning is one where you iterate many times. So we have a machine learning-based placement system, and what you can see is that it sort of spreads out the logic a bit more rather than having it in quite such a rectangular area, and that has enabled it to get improvements in both congestion and wire length. And we have got comparable or superhuman results on all the different IP blocks that we have tried so far.

Note: I am not sure we want to call AI algorithms superhuman. At least if you dont want to have it banned.

Anyway, here is how that low-powered machine learning accelerator for the RL network versus people doing the IP block placement:

And here is a table that shows the difference between doing the placing and routing by hand and automating it with machine learning:

And finally, here is how the IP block on the TPU chip was handled by the RL network compared to the humans:

Look at how organic these AI-created IP blocks look compared to the Cartesian ones designed by humans. Fascinating.

Now having done this, Google then asked this question: Can we train a general agent that is quickly effective at placing a new design that it has never seen before? Which is precisely the point when you are making a new chip. So Google tested this generalized model against four different IP blocks from the TPU architecture and then also on the Ariane RISC-V processor architecture. This data pits people working with commercial tools and various levels tuning on the model:

And here is some more data on the placement and routing done on the Ariane RISC-V chips:

You can see that experience on other designs actually improves the results significantly, so essentially in twelve hours you can get the darkest blue bar, Dean says, referring to the first chart above, and then continues with the second chart above. And this graph showing the wireline costs where we see if you train from scratch, it actually takes the system a little while before it sort of makes some breakthrough insight and was able to significantly drop the wiring cost, where the pretrained policy has some general intuitions about chip design from seeing other designs and people that get to that level very quickly.

Just like we do ensembles of simulations to do better weather forecasting, Dean says that this kind of AI-juiced placement and routing of IP block sin chip design could be used to quickly generate many different layouts, with different tradeoffs. And in the event that some feature needs to be added, the AI-juiced chip design game could re-do a layout quickly, not taking months to do it.

And most importantly, this automated design assistance could radically drop the cost of creating new chips. These costs are going up exponentially, and data we have seen (thanks to IT industry luminary and Arista Networks chairman and chief technology officer Andy Bechtolsheim), an advanced chip design using 16 nanometer processes cost an average of $106.3 million, shifting to 10 nanometers pushed that up to $174.4 million, and the move to 7 nanometers costs $297.8 million, with projections for 5 nanometer chips to be on the order of $542.2 million. Nearly half of that cost has been and continues to be for software. So we know where to target some of those costs, and machine learning can help.

The question is will the chip design software makers embed AI and foster an explosion in chip designs that can be truly called Cambrian, and then make it up in volume like the rest of us have to do in our work? It will be interesting to see what happens here, and how research like that being done by Google will help.

See the rest here:
Google Teaches AI To Play The Game Of Chip Design - The Next Platform