Bronco Webinar 800x100 1
Semiconductor Expert Forum

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!!!

Posted on

Nvidia: What the Doctor Ordered

Nvidia: What the Doctor Ordered
by Roger C. Lanctot on 04-01-2018 at 7:00 am
Categories: Automotive

Nvidia has an affinity for taking on computational challenges. Whether it be diagnostic tools derived from medical imaging, mapping the earth’s core or defining the structure of HIV, Nvidia is there with GPU computational resources to amp up the teraflops and shrink the computing time. In fact, according to Nvidia’s most recent earnings report, GPUs are increasingly being turned to by the leading creators of supercomputers in the U.S. and Japan.


The automotive industry has brought Nvidia the toughest test yet, in the words of Nvidia CEO Jensen Huang, in the form of mastering automated driving. In the midst of regulatory and legislative battles over self-driving technology, Nvidia has stepped forward with a clear path toward solving the problem and closing the gap between current and future safe autonomous vehicle performance.

Regulators and politicians may pontificate about autonomous technology but Nvidia is getting down to business. Nvidia is in a unique position to solve the problem as a public company at the center of an ecosystem of 370 development partners (and growing) all working on the autonomous driving challenge. Nvidia brings to that challenge a portfolio of hardware, software, servers, code libraries and technicians all working toward the same objective in real-time in the real world.

The implications of Nvidia’s market position are most significant because the challenge shared by all is getting, in the words of Nvidia CEO Jensen Huang, “from 1 million miles to 1 trillion miles.” To achieve any level of confidence in an automated driving system, developers will need to drive or simulate driving hundreds of billions of miles. If there is a company on the planet that knows anything about simulation, it is Nvidia.

In his keynote at GTC 2018 in San Jose this week, the Nvidia CEO picked up the automated driving gauntlet signifying Nvidia’s intention to conquer that challenge with new tools in the form of its DRIVE Constellation – a computing platform based on two different servers.

The first server runs Nvidia DRIVE Sim software to simulate a self-driving vehicle’s sensors, such as cameras, lidar and radar. The second contains a powerful Nvidia DRIVE Pegasus AI car computer that runs the complete autonomous vehicle software stack and processes the simulated data as if it were coming from the sensors of a car driving on the road.

Autonomous vehicle creators like Waymo and Cruise have been able to rack up single digit millions of miles from the dozens or hundreds of test vehicles they have been able to put on roads. But the weakness of this brute force method is manifest in the individual on-road mishaps and, in the case of Uber just last week, fatalities that result from unanticipated scenarios or system failures.

Automotive industry safety standards allow little or no room for failure and here, too, Nvidia is a leader. Huang says the Nvidia line up represents “the first line up of computers that Nvidia has ever made that stands up to the highest standard of functional safety ISO 26262 and ASIL-D. It is the first time that we have delivered this level of software and hardware complexity.” In fact, Huang describes the earlier announced Xavier as “the most complex SoC the world has ever created.”

One might wonder what Nvidia’s reward has been for the millions of dollars the company is pouring into the development of these self-driving compute platforms. The reality is that Nvidia’s shift in focus from automotive infotainment systems to autonomous driving technology has been almost as challenging as the process of creating those new systems.

Gaming, datacenters and professional visualization remain the dominant portions of Nvidia’s business. Revenue growth for automotive in the most recent quarter was a disappointing 3% and down sequentially as a result of this transition from infotainment to safety. Driving automation appears to be the correct bet for Nvidia, but it’s clearly a long-term play.

Nvidia’s commitment, though, is clear and deep – maybe that’s because the company sees a trillion-dollar opportunity, according to Huang. Presenters at the GTC event in San Jose are sharing papers on everything from object detection to driver monitoring with the common threads being the application of artificial intelligence and deep learning with Nvidia’s help. It would be hard to find a more technically oriented event focusing on automated driving anywhere in the world.

The scope of Nvidia’s comprehension of the task and CEO Huang’s grasp of the nitty gritty details was manifest in the closing segment of his keynote yesterday which focused on a virtualization exercise enabling a remote driver to guide a driverless vehicle. Huang called the audience’s attention to a fact that few have grasped that autonomous vehicles will require remote operation and control – a solution to which Nvidia has already created.

