Josh Rensch, Application Engineer, Mentor Graphics
How design engineers can get verification engineers to stop complaining, and other advice.
Hey you, verification engineer. Yeah, you. Are you tired of how long it takes you to figure out what the design is supposed to do? How much time it takes to jury-rig up all the pieces of the verification environment only to be told that isn’t what is supposed to be tested in the first place? Well, this article is for you.
Well, in truth, not actually for you. It’s for your designers. You should print it out and give it to them. Tell them it has some tricks and tips to make your life as a verification engineer easier. My hope is that your designers will better appreciate the whole verification thing, or at least develop more empathy for you. I know it’s hard being a verification engineer these days. But with any luck your designers, after reading this, will start to make it less painful for you to do your job. From here on out I will be talking to the designers and not verification engineers.
Hey you, design engineer. Yeah, you. Are you tired of the whiny verification engineer who is always asking you for stuff? Are you tired of this same verification engineer saying you have a bug that turns out not to have been yours in the first place? Do you like to learn of these bugs 15 minutes before you’re going home to have dinner with the family? Well, this article is for you.
Let’s start out by talking about documentation. I know everyone hates documentation. As a designer, you hate it because it takes away from writing code and doing fun stuff. It’s never good enough for the verification team. No matter how much time you spend on it, someone is always trying to correct your grammar instead of looking at the content. Here are some areas to focus on to make your verification team happy.
As Mark Twain said, “If it’s your job to eat a frog, it’s best to do it first thing in the morning. And if it’s your job to eat two frogs, it’s best to eat the biggest one first.” The lesson is clear. Start with documentation. I know that managers and executives push you to start writing HDL since that is the deliverable. But answer me this: if you boarded a plane destined for New York, would you be happy if the pilot came on the loudspeaker and told you that he doesn’t have a plan to get you there? That is exactly how people do HDL designs. They write code before they plan their designs. If you want the verification team off your back, document your interfaces, your state machines and what your blocks are supposed to do. This not only helps you and your fellow designers to plan things out ahead of time, it helps the verification team that’s responsible to make sure your design is doing the correct things. Besides, when the verification team comes asking a question, wouldn’t it be great to refer them to the documentation instead of taking up your time explaining things? Just saying.
Don’t just use words for your documentation. Pepper the thing with diagrams of various parts of your design, whether it is a true state diagram or one showing all your blocks and how they connect. This will save you hours of time drawing on the whiteboard explaining things to every verification person on the team (this should be good news unless you really like the smell of dry erase markers).
I’ve asked around and it appears to be a universal constant (like gravity) that all college programming classes want the whole two lines of comments for each line of code. Now, you might not need to go that far, but that estimate is not all that far off. Great comments in code do three things. First, they help you remember what your intent was when writing that code. Second, they help you quickly debug issues that come up. And lastly, it helps others who need to take a look at the code when you are on vacation. You do get vacation, right?
Besides inserting those comments, please use variables with meanings that are understandable by everyone. If it’s too much typing to give variable names of any length, take a look at tools out there that can expand your short type snippets to longer, more meaningful names. These tools also can be used to create templates to make your code look more uniform.
Have you ever noticed how the interfaces between two blocks usually represent a major sore spot for the verification team? Or that there appear to be lots of issues in these sections of code? If you are sick of these issues, here are some techniques that can be used to make things less complicated for the verification team.
We know, the interface you’ve come up with to connect to another block has patent and IEEE standard written all over it. People just need to see it so they can see the genius of it. Know, however, that these custom interface ideas cause more work for a verification engineer. Yeah, I know, they don’t do nearly enough work. Still, are the complaints and whining worth it? Might I suggest using a standard interface instead? That way the verification team can use off-theshelf verification IP, which will make life easier for them. Using a standard interface also means less documentation for you. Just refer the verification engineer to the specs in your design documents.
Okay, so we get it. You can’t use a standard interface. That’s cool. It happens that occasionally one of the hundred plus standard interfaces out there doesn’t do it for you and your team. When these situations happen, you should convince the other designers to use your award-winning interface. They will appreciate the greatness of your interface. They might even make a suggestion or two that would make your interface work better in their situation. The key in this discussion is to get everyone on the same page. Everyone should be using the same interface so that the verification engineer doesn’t need to whine about creating a bunch of different interfaces.
Are you using SystemVerilog? If so, that rocks. This means you can make use of SystemVerilog interfaces. They are a construct that bundles signals together. SystemVerilog interfaces are used primarily to group signals that represent a bus or a specific protocol. You can point your verification engineer to these bundles and say “I’ve done your work for you. Now just bundle some verification stuff in here too.” The latest monster in the closet is registers. We’ve all seen the statistics. Designs are getting larger. What? You haven’t seen that chart and didn’t know that? Well, email me so we can talk. That being said, bigger designs mean more and more registers. This also leads to more complaining by verification teams.
With regards to addresses of registers, align them on either word or double word boundaries. This simplifies things for the tools. What tools? The ones that the verification team uses to generate their models of the registers. Yes, verification people use tools to generate their registers while you are forced to write them out by hand. Not that you need to do this manual work. They didn’t tell you? Most of the same tools that verification uses to generate their models and tests of registers can be used to create your environment as well. Pretty neat, eh?
Now this is one that people don’t think about much: byte enables. These things can play havoc on your verification team, who winds up spending more time figuring out how to work on byte enables and less working on verifying your beautiful state machine. No one wins in that scenario. So try to remove the use byte enables, if possible. Most people have more than enough register space, so use it.
Most registers have fields. Given that, group registers fields together. There is no need for you to have two bits here and four bits there. Pull them together for a six-bit register. This helps verification by minimizing the amount of work with regards to backdoor accesses. If it comes to using byte enables or grouping register fields, don’t use byte enables. There are different types of registers: you can make them readable, writeable, read with clear, or even double read that leads to an execution of code with a clear of another register. Which one of those don’t belong? I bet you said writable. You didn’t? Well, that just goes to show what I know. That last one sounds really cool doesn’t it?
The problem is that it’s weird or “quirky” in verification vernacular. That sort of register makes things difficult for verification. Unless you need it, let it go, to quote an over played song that’s the bane of many parents. Try to make the register simpler or make it two registers instead of one. You make state machines beautiful. Then all you hear about is how hard it is for the verification team to make sure it’s sound. Just once, you’d like to have the verification team come to a meeting with a picture of your state machine and say how wonderful it is. These next tips will help you make your dream a reality.
Both VHDL and SystemVerilog both have the concept of enumerated types. These are your secret weapons when it comes to verification. That is, as long as you use meaningful names for each state. No, you can’t get by using S1 through S100 for your states. If you did, your verification team would pull its hair out. Stay away from that, unless you’ve invested heavily in some sort of miracle hair cream. Focus instead on using variable names that mean something to you. Refer to the paragraph above discussing meaningful variable names. The same holds true here.
There is absolutely no need to have a 100+ state machine. I know it’s a thing of beauty that makes you cry at how amazing it is. The problem is the massive number of state transitions your verification team must test. That’s a lot of work that may not need to happen if you simplify your state machine into multiple smaller state machines. How many states should be in a state machine? I don’t know, as each design is specific. But I’d bet there is no need to be over 100. Normally when a state machine gets in excess of 100 states, it’s signaling that there might be a pipeline somewhere in the loop.
And please don’t come up with a custom code structure for your state machine. There are standard 1-process, 2-process or 3-process state machine code structures for both VHDL and SystemVerilog. They are out there on various websites and can make it easier for your tools to understand that what you are designing is, in fact, a state machine.
I am hoping that I gave you some useful ideas. I know you are under pressure to get your stuff done. You don’t want to be the tall tent pole. Well, maybe some of these techniques can make things much easier on the verification group, which in turn should ease your load as well — or at least give you a break from their constant whining and complaining.
Back to Top