Verification Notes (Part 4:Fullchip Level)
The Code Slicer
When dealing with a large-scale project like this, instinct tells us to split it into “bite-size” pieces. And that’s exactly how we’re gonna begin.
So for starters, I wanna talk about a set of statements in Verilog commonly used as the “slicer” for huge programmes in real practice.
1 |
In this context, typically what “include” does is it extracts the text contained in the .v file and pastes it in the file where the statement is used. Already you realize what this means to digital IC engineers. But as we all know, simulation takes time and is very reliant on the performance of the server, and could be awfully time & memory-consuming depending on the complexity of the programme.(which, along with confidentiality reasons, is also why my own laptop is only used to draft relevant posts instead of running fullchip verification programmes to ease the workload at work. You might be able to fry some eggs on the mainframe afterwards if I did conduct some fullchip simulations with this, given the lovely capacity of this piece of antique). And that’s where “define”, “ifdef” and “elsif” can help. The thing is, we don’t have to test all aspects of the chip when it comes to verification. I’ll demonstrate with some of the code snippets that I wrote.
1 |
|
This is part of the verify_ctrl.v for one of my assignments, related to the high range (relative to high performance) banks. The utilization of the statements allows the user (well, my colleagues) to pick and run the corresponding programmes one at a time, providing convenience through flexibility. Instead of compiling and running a huge and complex verilog model which consumes unnecessarily long periods of time and extra memory usage, testing only the indispensible parameters for one simulation would be a lot more efficient. In the verify_ctrl.v, alternating the verilog models you wanna use can be done by simply changing the text after “define”.
There are other ways in which you can split the large verilog programme into separate files to revise. The easiest way is simply create multiple .v files and generate a filelist for your compiler. Pretty easy via Synopsys VCS that I’m using. But then of course you’d lose the flexibility as filelist does not contain conditional operations. You’d basically just make it easier for yourself to view and edit. The complier still takes them in as a whole chunk.
And you could always just tell your colleagues the file paths and let them scramble around themselves if you guys are “real buddies” and you wanna grab that cup of coffee so bad. But ah, let’s try to be nice and considerate shall we ~