RVN! 26 Banner revised (800 x 100 px) (600 x 100 px)
Semiconductor Expert Forum

Posted on

Stress and Aging

Stress and Aging
by Bernard Murphy on 04-05-2018 at 12:00 pm
Categories: Ansys, Inc., Automotive, EDA

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.

Posted on

Mentor Leads Emulation Innovation

Mentor Leads Emulation Innovation
by Daniel Nenni on 04-05-2018 at 8:00 am
Categories: AI, Automotive, EDA, Siemens EDA

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”

Posted on

A New Problem for High-Performance Mobile

A New Problem for High-Performance Mobile
by Bernard Murphy on 04-04-2018 at 7:00 am
Categories: Ansys, Inc., EDA, FinFET, Mobile
1 Comment

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

Posted on

Safety Critical Applications Require Onboard Aging Monitoring

Safety Critical Applications Require Onboard Aging Monitoring
by Tom Simon on 04-04-2018 at 6:00 am
Categories: EDA, IP, Synopsys

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.

Posted on

Combining IP and Product Lifecycle Tools

Combining IP and Product Lifecycle Tools
by Daniel Payne on 04-03-2018 at 12:00 pm
Categories: EDA, Perforce

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:

  • All product data and metadata are easily accessed
  • Collaboration happens when people and processes all access the same data
  • Instant access to data speeds decision making

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:

  • Product Engineers, Architects, Designers, Integration Engineers
  • Compliance, Sourcing/Procurement, Operations, Legal/Contracts

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:

  • Source Code Management – SCM integration (Perforce)
  • Linux command line
  • Analog IC tools (Cadence Virtuoso)

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

Posted on

Functional Safety Methodologies for Automotive Applications

Functional Safety Methodologies for Automotive Applications
by Alex Tan on 04-03-2018 at 12:00 pm
Categories: Cadence, EDA

During Q&A session at San Jose GTC 2018, nVidia CEO Jen-Hsun Huang reiterated that critical functional safety, such as in autonomous vehicle, requires both the redundancy and the diversity aspects. For example, CUDA with Tensor core and GPU with DLA were both utilized. Safety is paramount to automotive applications. Any failure related to the system performance could translate to dire consequences as the application owning exposure around human activities.

In ADAS application, aggressive small form-factor, low power consumption and increased compute requirements for inferencing have driven demand towards advanced process node migration. This in turn has caused more challenge for reliability such as in addressing process variation, electrostatic discharge and electromigration.

