You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!
Pratik Mahajan, Synopsys VC Formal R&D Group Director, kicked off an absorbing event featuring talks from multiple customers in Europe. He spent some time on formal signoff, an important topic that I’m still not sure is fully understood. Answering the questions “OK, we did a bunch of formal checking but how does that affect total design signoff? And how does this complement dynamic signoff?” A lot of progress has been made here, in areas like formal core coverage, combining formal and dynamic coverage together and accelerating debug through ML-assisted bug triage. Also using formal to accelerate and strengthen low power and safety verification. Lots of meat in this VC Formal SIG.
Keynote on formal today in production verification
Mirella Negra Marcigaglia, Verification Manager at ST Micro Catania, gave the opening keynote on how formal fits into today’s verification challenges. She pushes formal first in development because it’s faster (no TB needed), simpler to use through apps, easier to reuse and of course exhaustive. It’s not perfect: we still need to wrestle with convergence challenges, size constraints, how comprehensive are our properties and whether anything is over-constrained. Mirella makes a very interesting point in her closing slide, that formal skills should be taught much more broadly across design groups. She’s responsible for both, yet in her view formal is easier to pick up than UVM, so should not be limited to a formal-only group. Times are changing.
Modern formal applied to the FDIV bug
In the ‘90s, the Intel FDIV bug catapulted formal from an academic curiosity to a commercial reality. Max Freiburghaus of Imagination Technology shows how this bug would have been caught by modern formal equivalence checking, here in VC Formal DPV (datapath verifier). He goes into detail on the SRT algorithm, showing how approximations inherent in the method can lead to hard-to-reach corner case bugs. And how DPV can find these. You’ll have to concentrate carefully to follow the argument, but worth the effort for a nice demonstration.
When is a bounded proof good enough?
Anthony Wood of GraphCore presented on this topic, which always trips us up. Answering this question isn’t trivial. Perhaps you should increase the proof depth. But that may not be the smart option. Some elements, like counters and memories are between hard and impossible to test exhaustively. And not worth the effort because the great majority of states differ insignificantly from others. You want to cover boundary conditions, unique combinations where bugs may lurk. Anthony talks about a few examples and how formal testbench analysis can help navigate the possibilities. He also throws in a couple of teasers on how formal can help in continuous integration and continuous delivery flows. Nice! Disruptive changes often create new opportunities.
Ultra-low power verification
Another popular topic. Karine Avagian, R&D Formal Verification Engineer and Joakim Urdahl, Sr. Engineer in Verification Methodologies, both at Nordic Semiconductor talked about their work in this area. Joakim has strong background in formal, however adoption in Nordic is relatively recent, so this section covers their first steps to a foundation for ULP checking. Emphasis is on complete property checking, defining properties to describe the complete input/output behavior of a block.
This is an interesting study of first steps into using serious property checking (as opposed to apps). They start with the spec for a block (a UART), define a conceptual state machine for the behavior, then write properties they expect to apply based on that description. Even though this was a learning exercise, they found bugs in the implementation and opportunities for further ultra-low power optimization. For a part that has been in production for quite a while. (Note to self – already in production for years doesn’t mean it’s bug-free.)
Formal versus simulation
Finally, Paul Stravers from the Synopsys Solutions Group presented on eliminating block level sims using formal signoff. This is an eternal quest in formal, their ‘impossible dream’. Which might attract derision, but I like this thinking. We wouldn’t get anywhere interesting without moonshots. Even if/when these projects fail to reach their hoped-for goal, they still make important new discoveries. More power to them. Incidentally, an HSCA is a cluster adapter, commonly used in Ethernet logic. Took me quite a while to figure this out.
You can register to watch the complete VC Formal SIG HERE.
The semiconductor intellectual property (SIP) market is an integral part of the semiconductor industry. Third-party IP has propelled the industry, opening the door for many new products from start-ups to established IDMs. Enabling increasingly complex devices, reducing the cost of product development and reducing the time to market for both leading-edge and mature products are just a few of the benefits of third-party IP.
For the most part, third-party IP has used a business model that employed licensing and royalty fees. This payment arrangement has been successfully adopted by most market players and has matured with the IP market. Over time, we have seen a wide range of licensing and royalty fees depending on the supplier, the volume that is associated with the use of the IP and the complexity inherent to the IP itself. In general, IP users have been constrained by the rules and regulations of closed architectures, even though some of this IP has allowed the market to be highly successful. Over the years, some users of IP have been disgruntled with the lack of design flexibility and the high licensing fees and royalties associated with closed architectures.
Open architecture IP allows users to customize and adapt cores to their own specific applications and provide the opportunity for unique differentiation. RISC-V is an open-architecture Instruction Set Architecture (ISA) that is garnering industrywide attention.
The RISC-V Foundation was established to promote industry adoption and ecosystem collaboration of the RISC-V ISA. In order to gain a better perspective on the current situation, industry perception and future outlook, Semico Research surveyed industry players. Questions revolved around the use and adoption of the RISC-V ISA and its implementation. Semico Research then analyzed the data to develop a forecast for the number of RISC-V cores that will be consumed by the market.
Semico Research conducted a survey (RISC-V Market: Momentum Building) in November 2020 of RISC-V users. This follows an initial survey and report published by Semico in 2019. With this study, we wanted to quantify the total available market (TAM) for IP cores and estimate the served available market (SAM) for RISC-V IP cores. We surveyed and interviewed a cross section of the semiconductor industry to gather information related to the type of devices that are being designed with RISC-V and their target markets.
Semico, in conjunction with the RISC-V Foundation, identified 35 markets and developed both a TAM and a SAM for each of these markets. Utilizing Semico’s extensive end-market databases, we developed a forecast out to 2025. This report focuses on four semiconductor devices which have a high value opportunity to use RISC-V cores. These devices are:
Advanced Performance Multicore SoC
Value Multicore SoC
Basic SoCs, and
FPGAs
Semico’s survey results, RISC-V Market: Momentum Building, indicated increasing interest and significant ongoing developments for RISC-V products in all major end applications. RISC-V devices are also targeted at a broad range of performance levels. The compound annual growth rate for RISC-V cores between 2020 and 2025 is nearly 160%. The fastest growing served available market is automotive which is projected to achieve a 217.7% CAGR.
By 2025, Semico Research predicts that RISC-V cores will capture over 14% of the overall CPU core business. We also expect this trend to continue beyond 2025 as RISC-V gains market share and the ecosystem continues to evolve and mature.
RISC-V’s flexible, open-source strategy provides a competitive advantage which is changing the landscape of the CPU IP market. Other IP vendors have or will expand their architecture to provide an open-source option to maintain a competitive position in the market.
When I started in EDA the big three were Daisy, Mentor and Valid (DMV as we called them). Then came Synopsys in 1986 followed by Cadence, which was a clever merger between ECAD (Dracula DRC) and Solomon Design. Daisy and Valid were pushed aside and then there were, “Three dogs hovering over one bowl of dog food, not a pretty site.” said Joe Costello, former CEO of Cadence, June 1995, CEO Panel discussion, Design Automation Conference.
The fourth comer was Avanti which of course was undone by a “minor” legal problem. I worked for Avanti so I can tell you from personal experience that acquisitions made that company a shooting star and a lazy outside consultant brought it back down to earth. As a result Synopsys acquired Avanti in 2002 then there were three again.
Just a quick note on the Avanti acquisition, Cadence sued Avanti into submission and to save the company from annihilation there was a handshake merger deal with Mentor. Avanti then took that handshake deal to Synopsys and a better deal was made which included extra money for “key” executives meaning the Avanti CEO and his son. Handshake deals meant nothing to Avanti.
Twenty years later the big three EDA dogs are Synopsys, Cadence, and Siemens EDA and the big three have never been bigger. So, how did Mentor become Siemens EDA?
Back in 2011 Mentor attracted the interest of stock activists. In fact, one of the most notorious stock activists, Carl Ichahn, made an unsolicited $1.9B bid saying Mentor must be sold to appease disenfranchised investors. As it turns out Carl was right but his timing was off and so was his price. In 2016 Siemens made a $4.5B offer for Mentor which was accepted but the question is why?
Siemens made the call to Mentor at the right time. The stock was down and activists were again starting to rattle sabers. The real issue was a change in customers: EDA was transitioning from chip companies as the majority of customers to systems companies, and systems companies do business differently.
EDA was really founded on the point tool concept. Point tool companies would bring innovation to EDA with the ultimate goal of being acquired. Chip companies used point tools to get better chips and better pricing from the big EDA companies. Selling just chips is a much smaller margin proposition than systems so EDA budgets were always tight. I remember routinely being told by big chip companies that they were cutting budgets but they wanted more tools.
Systems companies however look for a complete vendor solution covering as many steps in the systems development process as possible. Apple is a perfect example of a systems chip company and now there are many others.
Unfortunately, Mentor had fewer pieces of the systems puzzle than Synopsys and Cadence so they were at a disadvantage. Synopsys and Cadence also had a much more aggressive acquisition strategy than Mentor so the lead was widening.
Now comes Siemens which is the largest engineering solutions company that sells more than $60B to systems companies around the world every year (Synopsys and Cadence combined revenue is around $6B). Definitely a game changer for EDA. And having been with quite a few EDA/IP companies that have been acquired (including by Siemens) I can tell you by experience, Siemens is in this to win this.
So, now we again have three big dogs eating from a larger bowl of dog food, which is much more interesting to watch, absolutely.
Even as Honda Motors puts a so-called Level 3 semi-autonomous vehicle on the road in Japan – 100 of them to be exact – the outrage grows over semi-autonomous vehicle tech requiring driver vigilance. Tesla Motors and General Motors have taken this plunge, creating a driving scenario where drivers – under certain circumstances – can take their hands off the steering wheel as long as they are still paying attention.
Allowing for the hands-off proposition, for some, requires the definition by the system designer of a so-called operational design domain (ODD). This appropriately named protocol describes the acceptable circumstances and functional capability of the semi-automated driving.
The ODD concept is raised in the UNECE ALKS (Automated Lane Keeping System) regulation that defines the enhanced cruise control functionality and the systems and circumstances that make it allowable – including a “driver availability recognition system.” Critics have begun speaking up. The latest is Mobileye CEO, Amnon Shashua.
In a blog post, Shashua asserts that all of these developments represent examples of “failure by design.” By allowing vehicles to drive under particular circumstances, the offending designers are setting the stage for catastrophic Black Swan events because the ODD does not provide for evasive maneuvers, only braking.
It’s worth noting that the main Black Swan scenario envisioned by Shashua is the autonomous driving car following another car, when the leading car swerves to avoid an obstruction and the following autonomous vehicle is incapable of reacting fast enough to avoid the obstruction. Ironically, one of Shashua’s proposed solutions to this problem is to ensure that “the immediate response (of the robotic driver) should handle crash avoidance maneuvers at least at a human level.”
The irony is that in the circumstance of a robotic driver following another car, the robotic driver may in fact be able to respond more rapidly than the human driver. So why should human driving be the standard in all cases? There are clearly circumstances where robotic driving will be superior – too numerous to list here.
Let’s review the UNECE ALKS ODD requirements for semi-autonomous driving – what the Society of Automotive Engineers describes as Level 3 automation:
The Regulation requires that on-board displays used by the driver for activities other than driving when the ALKS is activated shall be automatically suspended as soon as the system issues a transition (from robot driver to human) demand, for instance in advance of the end of an authorized road section. The Regulation also lays down requirements on how the driving task shall be safely handed back from the ALKS to the driver, including the capability for the vehicle to come to a stop in case the driver does not reply appropriately.
The Regulation defines safety requirements for:
Emergency maneuvers, in case of an imminent collision;
Transition demand, when the system asks the driver to take back control;
Minimum risk maneuvers – when the driver does not respond to a transition demand, in all situations the system shall minimize risks to safety of the vehicle occupants and other road users.
“The Regulation includes the obligation for car manufacturers to introduce Driver Availability Recognition Systems. These systems control both the driver’s presence (on the driver’s seats with seat belt fastened) and the driver’s availability to take back control (see details below).”
So the UNECE is very specific about when its ALKS ODD applies. In a recent SmartDrivingCar podcast, hosted by Princeton Faculty Chair of Autonomous Vehicle Engineering Alain Kornhauser, Kornhauser complains that the average driver is unlikely to either study or comprehend the ODD or the related in-vehicle user experience – i.e. settings, displays, interfaces, etc.
For Kornhauser, the inability of the driving public to understand the assisted driving proposition of semi-autonomous vehicle operation renders the entire proposition unwise and dangerous. He also appears to assert that additional sensors are necessary to avoid the kind of crashes that have continued to bedevil Tesla Motors: i.e. Tesla vehicles on Autopilot driving under tractor trailers situated athwart driving lanes, and certain highway crashes with stationary vehicles.
What Shashua and Kornhauser fail to recognize is that Tesla has actually brought to market an entirely new driving experience. While Tesla has clearly identified appropriate driving circumstances for the use of Autopilot, the company has also introduced an entirely new collaborative driving experience.
A driver using Autopilot is indeed expected to remain engaged. If the driver fails to respond to the vehicle’s periodic and frequent requests for acknowledgement, Autopilot will be disengaged. Repeated failures of driver response will render Autopilot unavailable for the remainder of that day.
More significantly, while appropriately equipped Tesla’s are able to recognize traffic lights and, in some cases, can recognize the phase of the signal, when a Tesla approaches a signalized intersection it defaults to slowing down – even if the light is green – and requires the driver to acknowledge the request for assistance. The Tesla will only proceed through the green light after being advised to do so by the human driver.
This operation and engagement occurs once the driver has made the appropriate choices of vehicle settings and may not require that the drive understand the vehicle’s operational design domain. When properly activated, the traffic light recognition system introduces the assistance of a “robot driver” that is humble enough to request assistance.
Regarding Shashua’s concern that a too-narrowly defined ODD, that does not provide for evasive maneuvers, is a failure by design. But appropriately equipped Tesla’s are capable of evasive maneuvers. In fact, appropriately equipped Tesla’s in Autopilot mode are capable of passing other vehicles without human prompting on highways. It’s not clear how well these capabilities are understood by the average Tesla owner/driver.
The problem lies in the messaging of Tesla Motors’ CEO, Elon Musk. Musk has repeatedly claimed – for five years or more – to be on the cusp of fully automated driving. Musk insists all of the vehicles the company is manufacturing today are possessed of all the hardware necessary to enable full self driving – ultimately setting the stage for what he sees as a global fleet of robotaxis.
The sad reality is that these claims of autonomy have displaced a deeper consumer understanding of what Tesla is actually delivering. Tesla is delivering a collaborative driving experience which provides driver assistance in the context of a vigilant and engaged driver. But Musk is SELLING assisted driving as something akin to fully automated driving.
This is where the Tesla story unravels. Current owners that understand and choose not to abuse this proposition view Musk as a visionary, a genius, who has empowered these drivers with a new driving experience.
Competitors of Tesla, regulators, and non-Tesla owning consumers are angry, intrigued, or confused. Some owners may even be outraged at the delta between the promise of Autopilot – as seen and heard in multiple presentations and interviews with Musk – and the reality.
To add insult to injury, those drivers that have suffered catastrophic crashes in their Tesla’s – some of them fatal – have discovered Musk’s willingness and ability to turn on his own customers and blame them and their bad driving behavior for those crashes – some of which appear to be failures of Autopilot. This is the critical issue.
Musk is essentially using his own ODD definition to exempt Tesla of any responsibility for bad choices made by Tesla owners – or even misunderstandings regarding the capability of Autopilot. As a result, Musk’s marketing has indeed given Tesla a license to kill by enabling ambiguous or outright misleading marketing information regarding Autopilot to proliferate and persist.
The collateral impact of this may well be insurance companies that refuse to pay claims based on drivers violating their vehicle’s end user licensing agreement – the fine print no one pays attention to. Musk is muddling the industry’s evolution toward assisted driving even as he is pioneering the proliferation of driver-and-car collaborative driving.
Can Tesla and Musk be stopped? Should they be stopped? How many more people will die in the gap that lies between what Autopilot is intended to do and what drivers think it is capable of? How many is too many?
The saddest part of all is that Musk is an excellent communicator, so there is no question that he knows precisely what he is doing. That somehow seems unforgiveable.
Verification is a resource limited ‘quest’ to find as many bugs as possible before shipping. It’s a long, difficult, costly search, constrained by cost, time and quality. For a multi-billion gate ASIC,
The search space is akin to a space search; practically infinite
In this article we talk about the quest for bugs at the system-level, which it turns out is even more difficult than finding another Earth-like planet humanity can survive on!
FPGA prototyping systems make deep cycles possible for deep RTL bug searches scaled-up to full chip or sub-system level by running real software payloads with realistic I/O stimulus. In fact, with scale-out, you can approximate the throughput of silicon devices.
Terms of reference
Are we on the same page?
Modern FPGA prototyping systems are effective and performant platforms for software development (in advance of available hardware reference boards), system-level validation (demonstrating that the hardware with the target firmware/software delivers the required capabilities), and system-level verification (bug searching/hunting from a system context). Hardware and software bugs can be found in all use-cases. Remember…
Sadly, bugs do remain undetected (even after rigorous searches such as simulation and formal)
Why do hardware bugs escape earlier verification levels such as simulation and formal and what type of bugs can be found when using an FPGA prototyping platform as your verification environment? Hardware and software cannot be developed in isolation. How are you going to ‘validate’ the capabilities of hardware and software combined before committing to silicon? How are you going to validate the ‘target’ system in terms of real software and realistic hardware I/O?
What are the key capabilities that you will need from your FPGA prototyping environment to be successful? Deployed silicon will achieve exacycles (1018) of usage over millions of devices. What are both the achievable and the aspirational targets for ‘deep cycles’ (at least a quadrillion cycles!) of pre-silicon verification, and how do you scale-up to meet these goals?
Hitting the buffers with simulation
You’ve probably met all your coverage goals with simulation. Does this mean all of the bugs have been found? We know you wouldn’t bet your house on it! Consider this for a moment: If you are developing an ASIC or an IP Core that will likely run with a target clock speed in the GHz range; consider how many cycles will run in daily usage and then try to figure out the total number of cycles that you have simulated? You might be surprised (or depressed!).
1e9 and 1e11 cumulative scaled-out simulation cycles is equivalent to only a few seconds of activity
And that’s if you have the servers and licences. You probably have not run the target firmware or software or been able to simulate realistic I/O traffic yet. Are you confident to go to silicon on that basis? Don’t be fooled by great coverage results. As previously mentioned in The Origin of Bugs,
Covered != Verified
How many silicon respins can you afford to address critical design bugs?
If one thinks about actual devices operating at 2-3GHz or greater, and being deployed in the millions, those devices in aggregate are running exacycles (1e18) and greater every day. Now, it’s not the job of verification to simulate the entire lifetime of all devices but,
You need a convincing road-test
Given that, what is the minimum cycle depth we would want to achieve if we want to sleep at night? Companies simply can’t afford to do this with simulation. Emulation goes a long way towards it, but FPGA takes performance and scalability up to another level. The challenge is how to validate designs to this depth, pre-silicon?
The only viable solution is scaled-out FPGA prototyping.
For a modest 1GHz device, consider how many simulation hours are needed to achieve just one hour of target speed equivalent cycles:
Total Simulation time (@100Hz) = 3600x1e9 /100 = 36x1e9 seconds (10M hours)
(or 10K elapsed hours if you can run 1000 simulations in parallel)
The latest FPGA prototyping technologies can achieve speeds from tens of MHz to hundreds of MHz depending on the design parameters. Even here, engineering will need to scale-out the FPGA prototyping capacity to achieve meaningful deep cycle targets.
Approximating to Silicon
As an example, for an FPGA clock speed of say 50MHz, 20 prototype instances will give an equivalent of 1GHz throughput capability. In other words,…
20 prototype instances gets us a piece of silicon to play with!
Scale-out further, and it’s possible to approximate to the throughput of multiple pieces of silicon. So, it’s feasible to achieve deep cycles of pre-silicon verification in a practical timeframe. Of course, the level of scale-out needed depends on achievable FPGA clock speed, the target silicon clock speed, and the depth of testing being targeted.
To find most of the bugs (at least all of the critical ones)
Deep cycles of verification testing alone is not a smart enough goal for our quest.
Hardware acceleration unlocks the ability to run real firmware and software on the RTL
Booting an operating system and then running some software, or rendering a few frames of video, demands long sequences of execution that are not practical with simulation – you can’t wait that long for the test to complete. Emulation takes a big step closer to this capability, and FPGA prototyping takes everything a stage further.
Finding bugs that escape simulation, formal and emulation
Both FPGA prototyping and emulation enable a software-driven approach to system-level verification. Just booting the OS alone is likely to take several billion cycles.
Booting Android takes around 30B cycles; that’s only a few minutes for our 50MHz FPGA, versus several thousand hours for a fast 1KHz simulation! Running the target software or other software payloads such as compliance suites, benchmarks or other test suites, can and does find bugs that will have escaped earlier stages of verification. You might not find a huge volume of such bugs, but when you find them, you know you have…
Saved an escape that otherwise would have made it into silicon
So, the relative value of these bug finds is high. If you then multiply this testing load by the configuration space of both the hardware and the software, you can quickly escalate towards an extremely large volume of testing demand.
When bugs occur, can you detect them?
A really great way to improve failure detection is to leverage SVA assertions from your simulation and formal environments. When SVA’s fire, they pinpoint the failure precisely, which is a huge advantage when you are running huge volumes of testing! You may be able to implement a home-grown flow for adding assertions to your FPGA prototyping environment, or better still, the FPGA prototyping vendor will have already provided a workflow to do this.
Recommendation: Leverage SVA assertions to enhance FPGA-prototyping checking capability
When bugs occur, can you debug them?
Debug consumes a lot of engineering time and this is also the case for an FPGA prototyping approach. There have been many studies[1] of where verification engineers spend their time and most of them show that over 40% of time is spent in debug. Debug is labor intensive, so,
Efficient debug is critical
FPGA prototyping systems necessitate a different approach to debug compared with emulation. You might start the debug process with software debug and trace tools, but from this point onwards you are going to need to debug the hardware, requiring visibility of internal state at the RTL code level. This requires trigger points for events of interest and the ability to extract signal waveforms for debug. It’s an iterative process as the designer zooms-in on the suspicious timeframe and provide enough of the internal hardware state and logic signals to diagnose the bug.
FPGA prototyping systems provide multiple complementary debug strategies to accomplish this. A logic analyzer is required to set up the necessary trigger points to start/stop waveform traces. Debug can be performed at speed, with visibility of a limited subset of chosen signals (probe points), which are then stored to either on-FPGA memory, on-board memory or off-board memory when deeper trace windows are required. This works well, especially when the engineer has a good idea of where to search in the RTL. The limited set of probe points may be more than sufficient to debug most problems.
More complex bugs require full-vision waveform analysis, demanding a different debug approach where full RTL visibility can be reconstructed.
Quest impossible?
No, scale-up and scale-out!
Nothing is impossible, but certain things are hard problems to solve. With many ASIC designs trending to multi-billion gates, prototyping systems need to get bigger, and offer platform architectures that
Scale-up to handle bigger systems and sub-systems
by plugging multiple boards and systems together while minimizing the impact on achievable DUT clock speeds.
You may have started with a lab or desk-based setup, but quickly conclude that you need to deploy an FPGA prototyping cluster (or farm). Deep cycles can be achieved if you
Scale-out to approximate to silicon levels of throughput
Use real-world traffic on a system realistic platform
Advanced FPGA prototyping solutions offer strong build and compile workflows, debug and visibility solutions, and high degrees of flexibility to configure the system to the design needs and cope with devices of any size. Plug-in hardware such as daughter cards allow users to quickly configure the environment to be system-realistic and connect the DUT to real I/O with real traffic profiles. This invariably involves some stepping down of native I/O speeds to the achieved FPGA clock speeds, and it means that the prototyping system needs to be able to handle many asynchronous clocks.
Good automation of the flow (e.g., auto-partitioning) will get you to running your first cycles within a few days. You can then optimize to get the fastest possible throughputs needed to drive towards your approximated-silicon testing goals.
How many cycles to run, is itself, a dilemma; a ‘deep cycles’ dilemma!
In practice this is determined by budget and the capacity available, but the fact is that risk of getting it badly wrong is increasing rapidly. Billion gate designs that integrate a growing array of IP components are required in our modern world to perform ever more complex tasks for applications such as 5G, AI, ML, Genomics, Big Data…the list goes on…
With scaled-out FPGA prototyping you can approximate to the throughput of the final silicon device. But how effective is this software-driven verification approach?
Bug data will be the best metric to measure effectiveness and ultimately the ROI of the investment. Be sure to document and analyze bugs found from FPGA prototyping and assess what the total impact cost would have been had those bugs escaped to be discovered later in costly silicon.
Even if no bugs were found, which is a highly unlikely scenario, there is a value calculation for the assurance that this level of extreme deep testing brings.
Think of it as the “help me sleep at night” verification metric
A true-negative result is just as valuable as a true-positive when it comes to confidence levels and the true value of the final product.
Innovation in technology always creates bigger, better, faster ways of completing the verification quest successfully
Balance the investment between simulation, formal, emulation and FPGA prototyping in a way that reflects the complexity and size of the design, but critically the nature of risk if there were to be escapes. Justifying investment in the quest for bugs is predicated on many factors: the risk of reputational damage and huge rework/mitigation costs can build a strong ROI for investment in FPGA prototyping at scale.
Dan and Mike are joined by Semir Haddad, senior director of product marketing at Eta Compute and Vineet Ganju, vice president and general manager, low power edge AI business at Synaptics. Semir and Vineet discuss the collaboration between Eta Compute and Synaptics to develop new and innovative solutions for AI applications at the edge.
The components of AI systems, both hardware and software are discussed, along with strategies for power reduction. New applications, from building management to farming are also explained.
The views, thoughts, and opinions expressed in these podcasts belong solely to the speaker, and not to the speaker’s employer, organization, committee or any other group or individual.
Semiconductor startups used to rule the roost in Silicon Valley. The very name, Silicon Valley, comes from the birth of the semiconductor industry in the San Francisco bay area 60+ years ago. Large percentage of venture financing used to go to semiconductor startups, even as recently as 15 years ago. As a chip designer doing startups in the late ‘90s and early 2000s in the San Francisco bay area, I felt as if there was a semi startup on every street corner.
Not so much in the last 10 years. Maturing industry, high capital requirements, and dwindling exits have caused a huge decline in funding for semiconductor startups. The narrative of Silicon Valley moved to consumer internet and software-led businesses. Remember, software is eating the world. But in the last few years, we have seen a slow but steady resurgence of semiconductor startups and witnessed blockbuster financing and acquisitions. So, are semiconductor startups on the comeback trail? Or is it a mirage?
First, it is important to separate semiconductor startups from the overall semiconductor industry. Globally, the market for semiconductor products has been growing for several decades and in recent years led by growth in computers, smartphones, consumer electronics, and automotive and industrial electronics. Computers have gotten powerful, phones have faster internet speeds, consumer gadgets have gotten smaller – all because of the technological advances in semiconductors.
Source: “2020 State of the US Semiconductor Industry” from SIA
In a large growing market with improving technology why is there no place for new startups? While semiconductor is maturing as an industry, it is hardly a commoditized market with no place for innovation.
Well, structurally a few things happened:
Cleantech, one of the prominent semiconductor sectors, had flopped badly, losing lots of capital for investors.
The technological advances made in internet infrastructure and mobile technologies led to a boom in the software application ecosystem across social, mobile, and cloud, moving entrepreneurial interest away from semiconductors.
China emerged as a large supplier of semiconductors, thus increasing competition while driving down premiums in the market.
Huge waves of consolidation happened in publicly traded semiconductor companies.
Most sectors go through these phenomena – they are nothing new. When this happens, newer innovations kickstart the next disruption cycle. Why didn’t it happen with semi startups?
Well, the success of a startup ecosystem rests on the number and variety of experiments that are attempted. The more experiments across a wider variety of areas, the better the chances for a breakout success. For semiconductor startups, two main issues slowed down these experiments:
It takes roughly $30M of financing to even get to a product and another $100M or more to get to volume production.
Buyer universe is limited because of the public market consolidation. The reduced list of buyers meant smaller acquisition premiums and smaller exits.
Huge capital costs combined with a small buyer universe and small exits don’t make for an attractive investment area. Combine this with harder macro trend, we saw a vicious cycle of diminishing interest and funding in semiconductor startups.
Things have started turning around over the last few years. Since 2017, investments in semiconductor startups have increased significantly. So, what happened?
One of the main reasons is the explosion of Artificial Intelligence (AI). Innovative semiconductor products were required to meet the computing demand of AI. Advances in AI and Computer Vision helped make huge strides in autonomous vehicles and autonomous platforms. That drove demand for specialized semiconductor sensors and processor architectures.
The cost of building semiconductor products has come down significantly, especially if you are not operating at the cutting edge of semiconductor manufacturing processes. Most semiconductor products do not require these advanced processes. Today, you can build a first-generation semiconductor chip with $10M or less. That is lot less than $30M.
Expanding buyer universe – Apple, Google, Microsoft, Facebook, Amazon, and other large internet and software companies have started building semiconductors for their internal use and consumer products. They have become new acquirers of semiconductor startups.
US-China trade tensions have centered around semiconductors and there has been an increased focus on self-sufficiency and nationalization. This has driven demand for US semiconductor suppliers. Chip shortages facing the automotive industry is driving home the point of self sufficiency.
All these factors have driven huge investments and exits in Semiconductors recently. Just a few examples:
Qualcomm acquired a two-year-old semiconductor startup, Nuvia for $1.4B
Automotive Sensor Semiconductor companies, Luminar, Aeva, Aeye, Ouster and Innoviz all going public at valuation of $1B or more.
Investments flowing into semiconductor startups focused on AI, Quantum computing, Robotics, and others.
So, are semiconductor startups back for good? As new areas come up including Quantum computing, Space technologies, Computational biology … the need for innovation and newer semiconductor products is on the rise. I remain bullish that the resurgence we have seen in semiconductor startups is here to stay. And once again, the name, Silicon Valley, will fit its description.
As a long-time member of the EDA community, I really believe in user groups. EDA tools are complicated beasts, with many options and different ways to use them, and they are constantly evolving. Users interact with their local field applications engineers (FAEs) and sometimes corporate AEs (product specialists) as well on a regular basis. But there is a lot of knowledge on how best to use tools in the R&D teams that develop them. There’s also a great deal of experience spread among the user base, but it’s uncommon for users from different companies to talk directly.
User group meetings are a great way to get a critical mass of users, AEs, and R&D engineers together in one place. It’s best if they’re held in person so that all the participants can interact informally during breaks and meals in addition to the technical sessions. Of course, for now almost every type of meeting and conference is virtual. I was pleased to learn that Agnisys recently held its first-ever user group meeting, which they dubbed AUGER for some mysterious reason. I talked with CEO and founder Anupam Bakshi to find out the scoop.
What is AUGER and what does the acronym mean?
It stands for Agnisys User Group Educational Roundtable, and it is for the most part a traditional user group meeting. It was virtual, as you’d expect right now, but it was a really successful event. There’s also a bit of a pun involved since we wanted to drill down (auger) into technical details and not just present a bunch of fluffy sales/marketing slides.
What were your goals?
It seems to me that there are three key forms of communication that should occur in a user group meeting: vendor to user, user to vendor, and user to user. The host vendor should present updates on new tools and features, often directly from members of the R&D team, and provide guidance on best practices for using the tools, usually from the field and corporate AEs. The CEO should also offer a company vision and talk about future directions. Second, the vendor wants to hear from the users. It’s really nice to have some user presentations where they share their own experiences and best practices. There should also be a feedback session where the users suggest new tools, features, and support mechanisms to make their lives easier. Last but certainly not least, the users need to interact with each other. That’s harder to accomplish in a virtual format, but we included a roundtable slot where anyone could talk about anything related to Agnisys.
What sort of topics were covered in the technical sessions?
Our engineering team worked hard to develop brand-new slides with the latest and greatest information. Our engineering head summarized the most recent tools and features, many of which were suggested directly by our users. We had a second talk focusing deeply on the latest properties and customizations available for users to tailor our tools to meet their specific needs and fit into their design and verification environments. As you know, we started as a register automation company and this area remains a big part of our business. Accordingly, we held a session dedicated to the quality checks that we do on the register maps provided by users. The more accurate the input maps are, the better the results that we generate for RTL design, UVM testbench verification, embedded C/C++ code, system validation, and documentation. Finally, we had a presentation on how our tools can be used to ensure functional safety and security in chip designs, a hot topic in these days of increasingly autonomous vehicles.
Did the interaction with the users go well?
Honestly, it exceeded my expectations. I have to admit that I was a bit worried about the roundtable, wondering what we would do for 30 minutes if no one spoke up. Fortunately, that was not the case. We had a great facilitator in Tom Anderson, who ensured that we had a lively discussion. We had participation by users from multiple companies, and I was really pleased with that. The attendees were also active participants in the technical sessions, asking lots of good questions. A user from Intrinsix presented an excellent case study on how they benefit from our tools, and other users shared experiences during the roundtable.
Is there anything you might change for future events?
Well, we fervently hope that the pandemic subsides and that we will be able to meet in person next time. We plan on a hybrid event so that users unable or unwilling to travel can still participate. It might make sense to hold multiple events in different regions where we have concentrations of customers. We also hope to add a few more user talks; this first AUGER was developed on a rather tight schedule and not everyone had time to prepare slides. Overall, I expect that we will do many of the same things we did this year because they worked so well.
For those who missed the event, is it possible to access the talks?
In the race to get people out of the driver’s seat, the developers of autonomous vehicles (AV) and advanced driving assistance systems (ADAS) have gone off road and into the virtual world.
Using simulation to design, train and validate the brains behind self-driving cars — the neural networks of sensors and systems that perceive the world then react to split-second changes in the environment — is an essential tool for building the AV/ADAS platform.
Without simulation, developers are limited to naturally occurring events on public roads as their proving grounds. That means they’d spend far more time and money creating specific scenarios to test that sensors recognize and algorithms respond appropriately and safely to routine and hazardous conditions: red lights, pets and wildlife, oncoming traffic, or a child darting into the street.
Real-world driving and simulation work together to advance ADAS/AV technology. Real-world driving data is an important measure of road-worthiness and system intelligence, and it provides additional inputs to improve their algorithms. Simulation complements on-road testing with its ability to run orders of magnitude more scenarios and challenging events that are rare in real-world driving but essential to get right.
CNET writer Kyle Hyatt describes how simulation technology gives Alphabet’s Waymo engineers the capacity to “simulate a century’s worth of on-road testing virtually in just a single 24-hour period.” Another way of looking at it: It took Waymo 10 years to log 20 million actual driving miles, and a single year to simulate 2.5 billion.
As valuable as simulation is, sometimes it needs to pick up the pace, too.
That’s where the real-time radar (RTR) simulation engine takes the wheel. Ultra-fast and physics-based RTR can accomplish in minutes what used to take days.
Images Made Faster than Ever
Along with LIDAR, cameras and ultrasonic sensors, the typical AV also has multiple radar sensors for short-, medium-, and long-range sensing tasks. Long-range radars monitor traffic down the road for adaptive cruise control and collision avoidance. Shorter range sensors handle blind spots, cross traffic, and collision avoidance.
Traditionally, central processing units (CPUs) were used for automotive radar simulations. CPU architecture is fast, but not nearly fast enough to simulate complex radar systems at real-time frame rates.
Radars sample the world at up to 30 frames per second (fps). Automotive radars have multiple transmitters that broadcast hundreds or thousands of radar chirps and multiple receiving antennas that measure those signals at hundreds of frequencies for a single frame of data. Multiple-input multiple-output (MIMO) radars measure millions of data points per frame – hundreds of channels, chirps per channel, and frequencies per chirp. That’s all for one radar, and autonomous vehicles have multiple radars.
Caption: Range-Doppler image of busy street shows the radar mounted on the white car detecting distance (range) and relative velocity (Doppler) of objects from a moving vehicle.
CPU-based simulation requires up to a minute to simulate one frame of data from one radar, even with new algorithms invented by Ansys. A revolutionary leap forward is needed.
Ansys’ Real-Time Radar (RTR) overcomes these limitations with graphics processing units (GPUs) . The combined power of Ansys simulation and NVIDIA GPU acceleration can not only generate data from single-channel, multi-channel, and MIMO radars, it generates images faster than real-time. Scenarios that took days, months, or years to simulate before RTR are possible in seconds or minutes. Single-channel radars are over 5000x faster. MIMO radars that would have taken so long to simulate that we never tried also run thousands of times faster.
Radar perception algorithms detect buildings, curbs, and other street-level objects of interest from RTR range-Doppler imagery. The range-Doppler imagery is shown in the lower left quadrant with waterfall plots above and to the right. Post-processed ISAR imagery is shown in the upper right.
Real-Time Simulation Enables New Applications
Ansys engineers are using RTR to create amazing new capabilities, and the difference is astonishing.
Setting up a scenario at Waymo (picture courtesy CNET): https://www.cnet.com/roadshow/pictures/waymo-castle/3/
For example, Ansys RTR took just 11 seconds to simulate a car with five radars at 250 fps traveling down a 1-kilometer (0.6-mile) busy street for a 20-second scenario using an NVIDIA RTX A6000 GPU. Because safe urban driving means contending with all kinds of hazards and distractions, we packed our scenario with 70 vehicles, 14 buildings, over 300 streetlights and a nightmarish 42 traffic signals.
Ansys RTR simulates a vehicle with five radars at over 250 fps in a busy urban environment.
Before RTR, that same simulation would have taken more than 25 hours. If that seems like a vast improvement, consider this: Before Ansys developed new algorithms for Doppler processing, the simulation would have taken more than four years. RTR cuts simulation time to 11 seconds and maintains 57 fps for five radars, far faster than the 30 fps real-time metric. This 8000x speedup compared to 25 hours and nearly 3 million times speedup over four years.
“With real-time radar, high-fidelity simulation is no longer a barrier in the development of ADAS data pipelines. Radar sensor data can be generated at a rate never thought possible for physics-based simulations.”
Arien Sligar, senior principal application engineer, Ansys
RTR’s dramatic performance improvement has already paid off as an enabling technology in downstream analysis. Labeling images – identifying locations of objects such as people, cars, and buses in a radar image – is a time-consuming effort when done by hand. RTR users produced more than 160,000 labeled images overnight with RTR compared to 9,000 images in five days with slower simulation or several dollars per image labeling by hand.
Ansys engineers also connected RTR to a machine learning algorithm to teach a car to drive through reinforcement learning. Ansys principal application engineer Dr. Kmeid Saad conducted a week-long webinar, Reinforcement Learning with Physics-based Real Time Radar for Longitudinal Vehicle Control, that trained a throttle-control algorithm using GPUs on Microsoft’s Azure cloud. RTR simulated radar returns at a faster-than-real-time 50-60 fps on one GPU while three other GPUs ran the driving simulator and machine learning.
Physics-Based Simulation Built on Established Methodology
The RTR simulation engine is based on the well-established shooting-and-bouncing-rays (SBR) technique for large, high-frequency scenes. RTR generates range-Doppler images that display the distance and relative velocity of objects in driving scenarios under various traffic conditions. SBR models radar reflection off objects, multi-bounce propagation through the scene, material properties, transmission through windows, and radar antenna patterns. RTR incorporates all of these real-world interactions to produce physics-based simulation results.
RTR simulates both range-Doppler images and “raw” radar chirp versus frequency data. Raw data is used post-processing like angle-of-arrival (AoA), inverse synthetic aperture radar (ISAR), object detection, perception, and object classification analysis.
RTR models radar waveforms, which influence the radar outputs. The frequency modulated continuous wave (FMCW) waveform is common in automotive radars. RTR users enter waveform details from the radar’s specification, and RTR outputs capture physics specific to the waveform, such as range-velocity coupling.
Being able to measure the target range and its velocity has considerable practical applications, not the least of which is keeping the AV from bumping into the car in front of it as it slows or if it suddenly stops. Given that studies indicate AVs are involved in rear-end collisions more than any other type of accident, training forward sensors to detect when there’s danger ahead is critically important.
Trained for Any Situation
Human error contributes to 94 percent of severe traffic accidents according to the U.S. Department of Transportation’s National Highway Traffic Safety Administration (NHTSA). The ADAS/AV community is working to make ADAS/AV systems safer than humans by eliminating the preoccupied, tired, or careless person behind the wheel.
At the same time, ADAS/AV systems lack human intuition and experience. People can differentiate whether a hazard up ahead is harmless litter to ignore, a stick in the road to swerve around, or a more serious roadblock that requires jamming on the brakes. Currently, most ADAS/AV systems cannot yet make the distinction.
But the day when they can might not be too far off. With ultra-fast tools like RTR, which can model radar bouncing off the walls and through the windows with Autobahn-like speed, automakers will be able train driverless cars to handle almost any situation, including scenarios that were impossible to model before. And that will put consumer confidence and acceptance into high gear.
HCL Technologies is a large, well-established multi-national company with an annual revenue of around $10B and worldwide employee count of well over 150K. They provide valuable solutions to about 20 different industries and related market segments. Over the years, I have had first hand insights to their semiconductor design services solutions but had not heard of VersionVault. Over the course of the last 12 months or so, there has been many writeups about HCL’s VersionVault software. Following is a summary what I gathered by researching VersionVault. The primary focus of this blog is to complement what was covered in a very recent blog by Manish Virmani, general manager at HCL Software Labs.
Before my research got underway, I figured VersionVault must be a product related to version control system. That turned out to be just the tip of the iceberg.
VersionVault offers a safe, secure and powerful configuration system that provides controlled access to soft assets, including code, requirements, design documents, models, schematics, test plans and test results and enables ease of hardware/software co-development. It allows for tracking and managing changes for all of a product’s assets throughout the entire lifecycle of the product.
As good a product VersionVault is in terms of its built-in capabilities, its value to semiconductor and EDA customers is further differentiated through its integration to EDA tool suite platforms. It is currently integrated with Cadence Virtuoso platform and exploring integrations with more EDA tool suites including Synopsys Custom Compiler.
Figure 1: VersionVault Virtuoso Integration
Source: HCL Software Labs
In addition to features (refer to Figure 1) such as Interactive graphical schematic diff, command-line interface, hierarchical design management through a GUI, common tooling for SW and HW teams, etc., VersionVault also offers the following, not very obvious, nonetheless very important benefits depending on your particular role in the organization. Your role may be as a developer, engineering manager, project manager, QA manager, field support engineer, support manager, IT manager, CIO or CTO.
Ease of Adoption and Consistent Use
For ease of adoption and consistent use in practice, anything new should fit into the regular workflow. Seamless integration with EDA tool suite enables designers to take advantage of core capabilities of VersionVault, without leaving their familiar design environment.
Handling Multiple Versions of Product
Software products typically support multiple versions in the market at any given time. An engineer needs to be able to quickly switch between one development setup on version 1 to another development setup on version 2. Developers should be able to visualize the difference in versions across streams. VersionVault’s Unified Change Management feature makes that possible and enhances developer’s productivity.
Compliance to Procedures and Effective Management
Need for compliance to procedures and desire for minimal overhead is a delicate balancing act. VersionVault provides controlled access to soft assets, including code, requirements, design documents, models, schematics, test plans, and test results. User authentication and authoritative audit trails capabilities help meet compliance requirements with minimal administrative overheads.
Role-based Access and Control
As a company, you want a tool that can control access to IP based on one’s role on a project-level basis rather than just at the user-level basis. VersionVault allows you to create role-based specifications of access control, and reuse that specification across teams by assigning users to roles for each team. Access control can be modified at any level of the asset hierarchy, or inherited through the hierarchy if desired.
VersionVault provides effective authoritative build auditing. It helps streamline the edit-build-debug cycle and accurately reproduces software versions. By detecting dependencies, reusing derived objects wherever possible and producing detailed build audit trails, it helps ensure the reproducibility of software versions and improve build performance. To recreate a result, for debugging purposes or for analysis and review by a third party, this information is important.
Auditing and Compliance Support
For projects within regulated industries which require every change to be captured and logged, VersionVault makes it effort-less to comply. Every build of a “derived object” can automatically create a configuration record with every tool version and every file version used in its creation recorded. The configuration record may then be used for comparison purposes when a build goes bad, making it very easy to find what change caused the problem. Every configuration, which may consist of hundreds of thousands of files, can be recreated instantaneously, whether the configuration was created yesterday, or a decade ago.
Fitting Name
The product name VersionVault is a two-word mashup. When we come across the word “vault”, a common imagery that pops in our head is of “bank vault”. Based on that, it is not unreasonable for one to think of VersionVault as just a safe and secure way to perform versioning. But as highlighted in this blog, VersionVault is much more than that. Out of curiosity, I looked up the word vault for synonyms and discovered that it has so many different synonyms. Some of the synonyms are bound (as in leaps and bounds), leap, rise, safe, soar, and structure. This expanded definition seems to be more descriptive of the scope and extent of the capabilities of the product.
You may want to do your own evaluation of VersionVault for consideration as a solution for use at your organization.
