SemiWiki – Page 480 – The Open Forum for Semiconductor Professionals

Banner Electrical Verification The invisible bottleneck in IC design updated 1

January 12, 2018

Mentor Investigates Using Neural Networks for CMP Modeling

I recently read a new white paper release by Mentor, a Siemens Business, that delved into the intricacies of Chemical Mechanical Polishing (CMP) and I got a sense of Déjà vu. My professional career in the IC industry started at Texas instruments and the white paper made me think of a conversation I had with one of my colleagues over lunch. We were experiencing some yield issues and he told a story of getting home late and trying to explain to his spouse the problems we were encountering. We often take for granted the miracle that the manufacturing of ICs is, and my friend’s wife brought that fact into perspective when she quipped, “Forget about yield, you should be happy any of them work at all!”.

One of the true innovations that helped make the IC industry what it is, has been the use CMP. CMP is responsible for the “leveling” of the wafer layers that makes for a good planar process. The CMP process is fascinating as it’s roughly akin to running a disc sander with a chemical slurry over the wafer to “polish” it smooth. This polishing is highly dependent upon the materials being polished and the density and shapes of the materials in any given location of the chip. To get consistent (and therefore flat) polishing, it’s important to maintain a constant density balance across the chip to prevent bumps and dishing that can cause shorts and opens.

With the introduction of softer copper interconnect at the 130nm node (vs harder aluminum), and then the introduction of high-k metal-gate technologies with costlier lithographic patterning schemes, it has become increasingly important to have higher accuracy CMP models that can be used to identify possible design “CMP hot-spots” before going to manufacturing. As mentioned, Mentor recently released a new white paper with a novel approach that uses machine learning and neural networks to accelerate the generation of good post-deposition (pre-CMP) profiles to be used with CMP manufacturing simulation models.

The main concept for building a CMP model is to extract geometric pattern properties of the chip layout, generate a pre-CMP surface profile after numerous etch and deposition steps and then use that data to simulate the post-CMP surface profile for different patterns on the layout. For high-quality modeling, it’s important to have a set of models corresponding to the deposition processes used by manufacturers to generate the correct input profile for CMP equipment simulations.

Generation of a high-quality pre-CMP surface profile is crucial for accurate CMP modeling and is complicated due to the convolving of geometric data, different materials and both short and long-range effects. Building physics-based models for different types of depositions processes such as high-density plasma CVD (HDP-CVD) and spin-on dielectric (SOD), is challenging and isn’t practical for more exotic deposition flows such as flowable CVD (FCVD) and enhanced high-aspect-ratio processes (eHARP). The key here is that if the pre-CMP profile isn’t accurate then neither will be the results of the CMP simulations for the post-CMP profile.

To attack this problem, researchers at Mentor recently had the idea of using machine learning (ML) algorithms to do a sensitivity analysis of measurement data on post-deposition (pre-CMP) surface profiles and found that the profile dependency was primarily influenced by the underlying pattern geometries while long-range effects look to be more secondary. Armed with this information they proposed the idea of using neural network (NN) regression calculations to model the pre-CMP surface profile using as input the geometric characteristics of the underlying patterns. The output of the NN would be the estimate of the pre-CMP profile that would then be used as input for the CMP equipment modeling.

Mentor already has algorithms to extract local geometric pattern characteristics from their Calibre CMP ModelBuilder and Calibre CMPAnalyzer products. They used these tools to extract pattern information such as width, space, pattern density and geometry perimeter and fed this into a multi-layer NN to generate post-deposition surface profile height data predictions. To test the practicality and accuracy of using ML and NNs to generate CMP models, Mentor took measured profile data from CMP test chips for four different deposition processes, HDP-CVD, SOD, FCVD and eHARP. Data was normalized and split into training and validation data sets and then used to train and validate NNs for each different process.

Mentor’s white paper goes into lots of details about the types of NNs used, the number of hidden layers in the NNs, numbers of neurons etc. All very interesting, but the best part was that the resulting models showed some very nice correlation, 95%, against the HDP-CVD and SOD processes for which compact models were already available in the Mentor Calibre CMP ModelBuilder tool. Mentor also applied this to modeling for the more complex FCVD and eHARP processes. Recall that these processes are too complicated for creating physics-based models with a reasonable runtime and accuracy. Using the NNs, they were again able to show good correlation with small errors per site. In summary, their approach looks to be a promising new way to build the post-deposition models for use by the CMP equipment simulators.

This is still early work and Mentor points out a few challenges of using NNs. One of them is that because the NN-based models are not physics-based, they can sometimes produce data that doesn’t physically make sense (e.g. small negative dishing as an example). They are hopeful that these issues can be handled either by some post-processing or more complete training data sets. None-the-less, this is quite promising work that could quickly become the norm for more advanced modeling in the future. One more level of complexity added to the miracle of manufacturing ICs!

January 12, 2018July 18, 2025

Achieving ISO 26262 Certification with ASIL Ready IP

