Bronco Webinar 800x100 1
Semiconductor Expert Forum

Posted on

Siemens Leverages Mentor Embedded IoT Framework for Industry 4.0

Siemens Leverages Mentor Embedded IoT Framework for Industry 4.0
by Daniel Nenni on 03-21-2018 at 7:00 am
Categories: EDA, Siemens EDA

For those of you who wondered at the logic behind Siemens acquisition of Mentor Graphics last year, look no further than a recent announcement by Mentor, now a Siemens business, regarding the release of their new Mentor Embedded IoT Framework (MEIF). To help connect the dots, we need to back up a bit and review a few things about how the IoT and Industry 4.0 works.


Since we are primarily concerned with ICs, we note that as part of the Industry 4.0, sensors, actuators, micro-controllers and sometimes multi-core SoCs are being added to industrial equipment to better enable management and control of industrial processes. The basic premise is that IoT edge devices are co-located with industrial equipment. Those devices monitor industrial processes and then send data to IoT gateways for data fusion and some processing. Eventually the data is then sent to the IoT Cloud for further processing.

In reality, it’s much more complex than that. IoT systems typically are made up of many Clouds and many edge and gateway devices from different providers that must talk to each other. Back-end processing in the cloud is usually handled by service providers such as Amazon, Microsoft and surprise, Siemens!

We typically think of Cloud companies providing services for things like data storage, data analytics, and transforming data into actionable business intelligence. However, cloud providers also have services to help manage IoT devices, including monitoring of device health, security, and providing for over-the-air software updates for devices with embedded software. This is usually done through a set of application programming interface (API) calls supplied by a software developer’s kit (SDK) that is unique to the cloud provider. The SDK and APIs help to massage data from edge and gateway devices into a form that can be used by the Cloud providers IoT operating system and data analysis applications.


Now let’s connect a couple more dots. For sophisticated SoCs at the gateway (and sometimes edge) devices, there will be embedded software that must deal with not one SDK but multiple SDKs from multiple cloud vendors. This is where Mentor’s MEIF product comes in. It acts as a standard software switch box that enables the embedded software provider to be able to write their software using one set of libraries, routines and API calls, regardless of the operating system or hardware it is running on, and regardless of the number of different cloud SDKs to which it must talk.

Some of the key attributes of Mentor’s Embedded IoT Framework are that it is:

  • scalable from micro-controllers up to large multi-core SoCs
  • portable across operating systems including Mentor’s own Embedded Linux and Nucleus RTOS
  • portable across hardware architectures like ARM and X86
  • extensible and customizable
  • has infrastructure and tools to enable IoT security
  • support multi-cloud environments


MEIF maps embedded software calls in edge and gateway devices to Cloud-provider specific API calls from Amazon Web Services (AWS), Eclipse IoT, Microsoft Azure, and Siemens MindSphere. It also adds code that takes care of a breadth of services that enables backend communications and applications including: device authentication and provisioning; configuration and control; monitoring and diagnostics; and software updates and maintenance. Mentor’s framework is open and customizable for industrial customers who want scalable and portable solutions for multi-cloud environments.

MEIF also supports features to help manufacturers manage reliability, uptime, and overall quality by using Smart Device information to report device utilization, do system profiling and to provide support for alarms and events, all of which are key value propositions for using Industry 4.0.


MEIF incorporates Mentor’s Embedded runtime platforms which provide for hardware-based root-of-trust and software chain-of-trust security both during runtime and during device boot-up. This also includes support for secure data transfers both up to the cloud and down to the devices on the manufacturing floor.

So, to complete the picture, when large companies make acquisitions, such as was done by Siemens with Mentor, you need to first look at the adjacencies. It’s clear in this case that Siemens has a large interest in the IoT Cloud infrastructure with their MindSphere family of products. Potential business is huge, but it could be bigger if they could make it easier for IoT edge and gateway device suppliers to be able to use MindSphere with other cloud providers. Mentor’s embedded systems group was a key enabler to doing just that.

While it may not be the only reason Siemens acquired Mentor, it certainly looks like one of the good ones. It makes a lot of sense and it’s good to see Siemens leveraging their Mentor investment back into their other products and services.

