Banner Electrical Verification The invisible bottleneck in IC design updated 1
Semiconductor Expert Forum

Posted on

Cross View Static Validation

Cross View Static Validation
by Alex Tan on 05-08-2018 at 12:00 pm
Categories: EDA, Fractal Technologies

Improper handling of design validation could simply translate into a debugging exercise. In mainstream RTL2GDS flow, design implementation involves a top-level integration and lower-level block developments. These lower-level components, comprising of macros, IPs and standard cells are subjected to frequent abstraction captures as inherently required by many cross-domain development and analysis tools. As a result, validation without automation is becoming a complex debugging feat.

Checklist
In dealing with numerous design view formats such as for netlist or layout, ambiguity may be present at the interface. Port directionality and labeling are critical. Although some attributes or design entities might later be implicitly defined at the top-level –such as the interface signals, which become internal nets at the top-level, correct assignment is still needed for completeness of the subdesign or the model’s boundary conditions. For example default I/O loading condition or input slew rate may be needed to prevent non-realistic ideal scenario.

Many approaches are available to capture a checklist in design flow. Static verification driven processes such as code linting, design rules checks and optimization constraints related checks have been quite effective in shaping design implementation and have their reliance on the use of a comprehensive checklist (rule set). Such checklist is normally aggregated over several project cycles and could be overwhelmingly long as well as complex to automate.

To address this cross data-format IP blocks or library validation need, Fractal Technologies provides Crossfire software. It is capable of doing the following two types of checks:

  • Implementation completeness of a design entity. For example it will compare any item that has been parsed against its equivalent items from a reference. Such checks are applied to all different object types in the Crossfire data model, such as cells, pins, nets, timing arcs and power domains.

  • Intrinsic sanity checks of model databases. For example it uses the various process corners described in library files and check whether delays shows increase with rising substrate temperature or decrease with increasing supply voltage.

In general, there are three usage categories for Crossfire as a sign-off tool for libraries and hard IP’s; as sanity checkpoint in library/IP development and as facility to inspect for the quality of incoming libraries and hard IP’s.

View Formats
Over the last few years, Fractal enhanced the Crossfire validation to expand coverage of settings and database used by many third-party well known implementation and analysis tools. Over 40 supported formats and databases that include the following list:


Bottleneck and Root Cause Analysis
Design rule checks could be in the order of hundreds or thousands. Multiple occurences of them could translate to tens of thousands or higher DRC errors depending on the design size. Similarly for database consistency checks, root causing the trigger point of a downstream error is a tricky feat requiring both traceability and understanding of the data flow.

Fractal Crosscheck has a mechanism to allow quick traceability through color-based connected graphs called fingerprint analysis and visualization (as shown in figure 2). For example designer could view the flagged errors and filter-out only on a cluster of interest through the color aided selection or by way of controlled waivers. This can be done up and down the design entities readily linked. Binning errors based on a rule-pivot or format-pivot can be performed as well.


Another Fractal usage flavor is to perform debug visualization through the use of the reporting dashboard. For example, assuming that an error occurs after running LEF vs DEF check check run, the designer could click on the analyze button to open message window. Subsequently, by selecting the layout view, the portion of the layout contributing to the error is highlighted in a pop-up view.

Library and hard IP validation is key in ensuring a smooth deployment for downstream tools in the design flow. Fractal’s Crossfire provides the facility to bridge many cross-domain design views and rule-based checklist to confirm the integrity of lower-level design implementation. The GUI driven dashboard and fingerprint diagram simplify diagnostic reporting, visualization and debugging process.

Native checks can be combined with externally done validation results (such as from DRC runs) to be viewed through the navigation dashboard. Currently more than 250 checks have been incorporated into Fractal Crossfire.

For more Fractal tool info, including whitepapers on usage cases and features, check this website LINK.

Posted on

Formal Signoff – a Cisco Perspective

Formal Signoff – a Cisco Perspective
by Bernard Murphy on 05-08-2018 at 7:00 am
Categories: Oski Technology, Semiconductor Services

The second segment of Oski’s most recent “Decoding Formal” event was a talk by Anatoli Sokhatski (formal tech lead at Cisco) on training and methodology development for a structured and scalable approach to formal verification, particularly with emphasis on formal signoff.

