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 '//'
  ltverification_directivegt
• '/'
  ltverification_directivegt '/'
• ltverification_directivegt ltSugar_directivegt
  ltModule_directivegt
• ltSugar_directivegt 'sugar' ltsugar_vunit_itemgt
• ltsugar_vunit_itemgt "Sugar Vunit Item - defn
  A.2 Sugar LRM"
• ltModule_directivegt 'vam' ltmodule_namegt
  ltnamegt
• ltargument_listgt
• "vam" Verilog/VHDL assertion module
  (placeholder)
• ltmodule_namegt ltVerilog_identifiergt
• Linking ltVerilog_identifiergt will be
  declared module name.
• ltnamegt '-name' ltidentifiergt
• ltargument_listgt ltargument_pairgt
  ltargument_listgt
• ltargument_pairgt '-'ltarg_namegt
  ltVerilog_expressiongt
• 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 -gt next !ack)
• / sugar
• assume always reqin ackout
  !abortin -gt
• 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