See Also:
Press release – Mentor advanced Industry 4.0 for Smart, Connected Devices
Data sheet – Mentor Embedded IoT Framework
Siemens MindSphere

Posted on

Free Webinar: Silvaco 3D Solver Based Extraction for Device and Circuit Designers

Free Webinar: Silvaco 3D Solver Based Extraction for Device and Circuit Designers
by admin on 03-20-2018 at 12:00 pm
Categories: EDA, Events, FinFET

Designers spend a lot of time looking at their layouts in 2D. This is done naturally because viewing in 2D is faster and simpler than in 3D. It helps that humans are good at extrapolating from 2D to 3D. Analysis software, such as extraction software also spend a lot of time looking at layouts in 2D. While this is fine for approximate results, it turns out that looking at the design this way is not accurate enough for a wide variety of target designs. Fortunately, there is an alternative offered by Silvaco that uses field solvers on 3D structures derived from layout data.


Using realistic 3D TCD structures for RC extraction may be new to many readers. Fortunately, Silvaco is offering a webinar on March 29[SUP]th[/SUP] that goes into depth on their preferred solution for highly accurate extraction. Dr. Garret Schlenvogt will present a detailed agenda covering an introduction to RC extraction and specifically the topic of solver based 3D extraction, while highlighting the important differences in approaches.

The webinar will also cover Silvaco’s solution from extraction through SPICE. Their solution works for devices, cells and interconnect – offering a versatile method to work at every level of critical designs. Their 3D structure generation takes advantage of Silvaco’s deep experience with TCAD.

This free webinar is going to be held at 10AM PST on March 29[SUP]th[/SUP]. It’s easy to register online through their website. This webinar will be informative to a wide audience, including circuit designers who need better RC parasitic information and also process and device engineers looking to improve their optimization efforts.

About Silvaco, Inc.
Silvaco, Inc. is a leading EDA and IP provider of software tools used for process and device development and for analog/mixed-signal, power IC and memory design. Silvaco delivers a full TCAD-to- sign-off flow for vertical markets including: displays, power electronics, optical devices, radiation and soft error reliability and advanced CMOS process and IP development. For over 30 years, Silvaco has enabled its customers to bring superior products to market with reduced cost and in the shortest time. The company is headquartered in Santa Clara, California and has a global presence with offices located in North America, Europe, Japan and Asia. www.silvaco.com

Posted on

Formal: Going Deep and Going Early

Formal: Going Deep and Going Early
by Bernard Murphy on 03-20-2018 at 7:00 am
Categories: Cadence, EDA

This year I got a chance to talk with Cadence at DVCon on a whole bunch of topics, so expect a steady stream of blogs over the next couple of months. First up was an update from Pete Hardee (Director of Product Management) on, surprise, surprise, formal verification. I’m always trying to learn more about this space, so I picked a couple of topics from our discussion to highlight here.

First, going deep. Formal methods, particularly bounded model-checking, typically operate breadth-first. The engine steps forward one cycle from the current state and checks active assertions, steps out another cycle and so on until assertions are proved, or counter-examples are found, or proving exceeds a specified depth (all modulo constraints of course). This method of proving is exhaustive but limited in the number of cycles it can analyze, since analysis size expands more or less exponentially with depth.

Does this mean you are stuck with checking properties inside that depth? Apparently not. While property-proving in the classical sense is restricted to breadth-first methods, bug-hunting to significantly deeper levels is also possible. One technique the Cadence JasperGold toolset supports is called cycle-swarm, in which the prover works exhaustively for a number of cycles, then advances forward some number of cycles while either not testing or only lightly testing, then restarts full proving from that point, and so on.

This trick, in which the engine ignores big chunks of the state space in order to reach further out, can be directed in other ways. State-swarm follows a trail of cover properties you plant on the design. It doesn’t guarantee to follow them in any particular order, only that it will hit each at some point. Guide-pointing follows a similar approach but guarantees to hit your cover properties in a specified order. In both cases you want to define cover-properties close to where you think something might fail.


I have struggled before in understanding these methods, but I believe I have got it now. The engine starts a new search from each such property (once hit), effectively resetting the span of the search at each such point. From each property you are starting a new (forward) cone of analysis, which is what allows you to reach out so far; you’re advancing step-wise, in bounded cones of analysis. This probably also means you need to scatter cover properties in increments of provable cycle depths before your goal property so none of the intermediate cones blow up before it hits such a property.

