Visible to Intel only — GUID: mwh1409959543887
Src Path: Ixiasoft
Visible to Intel only — GUID: mwh1409959543887
Src Path: Ixiasoft
1.3.2.1. Custom Design Rule Examples
This example shows the XML codes for checking SR latch structures in a design.
Detecting SR Latches in a Design
<DA_RULE ID="EX01" SEVERITY="CRITICAL" NAME="Checking Design for SR Latch" DEFAULT_RUN="YES">
<RULE_DEFINITION>
<FORBID>
<OR>
<NODE NAME="NODE_1" TYPE="SRLATCH" />
<HAS_NODE NODE_LIST="NODE_1" />
<NODE NAME="NODE_1" TOTAL_FANIN="EQ2" />
<NODE NAME="NODE_2" TOTAL_FANIN="EQ2" />
<AND>
<NODE_RELATIONSHIP FROM_NAME="NODE_1" FROM_TYPE="NAND" TO_NAME="NODE_2" TO_TYPE="NAND" />
<NODE_RELATIONSHIP FROM_NAME="NODE_2" FROM_TYPE="NAND" TO_NAME="NODE_1" TO_TYPE="NAND" />
</AND>
<AND>
<NODE_RELATIONSHIP FROM_NAME="NODE_1" FROM_TYPE="NOR" TO_NAME="NODE_2" TO_TYPE="NOR" />
<NODE_RELATIONSHIP FROM_NAME="NODE_2" FROM_TYPE="NOR" TO_NAME="NODE_1" TO_TYPE="NOR" />
</AND>
</OR>
</FORBID>
</RULE_DEFINITION>
<REPORTING_ROOT>
<MESSAGE NAME="Rule %ARG1%: Found %ARG2% node(s) related to this rule.">
<MESSAGE_ARGUMENT NAME="ARG1" TYPE="ATTRIBUTE" VALUE="ID" />
<MESSAGE_ARGUMENT NAME="ARG2" TYPE="TOTAL_NODE" VALUE="NODE_1" />
</MESSAGE>
</REPORTING_ROOT>
</DA_RULE>
The possible SR latch structures are specified in the rule definition section. Codes defined in the <AND></AND> block are tied together, meaning that each statement in the block must be true for the block to be fulfilled (AND gate similarity). In the <OR></OR> block, as long as one statement in the block is true, the block is fulfilled (OR gate similarity). If no <AND></AND> or <OR></OR> blocks are specified, the default is <AND></AND>.
The <FORBID></FORBID> section contains the undesirable condition for the design, which in this case is the SR latch structures. If the condition is fulfilled, the Design Assistant highlights a rule violation.
Detecting SR Latches in a Design
<AND>
<NODE_RELATIONSHIP FROM_NAME="NODE_1" FROM_TYPE="NAND" TO_NAME="NODE_2"
TO_TYPE="NAND" />
<NODE_RELATIONSHIP FROM_NAME="NODE_2" FROM_TYPE="NAND" TO_NAME="NODE_1"
TO_TYPE="NAND" />
</AND>
Detecting Incorrect Synchronizer Configuration
<DA_RULE ID="EX02" SEVERITY="HIGH" NAME="Data Transfer Not Synch Correctly" DEFAULT_RUN="YES">
<RULE_DEFINITION>
<DECLARE>
<NODE NAME="NODE_1" TYPE="REG" />
<NODE NAME="NODE_2" TYPE="REG" />
<NODE NAME="NODE_3" TYPE="REG" />
</DECLARE>
<FORBID>
<NODE_RELATIONSHIP FROM_NAME="NODE_1" TO_NAME="NODE_2" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="ASYN" />
<NODE_RELATIONSHIP FROM_NAME="NODE_2" TO_NAME="NODE_3" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="!ASYN" />
<OR>
<NODE_RELATIONSHIP FROM_NAME="NODE_1" TO_NAME="NODE_2" TO_PORT="D_PORT" REQUIRED_THROUGH="YES" THROUGH_TYPE="COMB" CLOCK_RELATIONSHIP="ASYN" />
<CLOCK_RELATIONSHIP NAME="SEQ_EDGE|ASYN" NODE_LIST="NODE_2, NODE_3" />
</OR>
</FORBID>
</RULE_DEFINITION>
<REPORTING_ROOT>
<MESSAGE NAME="Rule %ARG1%: Found %ARG2% node(s) related to this rule.">
<MESSAGE_ARGUMENT NAME="ARG1" TYPE="ATTRIBUTE" VALUE="ID" />
<MESSAGE_ARGUMENT NAME="ARG2" TYPE="TOTAL_NODE" VALUE="NODE_1" />
<MESSAGE NAME="Source node(s): %ARG3%, Destination node(s): %ARG4%">
<MESSAGE_ARGUMENT NAME="ARG3" TYPE="NODE" VALUE="NODE_1" />
<MESSAGE_ARGUMENT NAME="ARG4" TYPE="NODE" VALUE="NODE_2" />
</MESSAGE>
</MESSAGE>
</REPORTING_ROOT>
</DA_RULE>
The codes differentiate the clock domains. ASYN means asynchronous, and !ASYN means non-asynchronous. This notation is useful for describing nodes that are in different clock domains. The following lines from the example state that NODE_2 and NODE_3 are in the same clock domain, but NODE_1 is not.
<NODE_RELATIONSHIP FROM_NAME="NODE_1" TO_NAME="NODE_2" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="ASYN" />
<NODE_RELATIONSHIP FROM_NAME="NODE_2" TO_NAME="NODE_3" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="!ASYN" />
The next line of code states that NODE_2 and NODE_3 have a clock relationship of either sequential edge or asynchronous.
<CLOCK_RELATIONSHIP NAME="SEQ_EDGE|ASYN" NODE_LIST="NODE_2, NODE_3" />
The <FORBID></FORBID> section contains the undesirable condition for the design, which in this case is the undesired configuration of the synchronizer. If the condition is fulfilled, the Design Assistant highlights a rule violation.
The possible SR latch structures are specified in the rule definition section. Codes defined in the <AND></AND> block are tied together, meaning that each statement in the block must be true for the block to be fulfilled (AND gate similarity). In the <OR></OR> block, as long as one statement in the block is true, the block is fulfilled (OR gate similarity). If no <AND></AND> or <OR></OR> blocks are specified, the default is <AND></AND>.
The <FORBID></FORBID> section contains the undesirable condition for the design, which in this case is the SR latch structures. If the condition is fulfilled, the Design Assistant highlights a rule violation.
The following examples show the undesired conditions from with their equivalent block diagrams:
Undesired Condition 3
<NODE_RELATIONSHIP FROM_NAME="NODE_1" TO_NAME="NODE_2" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="ASYN" />
<NODE_RELATIONSHIP FROM_NAME="NODE_2" TO_NAME="NODE_3" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="!ASYN" />
<NODE_RELATIONSHIP FROM_NAME="NODE_1" TO_NAME="NODE_2" TO_PORT="D_PORT" REQUIRED_THROUGH="YES"
THROUGH_TYPE="COMB" CLOCK_RELATIONSHIP="ASYN" />
Undesired Condition 4
<NODE_RELATIONSHIP FROM_NAME="NODE_1" TO_NAME="NODE_2" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="ASYN" />
<NODE_RELATIONSHIP FROM_NAME="NODE_2" TO_NAME="NODE_3" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="!ASYN" />
<CLOCK_RELATIONSHIP NAME="SEQ_EDGE|ASYN" NODE_LIST="NODE_2, NODE_3" />