Achieving ISO 26262 Certification with ASIL Ready IP
by Eric Esteve on 01-12-2018 at 7:00 am
Categories: Automotive, IP, Security, Synopsys

According with McKinsey, “analysts predict revenue growth for advanced driver assistance systems (ADAS) to be up to 29 percent, giving the segment one of the highest growth rates in the automotive and related industries.” Design cycle in automotive segment is much longer than in segments like mobile, PC or consumer. If you expect to see ADAS powered or autonomous cars in the street in 2025, you need to start designing now, in 2018. That’s why rapid progress in the development of advanced driver assistance systems (ADAS) and autonomous driving technology is challenging the semiconductor industry to bring the rigorous safety standards used in the automotive industry to its design process.

ADAS SoCs have to process increasing volumes of sensor data from many types of automotive sensors, driving the adoption of 64bit processing. Other trends in automotive semiconductor design include the use of:·Ethernet for managing large amounts of time-sensitive data traffic, and reducing point-to-point wiring

·LPDDR4/4x, with data rates of at least 3.2Gbit/s, for faster DRAM operations

·MIPI standards such MIPI Camera Serial Interface (CSI-2) and Display Serial Interface (DSI) for imaging and display applications

·PCI Express for high-reliability chip-to-chip connectivity for 4G radios, future 5G radios, and external SSDs

·5G and IEEE standards such as 802.11p for real-time updates of maps and images to and from the Cloud, and vehicle-to-vehicle or vehicle-to-infrastructure communications

·A shift from traditional 90nm, 65nm and 40nm processes to16nm, 14nm and even 7nm FinFET processes

The above listed features could apply to various type of applications, but for the automotive segment, electronic system, integrated circuits and intellectual property functions (or design IP) must comply with specific safety, quality and reliability requirements. A failure mode effect and diagnosis analysis (FMEDA) report is generated by development teams to provide all the information about their adherence to ISO 26262 from a functional safety perspective.

The ISO 26262 certification process must start from the very beginning of development process, and include multiple steps to complete the certification process, the Safety Plan.

Safety Planmanages and guide execution of safety activities. At first, the designer must define a strategy to achieve functional safety and define work packages. Key milestones will be specified and mapped to safety life cycle. The required resources will be identified and planned, as well as specific roles and personal assignments. Functional safety should be verified as well as compliance with standards and standard processes. Procedures, methods and tools have to be defined and mapped to various project phases.

FMEDAforms a critical part of the safety plan, providing a detailed report encompassing various steps and analysis, as shown in the above figure. It must include a fault injection analysis for both permanent and transient faults, so their impact can be assessed. FMEDA also considers all the possible failure and distribution modes to understand how the product will behave if a failure occurs and what sort of diagnostics the product implements to identify and communicate such failures to the system.

Now the impact of the designated safety features can be defined in the FMEDA report. Safety features fall into three categories:

Protection mechanisms, such as protecting the interface between the various components, such as IP, in the SoC architecture; parity protection on the data path and configuration registers; and ECC protection for both writes and reads.
Replication mechanisms, which include duplicating or triplicating key modules and using voting logic to ensure redundancy.
Various, which includes parity checks for all the state registers, single-cycle pulse validity, various dedicated interrupts, and hot-state machine protection for bad states.

In addition to meeting ISO 26262 functional safety requirements, automotive SoC development teams and the rest of the supply chain must adhere to automotive reliability and quality requirements.

Any product, including IP, for an automotive application must meet the automotive reliability requirements defined by AEC-Q100. IP providers must make sure their IP meets the reliability targets of the application, which means exploring how a transistor or electromigration analysis might be affected by the defined temperature profile. IP providers must work with foundries to ensure that any special automotive rules are applied to their design.

Any product development in the automotive supply chain must also meet automotive quality management requirements. In addition to having quality manuals and compliance reports, developers also need to create a design failure mode and effect analysis report that says that the SoC and its components meet the automotive quality management requirements.

You can find a brochure about Synopsys DesignWare IP for automotive and the original article “Achieving ISO 26262 Certification with ASIL Ready IP” from Ron DiGiuseppe on Synopsys web site.

By Eric Esteve from IPnest

January 11, 2018

Is there anything in VLSI layout other than “pushing polygons”? (5)

Is there anything in VLSI layout other than “pushing polygons”? (5)
by Dan Clein on 01-11-2018 at 12:00 pm
Categories: EDA, Siemens EDA
3 Comments

Being new in Ottawa and trying to get some momentum towards automation in full custom layout I was telling industry people that I am interested to work with everybody to move this agenda forward. My Director of Engineering at that time, Peter Gillingham, took me to visit Carleton University in Ottawa. One of his professor friends, Martin Lefebvre, had one PhD student building a silicon compiler for standard cells. Theoretically they knew “everything” but somebody from the “real world” was needed to say what make sense and what not, what is quality in layout (!) and what rules are important to follow. David Skoll, who was the architect, the implementation and the AE for it became an instant friend. It was very exiting to share my layout knowledge with him and continued to see over the years most of their roadmap and advanced alpha demos. Like any other beginning it was a bunch of scripts and some free tools from all over the map and David called it Machiavelli.