Pete and others freely acknowledge this is bug-hunting rather than proving, however several customers claim this still can be a very productive exercise whether or not you also deploy “classic” formal. An HP user presented at JUG 2015 a case where he found a potential bug (FIFO underflow) using state-swarm at nearly 3000 cycles, far beyond the normal scope of formal proofs.

The second topic that always interests me is how to put more verification in the hands of RTL designers. Naturally there is a self-serving aspect to this for any tool provider but there are also broader benefits. One is in supporting continuing shift-left. To the extent that RTL designers can hand off cleaner code, verification engineers spend less time tracking down bugs and iterating on RTL updates. A second benefit is in supporting reusability. For a current application, you know bugs will be shaken out in block or system verification. But if this has to happen again and again on new applications of that block, reuse loses a lot of its appeal.

Formal apps can be a valuable contributor to ensuring high quality handoff (against certain objectives) in both cases. Formal lint (Cadence calls it Superlint) should be a familiar starting point for any RTL designer since it requires little more effort than running a regular linter in most cases.

The other app in the designer’s desktop is CDC. This app will run structural (e.g. requiring approved synchronizers at domain crossings), functional (e.g. checking grey-coding on FIFO read/write pointers) and reconvergence (e.g. requiring one-hot coding) checks. Handing this kind of analysis to RTL designers ought to be a no-brainer for handoff, though I’m not sure how far this has progressed across the industry and how much it’s still farmed out to the verification team. Perhaps the inevitability of the shift-left squeeze will make the transition inescapable.

Go HERE to learn more about JasperGold verification apps and watch a video in which Pete explains the advantages of RTL designer’s desktop.

Posted on

Webinar: Achieve High-performance and High-throughput with Intel based FPGA Prototyping

Webinar: Achieve High-performance and High-throughput with Intel based FPGA Prototyping
by Daniel Nenni on 03-19-2018 at 12:00 pm
Categories: Automotive, IoT, Prototyping, S2C EDA
3 Comments

FPGAs have been used for ASIC prototyping since the beginning of FPGAs (1980s) allowing hardware and software designers to work in harmony developing, testing, and optimizing their products. We covered the history of FPGAs in Chapter 3 of our book “Fabless: The Transformation of the Semiconductor Industry”, which includes a brief history of Xilinx. Of course ASIC design is much more complex now with exploding gate counts and a dizzying array of commercial IP and interfaces which brings us to today’s FPGA based prototyping systems.

“Designers using Intel FPGAs can now reap the benefits of FPGA prototyping with our A10 Single Prodigy Logic Module,” commented Toshio Nakama, CEO of S2C. “The new and unique sleek, metal enclosure that our A10 system comes in provides much needed flexibility, durability and portability that designers seek. Users, will of course, be able to take advantage of the full set of our leading Prodigy Complete Prototyping Platform components including Player Pro and Multi-Debug Module for advanced partitioning and debug.”

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

S2C Inc. has been successfully delivering rapid SoC prototyping solutions since 2003 with more than 200 customers worldwide. S2C has been on SemiWiki for two plus years with 30 blogs that have gathered more than 125,000 views. We also published a very popular free ebook “ PROTOTYPICAL – The Emergence of FPGA Prototyping for SoC Design”, so we know prototyping, absolutely.

I spent some time at the S2C HQ in San Jose (across from my favorite Starbucks) this week and actually got my hands on one of the new S2C Desktop Prototyping Systems and was quite impressed. My first question to S2C VP of Engineering Richard Chang was why would someone choose this new altera based system over an existing Xilinx system: Vendor bias plays a significant role (some people prefer Altera over Xilinx), others feel Altera is a better performing FPGA, but on this new product the desktop packaging is the big WOW factor. Here is a quick video I pulled from the S2C website:



This self contained prototyping system can be expanded from one FPGA to dual and quad FPGAs. Self contained so you can easily test your hardware/software design in a real world environment such as automotive or on the shop floor with an industrial IoT application. This truly is engineering driven packaging with an easy attachment for the dozens of daughter cards and interfaces available from S2C.