The only issue unaddressed by Nvidia’s impressive presentation was the special role the company is playing in the automation of driving. At a time when car companies and their suppliers are just beginning to come to grips with the need to share information and even vehicle data, Nvidia is in a unique position to create a data sharing platform to further accelerate the advancement of autonomous vehicle technology.

Nvidia’s Huang gave only the slightest hint of such a prospect. With 370 partners – and growing – it will be hard for the company to ignore the opportunity. It may even be something that partners seek out or that regulators require. Shrinking the 1M-to-1T gap will require more than simulation – it will require collaboration and data sharing. Huang made a single comment regarding the prospect of “opening up” Nvidia’s data sets during an analyst Q&A at the end of the day yesterday. Time will tell whether this is part of Nvidia’s solution to what may be its greatest challenge ever.

Posted on

FlexE at SoC IP Days with Open Silicon

FlexE at SoC IP Days with Open Silicon
by Daniel Nenni on 03-30-2018 at 12:00 pm
Categories: AI, Automotive, Events, FinFET, IoT, IP, Open-Silicon, RISC-V, Security

On Thursday April 5th the Design and Reuse SoC IP days continues in Santa Clara at the Hyatt Regency (my favorite hangout). SemiWiki is a co-sponsor and I am Chairman of the IP Security Track. More than 400 people have registered thus far and I expect a big turnout, if you look at the program you will see why. You should also know that registration is free and the food at the Hyatt is exceptional, absolutely!

In addition to RISC-V, IP Management, Automotive IP, Design Automation, Security IP, eFPGA, NVM, and Video IP, there is an Innovative IP section that features a talk “FlexE IP – A New flexible Ethernet client interface standard” presented by Vasan Karighattam, VP of Engineering, SoC and SSW, at Open Silicon. Prior to Open-Silicon, Vasan led the development of next-generation architectures of MDSL / HDSL transceivers and service framers, and was a key participant in the standards activity for the IEEE 802.17 Resilient Packet Ring MAC in the Optical Components group at Intel Corporation.

Here is the presentation abstract:

Traditional hierarchical network model with several explicit layers of devices are evolving to more simplified network model with a cloud services layer and a transport layer. FlexE (Flexible Ethernet) is a communications protocol published by the Optical Internetworking Forum (OIF). FlexE enables equipment to support new Ethernet connection types enabling simplified packet transport. FlexE allows data center providers to utilize optical transport network bandwidth in more flexible ways. FlexE dissociates the Ethernet rate on the client side from the actual physical interface (also called server) by introducing a new shim through the IEEE defined MAC and PCS layers. FlexE supports bonding, sub-rating, and channelization capabilities.

Open-Silicon’s FlexE IP is fully compliant to the OIF FlexE standard supporting various MAC client rates. Built upon a flexible and robust architecture, Open-Silicon’s FlexE IP core is compatible with various MACs supporting different rates. The FlexE IP supports FlexE aware, FlexE unaware and FlexE terminate modes of mapping over the transport network. Designed to be easily synthesizable into many ASIC technologies, the Open-Silicon FlexE IP is uniquely built to work with off-the-shelf MACs from leading technology vendors. Using vendor-specific proven MACs allows for fast and seamless integration of the FlexE IP into the technology of choice.

If you need a quick primer on FlexE here is an animated chalk talk from Sebastien Gareau, Hardware Systems Architect at Ciena:

https://www.youtube.com/watch?v=UQf1nFt3bdc

You can also see a deep dive FlexE presentation from the Internet Engineering Task Force from March 2017:

What is Flexible Ethernet

“FlexE refers to a generic mechanism defined in OIF-FLEXE-01.0 implementation agreement for supporting a variety of Ethernet MAC rates e.g.: – 200G MAC through bonding of 100GBASE-R PHYs – sub-rate of 50G MAC over a 100GBASE-R PHY. The FlexE group refers to a group of from 1 to 254 bonded 100G Ethernet PHYs. FlexE utilizes the FlexE group framework to provide the aforementioned flexible MAC rates.”

In addition to the rich technical content, more than 20 of your favorite IP companies will be on hand for networking, demos, and giveaways. Open-Silicon will showcase their Comprehensive IP Subsystem Solution for High-End Networking Applications and demonstrate its Comprehensive High Bandwidth Memory (HBM2) IP Subsystem Solution for 2.5D ASICs using FinFET technologies.