Anatoli stressed that he and others in the team did not go into this as novices in formal, but they found they needed a more consistent methodology they could carry forward between designs. Formal had been used successfully on previous products, however learning hadn’t really been captured before the experts moved on. I’m beginning to think this is a root-cause for why many organizations still consider formal to be hard. Imagine if you had to re-create, from scratch on each program, UVM and constrained-random expertise, along with coverage measures, assertions and all the other paraphernalia of modern dynamic verification. You don’t have to do that because you can start from a lot of process, assets and training built up over many programs. The same approach equally makes sense for formal.

Anatoli’s talk had three main sections: why formal is so important in verification for networking, a few examples of the methods they use to manage complexity in proofs, and the process they developed around formal signoff to ensure this expertise could carry forward onto other programs.

Formal is important in many contexts, but it’s always interesting to understand the application-specific reasons that make it important to a given domain. For Anatoli, in networking the problem starts with wide busses, deep pipelines and big memories. This is compounded by protocol challenges – packets spread across many cycles, packet interleaving and priority packets breaking into lower priority packets. Together these create one of those challenges so suited to formal – a huge range of combinational possibilities with some sequential depth but not too much, in proving that there is no possible case in which data could be corrupted in some manner.

Anatoli’s group kicked off with an intensive 2-week training Oski training session (lectures and labs) which gave them a solid grounding in flows, principles for calculating required proof depths (needed when justifying bounded proofs), techniques to overcome complexity (which I’ll briefly mention next), abstraction methods, constraints and managing over-constraints, wrapping up with principles of formal coverage and formal signoff.

Anatoli discussed several concepts which I’ve seen touched on in advanced formal usage, though rarely explained in depth. I’m going to give a quick summary here (thanks to info provided by Roger Sabbagh, VP Applications Engineering at Oski). I hope to do a deeper dive on these in a later blog. All of these are prompted by a basic question: how do you check the correctness/ integrity of packets passing through a pipeline when of course those packets can contain arbitrary data?

The starting point (at least for me) is something called the floating pulse method. This is a technique in which the formal tool can assert a single pulse at some arbitrary time after reset, and on that pulse do something special. The special thing that is done in this context is to tag a word in an incoming packet word with an easily recognized ID, a process widely known as coloring. That color can then be spotted at a later/deeper cycle, allowing for various kinds of check.

So for example, Anatoli said they applied this method to check that the time between the floating pulse on an incoming packet, and when that forwarded colored data appeared at the output. This should fall within a required maximum number of cycles. The clever trick here is that, thanks to the floating pulse method, the formal tool effectively tracks anyelement of anyincoming packet, therefore verifying that this maximum number of cycles holds for all possible packet sequences.

Anatoli talked about other checks, but I’ll mention just one that I particularly like, not least because it has confused me for a long time. This is Wolper coloringand is used (at least here) for data integrity checks. The same general approach is followed as above, but in this case, twoconsecutive words are colored, presumably differently, in the incoming packet. The check at the output is then that the same words are seen consecutively, in the correct sequence, with no additional colored words around them. This confirms that no words were dropped, no words were replicated, words weren’t swapped and nothing was inserted between words. In other words, data integrity was preserved. Again, pretty clever.

The third part of Anatoli’s presentation was on how they setup a repeatable and scalable flow, particularly for formal signoff though I imagine elements of this approach would be useful even for basic property proving. The first step towards not having to reinvent the wheel each time in a process must be documentation and templates. He detailed their approach:

  • A document describing phases & milestones

    • FV Planning, Basic Function Complete, Main Function Complete, Block Ready for Speculative Freeze, FV complete
  • A detailed description for/definition of each phase; for example for Main Function Complete:

    • Checkers implemented for all non-error cases
    • Constraints implemented for all non-error cases
    • Over-constraints applied to disable error cases
  • Defined exit criteria for each phase, for example for FV Complete:

    • Final FV Environment Specification review
    • Final FV Test Plan review
    • Checklist approved

