Posts Tagged ‘vertical reuse’
Thursday, September 1st, 2016
For those unfamiliar with the idiom, “hitting the town” or “going out on the town” means heading out to make the rounds of bars, restaurants, theaters, clubs, etc. It’s usually used in a city where such entertainment options abound. The topic of today’s post on The Breker Trekker blog is a particular club, DVClub, that packs in plenty of solid technical information along with entertainment. You may not have to go far to hit one; a DVClub event is likely to be coming to your city soon.
The history of the Design Verification Club (DVClub) is quite interesting, stretching back more than ten years. It started as an informal event for verification engineers to get together to share stories and talk about new technologies to help them do their jobs. You might have noticed that, unlike DVCon, the title means “design verification” and not “design and verification.” This gathering is intended for semiconductor functional verification engineers.
Thursday, August 18th, 2016
When we first began offering our Trek family of products for what’s now known as portable stimulus, we talked a lot about vertical and horizontal reuse. Vertical reuse means that you can create a scenario model for individual IP blocks and generate test cases to run in their UVM testbenches, then move up to clusters and subsystems. The IP models can simply be plugged together to form a higher-level model from which appropriate higher-level test cases can be generated.
At the full-SoC level, you can generate C test cases that run on your embedded processors. Horizontal reuse is the ability to move from simulation to hardware (acceleration/emulation, FPGA prototypes, and silicon) while generating appropriate tests for these platforms from the same SoC scenario model. We generally described both forms of reuse in a unidirectional flow. However, bidirectionality is very valuable and, we believe, essential for portable stimulus. Let’s cover that topic in today’s blog post.
Wednesday, August 10th, 2016
As some of you may have seen, two years ago the IEEE created an app that ranks the popularity of dozens of programming languages. They use twelve different metrics, from search results and social media mentions to technical publications and requirements listed in job openings. If you don’t like the way that they use these metrics, you can create your own ranking using your own mix. It’s really quite a clever idea and it generates lots of discussion every year.
For 2014 and 2015, C held the #2 spot, just below Java in the rankings. The big news this year is that C has edged into first place, although the top two spots remain very close as measured by the metrics the IEEE has chosen to use. C++ was in the #3 spot for the past two years, but for 2016 flipped places with Python. As you all know, we are strong advocates of C/C++ for verification and so we’d like to share some thoughts on these results and what they mean for our industry.
Wednesday, December 16th, 2015
Do you want to hear all the behind-the-scenes dirt from a workshop on the future of the MTV cable channel? Well, you’ll have to look elsewhere. “MTV” in this case means the International Workshop on Microprocessor Test and Verification, which celebrated its 16th incarnation in Austin two weeks ago. Although the name of the workshop has officially expanded to “Microprocessor and SOC Test and Verification” rest assured that the delightfully ambiguous abbreviation “MTV” will remain.
This was only my second time at this event, but I wish that I had been able to attend more. The setting is the top floor of the Hyatt Regency, with great views of Lady Bird Lake (formerly Town Lake) and downtown Austin. However, I noticed that recent high-rise construction has now blocked the sight of the Texas State Capitol from the hotel. The view might be distracting if not for the fact that the technical committee put together an interesting and diverse program, including a panel on portable stimulus.
Thursday, December 10th, 2015
The past two weeks, we’ve been having a bit of fun playing alchemist and letting readers in on some of the deep, dark secrets of graph-based verification technology. This week, we conclude the series by showing some additional capabilities for our scenario models that are easy to control and view in a graph visualization. Our point is, of course, that graphs are a natural way to represent data flow and verification intent with no advanced degrees from MIT, IIT, or Hogwarts required.
As a quick reminder, graph-based scenario models begin with the end in mind and show all possible paths to create each possible outcome for the design. They look much like a reversed data-flow diagram, with outcomes on the left and inputs on the right. Breker’s Trek family can traverse the graph from left to right, randomizing selections to automatically generate test cases tailored to run in any target platform. Today, we continue using our example of a scenario model to verify that an automobile can move forward or stop.
Thursday, December 3rd, 2015
Last week, we began exploring some of the ancient, mysterious powers of graph-based scenario models to show their power for verification and ability to capture the verification space, many aspects of the verification plan, and critical coverage metrics. We’re just kidding about the first part; there’s nothing at all mystical or magical about graphs. In fact, this series of posts is intended to show the opposite and demonstrate with a easy-to-follow example the value of graphs.
As we noted in our last post, graph-based scenario models are simple in concept: they begin with the end in mind and show all possible paths to create each possible outcome for the design. They look much like a reversed data-flow diagram, with outcomes on the left and inputs on the right. An automated tool such as Breker’s Trek family can traverse the graph from left to right, randomizing selections to generate test cases that can run in any target platform.
Tuesday, November 24th, 2015
If there’s one thing that Breker is known for, it’s the use of graphs for verification. From our earliest days, we harnessed the abstraction and expressive power of graph-based scenario models to capture the verification space, many aspects of the verification plan, and critical coverage metrics. As we reported in a post a few weeks ago, it looks certain that the industry will follow our lead and base the upcoming standard from Accellera‘s Portable Stimulus Working Group (PSWG) on a graph representation.
As discussions have proceeded both within the PSWG and informally with interested parties, it has become clear that “graph” may not mean the same thing to all people. Our view of graphs is precisely defined in a way that makes it easy for users to create them and feasible for our tools to generated complex, multiprocessor test cases from them. Most of the key concepts can be communicated easily by the use of a familiar example, which we will begin in today’s post and continue next week.
Tuesday, November 17th, 2015
In last week’s post, we dissected the results for verification languages and methodologies from a recent survey by Mentor Graphics and Wilson Research Group. The main result was that SystemVerilog is growing in popularity on all fronts, but we observed that C/C++ has a significant presence. We also argued that the survey’s focus on simulation likely resulted in C/C++ being under-represented since these languages are widely used for verification with hardware platforms and for silicon validation in the lab.
We see C/C++ as the common link for many types of programming activities, and so widely known that many consider it the lingua franca of software. Just type “lingua franca C/C++” into your favorite search engine and scan the results for some interesting arguments and a few counter-arguments. To be fair, some observers consider C the lingua franca and downplay C++. We tend to group them together since object-oriented programming is now widespread and so moving from C to C++ should be a natural transition.
Wednesday, November 11th, 2015
One of the cliches we hear from time to time in the industry is “designers want to stick with a single language, but verification engineers love learning new things.” The implication seems to be that because verification engineers have diverse jobs that require them to juggle lots of different tools and models, they necessarily have to learn new languages and methodologies on a regular basis. Of course, they may not actually love learning new languages; doing so may just be in the nature of their work.
Regardless of whether or not they “love” new languages, it is clear that most verification projects involve multiple languages and multiple approaches. One way to gauge the current situation is to turn to the excellent survey that Mentor Graphics performs with Wilson Research Group every couple of years. Harry Foster wrote a series of posts on the Mentor verification blog that give considerable insight into what verification (and design) engineers are doing on real projects.
Friday, October 2nd, 2015
Anyone who has followed Breker for any length of time knows that our key technology is the ability to generate both Universal Verification Methodology (UVM) testbench transactions and C test cases running on SoC embedded processors automatically from graph-based scenario models. Yes, that’s a long sentence but it’s most of the “elevator pitch” that we might deliver to a potential investor or to a visitor at a trade show booth asking what we do.
For the purposes of today’s post, note that graphs are the root of the solution we provide. Ten years ago, when we first began talking about the idea of graphs as the basis for functional verification of complex chip designs, we were the proverbial pioneer with arrows in our back. But many successful customer engagements and the ever-rising need for better verification have validated our position. Graphs are clearly the “next big thing” in verification and we’d like to explain why.