I should write a article on: What is the difference between reusing and salvaging…

by David Murray, 12/15/2010, Design and Reuse

As a hardware design engineer, I was never comfortable when someone talked about IP integration as ‘stitching a chip together’. First of all, it sounded like a painful process involving sharp needles, usually preceded by a painful accident. I happened to be the recipient of said stitches when, at 8 years of age, I contested a stairs post with my forehead, and sorely lost. I have to say, luckily, I have been quite adept at avoiding the needle and thread ever since. That was of course until once when, an hour before that important customer presentation, my top-shirt button, due to an over enthusiastic yawn, pinged across my hotel room floor like a nano-UFO. A panicked retrieval of the renegade button was followed quickly with a successful hunt for an elusive emergency sewing-kit. The crisis quickly dissipated as I stitched back the button in a random-but-directed type of methodology. Needle-less to say stitching, whilst sometimes necessary, makes me uncomfortable.

Stitching, according to Wikipedia, is “.. the fastening of cloth, leather, furs, bark, or other flexible materials, using needle and thread. Its use is nearly universal among human populations and dates back to Paleolithic times (30,000 BCE).” It also states that stitching predates the weaving of cloth. So, 32,000 years later, in these hi-tech times we are still stitching things together. It’s not fur this time, but ‘ports’. Stitching a chip together involves connecting ports together with wires. (Note the terminology also where, if you don’t use certain ports you ’tie’ them off).

Weaving is a different game altogether. One definition simplifies weaving as ‘creating fabric’. Thus a key differentiator between stitching and weaving is that stitching may refer to fixing/mending things whilst weaving is used to create. Stitching is an emergency, an ah-hoc approach (please refer to my stitched button above) whilst weaving is more structured, more planned. Stitching invokes the image of being bent over, eyes squinted, immersed in the tiniest of detail. Weaving is more graceful and productive. In IC design flow terms, I equate stitching with scripting. It is task that is useful to join pieces of the flow together. Weaving creates something. It transforms thread to cloth, and therefore equates more to synthesis. Weaving is a process.

So when it came to developing and naming a tool used to effectively integrate IP and create a chip hierarchy, in a structured manner, we didn’t consider consider ‘STITCHER’ – It had to be ‘WEAVER’.

Stitching is important to fix things, and is necessary in emergency situations, however it has its limitations and as if used as a core creation process, it may come undone. So as I ranted on during that vital presentation, as I got to the cusp of the value-add, I curbed my enthusiasm, keep it slightly in check just in case those button stitches came undone and resulted in a serious eye injury of an altogether innocent customer. What then, of those poor stitched chips? What if those threads start to unravel and your chip integration is running very late. You may have to resort to different type of Weaving, when dealing with your management, customers or partners.

Looks like Cadence is finally on offensive and pushing Specman strongly over SystemVerilog. As a long time user of Specman, I would like to see Specman wins the HVL war at the end which will make my skill and experience more valuable.

By Richard Goering on March 10, 2010

One thing I learned from the recent DVCon conference is that there are a number of common misconceptions about hardware verification languages (HVLs). I had a few of these myself. Two provocative and well-attended presentations provided a different way of looking at HVLs:

* “Apples Versus Apples HVL Comparison Finally Arrives.” Presented by Brett Lammers of Cadence Feb. 24.
* “Where OOP Falls Short of Verification Needs.” Presented by Matan Vax of Cadence Feb. 25.

Some of the misconceptions identified in these talks are as follows.

Misconception #1: The design language defines the HVL choice

At the beginning of his talk, Brett noted that verification is fundamentally different from design. With design, one is implementing a spec; with verification, one is checking the implementation. Instead of what the device should do, verification engineers are concerned about what the device should never do. Instead of area, timing and power, verification engineers prioritize test generation, coverage, and corner cases.

It thus makes sense that the unique characteristics of verification make HVLs “special,” as Brett put it.

An attentive DVCon audience listened to Brett Lammers’ HVL presentation.

Misconception #2: Object-oriented programming is the best way to get verification reuse