Remember, this is a free event and the food is exceptional. I hope to see you there!

Posted on

Meeting the Challenges of National Defense Strategy

Meeting the Challenges of National Defense Strategy
by Alex Tan on 03-30-2018 at 7:00 am
Categories: Cadence, EDA

In February this year, the Department of Defense (DoD) submitted a $686.1 billions budget for 2019 and published a National Defense Strategy outlining the overall spending for defense and military programs. The recently signed US $1.3 trillion spending bill included part of the funding. According to DoD Defense Budget Overview document, the increase in defense related program is anticipated to gradually increased over the next five years (refer to fig. 1).

As illustrated in fig. 2, the strategic approach of DoD is to expand competitive space by means of having creative operating concepts, interoperability, accelerate cycle of innovation and revitalize alliances and new partners.

As a solution provider, Cadence has a strong presence in the defense sponsored programs and has established good relationships with relevant parties in both congressional and the DoD ecosystem. Cadence’s active participations in DARPA programs such as CRAFT (Circuit Realization At Faster Timescales), CHIPS (Common Heterogeneous Integration and IP Reuse Strategies) and ACT (Arrays at Commercial Timescales) are some notable examples. Cadence holds a DoD Facility Security Clearance, offers “cleared” engineering resources and maintains commercial relationships with virtually every company that designs or provides electronics to the DoD. Cadence ability to leverage commercial best practices within the confines and requirements of national defense has been key to its success in navigating through its continuous evolution. In the public research domain, over 250 US universities (over a thousand worldwide) have also participated in Cadence Academic Network program, which exposes roughly thirty thousands students annually with best industry practices and design technology.

Cadence Solution and Enablement Strategy
With its design automation tools, semiconductor IP and solution flows, Cadence has systems design enablement comprising of three tenets:
-Acquire internal expertise on end markets requirements.
-Work directly with leading systems companies in developing products.
-Partner with other industry leaders to provide comprehensive solutions.

System Prototyping and Digital Twin
Catching a glimpse into the DoD Defense Budget Overview details, it stated that “Prototyping and experimentation should be used prior to defining requirements and commercial-off-the-shelf systems… A rapid, iterative approach to capability development will reduce costs, technological, obsolescence, and acquisition risk.” Along this line, the concept of digital twin which refers to a digital replica of a physical product can be applied. The digital twin captures a complete digital footprint of a product from design and development through the end of the product life-cycle. The basic elements of a digital twin for electronics include the physical electronic system in real space, the system prototypes in emulation space and data connections that tie the virtual and real systems together. The success of digital twin relies upon mission data collection and transmission to the digital twin. Hence, proper boundary conditions and capture of the mission profiles and environmental characteristics is crucial in order to prevent unintentional blocking of critical insights potentially needed to improve system efficacy or to avoid field failures. To support this, Cadence offers an array of electronics systems development program execution including:

– Common environment for chip, package and board for system development.
– Incremental parasitic extraction while physical layout progresses.
– Tools with foundry approved signoff engines yielding fewer iterations.
– Utilize metric driven verification methodology that tracks sign-off progress.
– Integrated hardware and software development to reduce integration time.
– Support to industry proven IPs to speed design cycle and to lower costs.


Early prototyping is also necessary to prevent surprises. The focus of system function, size, weight and power are the measured metrics. Cadence has developed a new and improved system prototyping methodology that folded-in emulation and analysis steps as well as an explicit go/no-go step prior to committing an idea to do a downstream, physical prototyping step. Emulation provides capacity, accuracy, performance and link to physical analysis. It enables running application software on hardware designs resident to the emulator. Cadence Palladium Z1 Enterprise Emulation Platform provides the enterprise-level reliability and scalability to accelerate system verification at different levels (IPs,subsystems, chips).

Hardware System Co-design
Taking further note from the DoD document: “Platform electronics and software must be designed for routine replacement instead of static configurations that last more than a decade… will realign incentive and reporting structures to increase speed of delivery, enable design tradeoffs in the requirements process,..”

Within this context, traditional design implementation involves approach that are segmented (e.g., chip, package, PCB). Such disjointed development is normally yielding a subpar result. With Cadence Virtuoso System Design Platform design team could perform co-design and co-analyze across different domains. It saves time and efforts while producing higher performance and cost competitive systems. For example in today analog and RF designs, failing to account for PCB or package level validation will result in great chance of chip failure. With Virtuoso such system level assessment can be done prior to chip completion.

