CVCBLR's VoW blog - Verification on the Web!

SystemVerilog enhances the TEXT-MACRO feature (a.k.a `define-s by many young engineers) of Verilog by a good length. Significant enhancements done are: Added capability to extend the definition to multiple lines Added macros with arguments; Macro arguments can have default values too! (not fully supported by all tools though) However there are few caveats – in general any text-macro usage in any computer language is hard to debug when it fails to compile. So be ready to be patient while debugging macro code. Recently an online forum user asked a question on SystemVerilog macros. Here is what the user defined to start with: To a bare eye, the above looks fine. However a  SV compiler would through an error at it. As per the LRM:   If formal arguments are used, the list of formal argument names shall be enclosed in parentheses following the name of the macro. The left parenthesis shall follow the text macro name immediately, with no space in ...

With SystemVerilog language gaining popularity among user, it is getting interesting to see user asking similar/repeating “patterns” of challenges in various forums. One of them is on constraint modeling when it becomes more than simple “a > 10” like stuff. Recently a VerifAcademy user asked:   in my testbench i have to make a random signal "[31:0] distortion". it must contain one (or, in other case, two) hot bit(s) (hot bit is "1", all others are "0"). So i have a problem with writing a constraint: i really don't want to write all possible combinations of these bits (if there are two of them, there will be 32! combinations, so...). Does anyone have solution for this problem?   A smart model is indeed available via 2 features of this vast language – System Verilog: 1. A handy system function to count the number of “ones” 2. Constraints can use functions in expressions. Combining the above two, here is a full solution to the ab...

As many of our customer learn during our regular VSV training sessions , System Verilog added `__FILE__ & `__LINE__ macros similar to C language. It is quite handy for debugging remotely developed code for a newcomer especially. Recently at an UVM forum a user asked how to get the relative path vs. absolute path from this macro. Consider the following code:   The SV LRM says; 22.13 `__FILE__ and `__LINE__ `__FILE__ expands to the name of the current input file, in the form of a string literal. This is the path by which a tool opened the file, So if you provide the absolute path name during compile command, you are bound to get the FULL PATH. Questa when run with full path to the file as below: produces the following output:   And you could get a pretty short output as below if you do a “magic” (Left as exercise to the interested reader :-) ) Enjoy System Verilog and have fun! TeamCVC   Technorati Tags: SystemVeril...

  With one of our recent blog entries on SystemVerilog constraint solver ( http://www.cvcblr.com/blog/?p=725 ) becoming so popular, several readers have contacted us via email to know little more about the puzzle. Specifically they wanted to understand how the solver ordering of variables is determined. Consider the same example as in that previous blog entry: As noted in the previous blog, this creates an “implicit ordering” of variables – i.e. ‘v1” is solved BEFORE “v2”. A smart engineer ( Muthurasu Sivaramakrishnan ) asked this: Nice one. However, why cant we use Solve.. Before constraint in this scenario? The answer is a little involved with yet-another subtlety in the language, and hence this new entry: This reader’s question boils down to whether the above constraint “ cst_ordered” is same as the following; constraint cst_guidance {solve v1 before v2;} First intuition says YES, but the answer unfortunately is NO. In SV there are 2 kinds of solver orde...

As the SVA usage expands/grows in the industry, so do the language syntax/features. One of the recent (2009) addition to System Verilog language was the ability to code “default disabling condition”. It is very handy to have an “inferred” disabling condition for all assertions so that one can save on verbosity while typing – every assertion doesn’t have to repeat;   a_without_default_disable : assert property (disable iff (!rst_n) my_prop); vs. a_with_default_disable : assert property (my_prop); Obviously anything that helps to save some typing is a BOON. However there are some special category of assertions that may get unintentionally disabled by this. For instance the “reset-checks” – assertions that check the reset value of various DUT outputs. For e.g. FIFO empty flag during reset serialout signal from a de-serializer design We recently had a similar DUT being verified with SVA. In the below code, notice the “default disable” and the reset-check...

Are you an avid fan of CRV – Constraint Random Verification? Have you played enough with System Verilog constraints? Many of our customers having attended our regular VSV training ( http://www.cvcblr.com/trainings ) do become so! One of the nice features of SystemVerilog constraint mechanism is its “bi-directionality” – a key feature that makes the distribution fairly wide spread and makes the state space well covered. The industry has learnt it over the last decade of CRV usage – bidirectional constraints are better than unidirectional ones (that was the default in previous generation solver inside popular tool like Specman – called PGen. Even Specman has moved to a more robust, bi-directional IGEN/Intelligen few years back). In SV this bi-directionality is subtle. Consider the code below: To an average SV engineer the above 2 constraints look “same” as the function is trivially doing a return job. However they are different for an avid SV user or a solid SV solver such as...

  Over the past few years, the term “pre-silicon verification” has been quite popular and several technology advancements have helped in solving that puzzle. Some of the biggest contributors have been languages such as e /Specman and SystemVerilog with supporting technologies such as constrained-random verification (CRV), coverage-driven verification (CDV) and assertion-based verification (ABV). All these three technologies when used in unison addressed the challenge at the block or intellectual property (IP)level fairly well. Recently UVM has been developed as a framework to use these languages in the best possible manner to try and keep these technologies scalable to larger designs, such as system-on-chips (SoC). Thanks to the Accellera committee devoting time and effort, UVM is becoming quite popular and the de-facto IP verification approach. However with SoCs, there are several new challenges in the verification space that threaten to quickly outgrow the current prevalent t...