Safety can be defined by referring to two existing safety standards:
IEC 61508 (International Electrotechnical Commission (IEC), a functional safety standard for the general electronics market developed by the IEC. ISO 26262 (IEC), a functional safety standard for automobiles from ISO. It has rapidly gaining acceptance as the guideline for the automotive engineer since its release. While compliance to these standards is initially addressed by car manufacturers and system suppliers, recent increasing complexity has also motivated all participants of the supply chain to participate. Since its first roll-out in 2011, more efforts being spent to formalize its adoption into the development stage of the electrical/electronic systems. As a solution provider, Cadence has made headways within this space as will be covered later in this article.

Functional Safety and Failure Classifications
As derivative to IEC-61508, the ISO 26262: Road Vehicles—Functional Safety was designated for passenger vehicles with a max gross vehicle mass up to 3,500 kg and that are equipped with one or more electrical/electronic (E/E) subsystems. Functional safety is defined as the “absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical/electronic systems”. The definition can be illustrated by chain of implication as shown in reversed waterfall diagram in figure 1.

On the other side of the equation, per ISO.26262 malfunction in E/E systems can be classified into either systematic or random failure. In each of this domain, it could be expanded into more approaches and necessary metrics to fully address the issue. For example systematic failures induced during development, manufacturing or maintenance could be due to process origin and can be resolved by change in the procedures and its related documentation (captured on left hand side in figure 3).

Unlike the systematic failures, random failures which might appear during the lifetime of a component could be due to random defects as part to innate usage or process conditions. A number of safety mechanisms and detection metrics are available as captured in the diagram. For more details on random failures metrics discussion, please refer tothis document.

Given the failure classification and applying the chain of implications, any potential malfunction of a defined automotive system function can be assessed within the context of ASIL term, Automotive Safety Integrity Level (ASIL) is the level of risk reduction needed to achieve a tolerable risk. For example, a malfunction in the Anti-lock Braking System (ABS) may involve addressing prompts at each sequence of ASIL. The severity level of each event, labelled as A (low) to D (high), can be measured in terms of FIT (Failures in Time), SPFM and LFM levels.


Functional Safety Analysis and Design Flow
To evaluate the safety level of design components such as an IP or SOC, one could use functional safety analysis. The dichotomy of this analysis can be illustrated in figure 4. It comprises quantitative evaluations (e.g. Failure Mode Effect and Diagnostic Analysis or FMEDA), timing analysis, and qualitative assessments (e.g. Dependent Failure Analysis or DFA. FMEDA is a structured approach to define failure modes, failure rate, and diagnostic capabilities of a hardware component and DFA is used to assess dependent failures between given elements (is important especially if the system has shared resources).

Built-In Self-Test (BIST) is the most notable example of safety mechanism already automated in the design flow. It is used for automotive in-system/field testing for lifetime reliability to achieve the desired ASIL. For testing random logic, there are online and offline BISTs, each is applied based on the stringent timing requirements. Types of challenges to be addressed during BIST integration are speed testing capabilities, power consumption, area, routing minimization, compression techniques and ASIL targets. Since the test coverage estimated during BIST insertion is not exactly the DC required by the ISO 26262 metrics; functional safety verification might be needed to accurately measure the DC. Other safety mechanisms are also available (such as Triple Modular Redundancy, Dual-Core Lockstep, etc.). For more details on these techniques, please refer to Cadence’s paper.

In the traditional RTL-to-GDS flow, FMEDA is utilized to drive design exploration to meet the functional safety targets. It shows where to focus the design effort for meeting the constraints and provides direction for improving diagnostic coverage. Implementing a design with functional safety produces more robust physical outcome.

Figure 5 shows a design implemented with and without functional safety routing constraints using Cadence Innovus Implementation System. The bottom-left region is the main copy of a block, while the top-right region is the replica inserted for redundancy. By guaranteeing that wires belonging to the main block can never venture into the top-right region, the redundant blocks are physically independent by construction and meet the requirements of the DFA.

Software Tool Confidence Level
Similar to the safety principles applied on the hardware components, the tool confidence level (TCL) quantifies the assurance that failures in the software tools can be detected. The tool confidence level spans from TCL1 to TCL3, with TCL1 being the highest, Tools classified as such do not require additional qualification and can be used in the development of applications with any ASIL. Cadence announced last year its industry’s first comprehensive TCL1 certification from TÜV SÜD, to meet stringent ISO 26262 automotive safety requirements. The functional safety documentation kits cover analog and mixed-signal, digital front-end and verification, digital implementation and signoff, and PCB flows comprised of nearly 40 tools, offering the broadest EDA-certified tool and flow documentation to support the automotive industry. For read more details on functional safety methodologies, please check HERE.

Posted on

Tutorial on Advanced Formal: NVIDIA and Qualcomm

Tutorial on Advanced Formal: NVIDIA and Qualcomm
by Bernard Murphy on 04-03-2018 at 7:00 am
Categories: EDA, Synopsys

I recently posted a blog on the first half of a tutorial Synopsys hosted at DVCon (2018). This blog covers the second half of that 3½ hour event (so you can see why I didn’t jam it all into one blog :D. The general theme was on advanced use models, the first half covering use of invariants and induction and views from a Samsung expert on efficient modeling for formal. In the second half we had customer presentations on two perennially popular topics: architectural formal verification for cache-coherence and formal signoff.

Syed Suhaib is a formal verification expert at NVIDIA and shared his view on verifying a coherency manager using architectural formal verification. I’ve written about this before, so you get my standard quick problem recap – you have a verification problem at the system-level (not contained inside a component), there are no obvious long-pole candidates to abstract so instead you abstract everything, replacing components with smaller FSM models to enable verifying control interactions.

Cache-coherence management is a popular target for this style of verification. You have multiple processors each with its own cache but still working with a shared logical memory model. Which means that changes to these caches must be kept coherent across the system. So this is a system-level verification problem, too big to fit in conventional formal proving. The usual abstraction tricks won’t work because everything is too big – CPUs, caches and interconnect. Abstracting one or two of these doesn’t reduce the size enough; you have to abstract everything.

There are multiple ways to implement coherency management; commonly you’ll have a central coherency manager which monitors reads and writes across all caches, looking for potential problems and stalling/updating as needed. The coherency management system is essentially a big FSM with many possible states and transitions covering all the potential sequences of updates, requests and so on. Syed said that a table representation of the protocol can runs to hundreds or thousands of lines.

Simulation is a non-starter for proving correctness because there are just too many possibilities to cover with confidence. In fact one of the early successes for formal was in validating these systems. The state diagram is wide but not especially deep, as long as you look at the problem in the right way, looking just at what is relevant to the proof – the control part of coherency management between CPUs and caches.

I’ve talked before about cross-validation between architectural models and the source RTL so I won’t bore you with it again (see e.g. my blog “System Level Formal”). Syed gave a quite detailed overview on their architectural models for tracker functions (e.g. for snoop and read on their cluster 1 interface), also on the coherency engine read-request FIFO. As a result of this analysis they found a couple of bugs, one an instance where read requests were re-ordered, also a potential deadlock.

An interesting question from the audience was whether they had considered yet more advanced approaches like TLA+ or Murphi. Syed said that the approach they used took 6-9 person-months so was not trivial, presumably implying that those other techniques would have taken even more effort. He did acknowledge that, thanks to abstraction, what they got were not full proofs, but they did get bounded proofs on the model and they did do coverage analysis. Note to the skeptics – what you would get with simulation would be markedly worse. Finally, he said they went with this approach rather than the more exotic approaches because it was familiar. They could build abstracted arch models in Verilog, prove on these and cross-verify with the source Verilog. Who could argue with that?

Mandar Munishwar (formal verification lead at Qualcomm) closed with a discussion on formal verification signoff, particularly complete formal signoff on a block – what does this mean and how to you get there? For Mandar this means answering:

  • Have I written all the checks I need?
  • What is the quality (and coverage) of those checks?
  • Were any of those checks over-constrained?

Unsurprisingly a credible signoff starts with disciplined planning, executing and measuring, especially on the first question, which must be based as much on a system view of needs as any coverage metrics. Since he’s talking about end-to-end (E2E) verification, Mandar likes to capture block behavior in a spreadsheet. For each signal he records: signal type (pulse, level, active type) and relationship with other signals in the same interface, what causes the signal to be asserted / de-asserted, latency between cause and effect, expectation for integrity of the data in transport and finally assertion name(s) corresponding to the natural language (NL) description implied in those entries. This makes a lot of sense to me; it’s a lot easier to review and debate NL expectations in a group than SVA assertions and constraints. Get the NL right first then translation to SVA and checking SVA against the NL definitions is easier and more certain.

Mandar also adds the common component checkers at this point – for FIFOs, counters, arbiters and so on; then execution starts. This is iterative of course – running, checking/fixing counter-examples, work on converging proofs, handling bounded proofs, all the usual steps. In the measurement phase (which overlaps with execution), he checks for over-constrained proofs, relaxing constraints where needed. He also checks coverage, starting from baseline COI coverage – a minimum necessary but far from sufficient requirement. For him, an important part of coverage is the subjective quality check at the planning phase, in review with the team: is the set of checkers sufficiently diverse for each of the block signals across signal type, relationship, causality, etc that they captured in the spreadsheet?

Back on measurement, Mandar is a believer in formal cores being a much tighter test than COI coverage as a measure of real coverage. I wonder if this realization is more important to the folks aiming for full formal signoffs. I think even those who aren’t so ambitious should still be looking at formal cores to understand how little of the logic they are really testing in some cases.

Finally he went back to his original question – can I trust formal signoff? This is a great question. If you have done all that up-front planning to ensure good coverage of checkers, you have made sure no proofs were over-constrained and you have further ensured that you have good formal core coverage, it feels like you should be pretty close, doesn’t it? Mandar suggested one final step. If you introduce a bug into the logic, bullet-proof verification should catch it. (VC Formal supports mutation for this purpose).

Mandar suggested a number of classes of mutation he thought were important to consider: top-output connectivity, reset bugs, lower-level connectivity errors and others (I would add clock-gating errors to this list based on an earlier talk in this session). If the mutation engine introduces bugs of these type and they are detected in proving, then you have yet higher confidence for formal signoff. Is this good enough? Eventually signoff is subjective, whether for simulation or formal, though you want it grounded in tight methodology, review and metrics. It seems like what Mandar proposes is a reasonable definition for formal signoff.

You can learn more about the Synopsys VC Formal solution HERE.

Posted on

Schematic porting – the key to analog design reuse

Schematic porting – the key to analog design reuse
by Tom Simon on 04-02-2018 at 12:00 pm
Categories: EDA, MunEDA

At the beginning of every project the one of the first questions that ought to be asked is whether there blocks from previous designs that can be reused. On the surface this seems pretty obvious. The wrinkle in this is that reusability varies a lot based on the design type and the effort that a team is willing to expend to bring a design forward. HDL’s are at the top when it comes to reusability. There is always some messing with constraints and details, but moving an HDL based design to a new PDK is a well-trod path.

Probably at the other end of the spectrum are analog designs that are captured in schematic form. These are full of vexing idiosyncrasies and PDK specific nuances. In contrast to HDL based blocks, which remain largely intact during a porting exercise, schematics change both structurally and visually. But that is not all, schematic based designs need to have operational parameters optimized for their performance objectives in the new process.

A workable solution for schematic porting needs to be able to convert the design to the new library, adapt the visual representation and also facilitate optimization of the design to the new process. If any of these actions are problematic, schematic porting and subsequent reuse will become troublesome.

MunEDA has made a name for themselves with their advanced analog circuit optimization software, and also have put a lot of effort into their schematic porting solution, called SPT. This gives them the notable advantage of having a complete solution. Let’s look a little deeper at the features that the schematic porting tool offers.

MunEDA’s recently enhanced SPT automatically performs many operations that can make porting by hand tedious and that other porting tools may not handle. The GUI for MunEDA’s SPT is started from inside of Virtuoso. The user selects the source and target PDK’s for the design. SPT makes suggestions for each cell mapping based on cell names. Users of course can change the mappings any way necessary. Property and symbol mapping are handled in an elegant way with a set of mapping rules that can be applied to cells based on common traits. Having classes of property and symbol mapping rules reduces repetitive work when a set of cells are similar.

The mapping setup GUI makes it easy to see the results for each cell. There is built in intelligence to help deal with extra pins, symbols with different orientations and aspect ratios. For instance, after pins are mapped, SPT looks at the orientation of the symbol to determine what orientation is best for maintaining existing connections. There are more features like this; MunEDA has been doing this for a long time and SPT shows the benefit of their experience.

However, as mentioned above the real power of their solution comes from adding powerful analog circuit optimization capabilities to complete the porting task. MunEDA breaks this portion into four phases. First off, their optimization flow is used to fulfill constraints for the design. Then they can perform nominal optimization so specs are met at typical conditions. Then the MunEDA tools ensure that the design meets specs at worst case operating conditions. Finally, robustness is improved with their flow by taking into consideration process variation and mismatch.

All in all, a fairly automated process. Once it is set up for a design, the porting profile can be saved and reused on other blocks easily. MunEDA suggests that what took weeks previously can be accomplished in hours. This certainly is good news for anyone embarking on a project that intends to reuse designs from other fabs or process nodes. The MunEDA website has more information on their schematic porting tool and circuit optimization tools.

Posted on

FPGA Prototyping Speeds Design Realization for the Internet of Things

FPGA Prototyping Speeds Design Realization for the Internet of Things
by Daniel Nenni on 04-02-2018 at 7:00 am
Categories: IoT, Prototyping, S2C EDA

When we talk about the Internet of Things (IoT), it isn’t a stretch to say that every intelligent device we interact with will become connected, sharing vast amounts of data with one another to make our lives more efficient. It isn’t only consumers of smart home, infotainment, and wearable technologies that are driving the demand, but also industrial, military, and government applications such as smart cities and factories that are changing the connectivity landscape.

Webinar April 4 : Achieve High-performance & High-throughput with Intel based FPGA Prototyping

From the Very Small to the Behemoth
When we explore IoT from this perspective, we understand that these devices can range from the smallest designs comprised of a handful of sensors and actuators made up of only a few million gates to extremely complex machines containing hundreds of sensors and billions of gates. Whatever the size and complexity, these smart systems require a great deal more software and real environment tests especially when integrating commercial IP. All of the IoT examples mentioned mandate interoperable connectivity, sophisticated control, and test efficiency forcing design teams to rethink their development strategies. Add to this the time-to-market pressures that consumer IoT devices demand and it becomes clear that engineers need adequate solutions to address these issues.

Getting Confidence in Your Design Early
FPGA-based prototyping is specifically geared toward meeting the design and verification demands created by the complexities of IoT devices. Prototyping technology advances in areas of partitioning and multi-FPGA debug have allowed FPGA-based prototyping to scale to address not only the small multi-million gate designs but also designs of up to 1.5 billion gates. FPGA-based prototyping allows designers to develop and test their systems and provides software developers early access to a fully functioning hardware platform long before silicon is available. The hardware prototype is the only solution that can be employed early enough for practical software development and testing. Software models don’t have the speed and capacity that hardware platforms provide for accuracy and reliability.

Even the smallest designs must negotiate very complex software issues and require an enormous amount if rigorous testing. The nature of this type of testing could run any design into the ground missing crucial time-to-market windows. Although prototyping can take weeks to set up, the number of tests that can be performed in a short amount of time after initial set up severely handicaps other solutions. At the modest of speed (just 5 Megahertz) and after 4 weeks of set up, FPGA prototyping can complete a staggeringly higher number of tests than other solutions just days after its initial set up. For more information on this, you can check out the Emulation vs. Prototyping Cross Over Calculator at http://www.s2cinc.com/prototyping-calculator.

Transactors Are Key to IoT Design Success
FPGA-based prototyping is well-suited for designs that are fully rendered in RTL that can be mapped to an FPGA. However, many IoT-natured designs may not be completely mapped to an FPGA and may be partially still only available as behavioral models in descriptions such as C++ or SystemC. In these cases, transaction-level interfaces play a critical role in being able to bridge the abstraction level between behavioral models and live hardware. These transactors offer a way to communicate between software running on a host and an FPGA-based prototyping platform that often includes memories, processors, and high-speed interfaces.

A system that can harness the power of transactors can allows designers to maximize the benefits of FPGA-based prototypes much earlier in the design project for algorithm validation, IP design, simulation acceleration and corner case testing. A prototype combined with a transactor interface makes a range of interesting applications possible throughout the design flow.

As we move into the next stage of connectivity, devices will need to undergo very exhaustive testing, FPGA prototyping is a key technology that will play an effective role in this process.

Webinar April 4 : Achieve High-performance & High-throughput with Intel based FPGA Prototyping

Posted on

Intel to buy Micron – Trump Blocks IC Equipment Sales to China – Broadcom Fighting for QCOM

Intel to buy Micron – Trump Blocks IC Equipment Sales to China – Broadcom Fighting for QCOM
by Robert Maire on 04-01-2018 at 12:00 pm
Categories: Foundries, Intel Foundry
4 Comments

It has been reported over the holiday weekend that Intel is in talks with Micron over a proposed merger that would value Micron at $70 per share in a deal of a combination of stock and cash for Micron shareholders. It is said that the boards of both companies have already approved the deal.

Intel’s CEO Brian Krzanich said, “We see enormous upside in the memory market over the next decade with the continued move to all things data. We view this as a perfect fit with our position in the data center and new data centric applications”

BK went on to explain why the deal was being done now; “We saw a value opportunity created as our stock price increased on declining sales while Micron’s stock price has declined on increasing sales, this aberration in the stock market created an opportunity we could not ignore.”

It was also reported that part of the unspoken reason for Intel’s acquisition was that Intel was under pressure from the administration to cease its cooperation with China, particularly the new memory fab it was planning on transferring technology to.

In related news, the Trump administration has called for a halt in chip equipment sales to China. The administration is using a unique combination of CFIUS and war powers act to block sales of advanced chip technology to China citing the military and economic threat.

In separate news, Hock Tan has vowed to keep up the fight to convince the administration to allow his bid for Qualcomm to continue.

Broadcom/Qualcomm failure motivated Intel/Micron
An unnamed source at Intel said, “Once the Broadcom/Qualcomm deal was dead we (Intel) were free to pursue other deals without the fear of a new chip behemoth”. ” We feel the Micron deal is a regulatory slam dunk as it’s two US companies in the face of foreign competition. We get an added bonus of bragging rights against Samsung by becoming the world leader in chips once again”.

Merger Moves
There are some other concerns about the merger. As part of the pre-arranged deal with the government included a move of the combined companies headquarters to Boise Idaho which would support the administrations goal of bringing more jobs to the American heartland and out of California.

A White House spokesperson said ” We are supportive of the move of the US chip industry back to its roots and source of its core ingredient in Idaho”

Intel going back to its beginning
By merging with Micron, Intel is going back to its early roots of being a memory manufacturer. Intel was the first to produce a DRAM chip in 1970 with the 1103 one kilobyte memory chip. In 1974 it controlled over 80% of the DRAM market before losing out to foreign competition. Mr Krzanich said “Our goal is to get back to a very high share of the memory market,… if at first you don’t succeed, try, try again….”

Chip Equipment sales to China Halted
As part of the back and forth in the trade tussle between China and the US, the administration took a pre-emptive move by halting “any chip equipment sales to China that includes unique American technology”.

President Trump hailed the decision as part of a comprehensive package aimed at limiting China’s economic and military aspirations.

Press secretary Sarah Sanders went into further detail about specific companies and products; ” Included in the chip equipment ban are laser anneal systems made by Veeco which “bake” chips. Etching systems made by Lam Research which are used to create patterns of “waves or Ruffles” on chips using SADP (self aligned double patterning) printing techniques. Applied Materials deposition equipment was cited for its ability to deposit unique layers of material flavorings including BBQ and Sour Cream”. Sanders went on to say, “We are also protecting our chip packaging industry by limiting the sales of equipment related to chip stacking as currently employed by Pringles which allows for very dense stacking of chips in a unique singular, protected package”

Trump went on to say, ” The American public was kept in the dark about real purpose of all this “chip” technology and its sales to China. We will protect the American chip industry and protect its workers so that Americans will be free to savor chips made in the US for future generations “

Further “Americanization” of Broadcom
As part of its efforts to gain approval to move ahead with its Qualcomm bid the company has accelerated the move of its headquarters and legal domicile back to the United States. This was also part of the agreement with the US agency CFIUS in order for the Brocade acquisition to go through.

In a little noticed SEC filing Broadcom announced that Hock Tan, CEO of Broadcom, has legally changed his name to “Harold Thomas”.

Separately it was announced that Trump would be having an oval office “photo op meeting ” with Thomas. Trump was quoted as saying ” I have never met Thomas before but any American bringing jobs back from Asia will have my full support in whatever he wants to do”. CFIUS was said to be re-evaluating its stance given those comments.

Happy April First!!!