The base system starts at $10,000 and goes up from there. If you are ready to prototype and have end-of-year budget you can start HERE and get a quick quote, simple as that.

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

About S2C
S2C Inc. is a worldwide leader of FPGA prototyping solutions for today’s innovative designs. S2C was founded in San Jose, California in 2003 by a group of Silicon Valley veterans with extensive knowledge in ASIC emulation, FPGA prototyping, and SoC validation technologies. The Company has been successfully delivering rapid SoC prototyping solutions since its inception. S2C provides:

  • Rapid FPGA-based prototyping hardware and automation software
  • Prototype Ready™ IP, interfaces and platforms
  • System-level design verification and acceleration tools

With over 200 customers and more than 800 systems installed, S2C’s focus is on SoC/ASIC development to reduce the SoC design cycle. Its highly qualified engineering team and customer-centric sales force understands our users’ SoC development needs. S2C systems have been deployed by leaders in consumer electronics, communications, computing, image processing, data storage, research, defense, education, automotive, medical, design services, and silicon IP. S2C is headquartered in San Jose, Calif., with offices and distributors around the globe including the U.K., Israel, China, Taiwan, Korea and Japan.

Currently the US headquarters office is focusing on technology research, strategic alliances, sales and marketing for North America and Europe. The Shanghai office focuses on product development, with the Hsinchu office serving as the manufacturing center.

Posted on

Don’t believe the hype about AI in business

Don’t believe the hype about AI in business
by Vivek Wadhwa on 03-18-2018 at 7:00 am
Categories: AI

To borrow a punch line from Duke professor Dan Ariely, artificial intelligence is like teenage sex: “Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.” Even though AI systems can now learn a game and beat champions within hours, they are hard to apply to business applications.

M.I.T. Sloan Management Review and Boston Consulting Group surveyed 3,000 business executives and found that while 85 percent of them believed AI would provide their companies with a competitive advantage, only one in 20 had “extensively” incorporated it into their offerings or processes. The challenge is that implementing AI isn’t as easy as installing software. It requires expertise, vision, and information that isn’t easily accessible.

When you look at well known applications of AI like Google’s AlphaGo Zero, you get the impression it’s like magic: AI learned the world’s most difficult board game in just three days and beat champions. Meanwhile, Nvidia’s AI can generate photorealistic images of people who look like celebrities just by looking at pictures of real ones.

AlphaGo and Nvidia used a technology called generative adversarial networks, which pits two AI systems against each another to allow them to learn from each other. The trick was that before the networks battled each other, they received a lot of coaching. And, more importantly, their problems and outcomes were well defined.

Most business problems can’t be turned into a game, however; you have more than two players and no clear rules. The outcomes of business decisions are rarely a clear win or loss, and there are far too many variables. So it’s a lot more difficult for businesses to implement AI than it seems.

Today’s AI systems do their best to emulate the functioning of the human brain’s neural networks, but they do this in a very limited way. They use a technique called deep learning, which adjusts the relationships of computer instructions designed to behave like neurons. To put it simply, you tell an AI exactly what you want it to learn and provide it with clearly labelled examples, and it analyzes the patterns in those data and stores them for future application. The accuracy of its patterns depends on data, so the more examples you give it, the more useful it becomes.

Herein lies a problem: An AI is only as good as the data it receives. And it is able to interpret that data only within the narrow confines of the supplied context. It doesn’t “understand” what it has analyzed, so it is unable to apply its analysis to scenarios in other contexts. And it can’t distinguish causation from correlation. AI is more like an Excel spreadsheet on steroids than a thinker.

The bigger difficulty in working with this form of AI is that what it has learned remains a mystery — a set of indefinable responses to data. Once a neural network is trained, not even its designer knows exactly how it is doing what it does. As New York University professor Gary Marcus explains, deep learning systems have millions or even billions of parameters, identifiable to their developers only in terms of their geography within a complex neural network. They are a “black box,” researchers say.

Speaking about the new developments in AlphaGo, Google / DeepMind CEO Demis Hassabis reportedly said, “It doesn’t play like a human, and it doesn’t play like a program. It plays in a third, almost alien, way.”

Businesses can’t afford to have their systems making alien decisions. They face regulatory requirements and reputational concerns and must be able to understand, explain, and demonstrate the logic behind every decision they make.

