In this edition, Alex Melikian discusses with Verilab consultant Jonathan Bromley about the various verification languages that exist today, and where they may be headed for tomorrow. Jonathan is a veteran consultant and author of numerous conference papers, including the SNUG Austin 2012 Best Paper “Taming Testbench Timing”. He has closely monitored the development of design and verification languages, and since 2005 has served on the IEEE committee that works on development of testbench features in SystemVerilog.

In Part 1, Alex and Jonathan review the different verification languages available today, their histories and differences.

Alex Melikian: Hello, Jonathan, thanks for joining me on this edition of “Thoughts on Verification”. So the theme of this conversation is going to be about verification languages, the ones that exist today and what they’re going to be like tomorrow. So to get started, for the readers out there who are not too familiar with verification languages, maybe you can run through a few of them and describe what exists and what is available.

Jonathan Bromley: Well, whatever I say, I’m sure it will be incomplete. But if you go back maybe 15 years, people who were doing verification of any digital designs were likely using the same languages that they were using to do the design itself. And I guess there’s a good historical reason for that because those languages typically were actually designed for verification. They were designed to model electronic systems rather than to create them. And it was only at the beginning of the 1990’s that logic synthesis became popular as a way of taking a subset of those languages and turning it into physical hardware. So it makes good historical sense that those traditional languages, typically VHDL and Verilog, would have been used for doing verification.

But it wasn’t too long before people began to realize those languages were running out of steam and weren’t flexible enough. They weren’t dynamic enough. They weren’t good enough at coping with the kind of software-like constructs like strings, for example, that you expect to be able to use. So people moved on, and we now see people doing verification with languages that may or may not look quite a lot like those earlier ones.
Read the rest of this entry »

In Part 3, Alex and Bryan discuss some of the growing pains of adopting or solidifying Agile methods in your verification process. Bryan also discusses about his website, which brings to light Agile related issues in SOC development. Part 1 and 2 can be viewed here and here respectively.

Special Note: If you missed Bryan’s presentation “Yes We Kanban” at the MTV Conference, never fear! Bryan will soon release a whitepaper on Kanban and its merits in the verification world. Look for it to be published soon on the Verilab website.

Alex Melikian: I’m beginning to get the picture that Agile is not a “one size fits all” solution, but a collection of methods that can be cherry picked to match the culture and working environment of the team. As mentioned previously, where cross auditing is used instead of pair programming, or vice versa.

Sadly I feel there are companies out there that don’t engage in any of these Agile techniques. There’s always a reason like lack of time and/or resources. Others however, I believe is simply due to omission, and that’s something that has to change. So how can we at Verilab help some of our clients adopt and benefit from Agile techniques?

Bryan Morris: If the client is not aware about agile, I think we can provide some education on the various frameworks and techniques, and then help them decide which best fits their unique culture. As well, we can provide some guidance on how to introduce the agile techniques. Almost nothing will guarantee an unsuccessful agile adoption if you try swap out what they are doing and and introduce a completely new “agile” way of doing things. I truly believe that it’s best to use an incremental approach. Pick and choose a few techniques that best fit your team’s culture and experience, and the closer to what you’re already doing the better. Make that successful, and then pick the next “low hanging fruit” to tackle. I think we can help to educate and encourage our clients.
Read the rest of this entry »

In Part 2, Alex and Bryan discuss some Agile techniques and tools, and which ones can fit into your verification project management flow. Part 1 can be found here.

Special Note: For those attending Microprocessor Test and Verification (MTV 2012) conference in Austin TX, we cordially invite you to attend Bryan’s presentation “Yes we Kanban!” on December 10th. Bryan will present the concepts of Kanban, an Agile methodology, and how it can work for your verification project management needs.

Alex Melikian: I think in our business, people are used to things moving really quickly and having to cope with it. Do you think those involved in project management or even verification are already doing something that is similar to an Agile technique, but they just don’t know it?

Bryan Morris: Yes, definitely. I think people are using a lot techniques and sub-sets of Agile in isolation with other techniques. I think very few teams are are using a pure waterfall scheduling approach. Most teams already break the project down into little chunks (or mini-milestones). Some teams do code reviews that allow you to review work in progress. People do mid-cycle or mid-project reviews to understand where they can improve their process. They say ‘stop’ and review what we’ve done and figure out what we need to do to move forward. So yeah, I agree, I think there are a lot of people who are using these in pieces. I think what the Agile framework allows you to do is pull everything into one package that creates a common understanding of how it’s going to work.

AM: So, kind of a glue that ensures everyone’s work fits together.

BM: Yes, exactly.

AM: We were talking about a ‘customer’ before. Who is the customer in an Agile context? You mentioned the marketing department, but who else can be that customer?

Read the rest of this entry »

Verilab is currently conducting a survey to find out how SystemVerilog/UVM users are, well, using phasing and phase jumping. We would greatly appreciate your feedback! Click on the link below to take the survey.