Templates include a checklist for each milestone (e.g. review required proof depth per assertion, review cover properties), a documentation template (e.g. interface components, E2E checkers, testbench configurations). Finally, they capture this in their (in-house) testplan tracking tool (similar I would guess to Cadence vPlanner/vManager). May all seem like a bunch of bureaucratic overhead, but anyone who has had to launch similar tasks more than twice or been tasked with training new hires on verification setup will instantly understand the value of this process.

Naturally they support all of their regression testing through in-house Makefile flows, which they use to run both simulation and formal testing (with different goal scripts per task). One aspect I found interesting is that they control proof parameters through Makefile macros, which simplifies setting up case-split runs (though no doubt they may need to experiment with this to ensure they cover all the parameters on which they might want to split).

Anatoli made a final point on interface checkers. Even though they are aiming for formal signoff, they still want to roll up interface checks (assertions and constraints) to simulation so they capture these in a separate file which can easily be reused in sim regressions. A reminder that even the more advanced users of formal methods (E2E checks) still want to sanity check against simulation. You can watch the video HERE.

Posted on

AI processing requirements reveal weaknesses in current methods

AI processing requirements reveal weaknesses in current methods
by Tom Simon on 05-07-2018 at 12:00 pm
Categories: AI, Analog Bits, IP
1 Comment

The traditional ways of boosting computing throughput are either to increase operating frequency or to use multiprocessing. The industry has done a good job of applying these techniques to maintain a steady increase in performance. However, there is a discontinuity in the needs for processing power. Artificial Intelligence (AI) is creating an exponential increase in throughput. Strategies for delivering more performance for AI have included moving to increased numbers of processors and moving to architectures that include GPUs and FPGAs.

Nonetheless, hard obstacles exist in using these approaches. For starters, processor speeds have been frozen at ~4GHZ for quite some time. This is why parallel processing has become the method of choice. Yet, as the number of processing elements increase, the performance per processor decreases as overhead ramps up. This is a result of a combination of hardware limitations and the difficulty in fully utilizing in software the available computing power. With multiprocessing, GPUs or FPGAs, there is consistently a bottleneck with the ‘head end’ processor. AI exacerbates this with its inherently parallel operation with massive peer-to-peer data transfer needs.

Wave Computing has developed systems that use a completely new, underlying dataflow processor architecture optimized to run machine learning (ML) workloads effortlessly and at scale. Their massively parallel data processor unit (DPU) chips contain 16,000 individual processors that are highly interconnected. Each processor runs non-branching instruction sequences, handling training or inference tasks at clock rates pushing 6 GHz. This is possible because they have eschewed a global clock signal and use an elegant synchronization method to keep the processors in step with each other.

In the Wave Compute Appliance, multiple chips are used to achieve up to 128,000 processing elements per appliance. Four appliances can be combined to provide 512,000 processing elements.

The hard work of delegating processing across the reconfigurable array is done up front with their programming tools. Without the need for a central task scheduler, their solution avoids a major potential choke point. In addition to a throughput advantage, their approach offers a significant energy advantage with the deskside system consuming no more than 0.16kW.

Naturally, the system connectivity and memory needs to be optimized to take advantage of their dataflow architecture. Their DPU boards have slots for 32GB of interconnected high-speed, high-bandwidth DRAM, and are equipped with 512GB of DDR4 high-capacity DRAM. Additionally, there is PCIe connectivity. Wave Computing had the task of building in extensive and varied high-speed off chip interfaces. To meet their power and performance needs at 16nm, they tapped Analog Bits for the SOC’s critical SerDes IP.

Using optimized SerDes can save a lot of area and power, given the increasing portion of a total chip’s resources they are consuming in newer designs, with many lanes and higher data rates. Wave Computing wanted to provision SerDes that matched the power sipping characteristics of their DPUs. Analog Bits offers a state-of-the-art, non-LC based SerDes that supports multiple protocols and is tolerant of metallization and orientation changes. This means that on three sides of their DPU, Wave Computing was able to use the one SerDes to support all their needs. Analog Bits’ 16nm low-power SerDes needs only 4mW/Gbps to operate up to 10Gbps. Above 16Gbps, their solution only uses 6.5mW/Gbps.