In the following years the name evolved into a full-size company that most of you will remember as Cadabra. In my opinion it was a very powerful idea and a solid implementation but had a limited usage. At that time ASIC flows started to pop-up from all over the map and every design house was buying or getting free libraries from fabs and ASIC vendors instead of developing themselves. They tried to implement a 2 level cells generation and process migration but with little success so the tool died a few years ago under Synopsys roof. What did I get from this? We learnt a lot about the power of “coins” or “basic bricks” and will Karl help MOSAID layout team had generated a lot of “basic” cells. From devices to via arrays, coding the decoders, etc. Later in PMC Sierra we had very advanced coins as part of our flow specifically enhanced for POWER connections and capacitors on power supplies.

One of the most time consuming and errors prone tasks for a Layout Designer is was (and still is) verifying DRC and LVS. MOSAID was using Dracula for verification but the preparation of data was tedious as the flat verification was not possible. As DRAM chips had a memory cell repeated, in our case 4-16 million times, we had to create “work structures”. To reduce the number of devices in a block we created doughnuts empty in the middle with only 1 cell on the boundary for interface checks. In top os size issues in DRAM we had 3 different sets of design rules, CORE, Memory and Periphery. Now we had to run verification on partial neighbouring. We also had to create schematics for each of these “working structures”. How many errors humans can introduce when ripping off full hierarchies to create this cells in layout and well as in schematic? Any 4M DRAM or above was taking about 1 week for one 1 DRC verification or LVS and 3-5 people in layout and circuit design. When all was clean any ECO will restart the creation and the full verification with many potential new errors.

We were very motivated to find a better solution. First, we evaluated the new Dracula (II) which was a 2 levels hierarchy verification versus Checkmate, the new advertised Mentor Graphics tool. About the same time Cadence started to talk about Vampire and ISS came with Hercules, advertised as the first hierarchical verification. I went to DAC in 1995 and had advance and private demos for each but I was not convinced that any has the “revolutionary” solution a memory needed. Most of their effort were toward ASIC which had at that time 1-3 levels of hierarchy but very few devices at any level as they used the standard cells as a stepping stone for hierarchy. Back from DAC we decided to bring Hercules for an evaluation but before doing that I called Mentor, as we had most of our platforms coming from them. We told them that unless they have something “cooking” worth waiting for, we will go for Hercules. Suddenly somebody wanted to talk to us and we got Michael McSherry, the technical marketing manager. Together with Gregg Shimokura, the coauthor of my book, we flew to Wilsonville, Oregon with our database on a tape.

After about a week of hiccups Gregg came back with great news, 1-hour LVS on a 16M DRAM. We had a clean data and a dirty one to be sure they actually find the same number of errors we found through our old Dracula flow. We started to see the light at the end of the tunnel. We agreed to work with them to make the tool ‘industry ready” and by 1996 was the official release. Mentor was so motivated to make this tool successful that they brought from China MingYong Yu, an experienced AE to learn everything we did and coordinate factory development. He was physically inside MOSAID for his first year in Canada. The biggest thing for a memory design was the reduction in the “potential errors” between our working structures as Calibre was the first real Hierarchical verification. In 1996 after a few successful tapeouts, I wrote a press release with Mentor about Calibre capabilities. For the following 2 years I personally helped Sundaram Natarajan, Mentor California sales guy, explaining customers why this solution is superior to all others offered at that time. Sundaram sold so much Calibre in these 2 years that he wanted to reward me somehow. I wanted the layout team to feel proud of their achievements so I convinced him to use this “reward” by subsidizing 220 t-shirts (one for each MOSAID employee) with the design attached in this article! Yes, another not “layout task” …

We solved the duration and errors issues but working with a new tool meant that the fabs, specifically the memory ones, did not have a Calibre PDK ready, we had to invent something else to make our life easier. We called it Process Independent Setup (PIS). We got from Germany a CAD expert, Britta Krueger, and together with the layout team prepared the specifications of this PIS. What we wanted first was the DRC. We built in layout all the possible design rules test cases in one chosen process and we wrote the code to verify them, obviously by different people. In parallel Britta and some helpers wrote all the Design Rules in a parameterized fashion in witch the numbers are actually parameters.

When a process comes in, one person takes the manual and inserts the values in the parameters page. When done just compiles the parameterized DECK and obtains the real values in Calibre command file. If a value is “0” this rule will not exist in the compile DECK. We knew that with this flow we can cover 80-85% of all design rules for any new process. We planned to add every time there are new design rules new test structures and their rules, in the original PDK and follow the flow. The intention was to reduce the new process setup from 100% new to 15% new. After a few months of work, we reduced any new process DECK generation from 3 weeks to 1 week when the processes were very different and to 1-day whey they were close. Then we started to enhance the PIS to get into LVS, Device generators, router setup, etc.

