SystemVerilog For Design phần 5 docx

150 SystemVerilog for Design always_comb begin a2 = data << 1; b2 = decode(); end function decode; // function with no inputs begin case (sel) 2'b01: decode = d | e; 2'b10: decode = d & e; default: decode = c; endcase end endfunction 6.2.2 Latched logic procedural blocks The always_latch procedural block is used to indicate that the intent of the procedural block is to model latched-based logic. always_latch infers its sensitivity list, just like always_comb. always_latch if (enable) q <= d; An always_latch procedural block follows the same semantic rules as with always_comb. The rules for what is to be included in the sensitivity list are the same for the two types of procedural blocks. Variables written in an always_latch procedural block cannot be written by any other procedural block. The always_latch procedural blocks also automatically execute once at time zero, in order to ensure that outputs of the latched logic are consistent with the input values at time zero. What makes always_latch different than always_comb is that software tools can determine that the designer’s intent is to model latched logic, and perform different checks on the code within the procedural block than the checks that would be performed for com- binational logic. For example, with latched logic, the variables rep- resenting the outputs of the procedural block do not need to be set for all possible input conditions. In the example above, a software tool could produce an error or warning if always_comb had been used, because the if statement without a matching else branch infers storage that combinational logic does not have. By specifying Infers @(data, sel, c, d, e) a l ways_ l a t c h represents latched logic a l ways_ l a t c h has the same semantics as always_comb t oo l s can ver if y always_latch contents represent latched logic Chapter 6: SystemVerilog Procedural Blocks, Tasks and Functions 151 always_latch, software tools know that the designer’s intent is to have storage in the logic of the design. As with always_comb, these additional semantic checks on an always_latch procedural block’s contents are optional. An example of using always_latch procedural blocks The following example illustrates a 5-bit counter that counts from 0 to 31. An input called ready controls when the counter starts counting. The ready input is only high for a brief time. Therefore, when ready goes high, the model latches it as an internal enable signal. The latch holds the internal enable high until the counter reaches a full count of 31, and then clears the enable, preventing the counter from running again until the next time the ready input goes high. Example 6-3: Latched input pulse using an always_latch procedural block module register_reader (input clk, ready, resetN, output logic [4:0] read_pointer); logic enable; // internal enable signal for the counter logic overflow; // internal counter overflow flag always_latch begin // latch the ready input if (!resetN) enable <= 0; else if (ready) enable <= 1; else if (overflow) enable <= 0; end always @(posedge clk, negedge resetN) begin // 5-bit counter if (!resetN) {overflow,read_pointer} <= 0; else if (enable) {overflow,read_pointer} <= read_pointer + 1; end endmodule 152 SystemVerilog for Design 6.2.3 Sequential logic procedural blocks The always_ff specialized procedural block indicates that the designer’s intent is to model synthesizable sequential logic behav- ior. always_ff @(posedge clock, negedge resetN) if (!resetN) q <= 0; else q <= d; A sensitivity list must be specified with an always_ff procedural block. This allows the engineer to model either synchronous or asynchronous set and/or reset logic, based on the contents of the sensitivity list. By using always_ff to model sequential logic, software tools do not need to examine the procedural block’s contents to try to infer the type of logic intended. With the intent clearly indicated by the specialized procedural block type, software tools can instead exam- ine the procedural block’s contents and warn if the contents cannot be synthesized as sequential logic. As with always_comb and always_latch, these additional semantic checks on an always_ff procedural block’s contents are optional. Sequential logic sensitivity lists The always_ff procedural block requires that every signal in the sensitivity list must be qualified with either posedge or negedge. This is a synthesis requirement for sequential logic sensitivity list. Making this rule a syntactical requirement helps ensure that simula- tion results will match synthesis results. An always_ff procedural block also prohibits using event controls anywhere except at the beginning of the procedural block. Event controls within the proce- dural block do not represent a sensitivity list for the procedural block, and are not allowed. This is also a synthesis requirement for RTL models of sequential logic. 6.2.4 Synthesis guidelines The specialized always_comb, always_latch, and always_ff procedural blocks are synthesizable. These specialized procedural blocks are a better modeling choice than Verilog’s general purpose always procedural block whenever a model is intended to be used a l ways_ ff represents sequential logic t oo l s can ver if y that always_ff contents represent sequential logic a l ways_ ff enforces synthesizable sensitivity lists Chapter 6: SystemVerilog Procedural Blocks, Tasks and Functions 153 with both simulation and synthesis tools. The specialized proce- dural blocks require simulators and other software tools to check for rules that are required by synthesis compilers. The use of always_comb, always_latch, and always_ff procedural blocks can help eliminate potential modeling errors early in the design process, before models are ready to synthesize. 6.3 Enhancements to tasks and functions SystemVerilog makes several enhancements to Verilog tasks and functions. These enhancements make it easier to model large designs in an efficient and intuitive manner. 6.3.1 Implicit task and function statement grouping In Verilog, multiple statements within a task or function must be grouped using begin end. Tasks also allow multiple statements to be grouped using fork join. SystemVerilog simplifies task and function definitions by not requiring the begin end grouping for multiple statements. If the grouping is omitted, multiple statements within a task or function are executed sequentially, as if within a begin end block. function states_t NextState(states_t State); NextState = State; // default next state case (State) WAITE: if (start) NextState = LOAD; LOAD: if (done) NextState = STORE; STORE: NextState = WAITE; endcase endfunction 6.3.2 Returning function values In Verilog, the function name itself is an inferred variable that is the same type as the function. The return value of a function is set by assigning a value to the name of the function. A function exits when the execution flow reaches the end of the function. The last value that was written into the inferred variable of the name of function is the value returned by the function. b eg i n en d groups multiple statements S ys t em V er il og infers begin end f unc ti ons crea t e an implied variable of the same name and type 154 SystemVerilog for Design function [31:0] add_and_inc (input [31:0] a,b); begin add_and_inc = a + b + 1; end endfunction SystemVerilog adds a return statement, which allows functions to return a value using return, as in C. function int add_and_inc (input int a, b); return a + b + 1; endfunction To maintain backward compatibility with Verilog, the return value of a function can be specified using either the return statement or by assigning to the function name. The return statement takes precedence. If a return statement is executed, that is the value returned. If the end of the function is reached without executing a return statement, then the last value assigned to the function name is the return value, as it is in Verilog. Even when using the return statement, the name of the function is still an inferred variable, and can be used as temporary storage before executing the return statement. For example: function int add_and_inc (input int a, b); add_and_inc = a + b; return ++add_and_inc; endfunction 6.3.3 Returning before the end of tasks and functions In Verilog, a task or function exits when the execution flow reaches the end, which is denoted by endtask or endfunction. In order to exit before the end a task or function is reached using Verilog, conditional statements such as if else must be used to force the execution flow to jump to the end of the task or function. A task can also be forced to jump to its end using the disable keyword, but this will affect all currently running invocations of a re-entrant task. The following example requires extra coding to prevent executing the function if the input to the function is less than or equal to 1. function automatic int log2 (input int n); if (n <=1) log2 = 1; else begin // skip this code when n<=1 re t urn h as priority over returning the value in the function name V er il og mus t reach the end of a task or function to exit Chapter 6: SystemVerilog Procedural Blocks, Tasks and Functions 155 log2 = 0; while (n > 1) begin n = n/2; log2 = log2+1; end end endfunction The SystemVerilog return statement can be used to exit a task or function at any time in the execution flow, without having to reach the end of the task or function. Using return, the example above can be simplified as follows: function automatic int log2 (input int n); if (n <=1) return 1; // abort function log2 = 0; while (n > 1) begin n = n/2; log2++; end endfunction Using return to exit a task or function before the end is reached can simplify the coding within the task or function, and make the execution flow more intuitive and readable. 6.3.4 Void functions In Verilog, functions must have a return value. When the function is called, the calling code must receive the return value. SystemVerilog adds a void type, similar to C. Functions can be explicitly declared as a void type, indicating that there is no return value from the function. Void functions are called as statements, like tasks, but have the syntax and semantic restrictions of func- tions. For example, functions cannot have any type of delay or event control, and cannot use nonblocking assignment statements. Another benefit of void functions is that they overcome the limita- tion that functions cannot call tasks, making it difficult to add cod- ing structure to a complex function. A function can call other functions, however. Functions can call void functions, and accom- plish the same structured coding style of using tasks. Another SystemVerilog enhancement is that functions can have output and inout formal arguments. This allows a void function, th e re t urn statement can be used to exit before the end V er il og f unc ti ons must return a value vo id f unc ti ons do not return a value 156 SystemVerilog for Design which has no return value, to still propagate changes to the scope that called the function. Function formal arguments are discussed in more detail later in this chapter, in section 6.3.6 on page 157. typedef struct { logic valid; logic [ 7:0] check; logic [63:0] data; } packet_t; function void fill_packet ( input logic [63:0] data_in, output packet_t data_out ); data_out.data = data_in; for (int i=0; i<=7; i++) data_out.check[i] = ^data_in[(8*i)+:8]; data_out.valid = 1; endfunction Synthesis guidelines An advantage of void functions is that they can be called like a task, but must adhere to the restrictions for function contents. These restrictions, such as the requirement that functions cannot contain any event controls, help ensure proper synthesis results. 6.3.5 Passing task/function arguments by name When a task or function is called, Verilog only allows values to be passed to the task or function in the same order in which the formal arguments of the task or function are defined. Unintentional coding errors can occur if values are passed to a task or function in the wrong order. In the following example, the order in which the argu- ments are passed to the divide function is important. In the call to the function, however, it is not apparent whether or not the argu- ments are in the correct order. always @(posedge clock) result <= divide(b, a); function int divide (input int numerator, In synthesizable models, use void functions in place of tasks. TIP V er il og passes argument values by position Chapter 6: SystemVerilog Procedural Blocks, Tasks and Functions 157 denominator); if (denominator == 0) begin $display("Error! divide by zero"); return 0; end else return numerator / denominator; endfunction SystemVerilog adds the ability to pass argument values to a task or function using the names of formal arguments, rather than the order of the formal arguments. Named argument values can be passed in any order, and will be explicitly passed through the specified formal argument. The syntax for named argument passing is the same as Verilog’s syntax for named port connections to a module instance. With SystemVerilog, the call to the function above can be coded as: // SystemVerilog style function call always @(posedge clock) result <= divide(.denominator(b), .numerator(a) ); Using named argument passing removes any ambiguity as to which formal argument of each value is to be passed. The code for the task or function call clearly documents the designer’s intent, and reduces the risk of inadvertent design errors that could be difficult to detect and debug. 6.3.6 Enhanced function formal arguments In Verilog, functions can only have inputs. The only output from a Verilog function is its single return value. // Verilog style function formal arguments function [63:0] add (input [63:0] a, b); endfunction SystemVerilog allows the formal arguments of functions to be declared as input, output or inout, the same a s with tasks. Allowing the function to have any number of outputs, in addition to the function return value greatly extends what can be modeled using functions. S ys t em V er il og can pass argument values by name name d argument passing can reduce errors V er il og f unc ti ons can only have inputs S ys t em V er il og functions can have inputs and outputs 158 SystemVerilog for Design The following code snippet shows a function that returns the result of an addition operation, plus an output formal argument that indi- cates if the addition operation resulted in an overflow. // SystemVerilog style function formal args function [63:0] add (input [63:0] a, b, output overflow); {overflow,add} = a + b; endfunction Restrictions on calling functions with outputs In order to prevent undesirable—and unsynthesizable—side effects, SystemVerilog restricts from where functions with output or inout arguments can be called. A function with output or inout arguments can not be called from: • an event expression. • an expression within a procedural continuous assignment. • an expression that is not within a procedural statement. 6.3.7 Functions with no formal arguments Verilog allows a task to have any number of formal arguments, including none. However, Verilog requires that functions have at least one input formal argument, even if the function never uses the value of that argument. SystemVerilog allows functions with no formal arguments, the same as with Verilog tasks. An example of using functions without arguments, and the benefits this style can offer, is presented in the latter part of section 6.2.1, under always_comb versus @*, on page 147. 6.3.8 Default formal argument direction and type In Verilog, the direction of each formal argument to a task or func- tion must be explicitly declared as an input for functions, or as input, output, or inout for tasks. A comma-separated list of arguments can follow a direction declaration. Each argument in the list will be the last direction declared. function integer compare (input integer a, input integer b); S ys t em V er il og functions can have no arguments Chapter 6: SystemVerilog Procedural Blocks, Tasks and Functions 159 endfunction task mytask (input a, b, output y1, y2); endtask SystemVerilog simplifies the task and function declaration syntax, by making the default direction input. Until a formal argument direction is declared, all arguments are assumed to be inputs. Once a direction is declared, subsequent arguments will be that direction, the same as in Verilog. function int compare (int a, b); endfunction // a and b are inputs, y1 and y2 are outputs task mytask (a, b, output y1, y2); endtask In Verilog, each formal argument of a task or function is assumed to be a reg type, unless explicitly declared as another variable type. SystemVerilog makes the default type for task or function argu- ments the logic type. Since logic is synonymous with reg, this is fully compatible with Verilog. 6.3.9 Default formal argument values SystemVerilog allows an optional default value to be defined for each formal argument of a task or function. The default value is specified using a syntax similar to setting the initial value of a vari- able. In the following example, the formal argument count has a default value of 0, and step has a default value of 1. function int incrementer(int count=0, step=1); incrementer = count + step; endfunction When a task or function is called, it is not necessary to pass a value to the arguments that have default argument values. If nothing is passed into the task or function for that argument position, the default value is used for that call of the task or function. In the call th e d e f au lt formal argument direction is input th e d e f au lt formal argument type is logic eac hf orma l argument can have a default value a ca ll t o a t as k or function can leave some arguments unspecified [...]... // local variable for (i = 0; i . that the designer’s intent is to model latched logic, and perform different checks on the code within the procedural block than the checks that would be performed for com- binational logic. For example,. resetN) begin // 5- bit counter if (!resetN) {overflow,read_pointer} <= 0; else if (enable) {overflow,read_pointer} <= read_pointer + 1; end endmodule 152 SystemVerilog for Design 6.2.3 Sequential. implied variable of the same name and type 154 SystemVerilog for Design function [31:0] add_and_inc (input [31:0] a,b); begin add_and_inc = a + b + 1; end endfunction SystemVerilog adds a return statement,