Ralph Zak's Emulation Systems Blog
Ralph Zak's Emulation Systems Blog RSSEmulation 104 — Running More Tests in Less Time
In an earlier blog I talked about the value of emulation in terms of providing direct project cost and schedule reductions that generally dwarf the actual costs of emulation systems. I have been asked by some to provide a “prequel” discussion, with a higher level description of the SoC verification problem and how emulation systems address verification challenges.
Rather than trying to cover the universe of SoC verification problems all at once, let me address a few of those challenges in a couple of blog posts. You will see that emulation systems can address most the challenges in one way or another — by themselves, by complementing other tools, or replacing other equipment and verification tools altogether.
So let’s start with a look at what is going on to generate better, more complete functional verification tests, and then how emulation executes them in less time.
As designs have become more complex, new test methodologies and test generation tools have evolved to complement traditional manual, directed testing. These principally include constrained random tests and tests generated by high level, behavioral test benches. While easier to create, the resulting test suites tend to be extremely large, and long simulation runtimes just get longer, exacerbating the verification schedule problem.
Emulation systems are a perfect complement to these test development tools. When run as simulation accelerators, emulation systems deliver throughputs hundreds or thousands of times those of simulators. Weeks of tests are reduced to hours, and days of tests to minutes.
Further, verification methodology has evolved with new standards. For example, OVM provides transaction-based verification with interoperability between standards compliant simulation and emulation environments, making testbenches re-usable. Many high-level testbench constructs can now be synthesized for use in emulation by tools like Mentor’s System Verilog extended RTL compiler (xRTL compiler). This enables timed portions of the testbench to be executed within emulation system hardware with the DUT and talk through Acellera and Verilog standards-based communications to untimed portions executing on a host. The result is that both the DUT and testbench are accelerated.
Consequently, emulation enables running larger, more complex testbenches several orders of magnitude faster than simulation, resulting in much shorter verification time and generally a portion of the verification time savings passing directly to project schedule shortening the time-to-tapeout of the SoC. Further, testbench interoperability between simulation and emulation maximizes the productivity of adopting the latest test bench generation tools and verification methodologies.
As always, comments are welcome. For more information on Mentor’s Emulation Systems go to www.mentor.com/products/FV/emulation-systems/
Tags: ASIC emulation, emulation, FPGA boards, FPGA Systems, simulation acceleration, SoC Emulation, SoC simulation, SoC verification, verification
Emulation 103–Accelerating Transaction-based Verification
Transaction-Based Verification is a technique for verifying modern SoC designs with interfaces such as PCI express, using test benches at the transaction level of abstraction. Transaction-based verification complements directed and constrained random tests, and is an emerging methodology for verifying complex SoCs that have multiple on-chip standard bus and peripheral interfaces. Typically in a transaction-based verification environment, the test bench is developed in C/C++, System C or System Verilog, and is used to drive data to the RTL design blocks of an IC’s design. The principal advantage of transaction-based tests is that they can be developed much more quickly than directed tests without needing in-depth knowledge of the protocol or the SoC, and can be re-used whenever the target standard is applied.
Most SoC development teams employ a variety of test development methods. Regardless of whether tests are directed, constrained random, or traffic generator oriented, as chip designs grow, the complexity of tests, and their run times grow exponentially.
In the old days (I date myself), even before emulation became available, simulation acceleration systems were used to overcome the long simulation run times. But these systems were targeted at what would be seen today as very small designs.
Early emulation systems did not have the high speed host interfaces or the efficient simulator APIs like SystemVerilog DPIs available today. The early emulation systems were largely used for system integration and test, post-RTL development. Often the use of emulation was limited by the time it took to map designs correctly, and it was in a race to show productivity before the first silicon was delivered. Today’s FPGA prototyping performs pretty much the same function, and often faces the same issue. As a consequence, to accommodate the ever increasing verification problem with large chip designs, the ‘farm” of simulation servers emerged the preferred RTL verification environment in the late 90’s and persists in most design environments today.
Over the last several years, simulation farms have run into limitations due to the overall complexity of the verification challenge and the finite ability to parallelize tests and a farm’s attendant power and cooling requirements. For the past several years, as new emulation technology emerged, the use of emulation systems for accelerating simulations has become its primary differentiation from FPGA-based prototyping systems. The principal value of such acceleration is to shorten the time to tapeout as many more verification cycles can be achieved in a much shorter period of time. Plus, the days and weeks of block and full chip simulation runs are typically reduced to minutes and hours, allowing bugs to be discovered faster and fixes verified in less time. The result is that much of the time savings can be applied to directly shorten schedules, and/or to remove some of the risk of slippage.
With the emergence of (1) transaction-based verification for critical portions of SoC design, (2) standards for communicating between host and DUT in emulation systems enabling interoperability with simulators, and (3) the widespread adoption of SystemVerilog for test benches, it is now possible to synthesize timed portions of transaction-based verification environment into emulators along with DUT to accelerate a large portion of the test bench with the DUT in an accelerated simulation using emulation systems. Critical to this type of operation is the availability of synthesis tools for the most crucial high-level System Verilog constructs. With all the old bottlenecks of co-simulation in the early emulation systems eliminated, in such an environment, accelerated transaction-based verification can be run at nearly full in-circuit emulation speeds.
As a result, what we see in the emulation space is that the traditional driver of getting a high speed platform for early software debug and system integration is now being displaced by the huge advantage of moving many of the simulation runs to an accelerated environment. And, with the increased ease of developing re-usable transaction-based test benches, transaction-based verification acceleration is quickly becoming a mainstream requirement for SoC development teams.
Tags: ASIC emulation, emulation, FPGA Prototyping, simulation, simulation server farms, SoC, SoC verification, System on Chip, TBV, transaction-based verification, verification
Emulation 102 – Emulation ROI – How can you not to invest in Emulation methodology?
In my last blog I stated I was an evangelist for using emulation to verify SoC designs. I defined Emulation Systems as verification systems which provide (1) Vector and transaction-based simulation acceleration and (2) in-circuit emulation (ICE) capability to perform system integration and test using real world data before silicon is available. Emulation systems are typically built on custom emulation SoC’s which provide extremely fast compilation and place and route times, and provide full internal DUT visibility for debug, among other features.
What I have seen over the years in this business is that many companies believe without question in the benefits of emulation and use it extensively. However, many other companies never take the time to quantify the potential benefits of emulation on their development project schedules and costs. They look at emulation system costs as an incremental project expense without considering that they may actually reduce their project budgets and minimize much of their schedule risk by leveraging this methodology. Companies taking this latter view are likely to fall behind their competition which leverages emulation in their development processes to reduce costs and schedules.
Let me try to summarize the value emulation delivers in reducing costs and minimizing project schedule risk.
Everyone has a plan. But then there is THE PLAN that everyone truly believes is the real plan. Several studies have documented that about 80% of projects slip their Engineering schedules by 20% or more, and that the typical project can easily have 2-3 unplanned spins of silicon. While the costs of such slippage and additional silicon cycles are not budgeted, project after project has proven that they are real costs that can be expected on a SoC project.
So one can pretend the costs are not likely, and face the consequences, or one can look for ways to minimize the attendant project schedule and cost risks. Eliminating the engineering slippage risk to a project and eliminating a single unplanned silicon spin cycle can save millions of dollars of direct project expenses and easily justify adopting new methodologies and tools.
Experienced emulation users use emulation to reduce or eliminate just such risks. Emulation systems typically accelerate both signal level and transaction level verification by 1000 to 10,000x, depending on the environment and how it is used. That means block level tests taking a couple of days can often be run in an hour or so, and weeks of full chip testing can be done in hours.
I would not advocate that emulation replace simulation completely. However, if one begins accelerating block level tests mid-way in the block level RTL development process, and accelerates the majority of the full chip simulation runs with emulation systems, then the project time savings of simulation runs can be tremendous. This can greatly increase the efficiency of engineering by providing much faster feedback about problems in the design. There are also easily quantifiable attendant lower server and simulation license project cost reductions. Further, if one can take a fraction, say 20% of the time savings of tests to reduce project schedule, then you may be looking at many weeks of reduced project engineering costs – hardware and software engineering, project management, etc..
Every project has different design and development project profiles. But here’s an example.
Let’s look at a moderate chip development project of 20 million gates. Personnel expenses can easily cost $100,000 per week for 25-30 hardware and software engineers. A typical schedule, including the up front architectural phase would be in the 65 week range. Eliminate a 20% engineering slip on a one year project, you save $1.3M or more in personnel expenses. Dropping just one extra silicon spin, which from tapeout to validation can eliminates another 10+ weeks from the schedule, and you save another $1M in direct personnel expenses. Eliminate the mask set costs from the spin – save another $1M. $1M here, $1M there, and you start to look at real money, $3M so far and 20+ weeks of project risk taken out of the “real” project plan. Then you start adding in reductions in project allocated simulation license and server costs from being able to replace half of your block level simulation runs and most your full chip simulations with acceleration. Even with added costs for emulations systems and support, you might reasonably see 20 weeks schedule improvement and save a few million dollars in total costs.
We have not even looked at the business impact of shipping on time, or even ahead of schedule, which is what most emulation users report. For a true ROI, one should really consider the value of 20 weeks of added product shipments. Or the converse without emulation, the negative impact on product lifetime revenue of engineering slippage and the extra silicon spins.
Tags: emulation, FPGA Prototyping, functional verification, OVM, SoC verification, System Verilog, VMM
Emulation 101 – SoC Emulation vs. Prototyping: What’s the Difference??
This is my first blog posting about SoC Emulation for verification of SoC designs. To set the stage, along with my biases, I am currently employed by Mentor Graphics and responsible for business development in the Emulation Division. I am an un-apologetic, evangelist for hardware-based verification.
My experiences with hardware assisted verification began with simulation accelerators in the 80’s as a Director of Marketing. After an initial 3 year stint with Mentor, I then became the first VP of Marketing with Quickturn (now arch rival Cadence). I also worked with ASIC prototyping companies, Aptix and GiDEL. So my background covers a spectrum of technologies. I have seen an incredible evolution of verification technology in this time that mirrors that of the SoCs themselves.
In this initial blog, let me address a question frequently asked of me — What are the differences between emulation and prototyping? And what difference does it make to users?
Simply put, emulation systems provide strong tools for (1) RTL simulation acceleration with debug similar to simulation environments, but at hardware speeds, and (2) the ability to be used for system integration and early software debug before first silicon is available. Consequently, emulation systems generally are used to provide value across the full spectrum of project phases — accelerating block-level and full SoC simulation runs, allowing pre-silicon “in-circuit emulation/operation (ICE)” of the DUT, and for debugging problems in the design in the post-silicon validation stage of the project. ICE is essentially silicon bring-up, with the DUT in a reconfigurable form without having to manufacture the silicon.
Most emulation systems available today are characterized by having very advanced and robust software to configure designs quickly and to allow very high performance testing and debug of the DUT using signal-based or transaction-based test benches. The leading emulation systems represent the DUT within custom programmable ICs that embed structures designed to provide for extremely fast design compilations and configurations and for complete internal DUT visibility for debug purposes.
Prototyping systems similarly provide reconfigurable representations of ASSP/ASIC SoC designs. Generally such systems are useful only after the RTL is essentially debugged, and offer value only in the later stages of the project while first silicon is being manufactured.
Prototyping systems, and some low end “emulation” systems, are all based on commercial FPGAs. Prototyping systems, by my definition, lack the robust software environments to provide for rapid configurations, full debug visibility, and the use of the system for RTL debug via simulation acceleration of both vector-based and transaction-based testbenches.
Commercial FPGAs used in prototyping systems and their software are designed to perfect the implementation of a design going into a large volume production application, not for fast compilation speed and internal design visibility for debug. While they have some tools for visibility within an FPGA, most prototyping systems do not provide the level of visibility, triggering, assertion support, and debug across multiple FPGAs which is needed for SoC RTL verification.
Therefore, the true value of prototyping platforms is to provide a somewhat flexible hardware representation of a design that is useful to get a head start on system integration and software debug before silicon is available, similar to the value obtained from emulation systems running in ICE mode.
There are also some “low-end” emulation systems built on commercial FPGAs. While faced with the configuration and debug limitations of FPGAs, they straddle the middle ground by offering software for simulation acceleration. Such systems, while priced near the level of the leading emulation systems, offer value by providing a smaller form factor where space is an issue, while sacrificing the configuration time and debug features of the mainline emulation systems.
So the major differences between emulation and prototyping systems lie in the emulation system’s value of accelerating verification from block level development to complete system integration vs. merely a backend tool with limited hardware debug capability, but offering a platform for early software test and system integration.
In my next posting, I will address The Value Proposition of Emulation, or How Could You Not Be Using this Verification Methodology.
Tags: Add new tag, ASIC emulation, ASIC verification, EDA, FPGA boards, FPGA Prototyping, Prototyping, SoC, SoC Emulation, SoC Prototyping, verification
About Ralph Zak's Emulation Systems Blog
Emulation systems offer SoC development teams unparalleled abilities to reduce project schedule and cost risks and to improve product quality. This blog is a forum to discuss the value achievable from using emulation systems and technology developments in the field.
Latest Posts
- Emulation 104 — Running More Tests in Less Time
- Emulation 103–Accelerating Transaction-based Verification
- Emulation 102 – Emulation ROI – How can you not to invest in Emulation methodology?
- Emulation 101 – SoC Emulation vs. Prototyping: What’s the Difference??