More about productivity enhancements next month!

Webinar: ISO 26262 and DO-254: Achieving Compliance to Both

Webinar: ISO 26262 and DO-254: Achieving Compliance to Both
by Bernard Murphy on 01-11-2018 at 7:00 am
Categories: Aldec, Automotive, EDA, FPGA

It’s near-impossible to read anything today about electronic design for cars without running into the ISO 26262 standard. If you design airborne electronic hardware, you’re likely very familiar with the DO-254 standard. But what do you do if you want to design a product to serve both markets? It looks like aircraft makers are increasingly turning to standard products, no doubt for reliability and cost, but they still need to hold those products to the DO-254 expectations they have embedded over many years. This presents both an opportunity and a challenge for chip and system designers – expanding demand but now required to comply with both standards.

Does this mean you have to run two separate compliance teams? Hopefully it isn’t that bad. Aldec have helpfully put together a webinar, hosted by an expert in these domains, to help understand where requirements are similar and where they differ between the standards. The speaker will wrap up with suggestions on how to effectively deliver compliance to both.

Abstract:
Increasingly, the DO-254 industry is turning to general purpose computing platforms to implement functionality with safety of life implications. This is creating opportunities for electronics to be developed that can be used to support both avionics and automotive applications. These two domains employ somewhat similar design assurance guidelines for electronic hardware found in ISO 26262 and DO-254. Each guideline addresses safety-requirements, design activities, verification and validation, and configuration management. In addition, specific attention is paid to proving the correctness of tool operations, as well as dealing with COTS.

This webinar will provide a high-level introduction to both ISO 26262 and DO-254 (along with the associated regulatory considerations). Guideline similarities and differences will be addressed when complying with the various life cycle activities and objectives. Data requirements of the two guidelines will be reviewed. The guidelines’ approaches to dealing with complexity, safety requirement verification, tools, and COTS, both components and intellectual property will be highlighted. The webinar will conclude with the speaker’s thoughts on how dual compliance can be achieved.

Agenda:

Quick Overview of the Automotive and Aviation Regulatory Domains
Structure and Overview of ISO 26262
Structure and Overview of DO-254
DO-254 Interpretation and Application (by FAA and EASA)
Similarities between ISO 26262 and DO-254
Differences between ISO 26262 and DO-254
Planning for Dual Compliance
Q&A

Presenter Bio:
Tom Ferrell is a software and airborne electronic hardware Designated Engineering Representative (DER) for the US Federal Aviation Administration. Tom is a co-founder of Ferrell and Associates Consulting, Inc. a certification and aviation safety consultancy. Previously, Tom has held senior technical positions at Science Application International Corporation (SAIC), Iridium LLC, and the Boeing Commercial Airplane Group. Tom holds a bachelor’s degree in Electrical Engineering from Northern Illinois University, a Master’s degree in Information Technology Management from Rensselaer PolyTechnic Institute, and a Master’s degree in History from George Mason University. Tom is one of the technical editors for the third edition of the Digital Avionics Handbook, published in 2014 by CRC Press.

January 10, 2018

Bicycles, Electronics and CES 2018

Bicycles, Electronics and CES 2018
by Daniel Payne on 01-10-2018 at 12:00 pm
Categories: EDA, Events, General
3 Comments

I’m an avid road bike enthusiast having just completed my 2017 goal of 13,000 miles, so follow me on Strava if you want to see the routes and photo adventures I have in Oregon. In the photo below I’m the guy in the middle with the Portland Velojersey on and we’re in a parking lot just 2 blocks away from Intel’s Ronler Acres site in Hillsboro.
Continue reading “Bicycles, Electronics and CES 2018”

January 10, 2018November 22, 2019

The lofty rise of the lowly FPGA

The lofty rise of the lowly FPGA
by Tom Simon on 01-10-2018 at 7:00 am
Categories: Achronix, eFPGA, FPGA, IP
4 Comments

FPGA programmable logic has served in many capacities since it was introduced back in the early 80’s. Recently, with designers looking for innovative ways to boost system performance, FPGA’s have moved front and center. This initiative has taken on new urgency with the slowing down of process node based performance gains. The search has moved to new algorithmic and architectural innovations that can push performance forward to meet the needs of big data, cloud computing, mobile, networking and other domains.

The new applications for FPGA’s are a far cry from the glue-logic uses that they first fulfilled. FPGA’s have been moving up the semiconductor food chain for some time though. They were applied to networking applications by Cisco and others back in the 90’s – as they entered their second decade. Most recently a major shift occurred when FPGA’s were paired with CPU’s to facilitate compute intensive operations. FPGA’s cannot adapt to new tasks as quickly as a general-purpose CPU, but they excel at repetitive operations that involve high throughput.