For AI to be more valuable, it needs to be able to look at the big picture and include many more sources of information than the computer systems it is replacing. Amazon is one of the few companies that has already understood and implemented AI effectively to optimize practically every part of its operations from inventory management and warehouse operation to running data centers.

In inventory management, for example, purchasing decisions are traditionally made by experienced individuals, called buyers, department by department. Their systems show them inventory levels by store, and they use their experience and instincts to place orders. Amazon’s AI consolidates data from all departments to see the larger trends — and relate them to socioeconomic data, customer-service inquiries, satellite images of competitors’ parking lots, predictions from The Weather Company, and other factors. Other retailers are doing some of these things, but none as effectively as Amazon.

This type of approach is also the basis of Echo and Alexa, Amazon’s voice-based home appliances. According to Wired, by bringing all of its development teams together and making machine learning a corporate focus, Amazon is solving a problem many companies have: disconnected islands of data. Corporate data are usually stored in disjointed datasets in different computer systems. Even when a company has all the data needed for machine learning, they usually aren’t labelled, up-to-date, or organized in a usable manner. The challenge is to create a grand vision for how to put these datasets together and use them in new ways, as Amazon has done.

AI is advancing rapidly and will surely make it easier to clean up and integrate data. But business leaders will still need to understand what it really does and create a vision for its use. That is when they will see the big benefits.

For more, you can read my book Driver in the Driverless Car

Posted on

Leading Edge Logic Landscape 2018

Leading Edge Logic Landscape 2018
by Scotten Jones on 03-16-2018 at 2:00 pm
Categories: Foundries, GlobalFoundries, Intel Foundry, Samsung Foundry, Semiconductor Services, TechInsights, TSMC
8 Comments

The most viewed blogs I write for SemiWiki are consistently blogs comparing the four leading edge logic producers, GLOBALFOUNDRIES (GF), Intel, Samsung (SS) and TSMC. Since the last time I compared the leading edge new data has become available and several new processes have been introduced. In this blog I will update the current status.
Continue reading “Leading Edge Logic Landscape 2018”

Posted on

Self-Driving Car Catch-22 and the Road to 5G

Self-Driving Car Catch-22 and the Road to 5G
by Roger C. Lanctot on 03-16-2018 at 12:00 pm
Categories: Automotive
1 Comment

In the novel “Catch-22” from which the eponymous 1970 movie was made we learn of a fictional bureaucratic means by which the U.S. Air Force was able to keep bomber pilots (who might be going crazy) from successfully requesting a release from flying missions based on a medical evaluation. The rationale behind this supposed “catch” was that a pilot would be demonstrating his own sanity by asking to be relieved of this task.

In a similar way, European transport authorities seeking to foster autonomous vehicle development are grappling with longstanding transportation regulations that require the presence of a driver and the ability of the driver to take control of the vehicle. The regulations in question include parts of the Vienna Convention, the Geneva Convention and the UNECE’s WP.29.

Regulators throughout Europe are trying to thread this needle by allowing for the existence of automatic pilot systems but requiring the presence of a driver and the means for that driver to retake control of the vehicle. It is actually somewhat surprising that the EU has taken so long to address this question of driver presence and control because even mandated stability control systems represent precursors of driving automation but never triggered concern for changing the regulations.

The Catch-22 for vehicle autonomy arises as countries, such as Finland, introduce legislation allowing for robotic vehicles with remote control, meaning the vehicle must have a driver but the driver need not be present in the vehicle. One might say, in a twist on the Catch 22 concept, that you’d be crazy to deploy autonomous vehicles without remote control – but you’d be equally crazy to try to control robotic vehicles remotely.

Crazy though it sounds, this is precisely the scenario for which European autonomous vehicle contenders are preparing and which is likely to influence the process of modifying the extant regulations.

We already have some experience of this remote control scenario in the form of the infamous hack of an FCA Jeep two years ago by “ethical” hackers Chris Valasek and Charlie Miller, both of whom now reportedly work for General Motors. Phantom Auto is touting this capability as a core value proposition for vehicle autonomy. And Nissan has indicated its plans to enable remote control of its self-driving vehicles.

