Posts Tagged ‘Verification’
In my previous blog, I introduced the 2012 Wilson Research Group Functional Verification Study (click here). The objective of my previous blog was to provide background on this large, worldwide industry study. I will present the key findings from this study in a set of upcoming blogs.
This blog begins the process of revealing the 2012 Wilson Research Group study findings by first focusing on current design trends. Let’s begin by examining process geometry adoption trends, as shown in Figure 1. Here, you will see trend comparisons between the 2007 Far West Research study (gray line), the 2010 Wilson Research Group study (blue line), and the 2012 Wilson Research Group study (green line).
Figure 1. Process geometry trends
Worldwide, the median process geometry size from the 2007 Far West Research study was about 90nm, while the median process geometry size is about 65nm in 2010. Today, the mean process geometry size for a typical project is about 45nm—although you can see that over a third of projects today are designing below 32nm.
In addition to the industry moving to smaller process geometries, the industry is also moving to larger design sizes as measured in number of gates of logic and datapath, excluding memories (which should not be a surprise). Figure 2 compares design sizes from the 2002 Collett study (dark blue line), the 2007 Far West Research study (gray line), the 2010 Wilson Research Group study (light blue line), and the 2012 Wilson Research Group study (green line).
Figure 2. Number of gates of logic and datapath trends, excluding memories
The study revealed that about a third of the non-FPGA designs today are less than 5M gates, while a third range in size between 5M to 20M gates, and about a third of all designs are larger than 20M gates.
It’s important to note here that the data on the mean design size trends does not reflect volume in terms of semiconductor production. For example, you could have fewer projects designing at a small geometry, yet they have higher volume in terms of production.
In Figure 3, I show the mean design size trends between the 2002 Collett study (dark blue line), the 2007 Far West Research study (gray line), the 2010 Wilson Research Group study (light blue line), and the 2012 Wilson Research Group study (green line). Obviously, gate counts have increased over the years, yet a significant number of designs continue to be developed with smaller (and larger) gate counts as indicated by the mean calculation. Another observation is that, as you would expect, the mean gate count trend is essentially following Moore’s law.
Figure 3. Mean design size trends
Figure 4 presents the current design implementation trends for non-FPGAs as identified by the survey participants.
Figure 4. Non-FPGA current design implementation trends
The data in Figure 4 presents trends in design implementation approaches for non-FPGA designs, ranging from the 2002 Collett study (dark blue bar), the 2004 Collet study (dark green bar), the 2007 Far West Research study (gray bar), the 2010 Wilson Research Group study (blue bar), and the 2012 Wilson Research Group study (green bar). Note that the study seems to indicate that there is a downward trend in standard cell design implementation.
Figure 5. FPGA design implementation trends
For the 2012 study, we decided that we wanted to get a sense of the percentage of FPGA projects that target the very complex programmable SoC FPGAs that have recently emerged, which is shown in Figure 5. Examples of these programmable SoC FPGAs include: Xilinx’s Zynq, Altera’s Arria/Cydone, and Microsemi’s SmarFusion.
In my next blog (click here), I’ll continue discussing current design trends, focusing specifically on embedded processors, power, and clock domains.
A unique concept most beginners have trouble grasping about the Verilog, and now the SystemVerilog, Hardware Description Language (HDL) is the difference between wire’s (networks) and reg‘s (variables). This concept is something that every experienced RTL designer should be familiar with, but there are now many verification engineers with no prior Verilog experience trying to pick up SystemVerilog for their testbench. Verification methodology courses tend to concentrate on the Object-Oriented programming aspects of testbench design, but do not cover this topic thinking that it is for designers only. Not true. If you have to communicate with a DUT then you need to understand the difference between wire’s and reg’s (nets and variables).
Anyone tasked with having to design or verify a piece of hardware should have some basic programming skills and understand the concept of a variable. If not, you had better stop right here and brush up on some programming basics. The key concept that you need to take away from programming is that you write a value into a variable and that value is saved until the next assignment to that variable. This concept is referred to as a procedural assignment which is part of executing an ordered set of statements. An HDL may add some notion of time in between assignments and other statements. The last assignment determines the current value of the variable.
|Combinatorial Logic||Sequential Logic|
Initially, Verilog used the keyword reg to declare variables representing sequential hardware registers. Eventually, synthesis tools began to use reg to represent both sequential and combinational hardware as shown above and the Verilog documentation was changed to say that reg is just what is used to declare a variable. SystemVerilog renamed reg to logic to avoid confusion with a register – it is just a data type (specifically reg is a 1-bit, 4-state data type). However people get confused because of all the old material that refers to reg. Just forget about it and use logic from now on.
Another distinctive characteristic of an HDL is that it models massive amounts of parallel processes. At the lowest level of digital design, every primitive gate (AND, OR, DFF) is an independent concurrent process. Modules are containers representing processes modeled at different levels of abstraction. Groups of primitives and modules pass values to each other via networks of signals. In Verilog, a wire declaration represents a network (net) of connections with each connection either driving a value or responding to the resolved value being driven on the net. The output of each of these concurrent processes drives a net in what is called a continuous assignment because the process continually updates the value it wants to drive on the net. There are various ways to declare a continuous assignment, all of which represent permanent behaviors:
wire A, B, C;
assign A = B| C; // continuous assignment construct.
or(A,B,C); // gate-level instance terminal connection
mymodule m1(A,B,C); // module instance port connection
Although these are all different forms of continuous assignment constructs, none of them directly assign a value to the net like a procedural assignment would. All of the values being concurrently driven onto the net are passed into a built-in resolution function. The result of that resolution function is based on the strengths of each driver representing the hardware technology in use. For example, an interrupt request signal might use the wired-or (wor) kind of net to indicate that at least one device is driving a ’1′, otherwise it will resolve to a ’0′. Some signals will have weaker pull-up/down resistors that will be overridden by the values of a stronger driver. Most technologies do not allow driving different values on the same net and the net will resolve to an unknown ‘x’ when that happens. In this case only one driver is actively assigning a ’0′ or ’1′ and the other drivers are effectively turned off by driving a high-impedance or ‘z’ state. The consequence of this is that a bi-directional port must be modeled using a net in order to have multiple drivers on either side of the port.
See my recent DVCon paper for an example of modeling bidirectional signals along with other tips for connecting the Testbench to your DUT.
It turns out that the vast majority of nets in a design will only have a single driver, so no strength information or resolution function is needed. SystemVerilog added a feature that allows a single continuous assignment to drive a variable. The expression driving the continuous assignment is assigned to the variable every time the expression changes its value. As soon as you have more than one driver or need strength information, you must go back to using a net. You cannot mix procedural and continuous assignments to the same variable. The reason for that restriction is that there is no way to resolve the “last write wins” semantics of a procedural assignment with a driver that wants to continually assign the variable (i.e. when is the last write finished and the continuous assignment supposed to take over?).
In summary, you should now be using logic for 4-state variables (or bit for 2-state variables) to represent all of your single drive signals. Any signal with more or the potential for more than one driver should be declared as a wire.
The latest revision of the IEEE 1800-2012 SystemVerilog Language Reference Manual (LRM) is about to hit the press; though I doubt people will be printing the 1300+ pages on their own from the soon to be readily available online version. Here’s a little background into what’s in all those pages.
The first SystemVerilog LRM came from Accellera in 2002 as a set of extensions to the IEEE 1364-2001 LRM. This first LRM was called version 3.0 because it was considered the third generation of Verilog. Accellera released a few more versions and turned version 3.1a over to the IEEE in 2004. The IEEE released the 1800-2005 SystemVerilog LRM as a set of extensions to the 1364-2005 Verilog LRM, which became the last revision of the 1364 LRM. Four years later, the IEEE combined the SystemVerilog extensions with the Verilog LRM producing a single 1800-2009 SystemVerilog LRM.
Now, a short three years later, the SystemVerilog IEEE 1800-2012 LRM is ready having addressed 225 issues. The majority of these issues are clarifications and corrections to the existing LRM. However, a few enhancements ranging from the simple removal of the restriction on non-blocking assignments to class members to the major addition of multiple class interface inheritance made their way into the new LRM. A number of those enhancements will undoubtedly be presented at the upcoming Design & Verification Conference.
I’d like to demonstrate two enhancements that should be of value to most verification engineers. They address two of the more commonly asked SystemVerilog questions I receive: How do I generate an array of unique values? and How to I create covergroup bins to get toggle or one-hot functional coverage?
Generating unique array of random values
Many verification scenarios require creating sets of random instructions or addresses with no repeating values, usually represented as elements in a dynamic array. Earlier versions of SystemVerilog required you to use either nested foreach loops to constrain all combinations of array elements so that they would not be equal to each other. Or else repeatedly randomize one element at a time, and then constraining the next element to not be in the list of already generated values.
The new unique constraint lets you use one statement to constrain a set of variables or array elements to have unique values. When randomized, this class generates a set of ten unique values from 0 to 15.
You can also add other non-random variables to the set of unique values which has the effect of excluding the values of those variables from the set of unique values. When randomized, this class generates a set of ten unique values excluding the values 0, 7 and 15.
Complex coverpoint bin expressions
The previous SystemVerilog syntax for specifying functional coverage bins was very limiting. Unless you could explicitly state the individual bin values or range of bin values in your coverpoint definition, or could figure out a way to instantiate multiple copies of your covergroup passing in a different bin value as an argument, you were out of luck. This also made defining coverage crosses extremely difficult.
The new SystemVerilog bin syntax lets you specify a bin expression that is evaluated over the range of possible values of the coverpoint expression. The bin expression acts like a constraint, and the set of coverpoint values where the bin expression is true become the set of bins. The coverpoint below generates as set of bin values between 0 and 127 that are divisible by 3. The range is 0 to 127 because sbyte is a 7 bit variable.
Probably the most powerful feature is the coverpoint bin set that simply allows you to define an array of values that you want as bins. This is useful for specifying one-hot encodings, toggle coverage of a register, or any complex algorithm that can generate the set of bin values you want. The code below builds a list of onehot values in the encodings array, and then constructs the protocol_cg covergroup using the array as a set of bin values.
Available in the latest version of Questa
By the way, every feature discussed in this post is available in the latest version of Questa, 10.2.
A new style takes center stage
It was Fashion Week in Portland, Oregon in early October. And while the thought of Portland and fashion might not be believable to many in the world, especially those who look to the design houses of Paris or Milan, it was. What struck me was the blend of fashion with high tech this year. Intel took the opportunity to roll out its fashion inspired campaign (dressing room mirror sized tablets) and Mitsubishi used it to launch its new electric vehicle (named MiEV in case you did not know). Certainly it was more than just your run-of-the-mill runway show. But that was not the only thing “getting some style” here in the Portland area.
The Verification Academy team at Mentor Graphics has been working hard as well to restyle the Verification Academy website, modernize it and make content easily accessible. It made its debut in late September, a few weeks before the Portland Fashion Show. While these two things are a coincidence, the focus on a refreshed style should not to be totally unexpected.
Some of the changes just had to be made given the success of the Verification Academy. When it started a few years back, Harry Foster (the face in the picture of the Verification Academy website above) knew the adoption of advanced technology was hampered by unequal and slow distribution of knowledge. Part of the Verification Academy’s thrust was to bring information about advanced verification topics to the whole world in a format that could be easily used. The content comes from respected verification subject matter experts and the first “runaway success” was the Open Verification Methodology (OVM) training by John Aynsley from Doulos for the “basic” module and Tom Fitzpatrick from Mentor Graphics for the “advanced” module. The Universal Verification Methodology (UVM) course, likewise, has also joined the ranks of the highly watched. Updates to the Academy improve the services to deliver video.
We have moved to the most current web video protocols that allow modern browsers and mobile devices to easily access course content. You can watch courses on the “smaller” smartphone screens to the largest of TV displays with SD and HD video to support your viewing preferences. Since content is delivered in native web technologies, users do not have to depend on Flash or other plugins.
We have also migrated the Academy to the leading open source content management system and adopted the use SSL throughout the Verification Academy to make it more secure.
When we first started the Verification Academy, we did not know how large the community would grow nor could we predict the demands the community would place on the resources to support it. Today, there are almost 12.5K users making it the largest single site to support the verification professional. The changes we have made to the internals of the site show a speed improvement of over 400% by exploiting a commercial content delivery network to handle large media.
And for many members, where English is a second language, the video captions, when offered, are in plain text. Registered users can click on the picture to the right to see the UVM Introduction and enable closed caption to see how the text appears right below the video. (Or, from reading the text below video in the picture to the right, you can see John is introducing himself at the moment of this screen capture.)
We have also made big improvements to searches. The searching facility now scans across all content at once, from the forums, to the UVM/OVM Cookbook and presents the information to you in an improved way to allow you to filter the results to focus on just that you want to know.
Want to experience the new Verification Academy 2.0 style? Click here to go to the Verification Academy to see these changes and discover these and other changes yourself. Share your comments with me on what you think. Have we made it better for you? And if not, what more can we do to improve your experience even more?
At the 2012 Design Automation Conference, I had the pleasure of moderating a panel at a workshop titled “Post-Silicon Debug: Technologies, Methodologies, and Best-Practices.” This workshop brought together a collection of experts from industry, academia, and EDA to discuss the emerging challenges and solutions associated with post-silicon validation. The speakers presented different instrumentation strategies, as well as methods of using data collected by the debug logic to facilitate fast and efficient debug.
Performing verification on real silicon introduces a number of new and unique challenges. On the one hand, real silicon offers great execution speed, which enables a long test run that reaches deep into the design’s state-space. On the other hand, real silicon lacks both good controllability and observability, which serve an important role in pre-silicon verification. Assertions, which have always been one of my passions, have been shown to address both the controllability and observability challenges associated pre-silicon verification (for example, RTL simulation). And now, there is emerging interest in addressing these same challenges in post-silicon validation.
I’d like to invite you to check out my Tech Design Forum article titled Synthesizing assertion into hardware for faster debug. Obviously, synthesizing hardware assertions is only one of many new solutions that are currently being explored to contain the growing cost and effort associated with post-silicon debug. One attractive benefit of assertion-based techniques is that they provide a nice natural link between pre-silicon verification and post-silicon validation, in terms of reuse.
I’d like to hear your opinions concerning synthesizing hardware assertions, as well as post-silicon debugging challenges in general.
A system-level verification engineer once told me that his company consumes over 50% of its emulation capacity debugging failures. According to him there was just no way around consuming emulators while debugging their SoC design emulation runs. In fact when failures occur during emulation, verification engineers often turn to live debugging with JTAG interfaces to the Design Under Test. This enables one engineer to debug one problem at a time, while consuming expensive emulation capacity for extended periods of time. After all, when some of the intricate interactions between system software and design hardware fail, it can take days if not weeks to debug. To say this is painful, slow, and expensive would be an understatement.
Would you be interested to learn about a better alternative for debugging SoC emulation runs? Veloce Codelink offers instant replay capability for emulation. This allows multiple engineers to debug multiple problems at the same time, without consuming any emulation capacity, leaving the emulators to be used where they’re most needed – running more regression tests. And Veloce Codelink is non-invasive – no additional clock cycles needed to extract emulation data.
If you consume as much time debugging emulation failures as the system-level verification engineer above, Veloce Codelink could double your emulation capacity, too. To learn more about Veloce Codelink’s “virtual emulation” that enables “DVR” control of emulation runs, check out our On-Demand Web Seminar titled “Off-line Debug of Multi-Core SoCs with Veloce Emulation“. In this web seminar you’ll also learn about Veloce Codelink’s “flight data recording” technology that enables long emulation runs to be debugged, without requiring huge amount of memory to store all of the data.
Graph-Based Intelligent Testbench Automation
While intelligent testbench automation is still reasonably new when measured in EDA years, this graph-based verification technology is being adopted by more and more verification teams every day. And the interest is global. Verification teams from Europe, North America, and the Pacific Rim are now using iTBA to help them verify their newest electronic designs in less time and with fewer resources. (If you haven’t adopted it yet, your competitors probably have.) If you have yet to learn how this new technology can help you achieve higher levels of verification, despite increasing design complexity, I’d suggest you check out a recent article in the June 2012 issue of Verification Horizons titled “Is Intelligent Testbench Automation For You?” The article focuses on where iTBA is best applied and where it will help you most by producing optimal results, and how design applications with a large verification space, functionally oriented coverage goals, and unbalanced conditions can often experience a 100X gain in coverage closure acceleration. For more detail about these and other considerations, you’ll have to read the article.
And while you’re there, you might also notice that the entire June 2012 issue of Verification Horizons is devoted to helping you achieve the highest levels of coverage as efficiently as possible. Editor and fellow verification technologist Tom Fitzpatrick succinctly adapts Murphy’s Law to verification, writing “If It Isn’t Covered, It Doesn’t Work”. And any experienced verification engineer (or manager) knows just how true this is, making it critical that we thoughtfully prioritize our verification goals, and achieve them as quickly and efficiently as possible. The June 2012 issue offers nine high quality articles, with a particular focus on coverage.
Another proof that iTBA is catching on globally, is the upcoming TVS DVClub event being held next Monday 2 July 2012, in Bristol, Cambridge, and Grenoble. The title of the event is “Graph-Based Verification”, and three industry experts will discuss different ways you can take advantage of what graph-based intelligent testbench automation has to offer. My colleague and fellow verification technologist Staffan Berg leads off the event with a proof of his own, as he will present how graph-based iTBA can significantly shorten your time-to-coverage. Staffan will show you how to use graph-based verification to define your stimulus space and coverage goals, by highlighting examples from some of the verification teams that have already adopted this technology, as I mentioned above. He’ll also show how you can introduce iTBA into your existing verification environment, so you can realize these benefits without disrupting your existing process. I have already registered and plan to attend the TVS DVClub event, but I’ll have to do some adapting of my own as the event runs from 11:30am to 2:00pm BST in the UK. But I’ve seen Staffan present before, and both he and intelligent testbench automation are worth getting up early for. Hope to see you there, remotely speaking.
Advanced verification techniques including functional coverage and constrained random stimulus generation have proven themselves invaluable in the design of the smallest FPGAs to the largest SoCs today. Still many design and verification teams that need to and are willing to embrace these technologies have yet to do so. Verification environments written with basic hardware description languages like Verilog and VHDL, as well as home grown environments patched together with C, Tcl, or PERL scripts are entrenched and difficult to move away from. Adopting these new techniques requires training on several fronts. You need to learn the SystemVerilog language along with Object-Oriented programming skills. And to make your verification environments reusable and interchangeable with Verification IP (VIP) that you may want to get from outside sources, you need to learn the Universal Verification Methodology (UVM).
Or do you?
Maybe you can get started by using the minimal amount of things to get started. But how can you know what you need to know when there is so much to learn? That’s where the UVM Express comes in.
The UVM Express is a carefully planned path with a few key steps along the way to get you up and running. You learn just the things you need to be more productive at each step and advance at your own pace. There’s no need to digest everything at once to get up and running. The UVM Express path has four key steps:
Step #1 Organize your Testbench into a BFM
- Use a SystemVerilog Interface to group your Signals
- Write your test in terms of transactions
- Call tasks to execute transactions
Step #2 Add Functional Coverage
- Use Metrics to check Verification quality- How good are your tests?
- Add coverage agents
- Leverage pre-built VIP in passive mode
Step #3 Add Constrained Random Stimulus
- Improve your test quality by generating stimulus efficiently
- Leverage pre-built VIP in active mode
Step #4 Use the full power of the UVM
- Modify your environment to improve reusability and configurability
- Leverage all your code from the previous steps
The UVM Express adds to the many guides and examples in the UVM/OVM Online Methodology Cookbook on the Verification Academy. There is also a new UVM Express module that provides a multi-media walk through each of the steps. You can discuss this with me at next week’s DVCon 2012.
“Ready, Set, Deploy”
The last half year has seen a theme from Accellera Systems Initiative that declares its Universal Verification Methodology (UVM) is ready for design and verification teams to adopt. This theme started with a whitepaper from Accellera I authored with two of my peers, Stan Krolikoski from Cadence Design Systems and Yatin Trivedi from Synopsys. A day long UVM tutorial will be featured during “Accellera Day” at DVCon with the same ready, set, deploy theme. The UVM tutorial is timely as I have seen UVM gain traction as OVM users transition at the end of their projects and those who have yet to adopt a standardized methodology have likewise begun their adoption.
The UVM tutorial starts with an introduction to UVM, concepts of structured verification methodology, base classes, resource configuration management, error handling and report generation. A section on the UVM register package will show how to create and manage stimulus and checking at the register level. Several expert users will show how this fits together in a complex SoC verification environment and relate lessons learned in preparing the transition to UVM, architecting reusable testbenches, debut techniques and use of the TLM 2.0 in real verification environment.
The tutorial will be presented by expert verification methodology architects and engineers as shown below:
|Speakers:||Tom Fitzpatrick||Mentor Graphics Corp.|
|Kathleen Meade||Cadence Design Systems, Inc.|
|Adiel Khan||Synopsys, Inc.|
|Stephen D’Onofrio||Paradigm Works, Inc.|
|Mark Strickland||Cisco Systems, Inc.|
|Vanessa Cooper||Verilab, Inc.|
|John Fowler||Advanced Micro Devices, Inc.|
|Peter J. D’Antonio||The MITRE Corp.|
|Justin Refice||Advanced Micro Devices, Inc.|
Conference attendees may choose this tutorial or if you wish to attend the tutorial only, DVCon charges a modest fee ($75.00). You can register here for the day long UVM tutorial.
More UVM News
With 33 exhibitors at DVCon and the heavy functional verification content, what other venue could deliver the potential of breaking UVM news? I invite you to stop by the Mentor Graphics booth were we can share with you the latest in support of UVM. You will find us at booth 801.
I look forward to seeing everyone at DVCon!
Instant Replay Offers Multiple Views at Any Speed
If you’ve watched any professional sporting event on television lately, you’ve seen the pressure put on referees and umpires. They have to make split-second decisions in real-time, having viewed ultra-high-speed action just a single time. But watching at home on television, we get the luxury of viewing multiple replays of events in question in high-definition super-slow-motion, one frame at a time, and even in reverse. We also get to see many different views of these controversial events, from the front, the back, the side, up close, or far away. Sometimes it seems there must be twenty different cameras at every sporting event.
Wouldn’t it nice if you could apply this same principle to your SoC level simulations? What if you had instant replay from multiple viewing angles in your functional verification toolbox? It turns out that such a technology indeed exists, and it’s called “Codelink Replay”.
Codelink Replay enables verification engineers to use instant replay with multiple viewing angles to quickly and accurately debug even the most complex SoC level simulation failures. This is becoming increasingly important, as we see in Harry Foster’s blog series about the 2010 Wilson Research Group Functional Verification Study that over half of all new design starts now contain multiple embedded processors. If you’re responsible for verifying a design with multiple embedded cores such as ARM’s new Cortex A15 and Cortex A7 processors, this technology will have a dramatic impact for you.
Multi-Core SoC Design Verification
Multi-core designs present a whole new level of verification challenges. Achieving functional coverage of your IP blocks at the RTL level has become merely a pre-requisite now – as they say “necessary but not sufficient”. Welcome to the world of SoC level verification, where you use your design’s software as a testbench. After all, since a testbench’s role is to mimic the design’s target environment, so as to test its functionality, how better to accomplish this than to execute the design’s software against its hardware, albeit during simulation?
Some verification teams have already dabbled in this world. Perhaps you’ve written a handful of tests in C or assembly code, loaded them into memory, initialized your processor, and executed them. This is indeed the best way to verify SoC level functionality including power optimization management, clocking domain control, bus traffic arbitration schemes, driver-to-peripheral compatibility, and more, as none of these aspects of an SoC design can be appropriately verified at the RTL IP block level.
However, imagine running a software testbench program only to see that the processor stopped executing code two hours into the simulation. What do you do next? Debugging “software as a testbench” simulation can be daunting. Especially when the software developers say “the software is good”, and the hardware designers say “the hardware is fine”. Until recently, you could count on weeks to debug these types of failures. And the problem is compounded with today’s SoC designs with multiple processors running software test programs from memory.
This is where Codelink Replay comes in. It enables you to replay your simulation in slow motion or fast forward, while observing many different views including hardware views (waveforms, CPU register values, program counter, call stack, bus transactions, and four-state logic) and software views (memory, source code, decompiled code, variable values, and output) – all remaining in perfect synchrony, whether you’re playing forward or backward, single-step, slow-motion, or fast speed. So when your simulation fails, just start at that point in time, and replay backwards to the root of the problem. It’s non-invasive. It doesn’t require any modifications to your design or to your tests.
Debugging SoC Designs Quickly and Accurately
So if you’re under pressure to make fast and accurate decisions when your SoC level tests fail, you can relate to the challenges faced by professional sports referees and umpires. But with Codelink Replay, you can be assured that there are about 20 different virtual “cameras” tracing and logging your processors during simulation, giving you the same instant replay benefit we get when we watch sporting events on television. If you’re interested to learn more about this new technology, check out the web seminar at the URL below, that introduces Codelink Replay, and shows how it supports the entire ARM family of processors, including even the latest Cortex A-Series, Cortex R-Series, and Cortex M-Series.
About Verification Horizons BLOG
This blog will provide an online forum to provide weekly updates on concepts, values, standards, methodologies and examples to assist with the understanding of what advanced functional verification technologies can do and how to most effectively apply them. We're looking forward to your comments and suggestions on the posts to make this a useful tool.
- Part 1: The 2012 Wilson Research Group Functional Verification Study
- What’s the deal with those wire’s and reg’s in Verilog
- Getting AMP’ed Up on the IEEE Low-Power Standard
- Prologue: The 2012 Wilson Research Group Functional Verification Study
- Even More UVM Debug in Questa 10.2
- IEEE Approves New Low Power Standard
- May 2013 (2)
- April 2013 (2)
- March 2013 (2)
- February 2013 (5)
- January 2013 (1)
- December 2012 (1)
- November 2012 (1)
- October 2012 (4)
- September 2012 (1)
- August 2012 (1)
- July 2012 (6)
- June 2012 (1)
- May 2012 (3)
- March 2012 (1)
- February 2012 (6)
- January 2012 (2)
- December 2011 (2)
- November 2011 (2)
- October 2011 (3)
- September 2011 (1)
- July 2011 (3)
- June 2011 (6)
- Intelligent Testbench Automation Delivers 10X to 100X Faster Functional Verification
- Part 9: The 2010 Wilson Research Group Functional Verification Study
- Verification Horizons DAC Issue Now Available Online
- Accellera & OSCI Unite
- The IEEE’s Most Popular EDA Standards
- UVM Register Kit Available for OVM 2.1.2
- May 2011 (2)
- April 2011 (7)
- User-2-User’s Functional Verification Track
- Part 7: The 2010 Wilson Research Group Functional Verification Study
- Part 6: The 2010 Wilson Research Group Functional Verification Study
- SystemC Day 2011 Videos Available Now
- Part 5: The 2010 Wilson Research Group Functional Verification Study
- Part 4: The 2010 Wilson Research Group Functional Verification Study
- Part 3: The 2010 Wilson Research Group Functional Verification Study
- March 2011 (5)
- February 2011 (4)
- January 2011 (1)
- December 2010 (2)
- October 2010 (3)
- September 2010 (4)
- August 2010 (1)
- July 2010 (3)
- June 2010 (9)
- The reports of OVM’s death are greatly exaggerated (with apologies to Mark Twain)
- New Verification Academy Advanced OVM (&UVM) Module
- OVM/UVM @DAC: The Dog That Didn’t Bark
- DAC: Day 1; An Ode to an Old Friend
- UVM: Joint Statement Issued by Mentor, Cadence & Synopsys
- Static Verification
- OVM/UVM at DAC 2010
- DAC Panel: Bridging Pre-Silicon Verification and Post-Silicon Validation
- Accellera’s DAC Breakfast & Panel Discussion
- May 2010 (9)
- Easier UVM Testbench Construction – UVM Sequence Layering
- North American SystemC User Group (NASCUG) Meeting at DAC
- An Extension to UVM: The UVM Container
- UVM Register Package 2.0 Available for Download
- Accellera’s OVM: Omnimodus Verification Methodology
- High-Level Design Validation and Test (HLDVT) 2010
- New OVM Sequence Layering Package – For Easier Tests
- OVM 2.0 Register Package Released
- OVM Extensions for Testbench Reuse
- April 2010 (6)
- SystemC Day Videos from DVCon Available Now
- On Committees and Motivations
- The Final Signatures (the meeting during the meeting)
- UVM Adoption: Go Native-UVM or use OVM Compatibility Kit?
- UVM-EA (Early Adopter) Starter Kit Available for Download
- Accellera Adopts OVM 2.1.1 for its Universal Verification Methodology (UVM)
- March 2010 (4)
- February 2010 (5)
- January 2010 (5)
- December 2009 (15)
- A Cliffhanger ABV Seminar, Jan 19, Santa Clara, CA
- Truth in Labeling: VMM2.0
- IEEE Std. 1800™-2009 (SystemVerilog) Ready for Purchase & Download
- December Verification Horizons Issue Out
- Evolution is a tinkerer
- It Is Better to Give than It Is to Receive
- Zombie Alert! (Can the CEDA DTC “User Voice” Be Heard When They Won’t Let You Listen)
- DVCon is Just Around the Corner
- The “Standards Corner” Becomes a Blog
- I Am Honored to Honor
- IEEE Standards Association Awards Ceremony
- ABV and being from Missouri…
- Time hogs, blogs, and evolving underdogs…
- Full House – and this is no gamble!
- Welcome to the Verification Horizons Blog!
- September 2009 (2)
- July 2009 (1)
- May 2009 (1)