Pseudo-Comment Directive Proposal

1. Pseudo-Comment Directive Proposal 0-In Design Automation August, 2002

2. Problem Statement • Designers benefit when properties are declared within HDL: • Acts as self-documentation. • Easier to identify what properties are relevant to local HDL code. • Reduce specification effort. • Easier to maintain. • Properties in a procedural context are useful: • Properties only valid under specific conditions. • Easier to write within procedural HDL code. • Want no side-effects from property. • Sugar properties are defined outside of HDL • Vunits allow linking to HDL.

3. Proposal • Use pseudo-comment directives to link assertions to HDL • Language independent mechanism to place assertion within HDL code. • Provides mechanism to place assertions within System Verilog code. • Assertions can be in property language, e.g. Sugar or as library element instantiation, e.g. OVL. • Pre-processor can translate pseudo-comment directives to Verilog declarative properties for existing tools, e.g. FOCS. • Backward compatible – parsers that ignore comments do not error out. • Simple to add to existing Verilog parsers. • Validated with customers in assertions (and other directives)

4. Benefits • 1. No side effects on SystemVerilog language. • 2. Directives can be located almost anywhere in HDL code • provides a mechanism that preserves the declarative nature of Sugar properties • at same time provides ability to place assertions in-context (procedurally) • 3. Allows for in-context inferencing of (for example): • variable referenced by assertion, • width of variable referenced by assertion, • conditional context of assertion, • clocks, synchronous resets & asynchronous resets. • 4. Brevity of specification due to in-context inferencing and use of defaults. • 5. Easy to add to existing Verilog parsers, invisible to Verilog parsers that want to ignore assertions. • 6. Pre-processors can translate pseudo-comment directives into Verilog code to provide support of assertions as an interim step towards full language support – minimizing the delay of using assertions on existing tool flows. • 7. For users, assertion creation and maintenance is simplified • assertions live within HDL • inference minimizes argument specification of assertions (compact representation) • in-context assertions act as documentation

5. Syntax • Pseudo-comment directive ::= '//' <verification_directive> | • '/*' <verification_directive> '*/' • <verification_directive> ::= <Sugar_directive> | <Module_directive> • <Sugar_directive> ::= 'sugar' <sugar_vunit_item> • <sugar_vunit_item> ::= "Sugar Vunit Item - defn A.2 Sugar LRM" • <Module_directive> ::= 'vam' <module_name> {<name>} • { <argument_list> } • "vam" = Verilog/VHDL assertion module (placeholder) • <module_name> ::= <Verilog_identifier> • Linking: <Verilog_identifier> will be declared module name. • <name> ::= '-name' <identifier> • <argument_list> ::= <argument_pair> { <argument_list> } • <argument_pair> ::= '-'<arg_name> <Verilog_expression> • e.g. // vam one_hot -var foo

6. Examples • reg one_hot_variable; // vam one_hot • 0-In style of assertion with 0-In library and use of inferencing to get name and width of variable. • // sugar assert always (ack -> next !ack) • /* sugar • assume always {reqin; ackout; !abortin} |-> • {ackin; ackin} */ • // vam prop1 -req r -gnt g • /* vam assert_sequence -severity 3 -width 4 • -clock clk -reset rst -event {ev1, ev2} */ • OVL instantiation: note that parameters are also named ports