The Growing Semiconductor Design Problem

in 1997 american chip consortium sematech sounded an alarm to the industry about the chip design productivity gap they observed that integrated chip manufacturing capabilities were expanding at about 40 percent a year at the time yet i see design capabilities were only growing at about half of that rate thus a potential crisis was brewing where design capabilities lag far behind manufacturing this crisis never took place for reasons we will discuss later in turn however a new challenge for the industry has emerged verification in this video we're going to look at why this previously unheralded step has become a rather big deal in today's competitive chip design world there are a few reasons why the cemetec chip productivity crisis never materialized the first is that the pace at which chip manufacturing advanced drastically slowed down as the science and its commercialization got harder i've done enough euv videos to make this point clear the second is that eda tools vastly scaled up their productivity they are now capable of handling much more abstraction and third designers have begun reusing chip ip to deal with product complexity and to get stuff out of the door faster from 2007 to 2012 the creation of new logic has declined by 32 replaced by pre-designed and purchased ip for instance cadence and synopsis not only make the eda software for their clients but also license out useful ip blocks for chip standard functions like io now designers can easily kick off their project with those pre-built functions already done thus relatively small teams can still design a billion transistor chip using the latest industry software and repurposed ip the data generally bears out this thesis a 2019 report by mentor graphics find that between 2007 and 2014 industry job growth for design engineers was just 3.8 percent a year the number of chip designers on a single project have largely stayed the same this is good but throughout the same period of time the growth rate for verification engineers was 12.6 percent and in 2018 there were more of the latter than the former on a project it is now a good time to start talking about what this verification thing is actually about the goal of chip verification is to identify and correct a design defect before it goes to the manufacturing stage you want to avoid a situation where a microchip does not perform as expected there are many types of verification in the industry functional verification timing verification layout verification functional test and built-in self-test or bist of these however functional verification is the most time-consuming and resource heavy processed if you have not already i recommend that you go through my earlier piece on eda software what it is and how it helps with the overall chip design process for background in that video i talked about logic design also known as circuit design this is where the engineer translate abstract requirements into circuits with the logic capable of meeting those requirements i use the metaphor of a ux designer who crafts how a software feature might look act and feel the output of the logic design stage is a cluster of groupings of logic and memory circuits connected together with wires this grouping is referred to as a quote netlist end quote but the designer is not directly working with those circuits on an individual basis there are millions of circuits this is not practical rather the engineer creates the logic using a hardware description language or hdl a high-level abstraction eda tool the two major languages are verilog and vhdl both are open standards the engineer is able to create the circuits with this high level language but how do we know that the whole thing works as it is intended and covers all the relevant corner cases that is what functional verification is for finding errors emits a c of hdl code okay so that might have made intuitive sense but might have also felt super abstract so here's a basic example a company is hired by the city to build a controller for a traffic light directing traffic between two streets red street and blue street the city tells the company to have the traffic light check the sensors embedded in its intersection if a sensor shows traffic waiting at a street then it shows a green light for that street for one minute the company writes up an algorithm to meet this specific spec they design a chip to execute this algorithm using hdl code the hdl can then be used to fab a chip that controls the light then a problem emerges the algorithm fulfills the requested spec but the resulting behavior neglects that the light needs to let cars from each side through in a fair manner the way the algorithm was written it does not do this instead it checks red streak verse and always thus lets the cars waiting at red street through blue street is locked in their car is unable to pass through until red street is entirely empty in the software world you can simply push up an update to fix this but this is hardware which means an entirely new chip needs to be made for the traffic light controller now obviously this is an ultra simplified example obviously a company would not fab an entirely new chip for this rudimentary purpose but you get the point this particular example addresses functionality but a significant concern is also security today's devices are intimately used you want to avoid hardware level vulnerabilities that might expose people to data theft or worse thus we might be able to say that verification is the design process in reverse in design you start with the specification and create implementations with verification you take the implementation and trace it back so to determine whether it meets the specification as well as the intent of the user so what does modern verification flows look like today of course these things vary from company to company same as with the chip design flows i discussed in the last video but here is a skeleton outline verification should be embedded throughout the entire design process so you start with verification planning creating the test plan defining the ips needed and so on the next thing is to verify whether the architecture is correct making sure to catch any high level protocol errors while everything is still very abstract and at an early stage you might want to create quote architectural models end quote which simulate the device's target use cases and workload this helps flesh out the device's security performance and power needs it also aids with low level software and firmware development which is often being done at the same time after that is a very intensive step called pre-silicon verification here pre-designed chip ips are tested to see whether it works as advertised if the ip has already been pre-verified that can be skipped a significant time save then the pre-designed ip is integrated into the overall soc and tested for accuracy at an overall system level this is repeated as other ips are added to the final design as part of this pre-silicon verification step it is general practice to prototype the hardware code in emulators or chips called field programmable gate arrays or fpgas an fpga is designed to be configurable after fabrication meaning that they are ideal for testing hardware software use cases like an os boot once everything works the system goes to a fab for fabbing onto a chip once the fab has done its job the chip goes through another lengthy and detailed process called post silicon verification this is the last step before the chip goes out to customers here the major benefit is that you are able to run the use case tests on actual silicon hardware the major drawback however is that debugging is much more difficult since obviously you can't easily dissect what is exactly going on inside the thing over time verification has come to take up a significant portion of total product development time it is often said that functional verification alone takes up 70 percent of the design team's energy and time in the product development cycle i do want to know that this statistic is clearly not a scientific measurement because i have also seen claims of 40 50 and 60 depending on the source regardless the point is clear this stuff is time consuming i spoke about the rapid growth and design verification engineer jobs in the past 10 or so years the same study finds that individual chip designers spend a lot of their working time on verification in 2014 design engineers spent an average of 47 percent of their time involved in design activities and 53 percent of their time in verification while in 2018 we found that design engineers spent on average 54 percent of their time involved design activities and 46 percent of their time in verification the expansion and verification jobs and time spent is because of what we call the verification gap modern day verification tools cannot keep up with the accelerating complexity of today's modern chip designs the sheer number of test cases that exist in some cases estimated to be around 10 to the 80th power means that it is impossible to look at every possible test case in existence the exploding numbers are exacerbated by a few modern design trends two of which i want to specifically call out here one of the fastest growing trends in modern chip design is related to the aforementioned soc an soc integrates a whole bunch of different often pre-designed ip components together on one microchip the benefits of an soc design are gains in performance size and power consumption a well-known example is the apple a series chip these are systems on chips that integrate a cpu with dedicated neural network hardware gpu image processing and more the design work impact associated with building an soc is not that great but the verification impact gets very large this is because you are essentially integrating other people's code to your own projects and it all needs to be tested imagine today's modern web programming projects where a single finished project is reliant on bunches of other people's projects despite people's best efforts bugs and these dependencies can easily cascade throughout the whole thing which is why a lot of software programmers concern themselves with code coverage intel studied and classified the 7855 bugs in its pentium 4 processor design prior to tape out pentium 4 was released in 2000 old i know they found that the two single most common bugs were because of careless coding typos and cut and paste errors and miscommunication these type bugs are linearly proportional to the lines of code in a project and since the projects are indeed growing larger at a rapid rate that means more bugs are lurking inside and need to be found the second major trend in the industry has to do with the shortening industry design cycle it used to be that teams had a lot of time about three to four years from the expiration step to production but intense competition has aggressively shortened that cycle companies like nvidia consider the rapid iteration and release cycle a key part of their overall business strategy and if one company does it then the rest of them need to speed up lest they lose market share it increases the risk of shipping a product with an undetected bug even with multiple teams working in unison a shorter product cycle makes it easier for errors and misunderstandings to slip through the cracks recent reliable survey data for what are called respins an immensely costly situation where a chip has to go back to the drawing board is hard to come by proprietary information i guess but i managed to dig up something from a 2002 industry study that claims that over half of all chip designs in north america fail the very first time they are fapped in a white paper from wilson research group commissioned by siemens though so take it with a grain of salt corroborates this saying that about 32 percent of projects in 2020 are able to achieve success on the first spin that means 68 percent fail the explosion and verification work in the late 2000s told companies that they had underscoped the scope of the task and it gave them a kick in the pants to mature their verification tools and the procedures today's verification teams use simulation and fpga emulation a whole lot more than before simulators are a backbone of eda product offerings and fpga emulation allows for the hardware and software to be tested together the one big drawback with fpga of course being that managing such an effort is a big engineering effort in of itself another popular solution is a methodology called constrained random verification it replaces traditional test methodologies with a system that generates a whole bunch of random tests the verification engineer only needs to provide the system with a template the example that i have seen used to explain this is a keyboard you want a test of hitting the a button properly creates the signal for the letter a you create a scenario where you hit the a button a few times well it worked fine in that one scenario but perhaps it might fail in a different one like after you hit the b button but how do you test for all the different scenarios and where you hit the letter a thus you tell the random test generator to generate a huge number of scenarios random key presses in a variety of different sequences for your keyboard if the a button passes all of them then you can be reasonably certain that the a button works fine so kind of like that but expanded from just one button to many possible hardware inputs there are many ways to go from here engineering teams are starting to apply machine learning and data mining to the constrained random verification procedure to automate the creation of the test template that sounds pretty cool but is far beyond the scope of this little video i have dabbled in web and ios programming a little bit one of the coolest parts were all the open source libraries offering cool features for anyone to add to their own projects slap together a few libraries wire them up and boom you have something that kind of looks professional on the surface now there are vast differences chip design teams are not afforded the same flexibilities as their software counterparts but doing this little video i am surprised by the connections between that scenario and today's hardware socs verification larger remains as much an art as a science you can measure how much a simulator program touches a line of code but that number says nothing about whether that line fully met its functionality as the industry continues to grind ahead into the future and more integrated circuits enter our lives this verification gap is going to matter a whole lot more in terms of functionality and security alright everyone that's it for tonight thanks for watching if you enjoyed the video consider subscribing i would like to reach 100 000 subscribers someday and you'll get to watch a whole lot of other videos on this channel that fit your interest and remember to check out the agenometry newsletter if you subscribe to the channel you should sign up for the newsletter read the full scripts to older videos with additional commentary after the fact you can find the link to the newsletter in the video description below or you can just go to asianometry.com as of right now you can expect a new newsletter every thursday at 1 am taiwan time so check that out and enjoy want to send me an email drop me a line at john asinometry.com i love reading your emails introduce yourself suggest a topic or more until next time i'll see you guys later

Channel: Asianometry

Views: 263,487

Keywords:

Id: rtaaOdGuMCc

Length: 16min 41sec (1001 seconds)

Published: Sun Dec 05 2021