While OOP facilitates reuse in many software applications, it’s not a complete solution for HVLs, Matan argued. His paper explained that verification does not lend itself naturally to classic object-oriented design, and that attempts to insert OOP techniques place an additional burden on programmers. In a video interview in a recent blog by Joe Hupcey III, Matan stated that “what you’re doing with the object-oriented mechanism is emulating a different paradigm, and it would be much easier if the language could use that paradigm directly.”

As Brett noted in his presentation, OOP allows a modular approach by encapsulating behavior within objects, but verification presents many “aspects” (like checking, coverage, and error injection) that cut across many objects. An aspect-oriented programming (AOP) language like the e language makes it possible to represent aspects as modules of their own. “Verification represents a lot of aspects, and AOP allows you to capture them in a more manageable way,” Brett said.

Misconception #3: Verification productivity = simulation runtime

Verification engineers tend to focus on how fast simulators run. But overall project productivity involves more than just simulation speed, Brett noted. If you can shrink the time required to create the verification environment and write the tests, and spend more time, rather than less time, in regression testing, this will provide more time to find and fix bugs.

Brett noted that simulator performance depends on simulation tools and has no inherent connection to the language that’s chosen.

Misconception #4: Compiling languages are best and fastest

Compiled languages such as e and SystemVerilog do provide the highest simulation performance, Brett acknowledged. But a language that can be either compiled or interpreted, such as e, provides more flexibility. A mix of interpreted and compiled code may be better for development, and using all interpreted code helps with debugging.

Misconception #5: Legacy VIP means you’re stuck with an HVL forever

Not so, Brett said. Cadence has extended the Open Verification Methodology (OVM) to support e and SystemC testbenches and verification IP (VIP) along with SystemVerilog. VIP in these languages can be mixed in a common environment. The Cadence Incisive Enterprise Simulator supports e, SystemVerilog, and SystemC, making it possible to migrate from one language to another.

Misconception #6: One HVL is best for all

Not even the e language, with all its capabilities, is the best choice for everyone. Brett’s last slide looked at “which language fits best where.” As you can see, there’s a place for both SystemVerilog and e.

Here is some words of wisdom on verification from thinkverification.com. I could not agree with this article any more, especially on the last point. We verifiers should education the importance of verification to the company, especially to the executives who make the budget decision.

Your tool provider won’t tell you that, nor will those fancy methodology books, but verification is not all about mastering technical skills. True, those will help you very much in your daily work but verification is first and foremost TEAM WORK. But not only that, there are several key factors, or qualities if you will, that really distinguish the great verification teams from the good ones. Here there are:

Resourcefulness – this is the single most important quality that a verifier should possess. Verifiers live in a turbulent environment, and if there’s one thing certain about verification is that things never go according to plan. This turbulence is caused by two groups of factors – exogenous factors and endogenous factors. Exogenous factors could be vague specifications, evolving requirements and so on. Something that keeps shaking the ground beneath you along the way. Endogenous factors could be debugging complexity, tool problems, and so on. One way or another, these things affect predictability and quite often verification team members get stuck. The path they’re on is blocked and they need to find a new path to proceed. Being able to always come up with new approaches and steer the verification ship forward is paramount.
Executive Tip: Try to predict in advance what could go wrong at any stage of the verification process and always have a Plan B.

Excitement – verifiers, let’s face it, don’t necessarily enjoy much glory in their work. Their job is often (wrongly) perceived as boring and second in importance (not true either). Being able to constantly generate excitement is a key factor. Different team members find excitement in different things. For instance, some verifiers might find it exciting to reveal bugs. They like the feeling of finding a critical bug in the design, and you can’t blame them. Other team members might get a kick out of building comlex environments – they enjoy software engineering challenges and once they manage to put together a really nice verification environment they’re very satisfied.
Executive Tip: Identify what excites your team members, find out what tasks they’re really good at and try to assign each member a matching task, to the extent possible.

The Pareto Principle – as with everything else, the Pareto principle can be applied here as well to optimize the efforts of the verification team. A great verification team knows that 20% of their efforts account for 80% of their achievements. For example – in Coverage Driven Verification it is a known fact that achieving 80% of the coverage goals is the relatively easy part. Getting to 100% takes much more effort and time.
Executive Tip: The sooner you identify what 20% will generate 80% of your verification goals the better – focus on that!