Microsoft has embraced this approach for its cloud and search engine operations after they assessed its feasibility in their Catapult project. Another big mover in this space is Intel with its $16B acquisition of Altera. Long gone are the days where FPGA’s were a poor man’s alternative to ASIC’s. Commercial FPGA’s routinely are built on leading edge process nodes – to wit, Altera going to Intel 22nm for its first FinFET design. FPGA’s have become quite efficient and they come with a bevy of ancillary IP and high performance IO’s ensure high performance.

In a recent white paper by Achronix, they argue that the pairing of CPU’s and FPGA’s was inevitable and in many ways obvious. However, for FPGA’s to be effectively paired with CPU’s several further optimizations are required. For one, the FPGA needs to access system memory using cache coherence. Another point that Achronix makes is that data transfer between system memory should operate as fast as possible. They also posit that board area ought to be reduced and that unused or unnecessary IP blocks or modules should be eliminated, to save cost and wasted silicon area.

The Achronix white paper touches on the CCIX group’s work to create a high speed standard for cache coherent memory that can be used by heterogeneous processors, IO devices and accelerators. Recent news on CCIX shows that 25Gb/sec has been demonstrated over PCIe 4.0. However, there is usually a price to pay when going off chip for any data, and especially for cache coherent data. The solution is to combine FPGA fabrics into SOC’s so they gain the efficiencies of being on-chip.

Achronix has a successful line of FPGA chips, the Speedster22i, but their latest move is shaking up the FPGA market. By taking their proven FPGA technology and embedding it, system designers can reap significant benefits. General purpose FPGA chips often have resources that are not optimally aligned with the target application. For instance, the off the shelf configuration might include IP, embedded memories or LUT’s that are not needed. Alternatively, Achronix eFPGA offers designers the ability to tailor the FPGA fabric tightly to the system requirements. Also, bypassing the need to go off-chip reduces the IO pad/ring overhead on both sides, while saving power, and improving speed and reliability.

The Achronix white paper covers the history of FPGA’s up to the new era of embeddable FPGA fabric, while articulating the advantages of this new approach. Additionally, they provide an overview of how they engage with customers to ensure design success. In the past FPGA’s have always been a game changer. However, with advances is technology their importance is system design has grown. With the switch over to embedded FPGA technology, an even higher level of performance and efficiency is possible. In some ways, this represents a fundamental shift in SOC design, one that will certainly create new opportunities in many of today’s leading application areas.

January 9, 2018November 24, 2020

French Tech at CES, 2nd country after USA with 274 Start-Up at Eureka Park!

French Tech at CES, 2nd country after USA with 274 Start-Up at Eureka Park!
by Eric Esteve on 01-09-2018 at 12:00 pm
Categories: Events, IPnest, Semiconductor Services
8 Comments

France exposure will be very strong at Las Vegas CES this year, the 3[SUP]rd[/SUP] country with 365 companies, behind USA and China. If you just take the start-up number into account, 274 French start-ups will be present, just behind the USA with 280 start-ups! If you look back, it’s a great jump compared with 2017 (178 start-up) and even greater with 2015 when only 66 French start-ups were exposing at CES.

If I write about this topic, it’s not just to say “Cocorico”, or Cook-a-doodle-doo, but to highlight a deep mind-change in France, and in the way France is perceived outside of the country. Just take two examples, one in pure business (investment in start-up), the other in media coverage (France has been named “country of the year 2017” by British magazine The Economist). In 2015, it was a major surprise to hear John Chambers saying that “France is the next new thing” to explain why CISCO will invest $100 million in French startups in the next three years. For information, it was CISCO largest investment in Europe, larger than in the UK for example…

The second example is more recent, dated December 22, 2017, when the British magazine The Economist named France “country of the year 2017” (The title, awarded since 2013, goes to a country that has notably changed for the better over the past 12 months, or “made the world brighter”). If you consider the way business people in the UK were regarding France just a couple of years back, that’s a massive change!

So, what’s new in France to justify the way the country is perceived as a dynamic country at business level?

There is an obvious answer linked with Emmanuel Macron election in May 2017 as new French “president de la republique”. He is not simply the youngest French president, he is also a politician who know more than politic, as he has worked in the banking industry (where he has made a lot of money in a couple of years by the way). In the US, such a CV may not even be mentioned, as many politicians come from the industry, but in France that’s a real change: most of the politicians have joined politic when leaving university!

This information is not just cosmetic, it helps understanding why Macron grasp the new dynamic of the industry, mostly based on the infinite potential offered by Internet. In this new industry, algorithms have replaced oil and coal, cars will become electric before being driverless.

If we need a proof about Macron’s ability to consider that startups will provide the new jobs in the future, just remember that he (or his staff) has organized the venue of French startups in Las Vegas in 2016. In fact, he did such an excellent job, running “French Tech Night” (see the above picture) to invite the top tech businessmen from around the world, that some media have complained about the cost of the party (€380K), leading to legal investigations… In some way, France is staying old style France in that sense that some people absolutely don’t understand the power of marketing. But Macron does, and, by the way, he speaks perfect English!