Wave Computing estimates that AI training can use 80% of data center capacity. Deploying a faster and more energy efficient data center resource for this activity could dramatically change AI performance and its carbon footprint. A side benefit will be the ability to allow for more experimentation and ultimately the development of better algorithms. A data scientist could have a supercomputer at their deskside for their dedicated use. Alternatively, with lower power densities and more compact packaging, serious computing power can move from the cloud closer to the edge to provide lower latency and better data fusion.

Comprehensive information about Analog Bits’ analog IP can be found on their website. To learn more about Wave Computing’s solution that uses this IP, I suggest looking on their website and checking out the white papers on their dataflow technology.

About Wave: Wave Computing is revolutionizing the deep learning industry by enabling organizations to drive better business value from their data with its roadmap of WaveFlow™ computing systems. The company’s innovative system solutions based upon dataflow technology provide high-performance training and high-efficiency inferencing at scale, bringing deep learning to customers’ data wherever it may be. Wave Computing was named a Machine Learning Industry Technology Innovation Leader by Frost & Sullivan, and a Top 25 Artificial Intelligence Provider by CIO Application Magazine.

About Analog Bits:Founded in 1995, Analog Bits, Inc. (www.analogbits.com), is a leading supplier of mixed-signal IP with a reputation for easy and reliable integration into advanced SOCs. Products include precision clocking macros such as PLLs & DLLs, programmable interconnect solutions such as multi-protocol SERDES and programmable I/O’s as well as specialized memories such as high-speed SRAMs and TCAMs. With billions of IP cores fabricated in customer silicon and design kits supporting processes from 0.35-micron to 7nm, Analog Bits has an outstanding heritage of “first-time-working” with foundries and IDMs.

Also Read:

7nm SERDES Design and Qualification Challenges!

CEO Interview: Alan Rogers of Analog Bits

IP development strategy and hockey

Posted on

My advice to the world’s entrepreneurs: Copy and steal the Silicon Valley way

My advice to the world’s entrepreneurs: Copy and steal the Silicon Valley way
by Vivek Wadhwa on 05-07-2018 at 7:00 am
Categories: General
1 Comment

In a videoconference hosted by Indian startup media publication Inc42, I gave entrepreneurs some advice that startled them. I said that instead of trying to invent new things, they should copy and steal all the ideas they can from China, Silicon Valley and the rest of the world. A billion Indians coming online through inexpensive smartphones offer Indian entrepreneurs an opportunity to build a digital infrastructure that will transform the country. The best way of getting started on that is not to reinvent the wheel but to learn from the successes and failures of others.

Before Japan, Korea and China began to innovate, they were called copycat nations; their electronics and consumer products were knockoffs from the West. Silicon Valley succeeds because it excels in sharing ideas and building on the work of others. As Steve Jobs said in 1994, “Picasso had a saying, ‘Good artists copy, great artists steal,’ and we have you know always been shameless about stealing great ideas.” Almost every Apple product has features that were first developed by others; rarely do its technologies wholly originate within the company.

Mark Zuckerberg also built Facebook by taking pages from MySpace and Friendster, and he continues to copy products. Facebook Places is a replica of Foursquare; Messenger video imitates Skype; Facebook Stories is a clone of Snapchat; and Facebook Live combines the best features of Meerkat and Periscope. This is another one of Silicon Valley’s other secrets: if stealing doesn’t work, then buy the company.

By the way, they don’t call this copying or stealing; it is “knowledge sharing.” Silicon Valley has very high rates of job-hopping, and top engineers rarely work at any one company for more than three years; they routinely join their competitors or start their own companies. As long as engineers don’t steal computer code or designs, they can build on the work they did before. Valley firms understand that collaborating and competing at the same time leads to success. This is even reflected in California’s unusual laws, which bar noncompetition agreements.

In most places, entrepreneurs hesitate to tell others what they are doing. Yet in Silicon Valley, entrepreneurs know that when they share an idea, they get important feedback. Both sides learn by exchanging ideas and developing new ones. So when you walk into a coffee shop in Palo Alto, those you ask will not hesitate to tell you their product-development plans.

Neither companies nor countries can succeed, however, merely by copying. They must move very fast and keep improving themselves and adapting to changing markets and technologies.