UVM Runtime Phasing and Phase Jumping Survey

In this edition of ‘Thoughts on Verification’, Verilab consultant Alex Melikian discusses Agile techniques and methodologies with Verilab senior consultant Bryan Morris. Before turning towards the verification world, Bryan came from a long history of software engineering and related project management. His experience and pedigree offer in-depth knowledge of how Agile can help development teams improve productivity and responsiveness when facing the increasing demands of a modern day ASIC/FPGA project.

In Part 1, Bryan explains the concepts and origins of Agile, as well as describing examples of how it can be applied in hardware development projects.

Special Note: For those attending Microprocessor Test and Verification (MTV 2012) conference in Austin TX, don’t miss Bryan’s presentation “Yes we Kanban!” on December 10th. Bryan will present the concepts of Kanban, an Agile methodology, and how it can work for your verification project management needs.

Alex Melikian: Hi Bryan! Thank you for joining me on this edition of ‘Thought’s on Verification’. Today we’re going to be talking about a topic that is a bit of a mystery for me and I suspect a few of our readers: Agile methodologies and techniques. Before we get into it, I would like to ask you to give a little introduction about yourself for our readers.

Bryan Morris: Great! I’m Bryan Morris and Senior Consultant at Verilab. I’ve been in the industry for about 27 years, the first 15 years were principally in embedded software design. Doing software on routers, wireless base-stations, and then gradually I moved up the food chain into a systems analysis role, where I was managing a group that did performance analysis of algorithms that were going to be implemented on ASICs. That led me into the ASIC design and verification space. Over the last 12 years I’ve specialized in ASIC/FPGA verification.

AM: How were you introduced to Agile? Or, in a nutshell how would you explain what Agile is?

BM: My introduction to Agile is interesting. Old things become new again, you know, the idea of doing incremental development was done back when I started in software. There were quite a few “agile” ideas that were being used: ‘evolutionary prototyping’, ‘incremental development’, that form a part of what Agile is today.
Read the rest of this entry »

In Part 2, Verilab consultants Alex Melikian and Vanessa Cooper discuss some of the challenges of learning and adopting the UVM into a new verification environment, or an existing one. They also provide tips and available resources to help one accelerate their ramp-up and adoption process. Part 1 can be viewed here.

Alex Melikian: Let’s talk about the learning curve involved with adopting UVM. These things always imply an initial investment in terms of time. What do you say is the quickest payoff or quickest ROI that someone can gain from using UVM?

Vanessa Cooper: Well, I guess I’ll go back to the reuse issue. You’ve created some code – say, an AHB VIP. Hopefully, the next person who needs an AHB driver doesn’t have to reinvent the wheel because you’ve already created it. If they can pick it up off the shelf and run with it, that’s the quickest payback.

And once you get over the hump of learning the UVM I think productivity increases because everybody’s marching along the same path. You know where the files are. You know what type of files you need to create.

And it’s just a lot easier when someone new comes in, and they know UVM. They don’t have that huge learning curve of “okay now, where would I find my stimulus?” They know exactly where that is. That is another quick payback. But like you said, there is an initial learning curve. I’ll go back to what you said about the registers. I think on my first UVM project the register model was the biggest thorn in my side because it was a tad bit more challenging to learn than just the basic concepts of getting stimulus up and going.

And it took awhile of really stepping through the library, understanding what was going on, and how the register could be used as a scoreboard, how to do checking before I got it up and working correctly. Now, once that’s done, doing it again is simpler.
Read the rest of this entry »

The subject of this edition of “Thoughts on Verification” is the UVM, or the Universal Verification Methodology. Verilab consultants Alex Melikian and Vanessa Cooper discuss, explain and give insight to their experiences with the UVM. Before learning UVM, Vanessa had no previous experience with verification methodology. Hence, her opinions provide a ‘fresh’ point of view on the UVM, and what it can offer to the verification community.

In Part 1, Alex gives a brief historical summary on the UVM and its past predecessors. Vanessa talks about her experiences learning and adopting the UVM, having no prior experience with employing any verification methodology library. Alex and Vanessa also discuss UVM’s pros and cons from their respective experiences with it.

Alex Melikian: Hi Vanessa.  Thanks for joining me on this conversation.

Vanessa Cooper: Hi Alex.  How are you today?

AM: I’m doing fine, thank you.  So we’re here today to have a conversation about the UVM, the verification methodology widely pushed by the EDA industry. Not only is it available in SystemVerilog but also for Specman/e.  And before we get into it and your experiences with learning and using UVM, perhaps I should talk about its history for readers who are not familiar with it.

Well, firstly UVM is a verification methodology library standard, where open source code libraries are available as reference implementation.  The available libraries are under the Apache license, but in practical terms it is free. It is not a commercial product, nor an EDA tool.  It’s straight out code that is either based in SystemVerilog or Specman e, but its intent is to be used as a Universal Verification Methodology.  That’s what UVM stands for. Where it came about is from a lineage of previous verification methodologies from different EDA vendors.