Just to make it clear, this blog is not a political hagiography for Emmanuel Macron. I simply want to explain what has changed in France, and how it can impact the potentially brilliant future for French startups.

If you want to look at the startups list, you can go here, let’s just mention some examples of the various industry segments, from health industry to agriculture, smart home, smart cities, wine or FinTech.

If you are interested by innovation in smart house, you could meet with some of the 70 exhibitors addressing this segment in Vegas this year. Health industry is also well covered by almost 50 startups, as well as services to enterprises (35) or transportation (31).

To conclude, I remind my first work in the high-tech industry in 1985. At that time I had to register to a certain organization, and to do so I had to select a code describing my profile (IC design engineer). In fact, I couldn’t find any code fitting with my job: it didn’t exist!

But in the 1990’s, you could find very good research or design engineers in France, like these who have designed OMAP for TI, the first Network-on-Chip (NoC) for Arteris (founded in France in 2005) or EVE emulation platform, founded in 2000 in France and now part of Synopsys.

There are many good, very good designers or soft developers in France. But most of the high-tech companies had poor marketing vision (basically limited to launch a press release). This massive venue to CES 2018 is certainly a good sign for change!

From Eric Esteve from IPNEST

January 9, 2018

System Level Formal

System Level Formal
by Bernard Murphy on 01-09-2018 at 7:00 am
Categories: EDA, Oski Technology
3 Comments

Two recently announced vulnerabilities in major processor platforms should remind us that bugs don’t organize themselves to appear only in domains we know how to test comprehensively. Both Meltdown and Spectre (the announced problems) are potential hardware system-level issues allowed by interactions between speculative execution and cache behavior under specialized circumstances. Finding hardware weaknesses among highly complex interactions is where formal-proving excels, but common belief is that formal analysis on hardware systems of this complexity is beyond the reach of today’s tools, which are typically bounded to block/IP-level proving.

Or so goes conventional wisdom. But not knowing how to test for complex issues doesn’t make them go away, so experienced teams look for creative approaches to formally verify at the system level. Qualcomm (Mandar Munishwar, Sr. Staff Eng. at Qualcomm/Atheros, who also teaches a class at UCSC on system-level assertions and formal) and Vigyan Singhal (CEO of Oski) co-presented on this topic at Oski’s most recent Decoding Formal event.

Mandar kicked off by showing a real example where he was looking for potential system-level deadlocks in a wireless PHY layer sub-system, a controller for a next-gen WiFi core. The central block in this system sequences operations of ten immediately surrounding blocks, together acting as 11 complex intercommunication state-machines. The total system is deep inside the design, therefore difficult to control/observe directly, and the complexity of interactions with other blocks is sufficiently high that deadlocks are possible. All of which fits my earlier characterization – conceptually a perfect for formal, but far too big.

When a design is too big for formal, the logical next step is to abstract. You replace memories or datapath elements (for example) in the design with reduced models which exhibit the important features of the replaced component for the purposes of the proof. This works well when just a handful of components stand between you and a feasible proof, but what do you do if all the components are too big? At this point you have to start thinking about architectural formal verification, where you abstract everything in the design.

Mandar explained that each block in this proof, including the central block, is abstracted down to an appropriate FSM. In essence, none of the original RTL remains except for the top-level connectivity, much of which may be ignored as not relevant to the deadlock verification. At this point, some of you will object (in the strongest possible terms). What are you verifying if hardly any of the original RTL remains? There were some attendees who seemed to be wrestling with that objection; I also have had the same concern, but listening to a previous talk on using this method for cache-coherence verification and this talk where abstraction was taken to the limit, along with Vigyan’s explanations both times, I believe I have come to terms with the value and the validity of the method.

This starts with the process. Since what you are verifying is not the design RTL, you need strong links between that RTL and the proof and also, incidentally, the original architectural spec. That last part is a nice plus in these proofs. You derive architectural models as simple FSMs for each block, starting in each case with the architectural spec for the block rather than the RTL. In the abstracted model, you preserve only those details considered relevant to the proof. In this case, Mandar was primarily concerned with handshakes passing between the blocks because he was looking for deadlocks, but he still allowed for timing variability, eg non-deterministic latencies.

The top-level design remains the same with architectural models (AMs) replacing the blocks under that top, and block signals irrelevant to the proof are stubbed or left open as appropriate. Also adjustments are made to time-frames to scale multi-microsecond transactions to ~200 cycles for reasonable proof times. To give us a sense of the complexity of sequencing through these intercommunicating FSMs, Mandar showed an example control flow. Proofs are run on this top-level architectural model to find potential deadlocks.

Finally, the AMs are validated against the corresponding RTL. This can be done in simulation or formally. Per Vigyan, the simulation approach works well for relatively simple AMs, where obviously all you want to look at is the handshaking behavior. Formal is used for the more complex AMs, where you validate between the RTL and the assumptions (constraints) made when constructing the AM.