Apple became the most valuable company in the world because it didn’t hesitate to cannibalize its own technologies. Steve Jobs didn’t worry that the iPad would hurt the sales of its laptops or that the music player in the iPhone would eliminate the need to buy an iPod. The company moved forward quickly as competitors copied its designs.

Technology is now moving faster than ever and becoming affordable to all. Advances in artificial intelligence, computing, networks and sensors are making it possible to build new trillion-dollar industries and destroy old ones. The new technologies that once only the West had access to are now available everywhere. As the world’s entrepreneurs learn from one another, they will find opportunities to solve the problems of not only their own countries but the world. And we will all benefit in a big way from this.

For more, follow me on Twitter: @wadhwa and visit my website: www.wadhwa.com.

Posted on

Automotive FD-SOI Update

Automotive FD-SOI Update
by Daniel Nenni on 05-07-2018 at 7:00 am
Categories: Automotive, FD-SOI, Foundries, GlobalFoundries

GF FD SOI

We have been tracking automotive related articles on SemiWiki since 2015 and have published more than 300 automotive blogs thus far that have garnered more than one million views. The automotive publishing pace has picked up quite a bit lately and the number of domains reading them has increased exponentially. So yes, automotive is a big deal for the semiconductor business, absolutely!

GlobalFoundries has a very nice automotive landing page to get you started. If you look at the market overview you will see the different market segments: Powertrain, Advanced Driver Assistance (ADAS), Infotainment, Body (human) Electronics, Instrument Cluster, Chassis and Safety, and EV.

FD-SOI is also a popular topic on SemiWiki. Since 2013 we have published 90 blogs that have been viewed close to one million times. FD-SOI is also one of the most commented on topics on Semiwiki. In fact, when I first blogged about FD-SOI I immediately thought of two markets: China and Automotive.

Today the automotive market is hot around the world especially in China so the question I had for GlobalFoundries after their latest FD-SOI design win with Arbe Robotics for Resolution Imaging Radar to Enable Safety for Autonomous Cars was: How does FD-SOI compare to FinFET or bulk planar technology for reliability aging?

Reliability aging is one of my biggest concerns with automotive semiconductors especially when talking about autonomous cars. My wife and I generally keep our cars for about 10 years (100,000 miles) and we keep our iPhones for 1-2 years. The National average for new car ownership seems to increase every year and is close to 6 years according to Kelly Blue Book. But the average life of a vehicle is at an all-time high of 10.8 years which matches us since we generally buy new cars.

Jamie Schaeffer, Sr. Director of product line management, at GF gave me the answer I was looking for:

All technologies are qualified to industry standard specifications, performance is the variable that is maximized while still satisfying the reliability limits of a predefined lifetime specification.22FDX, however, provides three unique advantages for reliability aging compared to bulk planar or FinFET technologies:

First, utilizing body-bias to boost frequency has inherently less impact on reliability lifetime compared to the traditional approach of applying voltage overdrive. Body-bias has zero to minimal impact on typical reliability parameters (TDDB, BTI, HCI) compared to voltage overdrive which strongly accelerates reliability aging and restricts design parameters such as Temperature, Lifetime, Area, or PPM.

Second, by using adaptive body-bias techniques the designer can compensate for reliability aging effects in their design. This enables power and area efficiencies by designing with less margin and compensating, real-time, for aging induced performance degradation through the use of on-die process monitors, controller IP, and body-bias generators. The use of body-bias is also more precise, less noisy, and less sensitive to IR drop than applying voltage overdrive techniques.

Third, 22FDX has superior soft-error rate for alpha and neutron radiation compared to bulk technologies giving it an intrinsic advantage compared to bulk technologies for radiation induced aging effects. For single-cell upsets 22FDX demonstrates 30x better FIT/Mbit (failure in time per Mbit) and for multi-cell upsets 22FDX demonstrates >1000x better FIP/Mbit compared to the historical trend of bulk technologies including 28, 40, and 45nm nodes. The improved SER in 22FDX saves layout space and computation overhead for ECC.

Jamie is one of my favorite sources/speakers at GF. He has a PhD from the University of Texas at Austin in Material Science and Engineering and started his career at Freescale in 1997 before joining GF in 2010. If you have more questions for Jamie post them here and I will make sure they get answered.

Posted on

