Visible to Intel only — GUID: mwh1409959543887
Ixiasoft
Visible to Intel only — GUID: mwh1409959543887
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" />