If we stay in the SystemVerilog world, the first verification methodologies that came out were AVM and VMM. This was back around 2005-2006. The problem however was that these verification methodologies were tied to their vendors, even though in the case of AVM, which was open source. Of course, it should be mentioned that Specman had the eRM, which was released around 2003, when Verisity was an independent EDA vendor. I mention the eRM because many of its concepts were transposed into the UVM. Back to the SystemVerilog world, after AVM and VMM, OVM came along in 2008. OVM was an evolution of Mentor’s AVM with concepts from Cadence’s URM SystemVerilog methodology. VMM continued on its own evolving path. So again, OVM was not quite universal. OVM was supported and available on some of the major simulators, but not all of them.

Read the rest of this entry »

In part 3, JL and Alex discuss some of the methodologies, outside of, but complimentary to HVL technologies, such as continuous integration. Typical mistakes and growing pains of adopting HVL methodologies are also reviewed. Finally, JL discusses about his verification blog, along with the various discussions and debates it has generated.

Alex Melikian: Sometimes the verification work that we do isn’t just about coding and writing requirements, test benches and test cases, but it involves usually a lot more than that.  For example, setting up a compute farm. Very often, verification engineers are involved with putting the compute farms together or at least giving some feedback into how it should be assembled. The setup of an adequate revision control or other EDA related elements are other examples.  Is there any particular challenge you took on that was related to verification work, where a client didn’t expect you to take on but recognized the importance of it once completed?

JL Gray: Well, one of the things in that area is the introduction of continuous integration techniques. Backing up, I think the major problems that exist on projects, regardless of whether they are using constrained random verification or not, are the project planning and the methodologies employed to carry the planning out. For example, the division of labor between design and verification engineers is frequently sub-optimal. And engineers often make decisions for the purpose of guarding their turf that do not support the success of the project.  Another issue would be design engineers who make decisions without taking into account the impacts or consequences on verification. These are, I think, the biggest problems that are faced – nothing to do with whether you use constrained random test benches or not.

Read the rest of this entry »

In part 2 of 3 of this conversation, JL and Alex talk over risks/reward involved with adopting an HVL workflow, as well as the diverging perspectives from management and engineers in a company. Also, they discuss the state of HVL technologies today and what might evolve from it next. Part 1 can be viewed here.

Alex Melikian: You bring up another hidden risk of not doing verification, negative cases that were unchecked in the design. Which once again comes back to our initial statement that unfortunately it sometimes takes a big and costly failure for some firms to realize that they do need verification, rather than taking a proactive stance and adopting it before the big costly failure happens.

JL Gray: But there is an interesting tradeoff though. I think there’s a big disconnect between the way that staff engineers view projects and the way that the senior management views projects. I often find that there’s a miscommunication that occurs there. The staff engineers are looking up and saying “if we would only just spend some money on this it would save us from so much pain” or we wouldn’t have to spend on so many re-spins on a chip. What are these guys in the senior management thinking? – They’re fools they don’t know what they’re doing.

Read the rest of this entry »

Verilab is pleased to introduce “Conversations About Verification”, a monthly publication featuring a discussion on VLSI verification topics. In this inaugural edition, Verilab consultant Alex Melikian discusses first experiences and adoptions of modern verification technologies with JL Gray, Vice President and General Manager, North America of Verilab.

In part 1, JL and Alex discuss about their first experiences involving advanced verification languages and methodologies. They also discuss why and how ASIC/FPGA development centers adopt and integrate Hardware Verification Languages (HVL) and related methodologies into their workflow. In addition, they also discuss some of the impediments as to why others hesitate to make the adoption.

Alex Melikian: Hi JL, thanks for participating in our inaugural conversation. Before we get things started maybe we should introduce ourselves to our readers. Since you’re the guest, go ahead first.

JL Gray: Sure. I’m JL at Verilab, I head up the North American operations. I also work with clients on coaching and consulting in the areas of verification planning, SystemVerilog, UVM, and other related types of verification activities. I’m also involved with the Accellera Verification IP Technical Subcommittee as a representative for Verilab. People can read up more about me through my bio.

AM: OK. I myself have been doing verification for about ten years now. I started out with Specman and was in the FPGA/ASIC department of a telecom company. The department was investigating new verification languages that were emerging and they assigned me on a team to do some research with Specman. That was my first taste of verification. It wasn’t like I had planned to specialize in verification when I graduated form university, the EDA industry had just started to produce concepts like functional coverage and the paradigm of verification into ASIC/FPGA development. But I found it to be a really powerful concept. It was a good balance between object-oriented software programming and low level HDL design. I found that really cool and I stuck with it. I have since moved on to learning and applying SystemC and SystemVerilog as well. What was your first experience with verification?
Read the rest of this entry »