What did Qualcomm get out of this? First, they found bugs in the architectural specs – try doing that with any kind of RTL verification. This is a human step, not automated, but simply the exercise of generating an AM exposes potential problems. Pretty valuable. Then system-level verification exposed bugs. And finally, in AM versus RTL verification they found corner case bugs in the RTL. Altogether they uncovered 9 hard-to-find bugs which could easily have gone through to production or at least a silicon re-spin.

I can understand why verification teams might feel queasy with this approach; what you are proving feels multiple steps removed from what you are building. Vigyan himself told me this approach isn’t for everyone. And yet problems at this level happen and can be difficult even to conceive, much less figure out how to test. Just ask the processor guys scrambling to deal with Meltdown and Spectre. I can’t tell if the Qualcomm approach is necessarily the best way to catch Meltdown/Spectre-type problems, but I do believe formal needs to play a bigger role at this level and it has to work with some kind of architectural spec level because proofs based directly on the RTL are impractical. You can check out Oski’s Decoding Formalvideos HERE.

January 8, 2018July 3, 2021

FinFET ASICs for Networking, Data Center, AI and 5G

FinFET ASICs for Networking, Data Center, AI and 5G
by Daniel Nenni on 01-08-2018 at 12:00 pm
Categories: 5G, AI, eSilicon, Events, FinFET, Semiconductor Services

On the heels of successful seminars in Tokyo and Shanghai, eSilicon is starting the new year back in the cloud with a webinar version of the live events for those, like myself, who could not attend. The webinar will compress the 3 hour live event into 60 minutes which will provide a great place to start a conversation on your next chip for networking, data center, artificial intelligence, and 5G applications.

In talking to my paisan Mike Gianfagna, eSilicon presented a complete ecosystem to address the requirements of advanced ASICs for markets such as high-performance computing, networking, deep learning and 5G. Samsung Memory presented their HBM2 solutions, Samsung Foundry talked about their advanced 14nm FinFET solutions, ASE Group reviewed their advanced 2.5D packaging solutions, eSilicon presented ASIC and 2.5D design/implementation and IP solutions, Rambus detailed their high-performance SerDes solutions and Northwest Logic presented their HBM2 controller solutions.

Mike is one of the few people I work with that has more semiconductor experience than I do. In fact, I worked for Mike many many many years ago at Zycad and he is still one of my favorite bosses, which is saying something because I have worked for a LOT of people in the past 33 years.

The most common lunch conversation Mike and I have is “what’s next” for semiconductors, him on the ASIC side and me on the SemiWiki side. Based on his experience from the live seminars and my end of year wrap up on SemiWiki you will be seeing a lot more advanced ASICs for HPC, networking, AI, and the beginnings of 5G infrastructure. Not all of these chips will come from the top semiconductor companies of course, which brings us to the mighty ASIC business model that I have written about many times.

According to Mike, and I concur, many markets are initially enabled with semiconductor devices in the form of application-specific standard products (ASSPs) or field-programmable gate arrays (FPGAs). The recent rise of deep learning applications has created another ASSP-like option, the graphics processing unit (GPU). All of these technologies offer a predictable unit cost with a specific set of features. This usually works well until one of two things happens:
[LIST=1]

Volume and cost pressures grow to the point where buying a standard product where perhaps only 60 percent of the chip is used becomes a financial problem.
Competition in the market becomes so strong that differentiating with the same chip everyone else uses becomes a marketing problem.When one or both of the above situations occur, traditional and non-traditional chip companies turn to ASICs as a way to reduce unit cost (the chip does exactly what’s needed with no wasted silicon) or as a way to increase differentiation (you can optimize the chip for your application). The result being a more competitive chip, right?
Mike makes a good point in regards to markets that are already high growth and highly competitive. Add to that the fact that the design cost of an ASIC is typically a very small part of the unit cost of the end system which makes ASICs a viable option if not a requirement, absolutely.

Bottom line: Mike’s prediction and SemiWiki analytics predict a robust ASIC business for the HPC, networking, AI, and 5G infrastructure markets in 2018 which brings us to the upcoming webinar:

FinFET ASICs for Networking, Data Center, AI and 5G Using 14nm 2.5D/HBM2 and SerDes
The huge amount of data generated, moved, stored and analyzed around the world today has changed custom IC development forever. The massive, FinFET-class ASICs used in todayÂ’s networking, data center, artificial intelligence (AI) and 5G infrastructure applications require doing things in silicon that have never been done before.

High-bandwidth memory (HBM2) addresses performance, power and size issues, but requires a 2.5D implementation. How do you find an ASIC ecosystem you can trust to build a 2.5D chip?

We will present real case studies and roadmaps for high-performance FinFET ASICs. We will introduce a complete ecosystem with proven delivery of high-performance ASICs and 2.5D/HBM2 systems.

Attendees will receive a new 2.5D/HBM2 white paper written by the HBM2 ecosystem, including presenting companies.

