Q: How important are language and methodology?
A: My point is: neither of these matters. It is the verification engineer who does the work, and the source is the Spec, so the Testplan (full coverage testplan) is the most important. The important thing is the awareness of verification, whether you are willing to realize HOT, even if you do a little "earth" at the beginning, it doesn't matter.
For example, the "automatic comparison function" that is often done in tb:
1) Maintain the queue, and then compare foreach
2) Use file-operation (fopen fread fwrite fscanf) to do file comparison 3) Direct $system(diff ab > c ) Look at the c file size later. The above three methods are all possible (although 2) will lead to more file IO, hard disk reading and writing bswk SMT processing www.smtsmt.com.cn will affect the simulation speed,
3) can not do real-time comparison. You don't have to stick to the method, the key is to have this awareness.
Q: EDA industry's support for verification?
A: Personally, I feel that although (dynamic) verification has not made much breakthrough in theory in recent years (static verification has always been a hot spot), the EDA industry has always attached great importance to it. The implementation tools are mainly for algorithm optimization, and there has been little breakthrough in these years. . However, point tools in the verification direction have been continuously released (although there may not be a few useful tools in the end), but it shows that the EDA industry has been committed to seeking breakthroughs in verification. And because there are too many SoCs and too many IPs, everyone is paying more and more attention to verification. Many large-scale companies have more verification personnel than designers. Personally, I think this may also be one of the reasons why EDA attaches great importance to verification (replace some people LL with cattle tools).
Q: How to track defects?
A: You can consider tools such as bug-zillar-automatically track problems.
Q: Job submission system (lsf or grid-engine)
A: Make full and reasonable use of computing resources.
Q: Management of environment variables?
A: I personally recommend using the Module tool. Many companies use this free tool
Q: What programming language does Testbench use?
A: I think systemverilog and verilog in tb can replace each other (of course, it will be very complicated to implement the unique content of systemverilog with verilog), so it is recommended that tb be built based on systemverilog, and some simulation models can be processed by bswk SMT www.smtsmt.com .cn to use verilog. C In addition to Cmodel, firmware will also be written in C and assembly. Basically the language used in the projects I have done: Script: perl, makefile, shell (perl is used a lot, others are rarely used) Tb (including vmm components): basically systemverilog Simulation model: systemverilog and verilog mixed Using Cmodel: C or C++ Firmware: Assembly and C
Q: What basic technologies do verification engineers need to master?
A: Share a copy of my basic training content arrangement for reference Perl, Makefile, AMBA introduction, SVTB.pdf, sva, File operation of several programming languages used, Low-power, C-pointer, Cshell-AWK +SED, some content related to the architecture, SV-1Day training, VMM_source_code, the basic concepts of Arm's embedded programming
Q: Is automation necessary?
A: It is not necessary, but it should be automated as much as possible. In short, let the machine run more. If the per capita license is too small, try to debug during the day and let the machine run at night. The "comparison" is too mechanical, so let the machine do it as much as possible. The machine's efficiency in doing this kind of thing is much higher than that of humans. Concentrate on constructing testcase, testbench, coverage and bswk SMT processing www.smtsmt.com.cn debug and analysis.
Q: How does Testplan do it?
A: The format is not important, xls, word, and txt are fine. But from Spec! In addition to listing function-test-piont in testplan, there should also be error-injection, random-test-point, cover-point and assertion. It is necessary to carefully review the testplan with each team one by one. Some coverpoints for specific implementations may only be proposed by the designer and need to be proposed as soon as possible. Before Tb is built, it is necessary to fully review the testplan, because a large modification of the Testplan may lead to the structural adjustment of the entire testbench, and the effort is large. Testplan is something that needs to be continuously added, iterated, and reviewed. Error injection needs to be reviewed one by one with RTL-designer, one is to see if RTL-designer has not thought of it, and the other is whether the design itself is not allowed, or it is impossible to appear in the architecture itself. Error-injection should dig deep. For example: the memory controller does not return data for a long time (here itself is a random point) à whether an error interrupt occurs due to the long time no data return à how to respond after an error interrupt occurs à how to recover if it fails to respond à software reset must be used for recovery , whether there are any requirements for the timing of software à what requirements and steps need to be followed before software Although there are some tools that can automatically generate cover-point and assertion according to the testplan described in a standardized description, I think the testplan described by natural language should be the most "natural" .
Q: Which places do random?
bswk SMT processing www.smtsmt.com.cn
A: 1) Random configuration (generally expected), but it is often the least important for a closed system, because the firmware can be developed by itself, so as to control the configuration process and value
2 ) Random incentive data (very important)
3) Random timing (usually easy to forget) But one thing must be clear: random is not completely random, it is constrained random, and it is as random as possible within a reasonable range.
Q: What should be paid attention to when writing constrained randomness?
A: It is recommended to read the snug paper. (Over-constraint leads to incomplete testing, under-constraint leads to unnecessary debugging and waste of resources) Efficiency of constraints: poorly written will lead to random failures. Q: How does Coverage work? A: code-coverage and function-coverage (covergroup, assertion coverage). Use covergroup for constraint-random, and assertion-coverage for some timing coverage.
Q: Core script?
A: The script of a single simulation ---- create different directories and different seeds used (the directory can be called case_ KaTeX parse error: Expected group after '_' at position 37: ...stcase, it can be case_̲ casename); environment Variable and license management; if you need to do offline comparison, you can also let the script automatically call the comparison script or command (you can also use system or system orsys t e m or systemf). bswk SMT processing www.smtsmt.com.cn Batch simulation script - automatically submit to lsf in batches. Automatically collect log information to determine which cases fail, and automatically resubmit and automatically dump waveforms for failed cases. And generate summary information after the batch simulation ends.
Q: Important points in SV?
A: Special data types, such as three new arrays (dynamic, associate, queue), string (match function, backref function, refer to svtb.pdf of vcs); object-oriented programming idea (handle); coverage; constraint- random. It is necessary to master the usage of these language points proficiently.
If you want to know more, you can pay attention to IC Xiuzhenyuan, and continue to update it for everyone in the next issue! Or you can directly ling the full document
Put a mouth here: a deep understanding of IC verification