It is a very real prospect and reveals the shortcomings of the current regulator regime and the limitations of regulators. There are two major challenges facing the transportation industry: autonomous driving and cybersecurity threats.

In both cases, the process of vehicle certification for roadworthiness is subverted by the inability of regulators to certify that vehicles are secure or to determine, with any degree of certainty, that an autonomous vehicle will function safely in all circumstances. But politicians abhor a regulatory vacuum so the U.S. Congress has passed the Self Drive Act – a piece of legislation with the broad support of the automotive industry but which has failed to gain sufficient support in the Senate.

The Self Drive Act would subvert U.S. Federal Motor Vehicle Safety Standards by providing exemptions for thousands of self-driving cars which might have no drivers and, indeed, no steering wheels or brake pedals. Safety advocates are perhaps understandably up in arms and seeking to block the legislation.

Generally speaking, in the U.S., car makers are granted the ability to self-certify their cars as meeting FMVSS requirements. In Europe, new cars must receive “type approval” from regulators before they are introduced to the market.

Autonomous vehicle developers in the U.S. have been able to skirt FMVSS standards by convincing individual states to allow for testing of autonomous vehicles. In the case of Waymo, the testing is evolving into actual service delivery of automated mobility.

The rub appears to be that autonomous vehicles cannot be sold to consumers without meeting FMVSS requirements – which include such things as steering wheels and brake pedals. This has created an amusing scenario where car makers – who appear to be determined to try to sell autonomous vehicles to consumers (an unlikely prospect) – are seeking the cover of the Self Drive Act while Waymo blithely pursues its business of offering transportation services with little or no interest in conveying ownership of its AVs to consumers. For Waymo, the Self Drive Act is irrelevant.

What can regulators do? It is impossible to certify the cybersecurity resilience of any car. A vehicle is only as secure as the last pen test it has survived. It is also impossible to certify the safe operation of an autonomous vehicle – dependent as it is on ever-evolving algorithms created within neural network black boxes.

Relying on remote control as a means to enable autonomous vehicle development does indeed seem crazy to me. But it seems equally crazy to have no provision for remote control or indeed to throw in the towel entirely on the idea of autonomous vehicles.

There is a silver lining, though. Any remote control system will require a wireless connection with high bandwidth and low latency. If nothing else, the potential for controlling vehicles remotely is a huge motivator for rapid development and adoption of 5G wireless technology – which might actually spur wireless carriers to prioritize automotive applications.

These regulatory issues and more will be discussed tomorrow at the Future Networked Car Symposium taking place in conjunction with the Geneva Motor Show at the Palexpo. If you happen to be in Geneva, come join us and share your thoughts and theories.

Posted on

Don’t Stand Between The Anonymous Bug and Tape-Out (Part 2 of 2)

Don’t Stand Between The Anonymous Bug and Tape-Out (Part 2 of 2)
by Alex Tan on 03-16-2018 at 7:00 am
Categories: Arm, Cadence, EDA, Events, IP, Oski Technology, Siemens EDA, Synopsys


The second panel is about system coverage and big data. Coverage metrics have been used to gauge the quality of verification efforts during development. At system level, there are still no standardized metrics to measure full coverage. The emergence of PSS, better formal verification, enhanced emulation and prototyping techniques may deliver some answers to the issue.

Functional verification – From vendor’s standpoint, verification is a risk analysis issue, which can be rectified with the use of graph-based analysis. The claim is that one could reason with data space and decide area to probe further. On the other hand, some panelists believe that functional verification still offer value. Hierarchy and abstraction inject complexity over time. While calculus/algebra deals with abstraction, hierarchy has posed several challenges to verification.

Portable Stimulus Standard (PSS) role — Vendor’s POV on PSS usage: it does not require giving-up functional coverage and should enable one to push-down system-level check to block-level. But the user states that issues to be checked at lower level are different (such as registers and data-paths) versus top-level types of checks (such as transition related). However, the intent of checking is finding a bug. Vendor agreed on how PSS can help catch bug at block that found at system level, and pointed out that DV guys at lower level versus software guy at top-level needs a better handshake.