The new National Defense Strategy provides challenging guidelines to revamp national defense programs and reiterates the impacts of rapid technological advancements to the security environment. According to DoD, the technological advantage depends on a healthy and secure innovation base that includes both traditional and non-traditional defense partners. It continues to streamline processes so that new entrants and small-scale vendors can provide cutting-edge technologies. Cadence has been a direct performer on several DoD projects, collaborated with many DoD suppliers and can act as a key partner to meet the demanding requirements in the agenda. For more details of such engagements and Cadence solutions, please refer to this whitepaper HERE.

Posted on

Edge Devices Rely on Intelligent MEMS Based Sensors

Edge Devices Rely on Intelligent MEMS Based Sensors
by Tom Simon on 03-29-2018 at 12:00 pm
Categories: EDA, IoT, Mobile, Siemens EDA
1 Comment

MEMS sensors play a huge role in intelligent systems these days. Mobile and IoT devices would essentially be blind if not for the rich variety of MEMS sensors integrated into them. The MEMS sensor market is growing rapidly, topping $10B in 2016 and slated to exceed $20B by 2020. MEMS is also growing in the RF market, where they are providing alternatives to passive and active electronic devices. Some surveys show that RF MEMS surpassed 6 billion units in 2016. In comparison the next most popular MEMS devices are microphones, which shipped 4.5 billion units in the same year.

A pair of white papers from Mentor talk about the growing importance of the MEMS market and the design considerations necessary to integrate MEMS into intelligent systems. MEMS are used in almost every market, telecom, medical, industrial, defense, consumer, automotive, and aeronautics, among others. As you might imagine the consumer market accounts for the largest share, coming in at $28B in 2016. Impressive, yet not surprising considering how many are used in phones and other gadgets.

An important trend in MEMS sensor based systems is combining sensors into one package and implementing sensor fusion there as well. Sensor fusion not only merges sensor data so it is easier to process downstream, it also helps weed out artifacts and reduce noise in sensor data. It’s not uncommon to have 3 axis gyroscopes, 3 axis accelerometers, temperature, barometric and magnetic sensors all in one unit.

MEMS sensors are also outperforming their predecessors. One of the most interesting examples is an accelerometer from Memsic, that has no moving parts. It relies on detecting the motion of heated gas molecules induced by acceleration. It consists of a minute flat chamber with a heater at the center and several distributed thermal sensors. In the absence of motion, the thermal sensors will see a uniform temperature gradient, which will become disrupted by acceleration. As you can imagine the processing to calibrate and convert the temperature values to acceleration is an essential part of the total solution. This device has high vibration immunity and up to 50,000g shock tolerance, specifications mechanical alternatives would be hard pressed to match.

To succeed with any MEMS based intelligent sensor design requires the highest level of integration possible. This applies not only to the design itself, but also to the methodology used to deliver the completed design. Ideally the MEMS and circuit layout should be created in the same environment and then simulated as one.

Mentor’s Tanner tools make it possible to create schematic for the MEMS and circuit together, referencing the appropriate models for each. The MEMS models can be defined using System Model Builder using analytical equations in SPICE or Verilog-A to map the electrical outputs of that portion of the design. The combined schematic can be simulated to verify design functionality and performance.

The Mentor white papers I mentioned above describe a flow that enables design and simulation from a common platform. It’s well understood that 3D silicon shapes are derived from the 2D layers created in layout tools. However, for mechanical designs, such as MEMS, people often start with a 3D model. The drawback for MEMS flows is that while you can perform 3D simulation on such a model, it is cumbersome to convert it into a 2D representation suitable for mask preparation. Masks are needed to complete the MEMS fabrication process in just the same way they are needed for semiconductor fabrication.

Mentor’s Tanner tools take a unique approach to solve this dilemma. They have designers start by defining a series of fabrication steps for the MEMS design. Next comes creating the masks in the layout tool, after which the fabrication process can be ‘simulated’ to ensure the resulting structure matches the intended design. At the same time the 3D model created can be exported to 3D modeling tools for that phase of the analysis.