Planned Mode vs. Combat Mode – verification projects typically have a work plan. The project is divided into groups of tasks and sub-tasks of various types along the project’s time-line. Experience shows that there are stages in the verification process where the team should stick to the plan at all costs. Typical stages – during the development of verification IP, or during the process of analyzing the Spec and generating verification plans. There might be, however, periods of times when the plan ought to be tossed away and the team should switch to “combat mode”. Once things start to stabilize again it’s time to go back to the Gantt chart and readjust the work plan. A good “combat mode” example is the regression phase which is usually the last phase of any verification project. In this phase the team is focused on debugging failing tests from the nightly or weekly regression. It’s hard to estimate the duration of this phase. In most cases reality dictates schedule. Another example – integrating verification IP or design IP. It doesn’t matter how much time such tasks should take, in reality those tasks cannot be forced into completion. They need their time. Code integration is therefore a classic “combat mode” phase where plans should be left aside, replaced by a big to do list.
Executive Tip: Plans are nothing; planning is everything (Dwight. D Eisenhower)

Educate Your Company – great verification teams not only outperform the good ones, but they also try to educate their colleagues along the way. Why? Because people who have no hands-on verification experience don’t understand it (“hey- what’s the big deal, just write a bunch of tests and run them. Now how hard could that be right?”). Ignorance and wrong perceptions inevitably lead to wrong decision making. The times are changing, and the sooner chip designers and managers realize that verification is much less bug hunting and much more system engineering than they think, the better.
Executive Tip: Make a short presentation on how verification is done today – concepts, architecture, methodology and tools. Your colleagues will thank you.

Every verification engineer should remember this list by heart so that they can educate their managers. The list is so true that I print a copy and pin it to my cube

“This is legacy code no need to verify it” - Hold your horses! are you 100% sure that you’re dealing with silicon proven code? are you sure that nobody’s touched it since it last worked?

“I can come up with a patch in 5 minutes” – That’s OK as long as you make sure you don’t end up with a verification environment that looks like a bunch of patches hooked together. Ask yourself how easily it would be to modify or fix your environment a week from today? Isn’t it worth it to take a couple of more minutes and write a robust code?

“Start checking and plan as you go” – A big no no! Don’t be tempted into this. Even if your task looks like a piece of cake, always plan in advance. You’ll be amazed to see how many problems can be completely avoided… With that being said – I know that some engineers out there prefer to get started and only then stop and plan ahead.

“This is really simple, no need for a test plan” – Consider your test plan document as your working contract. Whatever you put in it defines the requirements for your current work. If it’s a simple task then just write a test plan on half a page.

“Verification is not the product, no need to keep software standards” – True, verification is not the product but still – when you’re dealing with thousands lines of code, you’d better make sure there is a certain level of consistency, let alone programming errors.

“Don’t have time to add comments” – Remember the last time you spent half a day on reverse engineering somebody else’s code? How about your own code?

“Oh I know! Let’s just force the signal from outside” – Forced wires have this tendency to get forgotten along the way and then reappear at a later stage, usually a week before tapeout… So be extra careful.

“Must have regression running in the background all the time” - Regression runs alone can’t do the job. You must have a “Regression Sitter” to monitor and analyze the results or else – you’re just wearing out your servers.

“We have reached 100% coverage there’s no point in running more tests” – Not really. Your coverage model can only capture what you thought about in advance . Obviously a random test bench is capable of generating additional scenarios that might reveal a bug, so don’t stop at 100%. Instead – enhance the functional coverage model.

“Verifiers should be looking for bugs” – This is a common misconception of what verification is all about. Verifiers should be focused on building a well constructed, robust and complete test bench. Bugs will come out on their own.

The story of my friend and her new crush keeps evolving and it’s getting more and more interesting. It seems she already know more about that guy than I do, even though it is me who introduce her the guy. Let’s see how this romantic adventure will turns out, Pat and I will pay close attention to the latest development.