Functional Coverage— Bug planning caused shift earlier left, better preparation for everyone. Take system level coverage to lower block level. Coverage heat map, clustering, identify which tests useful or not –all are good. Need to understand how to run functional coverage post-silicon. Few panelists agreed that coverage model need to be rethought and clever people are needed. Comment from the floor, if everything placed into graph, how to catch if something is missed. Would it be using decision graph work on entire space or coverage closure assisted with ML?.

Big data and ML— Big data implied inference problem (statistical inference) – how to extract meaning such as techniques with graphics, machine learning. Vendor’s POV that inference can be used to get full coverage with ML, checks that cause failure. Anticipating of less combination of logic paths be exercised when system get more complex and data getting bigger. A user panelist believes that logical inferencing within reach, however the space so big, need to get models that make sense. Don’t know about ML, but statistical method should be known approach already. How to address data merging from block-level IP, system level, emulators, FPGA – does big data help? Another vendor stated that PSS may not be the answer; need to know how to compact data; it’s an infrastructure issue. Audience comment: “Not handling data conditioning may translate to big data issue”.

Formal verification can be categorized into two camps: the deep FPV advocates writing more custom written assertions and the broad formal apps advocates such as connectivity check, unreachability analysis or register verification. The third panel explore the reasoning behind each preference.

Go broad arguments — Designer cares about usability and ease of debug. Return On Investment (ROI) for doing formal can still be questioned. Usually formal expert is hard to find while one can ramp up verification as long as one is RTL literate and know DV. Formal applications to be considered such as Sequential Equivalence Checks (SEQ), connectivity, X-property, CSR, security, deadlock.

Go deep arguments — Formal 2.0 methodology is key to success, to understand value proposition and scope, training and process are also crucial. On Formal Property Verification (FPV) growth: why not used more? It’s true deep FPV needing few heroes for wider usage. One user said a key principle: do unit testing. Individual design engineer needs to understand local RTL prior to turn-in. Find bug at lowest level, etc. Clear expectation for designer for unit testing is key to success to growing designer to exercise FPV? Have supporting tasks to make it happen. Formal 3.0 — Should have wider use endorsement. It’s not hard and doing formal to identify post-silicon bug has value. Hence, we need to go deep. Write assertion to identify bug. Need to verify design going deep, not resource intensive with formal. It just needs different mindset. User example with regards to resources vs usage:

2015: 2 blocks — 1 person,
2018: 30+ blocks — 3 persons

The final panel is related to smarter and faster verification. What trends and impact of data analytics or ML may have.

Pre-vs-Post Silicon Data — Data recycling, reuse in formal verification. How to align pre and post-silicon data? Usage scenario from mobile/phone → run during pre-silicon, but not 1:1 as lack of infrastructure. Customers deal with lots of data and size. How to collapse and aggregate as we move forward. Need to be smart about managing this. Connecting both pre and post domains, there are opportunities. Post silicon data: how to identify and recapture into emulation (along with test-benches). Vendor opinion to use Portable stimulus to provide feedback upstream to pre-silicon space. How to capture post-silicon as pre-silicon model. Currently using PS as vehicle to solve.

Smartness in debug — Significant resources spent on debug, which usually need adequate level of signatures. Documenting debug process, automating it and potentially apply ML in the process. If a pattern emerges during the process of debug, can we automate it? Question on can we detect design changes and correlate with design problems. Goal is to reduce debug time — we are not there yet. One panelist commented that he had already seen some facilities in assisting debug.

Hidden barriers in ecosystems — Several panelists concurred that silos mode does exist. An example to remedy the problem, through the use of IP-XACT as bridge for DV and logic designer. Formalizing the specification, generate test cases also help. Spending time more on complex cases. Continuous integration, catching corner cases, collaboration is key between DV and logic designer.

Overall, there is an increased interest, though gradual, in considering new solutions (PSS, localized verification methods, spec-capture, etc.) in addressing design verification and validation, while keep pushing the envelope on existing verification flows.

Also read Part 1 of 2

Posted on

Computer Vision and High-Level Synthesis

Computer Vision and High-Level Synthesis
by Daniel Payne on 03-15-2018 at 12:00 pm
Categories: EDA, Siemens EDA
2 Comments

