At the SPIE Advanced Lithography Conference in February ASML gave an update on their EUV systems, in this blog I will provide a summary of what they presented. I have also written about my impressions on EUV for the overall conference here.
Continue reading “SPIE Advanced Lithography 2018 – ASML Update on EUV”
If there was a central takeaway to Nvidia’s GTC event last week in San Jose it was this: autonomous vehicles are already operating or at least testing in virtual every corner of the planet including companies such as Tier IV and ZMP in Japan, and Pony.ai and Baidu in China. But two U.S. companies standout globally for the growing number of vehicles they have successfully and safely put into public road operation: Waymo and Cruise.
In the wake of Uber’s fatal crash in Tempe one has to ask whether or how Uber can regain its public road testing privileges in Arizona and California and how Uber obtained those rights in the first place. And if an operator like Uber with estimable experts on board can, nevertheless, fail to deliver a safely operating system, what are the terms and conditions of certification or recertification for on-road testing.
Even taking into account the fact that the fatal Uber crash, according to a layman’s assessment of the publicly released dashcam and in-car video, appears to be a basic comprehensive failure of the self-driving system, how does Uber and the relevant public authorities hit the reset button? Will self-driving car failures be a one-and-done proposition? Do we want Uber banned from future self driving car tests and operations?
It’s clear that automating the driving process is no simple proposition and that solving this challenge requires extensive testing and – as was discussed at the Nvidia event – extensive simulation and modeling. The best way to accelerate the process is to increase the number of vehicles on the road to expand the data collection pipeline.
Residents of Tempe, Ariz. and San Francisco can attest to the frequent sightings of self-driving vehicles as testament to the fact that fleets of vehicles are essential to mastering self-driving operation. As such, Uber represents an ideal self-driving car development platform – especially since it is capable of combining data gathering with the provision of taxi services. Lyft, too, is seeking to act as a platform for multiple self-driving car development partners.
Companies such as Mapper.ai, for example, have sought to leverage the daily driving behavior of Uber drivers for map data gathering via aftermarket devices installed in their vehicles. Virtually every fleet operator in the world – from rental cars and taxis to delivery companies – is being sought out by mapping companies, traffic information companies and self-driving vehicle developers for the data gathering properties of their fleets.
Uber’s failure (followed two weeks later by a crash of a Tesla Motors vehicle operating in “autopilot” mode), highlighted the development gap between Waymo and Cruise and the rest of the self-driving industry. It would be a shame, it seems, if Uber is unable to sort out its issues and get back in the self-driving business, but regulators, legislators and the transportation industry lacks a protocol for restoring faith and credabiity in an operator that has failed in the manner that Uber has.
The bottom line is that investigators from the National Transportation Safety Board are likely to conclude that the Uber vehicle simply failed to identify the pedestrian and the Uber safety driver simply wasn’t paying attention. In fact, a similar conclusion will arise from the fatal Tesla crash, according to data already shared by Tesla, that the driver did not have his hands on the wheel for six seconds before the fatal crash. In both cases, driver inattention played a role.
Waymo and Cruise may be leading the race to automate driving, but that race is rapidly revealing itself to be a marathon. Scaling automated driving from warm, sunny climates to more variable environments is a years-long process. (Volvo will gain an edge from its testing operations in Sweden.) This is a process that will require fleets of vehicles to solve and Uber is an ideal candidate to lead if the company can sort out its technical and organizational challenges to the satisfaction of regulators. Whether that recovery involves new ownership remains to be seen.
The final takeaway highlights the impressive performance of yet another market player which has been plying the path of Level 2 autonomy: Cadillac and its Super Cruise. The Super Cruise system cleverly leverages a camera-based in-cabin driver monitoring system to scan the head and eyes of the driver to ensure attention is focused on the road in combination with a high-definition Lidar-scanned map of the roadway to offer what may be best described as enhanced cruise control.
Super Cruise was launched on the Cadillac CT6 more than six months ago and has been operating without a reported failure and without the creation of dozens of Youtube videos showing drivers sleeping, or with their feet out the window or in the backseat. By geo-fencing the feature (so that it is only available on 130,000 Lidar-scanned miles of controlled access highways) and monitoring the drivers, Cadillac has found a way to deliver an autopilot-like experience without ever claiming autopilot functionality. But it has done so safely without any reported crashes, injuries or fatalities.
It’s a long way from Cadillac Super Cruise SAE Level 2 assisted driving to SAE Level 4 hands-free/eyes-free driving, but it’s important to give credit where credit is due – including suppliers Seeing Machines and high definition map prover, Ushr. Most importantly of all, Super Cruise is offered on a production vehicle and, finally, it is by now clear that Cadillac customers using this system understand its limitations and, if they don’t, the system will enforce those limitations by disengaging.
This driver monitoring and system disengagement is the beginning of a new relationship between car and driver. Cars have been helping humans drive since the onset of cruise control, electronic stability control, anti-lock breaks and all the rest of the various advanced driver assist technologies. But now we are launched on the path of removing our hands from the steering wheel while driving – yet keeping our eyes on the road. Maybe Uber will be able to rejoin the journey or maybe it won’t. For the time being, Uber’s driving privileges are only available in Pittsburgh. All eyes are now on Pittsburgh to discover what the next turn of the wheel will bring for Uber. Uber’s clearly gone to the trouble of integrating an in-cabin camera to watch the driver. It may be time to integrate that driver monitor with the vehicle controls a la Cadillac’s Super Cruise.
In “Willy Wonka and the Chocolate Factory” circa 1971, Gene Wilder plays a vaguely misanthropic Willy Wonka who leads the young winners of his golden wrapper contest on a tour of the seven deadly sins within his candy factory and labs. (Who can forget Augustus Gloop?) At one point, Mike Teavee, a television-obsessed pre-teen, is so enamored of Wonka’s experimental Wonka-vision that he insists on being transmitted – despite a half-hearted warning (see above) from Wonka himself.
Mike is thrilled when the device “transmits” him into a faux TV set, but when he steps out of the set it is clear to all but him that he has suffered a likely irreversible shrinking process to the shock and horror of his mother. Mike’s glee is undimmed. Wonka gives a shrug.
Something similar appears to be playing out with Tesla Motors as the company has rolled out Autopilot 2.5 and Tesla owners are taking more liberties than ever with the system. As the first production vehicle with advanced automated driving level 2 capabilities such as lane changing and passing, people have been taking liberties with Autopilot-equipped Tesla’s since day one, with fatal results for at least one driver.
Tesla’s equivalent of Gene Wilder’s half-hearted warning is the admonition that the driver must keep his or her hands on the wheel at all times and pay attention to the road ahead. It’s no surprise that drivers continue to ignore these warnings (suggestions?).
The results can be interesting, like the drunk Tesla driver who claimed he wasn’t actually driving or the heart attack victim who claimed autopilot got him to the hospital. The latest episode of the Tesla follies is the Tesla driver who put his feet out the window during an “Inside Edition” interview and was subsequently pulled over by a police officer. The driver received a ticket for going too slow (25 miles per hour) in a 65 mile per hour zone – but the ticket was later dismissed. It seems the traffic code may need a rewrite to cope with semi-autonomy.
The real news, though, is the Autopilot 2.5 update. Tesla has been in the midst of a process of playing catch-up since the fatal crash in Florida two years ago, after which Mobileye (a supplier of the camera system in the original Autopilot) parted company with the automaker.
Forced to rely on its own in-house algorithms, Tesla quickly down-shifted with a software update (downgrade?) and instituted a new geo-fenced version of Autopilot that only worked in certain driving environments and at certain speeds. Over time, the geo-fence expanded and the speed restrictions were relaxed and, with the release of 2.5, Tesla may have finally achieved parity with or surpassed the Mobileye-enabled performance of the original Autopilot.
With Musk’s claimed plan to deliver full autonomy via Autopilot, this may be good news or bad. Is the Model S (or X or 3) really ready or capable of full autonomy? And what exactly is full autonomy? Can a Tesla perform like a Waymo? Probably not for a while.
The concern is that Tesla throws the driving candy out to the sinners and more or less looks the other way (Stop. Don’t. Come back.) as the misbehavior unfolds. Try to pull Tesla-like shenanigans in a Cadillac with Supercruise and the car shuts the feature down.
There’s got to be more to corporate responsibility – enforced in real-time in the vehicle a la Cadillac – than a CEO Pied Piper crooning Wonka-like “Come with me…”
The issue is highlighted in a review of vehicle videos released by the Tempe, Ariz., police in connection with the fatal crash of an Uber autonomous test vehicle with a pedestrian walking a bicycle. The driver was looking down, distracted, but the vehicle sensors ought to have detected the pedestrian in spite of the nighttime circumstances. (Guess who Uber is going to blame.)
This is yet another case where the safety driver can and likely will be blamed – but one would also be correct in holding Uber responsible for the failure of the system. The video evidence suggests a failure of the system hardware or software. Putting such a system on public roads for testing suggests a certain degree of Wonka-like indifference. Automated vehicle-friendly states like Arizona ought to think about implementing sanctions for such failures to encourage a more responsible approach from the testers. Without consequences there will be no progress.
https://tinyurl.com/yalzhgpc – What happened when driver put his Tela on Auto Pilot? – Inside Edition
https://tinyurl.com/ybzab85o – Uber driver looks down for seconds before fatal crash – Ars technica
The EDA CEO outlook took an interesting turn last night but before I get into that I will offer a few comments about the start of the show. I attend this event every year for the content but also for the networking. It isn’t everyday you get to hang out with semiconductor industry elite and have candid conversations over food and drinks. I always come prepared with questions for this blog but also for my other work inside the fabless semiconductor ecosystem.
Join us on April 5, 2018 for the 2018 ESD Alliance CEO Outlook!At this important event, the CEOs of four leading ESD Alliance member companies will discuss their views of where our industry – the semiconductor design ecosystem – is heading.
The distinguished panel will discuss major new trends they see, with the potential opportunities they anticipate. Panelists for the evening are Dean Drako(IC Manage), Grant Pierce (Sonics), Wally Rhines (Mentor, A Siemens Company) and Simon Segars (Arm). Ed Sperling (Semiconductor Engineering) will moderate the panel. Each CEO will present a brief opening statement about the future of the industry, followed by an interactive, moderated audience discussion.
It was mostly attended by people who I know but I did make some new friends. People who read SemiWiki introduced themselves and one person even said they had SemiWiki bookmarked in their browser which to me is a very high compliment.
Missing was Synopsys CEO Aart de Geus and Cadence CEO Lip-Bu Tan. In the past the CEO panel was CEO’s of publicly traded companies who either were in their quiet period so they could not comment on forecast questions or they would simpley take the fifth. This time there were CEOs of a very small EDA and IP company and two CEOs of companies that were acquired by much larger companies so they were technically no longer CEOs of publicly traded companies.
Prior to the event there was a lot of discussion about the pending trade war with China. I participated in an article last week for the Chicago Tribune (Trump may win the trade battle with China but lose the war – Chicago Tribune), my quote is at the bottom of the article:
“I don’t think tariffs will be a long-term thing, but they will accelerate (China’s) campaign to become independent,” said Daniel Nenni, CEO, and founder of Silicon Valley-based SemiWiki.com, an open forum for semiconductor professionals. “You have to control silicon to control your destiny.”
The point being that a country has to have their own fabs and design their own chips to ensure supply and security. The same goes for systems companies in a sense which is why Apple is now the most powerful fabless systems company. And based on the SemiWiki analytics, literally thousands of systems companies will follow Apple into the fabless systems business model. If you are interested in how Apple became a semiconductor force of nature read chapter seven of our book Mobile Unleashed.
The pre programmed questions were kind of tame but I understand how hard it is to moderate a panel like this because I did it many years ago. The first question was positive and negatives in regards to outlook. Simon was quite positive of course noting that we are now transitioning from mobile as a driver to a much more diverse ecosystem with Cryptocurrency, IoT, AI, Automotive, etc… and he did not see any barriers to future growth citing that mobile had everyone pulling their hair out (big laugh here since Wally and Simon are both hairline challenged) but we persevered.
Wally said that VC money is back for semiconductor start-ups and the semiconductor industry will continue to grow.
More than $900M was invested in 2017 with AI playing a role in the majority if not all of them. Deja veu of the dot com bubble maybe. Successful or not, they all have to buy EDA tools so Wally is more than happy to help.
Last year we saw 20% growth with about half being memory. Wally expects non memory to grow another 10% in 2018. Automotive was discussed and Wally compared today’s automotive burst to the one in the early 1900s where there were 285 car companies that narrowed down to 3 and now we are back up to more than 300 car companies suggesting history will repeat itself sooner than later.
When talking about the possible outlook downside the best line was from Wally when people casted doubt ”There are always things to worry about if you want to worry” but clearly Wally is not worried.
I will blog about the “interesting turn” of the event next…
As verification continues to be a key ingredient in successful design implementation, new approaches have been tried to balance cost, time to results and comprehensive analysis in designs that require large patterns in some application like Image Processing. Simulation environments are well proven, and designers tend to use approaches they are familiar with, but these tend to take a lot of time for large verification suites. FPGA prototyping provides improved runtimes but setting up the targeting flow takes time. Emulation provides significant acceleration, but this comes at a hefty cost.
Vaxel Inc, a Silicon Valley startup, provides a verification approach that blends nicely the Simulation, FPGA synthesis and Emulation methodologies and it calls it Verification Acceleration (thus the name Vaxel). It is a low-cost software solution that is FPGA target agnostic and it automates the steps in FPGA targeting, allowing the designer to choose their preferred FPGA vendor and then allowing a 10X-30X improvement in runtime at a much cheaper cost than emulation. (Disclosure: I am helping Vaxel in Design Enablement and I am part of the organization).
Note that VAXEL is NOT an FPGA based prototyping tool but is a block level verification acceleration tool.
Yasu Sakakibara, Vaxel Inc CTO has published a paper entitled ‘Image Processing Verification beyond Simulation, Emulation, FPGA synthesis’.
In this paper, he examines the benefits and limitations of each verification approach (summarized by drawing excerpts here from the paper):
Simulator
A Simulator is without a doubt the verification tool that is most widely used in chip development projects. On one hand, it provides a large degree of latitude and helps you construct a verification environment where you can check operations closely by viewing waveforms and performing highly flexible input/output simulations. On the other hand, its operation speed is devastatingly slow. Therefore, you need creative approaches to the verification environment to compensate for the slowness. The following are examples:
These approaches will speed up a Simulator, but the downside is that they all lead to more complicated configuration procedures and more cumbersome code maintenance.
Emulator
While a conventional Emulator can perform high-speed verification because it is constructed with dedicated hardware to perform an HDL operation, the first and foremost issue with the Emulator is its cost. It is a very powerful tool and the capabilities are vast. But, the license for both initial deployment and the subsequent renewals is extraordinarily expensive. Because of this, Emulators are usually shared among multiple projects, even within the largest OEMs in the industry. Not only from the economical viewpoint, but also from the verification procedure viewpoint, an Emulator requires you to prepare behavior models to substitute peripheral functions. This is also time-consuming work.
Design verification on an Emulator can often result in a poor perspective in terms of error correction due to the discovery of block-level bugs that were not caught in the previous process using the Simulator because of those cutting-corners approaches you took to compensate for the slowness.
FPGA Prototyping
FPGA Prototyping is an effective low-cost verification method compared to an Emulator. However, to effectively prepare the dedicated hardware requires extensive knowledge of FPGA. In many cases, an FPGA specialist is assigned to the project in addition to the design engineer and the verification engineer. As a result, the benefit of FPGA Prototyping diminishes rather quickly.
The following illustrates other problems that need to be addressed with FPGA prototyping:
The Verification Acceleration Value Proposition
The ideal verification acceleration tool should come with a ready-to-use set of standard hardware function IP blocks, such as bridges and interfaces so that the setup would be easy and fast. The tool should be affordable, and that it should require little expertise in FPGA.
To accomplish the above, the following should be the elements and requirements of a 4[SUP]th[/SUP] way solution:
The paper details the approach taken to verify an Image Processing design with large test patterns in three steps:
1. Run a smoke test on the simulator
2. Confirm connection to the simulator
3. Conduct verification on the FPGA
Controlling the FPGA board, loading firmware to the CPU on FPGA, and transmitting and extracting the input/output data are all done by the host PC.
The 4th way seems to find a way optimizing cost, time and block functionality checking with automation and acceleration.
These failings aren’t just a cross we humans bear; they’re also a concern for chips, particularly in electrical over-stress (EOS) and aging of the circuitry. Such concerns are not new, but they are taking on new urgency given the high reliability and long lifetime expectations we have for safety-critical components in cars and maintenance-free needs in many industrial applications.
EOS is generally grouped with two other failure-modes: electromigration (EM) and electrostatic discharge (ESD). EM is primarily about current; inrush when switching on a power domain or localized high activity can knock metal atoms in interconnect aside; over time this accelerates through increased resistive heating. ESD and EOS are two ends of a spectrum related to high electric fields (modest voltage differences over tiny distances), causing dielectric breakdown – in gate-oxide for example. ESD is normally associated with external static shocks propagating into a device – big spikes but short duration.
EOS is generally associated with misbehavior in the “normally” operating circuit, often a result of incorrect handling through voltage- or power-domain crossings where isolation or level-shifting was poorly implemented. These events can obviously persist for much longer than for ESD. João Geada, Chief Technologist at ANSYS, told me getting to a bad state doesn’t take much; for ultra-low-power HVT transistors, 0.1V (or less) outside the operating range starts to cause damage. The acuteness of all three failure modes is amplified in advanced technologies where metal widths and dielectric thicknesses have become so tiny.
You really want to check for problems like this at the implementation/transistor level and obviously you have to consider that EOS problems will be activity-dependent. One approach is to analyze statically (a bit like STA), but João says that tends to be very noisy (unsurprising). Dynamic analysis will obviously avoid the noise problem; that’s where ANSYS’ FX (super-fast Spice-accurate simulation) comes in. They have introduced an application, EOS FX, specifically to deal with this need. EOS FX is a full block/IP solution which will automate input vectors to cover all scenarios for possible EOS failures.
Aging is a different problem. We’ve all experienced this – you buy an electronic device, it works perfectly for a couple of years, then it jams for no obvious reason. You power-cycle it and it works fine again; but over time you find it jams more frequently and you have to power-cycle more and more often. A major root-cause is something call negative-bias temperature instability (NBTI) which occurs when (stable) electric fields are applied for a long time across a dielectric. (Another contributor is hot carrier injection which I will skip here.)
NBTI causes voltage thresholds to increase over time, which in turn causes propagation delays to increase over time. The effect is limited if those fields cycle frequently, as for a free-running clock for example, but has bigger impact in circuitry which rests in a stable state for extended periods. Curiously, clock gating exacerbates this problem. When the clock is gated off, state and therefore electric fields throughout downstream logic are fixed, giving free rein to NBTI to age that logic. This problem could be fixed by power gating the logic (turning off the power makes electric field go to zero) but that has downsides too (power-on latency, inrush, …). Oh well.
The impact of this aging is both circuit- and activity-dependent and will vary across the device; different parts of a design will age at different rates. Since aging increases delays, you should expect that paths which passed as non-critical for the new device will over time drift closer to critical or will become critical (hello device hangs). How likely this is to happen depends on how much margin you built into path slacks. You could also use adaptive voltage scaling (AVS) to compensate for delay degradation. Either way, you can’t afford to build enough slack into every path or put AVS islands everywhere, so you have to be selective, which again requires detailed transistor/implementation analysis with activity.
ANSYS now offers FX Agingfor this analysis. I believe this is the only detailed dynamic aging analysis on the market. The application builds a database of signal transition probabilities (from use-cases I believe) and propagates these through the circuit, looking for long term aging-stress candidates. It also looks at potentially infrequent events (possibly not covered in the use-cases), such as clock gating turn-on and isolation, which are particularly at-risk candidates. Stress conditions are propagated down to the transistor-level to ensure an accurate view of differential aging across the design.
How big a deal is this? Various presentations (eg this) show voltage thresholds increasing from 130mV to 210mV over a period of 5 years. When the operating voltage is 1V (or lower), that can have a huge impact on propagation delays. What makes both EOS FX and FX Aging possible is FX’s ability (on which I have written before) to do Spice-accurate path delay analyses orders of magnitude faster than Spice. That speed and accuracy allows for confident EOS and aging-based signoff in practical run-times. You can learn more about these ANSYS products HERE.
Publishing eBooks on FPGA Prototyping and Emulation really was an eye opener for me as a long time EDA and IP professional. Both markets are considered EDA in the traditional sense but they are very much in the systems business with a lot of IP. Both markets are also growing very rapidly and operate side-by-side with complimentary overlap. Emulation of course is a billion dollar prize in the making with AI rapidly consuming silicon and increasing die sizes in all market segments, absolutely.
Continue reading “Mentor Leads Emulation Innovation”
About 6 months ago, ANSYS was approached by a couple of leading mobile platform vendors/suppliers with a challenging problem. These companies were hitting target 2.5GHz performance goals on their (N10 or N7) application processors, but getting about 10% lower yield than expected, which they attributed to performance failures. Speed grades aren’t an option in this market (when were you last offered the “low-speed version” of a phone?), so the yield problem had to be fixed but they didn’t know where to start. Remember these are very experienced SoC design teams who nevertheless were unable to find in their STA analyses any obvious root cause for these failures.
REGISTER HERE for an ANSYS webinar on variability-aware timing closure, April 18[SUP]th[/SUP] at 8am PDT
According to Ankur Gupta (director of field apps), ANSYS were asked to run blind tests to figure out potential root causes, which those customers would then correlate back to observed failures. This is a timing problem, so think first about the vanilla approach to timing – run STA across however many hundreds of corners, using separately extracted margins for static and dynamic voltage drops (DvD) in the power grid, designed for a static timing target. It’s unlikely that there would be anything wrong with the STA and corners part of the problem given the relationship and influence these design houses have with the foundries and tool vendors. So DvDs have to be a prime suspect.
Now I’m going to switch to a presentation João Geada (chief technologist at ANSYS) gave at the Tau 2018 conference, then come back to the results from the analysis above. João opened with a seemingly obvious but under-appreciated point for advanced designs and technologies – the power supply is neither static nor uniform (within reasonable bounds) across the design, particularly in FinFET designs with large capacitive coupling between power and signals (as a result he describes power integrity now as much more like a signal integrity problem). Between ground-bounce and IR-drop, effective voltage across gates can be squeezed by 100s of mV against a 0.7-0.8V operating voltage, and this can have a huge impact on timing.
Where and when this happens is clearly both instance- and use-case-dependent; attempting to capture this effect in global margins is going to be both very expensive in area (João noted that 30%+ of metal is devoted to power in small geometry designs) and potentially risky in missing critical cases (since detailed DvD analysis is practically limited to a small set of vectors). The first step in addressing these problems is through RedHawk-SC elastic-compute, on which I have written multiple times. Through big data methods, analysis of very large vector sets can be farmed out across a wide range of compute-servers, from big to small, to look for potentially interesting corner cases. This analysis runs fast enough that power distribution design can run iteratively in the implementation/timing flow. By finding the corners to analyze in detail, localizing where they have impact, and refining power distribution surgically and iteratively, you get a higher confidence signoff with lower area (~9% reduction in one case).
But wait, there’s more. Remember the voltage squeeze and how close you are already operating to threshold voltages? Timing this confidently for paths close to critical requires Spice-level accuracy; real delays at this level can no longer be captured simply through delay addition and lookups across corners (varying VSS-VDD ranges as you move along a path make this even uglier). ANSYS FX path analysis can run first in a fast mode, as fast as STA, to identify suspect paths requiring closer analysis and then can run at accuracy within a few percent of Spice (but much faster) to do detailed path delay analysis based on both the circuitry and the PG dynamic behavior. ANSYS find this is quite likely to reorder STA path criticality, suggesting further surgical refinements to the power distribution plan, upsizing where this more accurate analysis suggests paths are more critical than you thought, downsizing where you have more slack.
Back to the big mobile vendors. ANSYS followed this strategy in those blind tests against 100-200K of the (supposedly) positive slack paths, mining DVD drops and ground bounces along paths and timing with these compressed voltages. You won’t be surprised to hear that their reordering of path criticality corresponded nicely with what customers had observed in lab testing, or that those customers are now very interested in this methodology. Ankur closed by noting ANSYS have subsequently been approached by all the rest of the contenders in the mobile benchmark race, which must say something about the credibility of their solution.
So if you thought all this elastic-compute and Spice-level path timing stuff from ANSYS was just marketing hype, think again. If all the significant mobile platform vendors in the world are forming a line at their door, this integrated DvD/STA approach looks like it might be the future of high-performance timing and power signoff.
Remember to REGISTER HERE for an ANSYS webinar on variability-aware timing closure, April 18[SUP]th[/SUP] at 8am PDT
When it comes to safety, ISO 26262 is the spec that comes to mind for many people. However, there are layers of specifications that enable the level of safety required for automotive and other systems that need high reliability. For any application requiring safety, test is a critical element. A key spec for SOC test is IEEE 1500, which defines a hierarchical test structure for SOC’s that enables testing of individual blocks and circuit elements independently. With a hierarchical testing approach chip testing becomes much more efficient, and new types of test functionality can be implemented.
Coming back to ISO 26262, one of the critical aspects is testing over the life of a chip to ensure it is performing properly as it ages. ISO 26262 includes provisions for real-time testing on a continuous basis to ensure proper performance over time. And, if we are talking about things that are required for proper performance, few matter more than clock performance, process variation and memory performance. These aspects of an SOC define the foundation that all other aspects of system reliability depend on.
In the white paper below Synopsys references their Measurement Unit (MU) which is part of its STAR Hierarchical System for SOC test implementation. The STAR Hierarchical System offers a means of implementing comprehensive test on SOC’s. It has been certified for ISO 26262 ASIL D level applications. To refresh, ASIL D is applied to systems whose failures can lead to death or serious injury.
There is a need for a compact and efficient method to test for clock frequency and duty cycle over the life of an SOC in ASIL D systems. The MU cleverly performs these function with minimal external support. The MU is configurable to perform several different functions, with clock frequency as the only one requiring an external reference clock. Even so, the reference clock can be a low speed clock. The MU counts the internal and external clock pulses and returns the internal clock period.
The MU also has a mode which tests duty cycle for internal clocks, this time with no external reference clocks required. Synopsys has also added modes to the STAR Hierarchical System’s MU to report process variation by using it in conjunction with a ring oscillator. Once the system clock is calibrated, the MU can evaluate process variation by comparing ring oscillator frequencies. This is useful when performed in a single location to monitor the effects of aging, or across multiple locations to look at on chip variation that could jeopardize chip performance. This same mode can be used to evaluate IR drop related performance issues. The test can be performed at chip idle mode and during high activity to determine the effects of IR drop.
The MU also has an operational mode for testing memory performance. The details of this mode are explained in the white paper mentioned above. The white paper is titled On-Chip Clock and Process Monitoring Using STAR Hierarchical System’s Measurement Unit and can be found on the Synopsys website. The white paper is authored by Karen Darbinyan, ASIC Digital Design Manager at Synopsys.
No single EDA company provides all of the tools needed to define requirements, design exploration, track IP, simulate, manage and verify a complex SoC system, so it makes sense that EDA vendors and point tool companies have tools that work together to achieve all of these difficult tasks. Systems design has been around for decades and has been enabled by the widespread use of Product Lifecycle Management (PLM) tools that help manage the process of starting with an idea then tracking details through the end of life. Our modern lifestyle is only made possible through huge industries that already use PLM systems: automotive, aerospace, IoT and consumer.
Some of the common features of a PLM system include:
Our own semiconductor industry caught hold of the PLM concepts first from the mechanical CAD companies looking for new markets, so they really focused on “part” management and some design process data. As you can imagine these first PLM systems were not widely adopted at semiconductor companies, but the good news is that PLM systems have grown over time to include product Bill Of Materials (BOM) plus the data needed for design and verification processes.
Chip design firms are big re-users of semiconductor IP which have created a fast growing market opportunity for IP vendors to serve along with verification IP, so that both design and verification schedules are sped up. These IP building blocks can be well documented, quick to deploy, and are designed to meet industry standard specifications, aspects which quicken time to market. With this new IP reality we need PLM systems that can track semiconductor IP across global borders and dispersed design teams.
Going back to an idea in the opening paragraph, there are incentives to integrate a PLM tool at the system level along with a semiconductor IP lifecycle management tool, creating a coherent process across the entire product lifecycle. Such an integration enables a team to start with an idea, define requirements and trace that all the way through detailed SoC implementation. Even the team members in manufacturing, sales and support are included in this PLM environment. For IP Lifecycle Management we create a new acronym – IPLM.
Let’s stop and think for a moment about how some organizations have been separated into distinct departments, with narrowly defined tasks, then each department chooses to use tools that make sense for their separate area which then causes data silos to emerge where valuable data isn’t visible or being shared between departments. See if this disconnected, two-silo approach looks familiar to an organization you may have worked in before:
In this product flow we have have two distinct groups that are not connected because their tools are in silos:
Now let’s turn to an enterprise that uses integration between IPLM and PLM technologies to see how an idea gets started and followed throughout a complete product lifecycle, something that spans multiple departments and many stakeholders:
With this integrated approach each group receives their unique BOM: engineering, manufacturing, service. Continuing to drop down into the development box, this is where traditional EDA tools and IP blocks form an SoC design flow, resulting in silicon wafers and packaged parts:
All of the design details used to create the SoC can be labeled a Bill Of Information (BOI), which includes each semiconductor IP block along with all of the metadata. The ideal IPLM system should work with common environments:
An EDA company named Methodicsdoes offer such an IPLM tool, dubbed Percipient that allows teams to perform IP lifecycle management, enables IP reuse, and provides an updated IP catalog throughout the IC design process. Each member of the chip design team can decide which version of a particular IP block they want to incorporate into the portion of their design hierarchy.
The Percipient tool has the concept of ‘workspaces’ where creators work in, created by the SCM tool, then managed by Percipient. Users of each IP block would have ‘read-only’ workspaces created from the SCM tool, and then decide which version of the IP to use. Here’s a diagram of how Percipient works with an SCM and other tools:
IC designers could just try and package an IP block with maybe hundreds of files and folders into a simple tarball, but that approach is quite inefficient as IP blocks start to reach GB file sizes, IP tracking isn’t part of a tarball, making fixes to an IP block would mean re-tarring and distributing to all users, and knowing what changed between versions is difficult with a binary tarfile. So in each of these cases the optimized approach in Percipient is much preferred.
Engineers love efficiency, so Percipient includes a command line client in Linux that is quick to learn: catalog listing, workspace operations, releases, tracking, etc. Commands can take a JSON argument so that you can view output results in JSON. Here’s an command line example to look at an IP tree hierarchy:
Team members can even code in their favorite language (.NET, Python, Perl, C++, etc.) or framework that supports GET and PUT requests to URL endpoints, controlling Percipient with an API.
Percipient manages IP hierarchy for blocks that use digital, analog and mixed-signal designs, along with version control. Each IP block can include rich data like graphs, charts, even HTML data sheets. Chip designs can query the IP catalog to find each IP block best suited for their project.
Engineers at Methodics have figured out how to integrate their IPLM tool with any PLM system using a set of four integration touch points as show in the following diagram:
So the good news for SoC design teams is that they can continue to use their favorite PLM system along with the IPLM from Methodics in an integrated fashion, creating a seamless flow, which in turn has improved communication within the team, shortening product development cycles in your enterprise.
Summary
Semiconductor design companies can now create new systems more efficiently and with fewer errors and iterations by taking an integrated approach with their PLM and IPLM tools. Methodics has led the way in enabling such an integration with their IPLM tool and they have the experience integrating with other PLM vendors. To learn more about this topic consider reading the 20 page White Paper from Methodics – Putting the “I” in PLM.
Related Articles