Register for the 8:00-9:00 AM or 6:00-7:00 PM Pacific Time webinar.

Agenda
· Samsung: HBM2 memory solutions
· Samsung: Foundry solutions including 14nm FinFET technology
· ASE Group: advanced 2.5D packaging
· eSilicon: ASIC and 2.5D design and implementation, HBM2 PHY, high-speed memories
· Rambus: high-performance SerDes
· Northwest Logic: HBM2 controller

About eSilicon
Silicon is an independent provider of complex FinFET-class ASIC design, custom IP and advanced 2.5D packaging solutions. Our ASIC+IP synergies include complete, silicon-proven 2.5D/HBM2 and TCAM platforms for FinFET technology at 14/16nm. Supported by patented knowledge base and optimization technology, eSilicon delivers a transparent, collaborative, flexible customer experience to serve the high-bandwidth networking, high-performance computing, artificial intelligence (AI) and 5G infrastructure markets. www.esilicon.com

January 8, 2018December 27, 2023

CEVA ClearVox Simplifies Voice Pickup

CEVA ClearVox Simplifies Voice Pickup
by Bernard Murphy on 01-08-2018 at 7:00 am
Categories: AI, Ceva, Events, IoT, IP, Mobile

Voice-based control is arguably becoming another killer app, or killer app-enabler in the very significant shifts we are seeing in automation. After a bumpy start in car feature control (for navigation, phone calls, etc) and early smartphone “intelligent” assistants, voice-based interfaces now seem to be maturing into a genuinely useful capability. As I have said before, it’s about time. Buttons and keyboards, real or virtual, and byzantine menu hierarchies are clumsy, distracting, sometimes dangerous and anyway are a poor substitute for the way we humans would ideally like to communicate with our machines.

AI tends to dominate our thinking in this area – speech recognition and natural language processing being obvious examples – but there’s a rather important step before that; picking up the voice (or voices) and passing clean signals to those algorithms. This isn’t just a question of using a high-fidelity analog path from microphones to the eventual digitized output. Voice-based systems these days frequently use multiple microphones for direction discrimination, you have to deal with (acoustic) reflections from walls and other surfaces, you need to be able to capture commands in noisy environments and increasingly there is a trend to identifying who is speaking among multiple potential speakers. Handling all of this is owned by the front-end of voice-processing, also known as voice pickup.

CEVA is already very active in this space with their CEVA-TeakLite-4 (ultra-low-power) and CEVA-X2 (high-performance) embedded DSP platforms. Now they have introduced a software suite they call ClearVox, bundling the input voice-processing algorithms optimized to drive these hardware platforms, rounding out a complete voice-pickup solution package for voice-enabled system builders. This spans from voice activation (eg. “Hello Google”), to tracking speakers, beamforming, echo cancellation and noise suppression.

I already talked about voice activation in any earlier blog (Active Voice), based on some very neat technology supporting always-on listening at ultra-low power, allowing everything else to be powered down until the trigger word/phrase is detected.

ClearVox also includes beamforming software which is absolutely essential for directional discrimination and speaker tracking in far-field applications (smart speakers like Amazon Echo and Google Home for example). Multiple omnidirectional microphones, from as few as 2 to as many as 13, provide inputs to the (DSP) software which can then use weighting, filtering and summing to extract a strongly directed signal, which could also be used to track a speaker (whose direction may change).

Another benefit in beamforming is significant noise reduction in the signal. By focusing only on the speaker, input from other directions is very largely suppressed. ClearVox algorithms support circular array technologies, familiar in smart speakers, and also linear technologies, expected to become more popular in smart TVs.

Acoustic echo cancellation (AEC) is another essential feature in all voice-activated systems (even in speakerphones). Sound waves from a speaker and other sources in any enclosed area (living room, conference room, car) will reflect back from hard surfaces (walls, tables, etc), resulting in multiple delayed inputs to the microphones on your voice-based system and adding further noise the signal. But echoes can be recognized and removed given sufficient sophistication in the DSP software. Again, ClearVox provides this capability.

As a part of the AEC algorithms, ClearVox also provides support for barge-in. This is voice-driven systems, where the speaker (you) must take priority over any music that may be playing or responses from the personal assistant. Asking your assistant to turn the music volume down isn’t going to work very well if said assistant can’t hear you over the music it is playing, or if it is preoccupied with answering your last question.

Naturally since this is CEVA software running on CEVA hardware (and it only runs with CEVA hardware, if you were wondering) it is optimized for performance and power. You don’t have to sweat those details when you’re building your solution. That said, it is configurable and modular so you can optimize the platform to best suit your needs in your system.

ClearVox is available in two configurations: for near-field applications (headsets, earbuds, hearables and wearables) and far-field applications (smart speakers, smart home, voice enabled IoT, mobile phones). The product is available to lead customers today and will be generally available in Q2 (2018).

CEVA provide a reference design showing use of ClearVox which you can see this week at CES. Again, this is hot off the presses, so checkout the website for more details.