Top 10 Highlights of the TSMC 2018 Technology Symposium

Top 10 Highlights of the TSMC 2018 Technology Symposium
by Tom Dillinger on 05-04-2018 at 12:00 pm
Categories: Events, FinFET, Foundries, TSMC
9 Comments

Here are the Top 10 highlights from the recent TSMC 2018 Technology Symposium, held in Santa Clara CA. A couple of years ago, TSMC acknowledged the unique requirements of 4 different market segments, which has since guided their process development strategy — Mobile, High-Performance Computing (HPC), Automotive, and IoT. Many of the highlights described below are in the context of a specific platform.
Continue reading “Top 10 Highlights of the TSMC 2018 Technology Symposium”

Posted on

Samsung 10nm 8nm and 7nm at VLSIT

Samsung 10nm 8nm and 7nm at VLSIT
by Scotten Jones on 05-04-2018 at 7:00 am
Categories: Events, FinFET, Foundries, Samsung Foundry, Semiconductor Services, TechInsights
33 Comments

I got a tip sheet today for the upcoming 2018 Symposia on VLSI Technology & Circuits to be held June 19th through 21st in Honolulu, Hawaii. There is some interesting information on Samsung’s 10nm, 8nm and 7nm processes in the tip sheet:
Continue reading “Samsung 10nm 8nm and 7nm at VLSIT”

Posted on

IP Vendor Tuning of Your SoC A Practice for Design Success

IP Vendor Tuning of Your SoC A Practice for Design Success
by Camille Kokozaki on 05-03-2018 at 12:00 pm
Categories: IP, Synopsys

On April 17, Mick Posner, Director of Product Marketing, IP Subsystems, Hardening & IP Kit solutions held a Webinar entitled ‘Getting more from your IP Vendor, IP Tuned to Your SoC’. This brought back memories of the challenges in days past of making the right choices in IP selection, integration and validation when prudence limited choices and necessity dictated over-design or schedule push-out to make sure nothing was overlooked. Even with that, there were some setbacks followed by workarounds or waivers or fixes or ‘bug-as-a-feature’ specifications.

Luckily, we are in a golden age of design where success is more the norm and discipline and methodology complement the availability of pre-designed, pre-verified IP that interoperates and simplifies the task of subsystem and system verification.

The webinar addressed silicon design trends, approaches to faster IP integration, IP software development acceleration, IP validation and bring-up, DesignWare IP from architecture to silicon.
Increased System complexity has Silicon Design trends moving towards increased reuse of pre-designed and validated IP blocks and subsystems. This limits the task of verification to ensuring functionality at crossing boundaries of the IP interfaces and with this reduced exposure to implementation variability and increased consistency, the verification duration is reduced along with the functionality risk.

An IP Subsystem is far more complex than one realizes at first. As an example, one subsystem may contain more than a controller and PHY. You have unique logic intended to address clocking, reset, interrupts, DFT, security, and booting sequences to name a few. To address this, you need more than an RTL designer, you need expertise in layout, backend, test.

In addition, system level issues must be addressed like interface customization, interoperability, test and FPGA bring-up, interface simulation debug. Additional challenges exist like adequate throughput, latency, a timely schedule for tape out and silicon bring up.

This is where your IP provider can increase the chances of success, allowing a fast integration of IP into your SoC, enabling the acceleration of IP software development and the experience to support comprehensive silicon bring-up.

From the initial critical decisions in architecting the SoC design where low power strategies, performance, and area can be gauged and optimized to leveraging protocol expertise of Synopsys IP R&D team, you are able to define the SoC correctly right from the start and implement it with the least amount of delay and the highest degree of confidence in proper implementation. Custom IP Subsystems tailor functionality to your requirements and accelerate your Time-to-Market with a reduced Design Risk.

A comprehensive provision of resources, test suites, monitors, synthesis scripts and integration documentation combine to make the integration of the IP subsystem as seamless as can be. Case studies from High-End Application Mobile Processor design with a high number of IPs and complex power domain shutoff to IP Hardening with Performance and size optimization, involving floor planning, clock balancing and timing analysis. Hardening services with Signal and Power Integrity on Low-Power, High-Performance Mixed-Signal are another example of the breadth and width of available assistance. Five days of SoC integration support come with the typical IP hardening effort.