The two white papers from Mentor on the Tanner tools for MEMS based circuits describe the flow more thoroughly. MEMS based IC designs have brought about dramatic innovation in every sector they are used. This goes for drones, to automobiles and even rockets, which all rely on robust and compact sensors. Novel new sensors and applications will continue to become available. The companies that can most efficiently integrate and deliver solutions that use them will be the next round of winners in the ongoing evolution of intelligent sensor based products.

Posted on

The Future of Verification Management

The Future of Verification Management
by Bernard Murphy on 03-29-2018 at 7:00 am
Categories: Cadence, EDA

One of the great aspects of modern hardware verification is that we keep adding new tools and methodologies to support different verification objectives (formal, simulation, real-number simulation, emulation, prototyping, UVM, PSS, software-driven verification, continuous integration, …). One of the downsides to this proliferation of verification solutions is that it can become increasingly onerous to manage all the results from these multiple sources (and multiple verification teams) into the unified view you ultimately need – have we covered all testplan objectives to an acceptable level?

You could administrate the combination of all this data through mounds of paperwork and presentations (not advisable) or more realistically through scripting, spreadsheets and databases. I’m sure some of the biggest engineering organizations have the time, skills and horsepower to pull that off. For everyone else this task can be daunting. It isn’t as simple as rolling up dynamic coverage from RTL sims. Consider that some of the testing may be formal-based; how do you roll that up with dynamic coverage? (Answer: by showing combined coverage results – dynamic and formal. Then as you move up through the hierarchy, you see a combined coverage summary). Some may come from emulation, some from mixed-signal sims, some may be for power verification, some for safety goals, some from HLS, some related to application software coverage. You can see why traditional RTL sim rollup scripting may struggle with this range.

Larry Melling (Director product management and marketing at Cadence) shared with me how vManager automates this objective and how some customers are already using the solution. Briefly, vManager is a system to gather functional verification results from a variety of platforms and objectives and score progress against an executable testplan. You can tie in all the Cadence verification platforms, from formal to prototyping, and objectives from functional to safety, to power and application software coverage. The system can also tie into requirements tracing and functional spec annotation, so you can see side-by-side how well you are meeting expectations for the product definition and provide spec updates/errata where these may deviate.

Larry pointed to several examples where vManager is in active use. Infineon already uses the tool to combine formal and simulation coverage results. I’ve written about this before. I don’t know of any solution (yet) to “merge” these coverage results but seeing them combined is a good enough way to judge whether the spirit of good coverage has been met. Infineon also notes that seeing these results together helps them optimize the split between formal and simulation effort, so that over time they improve the quality of results (more formal, where appropriate) while also reducing effort (less simulation, where appropriate).

ST, who are always very careful to quantify the impact of new tools and methodologies, showed that adoption of vManager with metric-driven verification ultimately was able to reduce verification effort by more than 50% over their original approach. They added that verification productivity increased, they had higher quality RTL and that tracking multi-site project status was much easier than in previous projects.

One last very interesting example. In software product development there have been aggressive moves to agile design and continuous integration (CI) methods. You might not think this has much relevance to hardware design, however RAD, a telecom access solutions provider based in Israel, thinks differently. They do most of their development in FPGAs; here lab testing plays a big role and regression data is not always up-to-date with latest source-code fixes. To overcome this problem, RAD have switched to a CI approach based on Jenkins for its ability to trigger regressions automatically (at scheduled times) on source-code updates.

RAD uses vManager together with Jenkins to run nightly regressions on known-good compilations, thus ensuring that regression results are always up-to-date with the latest source-code changes. They commented on a number of advantages, but one will resonate with all of us – the impact of the well-known “small” fix (trust me – this won’t break anything). A bug caused by such a fix previously could take an indeterminate amount of time to resolve. Now it takes a day – just look at the nightly regression. That’s pretty obvious value.

A quick note on who might need this and how disruptive adoption might be. Larry acknowledges that if you’re building IoT sensor solutions (100K gates), the full scope of vManager (multi-engine, multi-level) is probably overkill. Solutions like this are for big SoCs supported by large development and verification teams. Also, this solution is designed to fit comfortably into existing infrastructures. No need to throw out what you already have; you can adopt vManager just to handle those components for which you don’t have a solution in place – such as combining formal and simulation coverage results.

You can learn more about vManager HERE and read a useful white paper about metric-driven verification HERE.