Verification in IEEE Verilog Verisity’s Donation WORK IN PROGRESS

IEEE 1364 Verilog has 16 years of momentum as a design language Invented by Gateway Design Automation in 1987 Donated to OVI in 1990 Donated to IEEE in 1993 IEEE standardized in 1995 De facto standardization of Verilog-XL 1.6 IEEE standardized in 2001 Top five features requested by users at DAC’1995 to make Verilog a better design language.

IEEE effort is underway Requirements Definition Phase until September of 2003 Donations received to date are: Extended Data Types Struct, typedef, union, et cetera Protected Envelopes Public key encryption system for IP sharing Randomization and Constraint Extensions System tasks for constraining and generating random values Separate Compilation Technology Allows pre-compilation of design hierarchy, and sharing of same with outside parties Suggestion to use PSL by reference Includes this key technology in a unifying way, just as done by IEEE VHDL x

IEEE 1364 is missing decent generation and any coverage The donations received to date significantly extend the language to serve many of the design needs of the user community What is missing are features that bridge the gap between the design team, and a full fledged Verification Language This donation fills this gap

Motivation Verilog is an excellent language for designers Verilog needs an extension that keeps to the spirit and elegance of Verilog, while providing verification features that designers will use Intended uses are Designers should be able to define simple unit level verification environments Designs should embed in the HDL information that will help in the full system verification. “Design for Verification”

The Donation For Coverage, Generation and Extension, we propose the market proven syntax and semantics familiar to users of Specman and other test bench tools For Assertions, we endorse including Accellera’s PSL 1.01 in IEEE 1364 by reference

Coverage The syntax and semantics are very similar to those in IEEE P1647 and ‘e’, and are perhaps best motivated by an example in Verilog: module foo; reg [1:0] r1; reg r2; event eve_1; -> eve_1; cover eve_1 begin item r1; item r2; transition r1; cross r1, r2; end... endmodule 4 new keywords: “cover”, “item”, “transition” and “cross”. cover introduces a coverage definition, and specifies the sample event item specifies those Verilog objects to track coverage when the event occurs transition specifies Verilog objects whose transition between all possible values shall be measured. cross specifies two or more items whose respective coverage should be measured. Record all the values r1 held while r2 was true; as well as all the values r1 held while r2 was false

Coverage BNF cov_declaration ::= cover event_identifier { cov_attributes } begin list_of_cov_items end cov_attributes ::= (* cov_attribute {, cov_attribute } *) cov_attribute ::= text = string ; | when = expression ; | weight = unsigned_number ; list_of_cov_items ::= {list_of_cov_items} cov_item {cov_item_attribute} cov_item ::= item identifier [ : reg_declaration = identifier ] ; | cross identifier, identifier {, identifier} ; | transition identifier ; cov_item_attributes ::= (* cov_item_attribute {, cov_item_attribute } *) cov_item_attribute ::= name = string | text = string | when = expression | at_least = constant_expression | weight = unsigned_number | ignore = expression | illegal = expression coverage_system_task ::= $set_cover ( event_expression, unsigned_integer ); | $set_cover_file ( string );

A More Complete Coverage Example module cpu(...); event e17; clk or psl_event) -> e17; cover e7 (* weight=5, text=‘Coverage Target 17’ *) begin item opcode; item mode (* name=addressing_mode, ignore=(mode > 85) *); transition opcode; item StatusBits : reg[7:0] = {alu.status, fpu.status}; cross opcode, mode, StatusBits end reset) #10 $set_cover(cpu.e17, 1); reset) #10 $set_cover(cpu.e17, 0); endmodule Coverage is triggered by the occurrence of an event, which implicitly names the coverage point. Attributes can be used to name and control coverage collection, without using up valuable keyword namespace. Synthetic coverage items can be created inline using regular verilog syntax, without cluttering design registers Coverage collection can be enabled and disabled with system tasks, avoiding credit for points hit during reset, for example Synthesis tools can easily ignore coverage by simply ignoring the coverage statement

Generation The syntax and semantics are very similar to those in IEEE P1647 and ‘e’, and are again best motivated by an example in Verilog: typedef struct { reg [3:0] x; reg [4:0] y; } packet; module foo; packet p; keep p.x > p.y; keep p.x==2 => p.y==0; begin gen p; end... endmodule 2 new keywords: “keep” and “gen”. The keep statement specifies a constraint expression whose value must be held true by any gen statement of an object referred to in the constraint expression. The keep expression can refer only to registers declared in the module, or to registers declared in modules instantiated by the module or their children. Execution of a gen statement produces new values for the argument register or each element of the argument struct passed to the gen, while satisfying all keep statements. Existing specifiy operator “=>” is given new meaning to specify implication.

Generation BNF keep_declaration ::= keep constraint_expression ; constraint_expression::= [ keep_attributes ] expression | expression => [ keep_attributes ] expression keep_attributes ::= (* keep_attribute {, keep_attribute } *) keep_attribute ::= soft ; extend_statement ::= extend module_name keep_declaration | extend module_name begin {keep_declaration} end generation_statement ::= gen struct_identifier [ keep_declaration ] ; | gen reg_identifier [ keep_declaration ] ; generation_system_task ::= $set_gen_seed ( [ unsigned_integer ] ) ; /* Add to the ‘Proposal for Extending Verilog data types’ */ list_of_type_declaration_names ::= [!] identifier | list_of_type_declaration_names, [!] identifier

More Complex Example The ‘gen p’; statement shall build values only for p.src, p.dest, p.payload, and p.crc, because the ! qualifier to the p.result sub struct specifies that the gen should leave this item uninitialized, as presumably it will be filled in procedurally when the packet is transmitted. In this example the CalculateCrc function call builds a value for p.crc based on p.payload. The (* soft *) attribute on the keep states that a later keep statement may override this generation rule (perhaps in order to test behavior given illegal packets). module packet_gen(... ) ; typedef struct { reg [7:0] src, dest; reg [31:0] payload [1500]; reg [15:0] crc; reg crc_is_good; transmit_results ! result; } Ethernet_packet; Ethernet_packet p; begin gen p; keep crc_is_good => (*soft*) p.crc == CalculateCrc(p.payload); end endmodule The optional identifier prefix ‘!’ specifies that any gen statement should not build a value for that identifier.

Extension In order to facilitate effective test writing, constraints may be added hierarchically using the new extend statement. An example: extend top keep bar.src==0; extend packet_gen begin keep dest>2 && dest<4; keep payload[37] == 3; end 1 new keyword: “extend” Extend names a module, and may appear anywhere in the list of files presented to the simulator Extend adds the one or more keep statements to the list of keep statements that may already exist in the named module. The keep can refer only to registers declared in the named module, or to registers in modules instantiated by that module or their children. The first extend example only affects one instance of packet_gen The second extend example affects all instances of packet_gen

Summary This donation adds simple, yet powerful, designer focused verification features to IEEE-1364 with the use of just seven new key words These additions are the same or are a subset of the syntax in IEEE P1647, facilitating reuse between these standards