IP Hardening Benefits
• Integration: Enables faster PHY and/or Subsystem integration
• Floorplan: Explore high-performance design to find an optimal solution for a given PHY
• Placement: Deal with a high power density in reduced core power areas
• CTS: Leverage access to custom cell development to meet performance targets
• Routing: Experience to allocate higher metal layers for critical signals for higher performance

DesignWare DDR PHY hardening projects in Wireless, Networking, Video, and Automotive applications have been supported in a wide range of process technology nodes.

Software IP Software Development acceleration is another important aspect of support of DesignWare prototyping kits enabling Reference Design and Reference Software Stack with the provision of immediate out-of-the-box hardware or software -only Kits. Expert support in Silicon Bring-Up is another aspect of the comprehensive Synopsys offerings.

The Synopsys Global IP Development and Support Organization includes 2400+ R&D engineers, 220+ Application engineers, and 30 Program Managers. These all accomplish the task of getting more from the IP Vendor, combining the customer vision and Synopsys expertise from Architecture to Silicon.
Register to view the webinar replay

Posted on

Peering Over the Timing Edge

Peering Over the Timing Edge
by Bernard Murphy on 05-03-2018 at 7:00 am
Categories: Ansys, Inc., EDA, FinFET, Mobile

I wrote recently about a yield problem which mobile vendors have been finding for devices built in advanced technologies. This was a performance issue (the devices worked fine at lower clock speeds), pointing to a discrepancy in some devices between predicted and observed timing. These were experienced design teams, using state of the art timing flows and libraries and yet performance yield was 10% lower than expected. This should raise a concern – are we approaching a point where current approximations for timing are becoming insufficient for signoff?

When we started analyzing timing, back in the days of really small circuits, we used SPICE. Designs grew, SPICE was no longer practical for full-circuit analysis, so we switched to cell-based design, with cells characterized for timing (ultimately in the Liberty format), with which we could do static timing analysis (STA) and drive timing-based synthesis and physical design. Those timing models have evolved through multiple versions as processes have shrunk and manufacturing variabilities have become more important, but we’ve still managed to retain the concept of cell-based timing models in some form, albeit more complex and requiring more corners to fully capture process variations. Factors which cannot be captured at the cell-level, such as power noise, have been managed by setting global margins and ensuring that IR-drop (in the power-noise case) does not stray outside those margins.

But the non-cell-based factors are becoming more troublesome at advanced processes where nominal voltages are much closer to threshold. Now noise, both in power and ground, can squeeze actual potential differences below threshold, pushing delays and slew rates well outside the nominal characterization range. Compensating by further increasing global margins becomes prohibitively expensive in power routing, decaps and ultimately total die cost. Which means we now must deal with instance-based and use-case-sensitive modeling; cell-based timing models, complemented by margins, are not sufficiently accurate for cost-effective design.

I doubt this is a cliff-edge in timing. The Liberty style of modeling (with many corners) still works well for huge designs on the most advanced processes. But we’re starting to see evidence, as I mentioned in that earlier blog, that accuracy is deteriorating noticeably (10% performance yield hit) at the fringes. Over time hopefully the library solution will improve further but that’s not a near-term fix. Monte-Carlo SPICE (MC-SPICE) can be used today but even in massive parallelism will be bounded to hundreds of paths, not very compelling on the mega-designs of today with potentially tens of thousands of paths near-critical.

Of course, there is another solution, one I’ve written about before – the FX platform from ANSYS. FX doesn’t look at Liberty models or faked waveforms. It does transistor-level modeling of the circuit with analog waveforms, Miller capacitances and the like. It’s not SPICE but it’s close – within 2% accuracy when compared with SPICE on one 7nm example operation at 435mV (sub-threshold). And it runs much faster than MC-SPICE, able to analyze up to 10K paths per hour.

Better yet, FX can model both voltage and ground noise accurately with real use-case waveforms. It’s integrated with the RedHawk product family – RedHawk and RedHawk-SC – for detailed IR-drop analysis and DvD-aware clock-jitter analysis. It can also do aging analysis, looking at per-transistor degradation (increase in Vt) as a result of use-case-dependent electrical stress.