Computer vision as a research topic has been around since the 1960’s and we are enjoying the benefits of this work in modern-day products all around us as robots with computer vision are performing an increasing number of tasks, even our farmers are using computer vision systems to become more productive:

  • AgEagle® has a drone that takes aerial images to create a geo-tagged layout of the land and crops
  • Prospera® analyzes crop images for health, nutrient levels, water and crop rotation
  • Blue River Technology® created a robot with computer vision to spray crops for weeds
  • Energid Technologies® built a system to pick citrus fruits using six cameras
  • Case IH® enables self-driving tractors to till the soil and harvest crops
  • John Deere® provides JDLink so that farmers can track and analyze their machinery, monitor for maintenance and connect to a local dealer at service time

The markets for computer vision products are expected to grow into a $48B size by 2022, according to research company Tractica.

In these eight segments we can expect to see new products based on new semiconductors, image sensors and specialized software:

  • Automotive – driver assistance, autonomous
  • Sports and entertainment – special effects, movies, TV content
  • Consumer – smart phones, AR, VR, biometrics, cameras
  • Robotics – industrial, inspection, drones
  • Security – surveillance, prevent crime, track faces
  • Medical – 3D images from body scanners
  • Retail – customer tracking, buying analytics
  • Agriculture – crop inspection, harvesting, weeding, tilling

I use Facebook everyday and after uploading a photo they automatically identify my face and friend’s by using Convolutional Neural Networks (CNN) for image recognition and classification. Our economy is helped by the new products and services in computer vision, all made possible by technologies like: deep learning to identify and classify objects, WiFi and mobile networks, fast image uploading, CNN training with huge image databases, parallel processing in the cloud, software libraries, affordable chip and memory prices, plentiful CMOS image sensors.

The pace of innovation in computer vision has created VC funding to the tune of $3.48 billion between Q3 2015 and Q3 2016 for AI startups (neural networks, deep learning, CNN), according to Venture Pulse – KPMG International and CB Insights. The top AI investors from 2011 to June 2016 include: Intel Capital, Google Ventures, GE Ventures, Samsung Ventures and Bloomberg Beta. Talk about merger mania, there were 140 VC-backed AI companies acquired by these AI investors.

A computer vision system has the following basic building blocks:

Engineers have many choices on how to implement their computer vision system:

  • CPU
  • DSP
  • GPU
  • FPGA, embedded FPGA
  • ASIC

On the downside a GPU consumes the most power, so wouldn’t be appropriate for an onboard system. A DSP is lower power than a GPU, but they aren’t efficient for CNN tasks. CPUs are popular for general purpose computing, however they also tend to be the slowest at performing vision tasks so wouldn’t be appropriate for visual identification in automobiles. FGPA approaches are helpful for getting a vision prototype up and running to see if the concept is viable, before committing to an ASIC for lowest cost and lowest power. So an ASIC approach for vision processing could provide the highest performance at the lowest cost, but then you need to know something about chip-level hardware design.

To the rescue for new hardware designers in the computer vision field is the very popular C++ language which can now be used both to describe algorithms and as a source for hardware description. To get from C++ into RTL code an engineer can use High Level Synthesis (HLS) as a starting point instead of the lower-level RTL languages like SystemVerilog or VHDL. With C++ code for your algorithm it is possible to compare the speed and power of an idea using an ASIC, FPGA, CPU or GPU. Iterations in C++ allow the system architect to make trade offs and come up with something optimal for their unique application.

HLS tools have been around for the past 15 years and Mentor (a Siemens business) has been automating this approach with their Catapult HLS tool as shown in this flow diagram:

So an algorithm designer starts out with C++ code then ends up with RTL code ready for use in ASIC or FPGA devices. You get to check the concept for errors before simulation, have a testing environment, and use formal equivalence checking to ensure that RTL matches the C++. The generated RTL code is optimized for power and ready for functional simulation and RTL synthesis into technology-specific cells. Computer vision teams can quickly go from a concept to a hardware prototype in record time by using a C++ flow and HLS technology like Catapult.

Summary
Expect computer vision products to grow both in number and volume over the coming years, and to build a new vision system there is a proven flow from C++ to RTL to cells with software called Catapult HLS from Mentor. You don’t have to be a hardware expert to get optimal hardware results using a HLS tool flow.

Here are a couple more resources to consider:

Related articles: