They were the B. Tech days, and we were taught about Verilog and VHDL programming languages. Obviously, learning the syntax was never enough. We need to use it - have to write programs.
As it is a hardware language, we need to develop the codes for electronic blocks. Starting with trivial ones like AND gates, and OR gates and going up to priority encoder, kind of blocks.
However, we are taught that that was not enough. We need to code another part, which is called "testbench." We were given a few examples of the test benches for some blocks. Honestly, the testbench part looked almost the same for all the designs. We simply concluded that the test bench was easier to code than the design part.
Cut to the training period in the initial days of the core company. The good news is that the hardware languages we were taught and that the companies use are almost similar, even though that is not enough. After the basic training, there is the assignment of domains to people and then is the entry of...
The Verification Domain
The thing for which we have an inferior look, the "testbench", is the job of verification people. It's the life of verification people (It's the nightmare of verification people). Slowly, we started to understand the significance of that test bench.
It is not simply writing the same code for all designs. The test bench is not a "traditional" thing to do before closing. The test bench is not "it does nothing".
Instead, the test bench, as the name says, tests the design. For every design, there are inputs and outputs. Put simply, through a test bench, we give the inputs to the design and wait for the outputs. Then we compare what the design is giving out with what should be theoretical outputs. We are comparing the "ideal" vs. "actual" outputs.
What's the deal with Verification?
If you observe, there are two flaws in our undergraduate learning period. First thing, the designs are too basic. All those designs are already part of "standard" cells - they are very robust and already verified. We need not reinvent the wheel.
The second issue is the limited information in our textbooks on verification. We knew that, in practical cases, the designs would go very tough. But we never guessed the seriousness of the verification part - we were too dumb for that.
The design and verification jobs require the same thing - complete knowledge of the block that is being designed/verified. While design involves how to code it correctly, verification involves how to ensure correctness.
The verification part is as challenging as the design part. For suppose, sending inputs to the design. Theoretically, each bit of the input can be either zero or one. So, the ideal method is to try all the combinations of inputs from all zeros to all ones and check the output. But it would be the dumbest method because the design contains a very huge number of inputs. It takes generations to be completely sure that your design is good enough. Of course, we have to save time because we got to do many things rather than just verifying some block throughout our life.
Of course, humans are smart beings, so we don't give just all combinations of input. We have to choose the inputs which we feel are important - the "corner case" inputs, like when the counter is at extremes, when memory is just full, etc. We cut short the possible scenarios, which is very important. The combinations of inputs should be a minimum so that we cover all such corner and basic cases, and should be within a maximum so that we don't waste time.
However, thanks to the latest tech, we need not worry about how to "drive" the design exactly. Welcome the formal verification, where the AI engines will assist you and make things simpler. But still, it has got its own problems. Because AI takes the burden of choosing the best inputs to the design, it gets complicated easily despite the efficient algorithms.
Note: At this point in time, formal verification is only used for relatively smaller designs but not much for larger and highly complex chips. But still, there is that puzzle part of how to "help" AI do its job of verification. Formal verification is a sign of perfection. If a design is marked as "verified" in formal, means the design is as good as our "standard" designs. (In conventional verification if the design is verified, it is meant only for the inputs we have given. There might be some bugs if we change the inputs. We have to be very sure that we covered all the tricky inputs exhaustively).
So, the verification is all about giving the inputs? Not exactly though. The other main part is about how to "judge" the outputs. We have to, in fact, compare right?
Then comes - assertions. They are like the rules we state which the design must comply with. Eventually, the assertions are the ones which will check the outputs for the given inputs. Having a good set of assertions is a must. To do so, we need to have a clear idea of what the design should do, and should not do. With the proper inputs and assertions to the design, we almost established a strong foundation for the verification.
That's it? Is a good set of inputs and assertions enough?
A good testbench touches all the scenarios the design is made for, which gives the measure of how good our verification is. If our testbench can trigger all the code of the design, we are good. If not, there might be two things - the test bench missed something, or the design has redundant code. This measure of the effectiveness of our verification is called "coverage."
The three - driving inputs, writing the assertions and measuring the coverage form the basis of verification.
Which is tougher? Designing or Verifying?
It doesn't matter.
Sometimes, designing feels tough but verifying is easy, and sometimes, vice versa. If you already made up your mind about going into one of the two, that's great. You need not feel any regret for not choosing the other. If you are not sure, it's time to let seniors decide for you, or just toss a coin ;)
P.S. After this realization about the role of the test bench, there was a call from my B. Tech friend who was then pursuing M. Tech. He said there was an assignment about coding the design and test bench for various blocks, but none of them is a simple one. So he asked help for with the design part. Then I was wondering how to code the verification part. Breaking my thoughts, he just asked, "Just help me with the design, because what's the deal with test bench anyways?"
Comments
Post a Comment