Clearly even at this performance, FX doesn’t replace STA for bulk timing on SoCs. But when it comes to signoff for paths close to critical, higher accuracy will be necessary, with higher throughput than you can get with MC-SPICE. Why not just stick to Spicing a few hundred paths? If STA+Liberty was sufficiently accurate you could, if you knew for certain that no other paths were near-critical. But as outlined above, the standard flow isn’t sufficiently accurate near-critical. So you need check a larger selection of paths. Remember that what should be checked can’t be judged solely by how close STA says the path is; you also must consider use-cases which may promote big IR-drops and ground bounces. ANSYS mentions a customer example: a path thought to be just fine, which proved to be a real problem in a realistic use-case.

Over the long-term, where might this go? No doubt the STA/library model approach will continue to improve but there has to be some upper bound to acceptable model complexity given bounded return in accuracy for those models. That said, there is too big an investment in cell-based design and STA-based signoff methods to abandon this methodology. Perhaps there will be a shift over time to using Liberty-style models and STA for the bulk of the timing heavy-lifting, complemented by SPICE or FX-like methods for signoff near the margins.

You can watch a detailed webinar on the FX platform HERE.

Posted on

ISO 26262: Automotive electronics safety gets an update in 2018

ISO 26262: Automotive electronics safety gets an update in 2018
by Tom Simon on 05-02-2018 at 12:00 pm
Categories: Automotive, EDA, Siemens EDA

In the field of automotive electronics, the year 2011 was a long time ago. So, it is about time that the initial ISO 26262 specification that was adopted back then gets an update. The latest version will be known as ISO26262:2018 and will expand the scope of the original to cover more types of vehicles. It will add an entire section on semiconductors. This is good because with the existing standard there were many questions about best practices for semiconductor design.

The original specification only applied to passenger vehicles with a maximum gross weight of 3,500 kilograms. The weight limit is being eliminated and the spec adds other vehicles such as trucks, buses, and even motorcycles. The 2011 version applied to automotive electronic systems, but had little to say about semiconductors or the tools used to develop them. Very often this created confusion for chip developers and even more so for IP providers. ISO 26262 was really a system level specification, and sub-components could not be certified. Individual IC’s became what is known as a Safety Element Out of Context (SEooC). I have attended many technical panels where the participants tried to parse the implications of the 2011 standard in this regard. Hopefully the 2018 standard will add clarity here.

It is impossible to talk about semiconductor quality if we do not include the tools used to design and verify them. The 2018 version enumerates four different methods that can be applied to help qualify tools. The level needed depends on the characteristics of the tool as used in the flow. So called Tool Confidence Levels come from a determination of two inputs. The first is Tool Error Detection (TD1-TD3), with 1 being a high degree of confidence that the tool can detect an error. The second is Tool Impact (TI1-2), with TI1 being no chance that a tool malfunction can lead to a design failure. There is a matrix that combines these two factors into the Tool Confidence Level (TCL1-TCL3). When looking at the precautions necessary for a given automotive function, the ASIL level of the function has to be factored in.

Mentor has put together a useful white paper on the updates in ISO26262:2018. Included in this are some tables that help map out the effort recommended on tool qualification, given the inputs of TCL and ASIL. See the figure below from their white paper.

It’s an important to acknowledge that the tools used to design electronics for automotive use are an essential link in the quality chain. Over the decades that I have been involved with design tools, there has been an evolution from what you might call the early frontier days, to what is now a fairly sophisticated approach to tool and tool result quality. This has largely happened through pressure from customers. Of course tool vendors have also been willing participants in this activity, witness the ISO 9000 push years back. Through all of this, tool customers have learned and adapted in order to get their job done – namely to produce reliable chips.

Better tool qualification helps everyone, so having ISO26262 with its automotive origins providing the catalyst is not a bad thing. Maybe now that chips are being used in applications where failure could be life threatening, it is more than just a good thing. Tool vendors like Mentor have and will continue to invest in improving their tools to meet the new higher standards. It’s good to see them engaging in the public conversation around the ISO 26262 standard, and the upcoming related standards for fully autonomous vehicles. If you want to give their white paper a full read through it can be found on their website.