Industry Solutions
|
|
|
It is important to note that classes are different than other Verilog and SystemVerilog data types, in that classes are dynamic by nature, instead of static. The storage required by a class object is automatically created when needed, and deleted when no longer required. The dynamic nature of classes make them ideal for testbench modeling, whereas the static nature of other variable types make them appropriate for modeling hardware, which is also static in nature. Because of the dynamic nature of classes, they are not considered synthesizable constructs. Classes are intended for verification routines and highly abstract system-level modeling.
String data type. SystemVerilog adds a "string" data type, defined as a built-in class. The string data type contains a variable length array of ASCII characters. Each time a value is assigned to the string, the length of the array is automatically adjusted. This eliminates the need for the user to define the size of character arrays, or to be concerned about strings being truncated due to an array of an incorrect size.
String operations can be performed using standard Verilog operators: =, ==, !=, <, <=, >, >=, {,}, {{}}. In addition, a number of methods are defined to manipulate strings: len(), putc(), getc(), toupper(), tolower(), compare(), icompare(), substr(), atoi(), atohex(), atooct(), atobin(), atoreal(), itoa(), hextoa(), octtoa(), bintoa() and realtoa().
Operators. SystemVerilog adds several new operators:
++ and -- increment and decrement operators
+=, -=, *=, /=, %=, &=, ^=, |=, <<=, >>=, <<<= and >>>= assignment operators
Unique and priority decision statements. The Verilog if-else and case statements can be a source of mismatches between RTL simulation and how synthesis interprets an RTL model, if strict coding styles are not followed. The synthesis full_case and parallel_case pragmas can lead to further mismatches if improperly used, as they affect synthesis but not simulation.
SystemVerilog adds the ability to explicitly specify when each branch of a decision statement is unique or requires priority evaluation, using the keywords "unique" and "priority." These keywords affect simulators, synthesis compilers, formal verifiers and other tools, ensuring that all tools interpret the model the same way.
Enhanced for loops. Verilog for loops can have a single initial assignment statement, and a single step assignment statement. The variable used as the loop control must be declared outside of the loop. SystemVerilog enhances for loops to allow the loop control variable to be declared as part of the for loop, and allows the loop to contain multiple initial and step assignments.
for (int i=1,shortint count=0; i*count < 125; i++, count+=3)
Bottom testing loops. Verilog has for, while and repeat loops, all of which test to execute the loop at the beginning of the loop. SystemVerilog adds a do-while loop, which tests the loop condition at the end of executing code in the loop.
Jump statements. Verilog provides the ability to jump to the end of a named statement group using the disable statement. SystemVerilog adds the C "break" and "continue" keywords, which do not require the use of block names, and a "return" keyword, which can be used to exit a task or function at any point. SystemVerilog does not include the C "goto" statement.
Final blocks. Verilog has initial blocks that begin execution at the very beginning of simulation. SystemVerilog adds final blocks, which execute at the very end of simulation, just before simulation exits. Final blocks can be used in verification to print simulation results, such as code coverage reports.
Hardware-specific procedures. Verilog uses the "always" procedure as a general purpose construct to represent models of sequential logic, combinational logic and latched logic, as well as in testbenches and code that is not intended to be synthesized. Synthesis and other software tools must infer the intent of the always procedure from the sensitivity list and the statements within the procedure.
SystemVerilog adds three new procedures to explicitly indicate the intent of the logic:
always_ff " the procedure is intended to represent sequential logic
always_comb ": the procedure is intended to represent combinational logic
always_latch " the procedure is intended to represent latched logic. For example:
Software tools can examine the procedure contents to ensure that the functionality matches the type of procedure. In the example above, since a tool knows the designer's intent is to represent combinational logic, the tool can check that the procedure makes assignments to the same variables for every branch of logic, and that the branches cover every possible condition.
If these conditions are not true, the tool can report that the procedure does not properly model the engineers intent. These explicit procedures also have special semantics that are different than the general purpose always procedure, which more accurately simulate the behavior of the specified type of hardware.
Next
|
|
Quick
Links...
Search...
Veritools.com
LOGIN...
Click Here for
fast access to whitepapers and datasheets and to receive electronic Veritools' news, services and upcoming events.
New
Downloads...
|