We propose the following syntax for per-rule attributes:
Rule-attribs are generalized as key-value(s) pairs, which permits the programmer to add arbitrary attributes to the language without adding more keywords to the language. Rule-attrib-lists are just semicolon-delimited lists of one or more rule-attributes. In the case of repeated attributes, the latter pair will override the former. Rule-attribute-lists are optional prefixes to PRS-rules.
For now, the purpose of these attributes is to emit attribute lines suitable for consumption by another text-based tool, such as old versions of prsim. Q: What happens when we OR-combine rules with different attributes?
Some existing attributes:
Applies a fixed delay d to a single rule. Affects hflat output and hacprsim operation.
Specifies upper and lower bounds on delays for a rule. The upper bound should be greater than or equal to the lower bound, however, this is not checked here.
If b is true (1), rule is considered weak, e.g. feedback, and may be overpowered by non-weak rules. If unspecified, default value is true.
If b is true (1), rule is allowed to be unstable, as an exception. If unspecified, default value is true.
If b is true (1), flag that this rule is part of a standard keeper. If unspeficied, default value is true.
If b is true (1), flag that this rule is part of a combinational feedback keeper. If unspeficied, default value is true.
For LVS, If b is true (1), staticize (explicitly). This attribute will soon be deprecated in favor of a node attribute autokeeper.
If b is true (1), staticize (explicitly). Q: should this really be a rule-attribute? better off as node-attribute?