Understanding Priorities with Multiple Wildcard LogicLock Region Membership Assignments

While the relative priority of node assignments and entity assignments is clear (node assignments take precedence), the relative priority between multiple wildcard assignments can be ambiguous.

Example:

Consider the node a:inst1|mynode .

An assignment made to a:inst1 would apply to the above node, as would an assignment made to a:inst1|mynode; however, the a:inst1|mynode assignment takes priority because it is the more specific assignment.

If you make a wildcard assignment to a*, the order of precedence is as follows:

• Highest priority— a:inst1|mynode
• Second priority— a*
• Lowest priority— a:inst1

However, if you make a second wildcard assignment, * mynode, the intended order of priority is ambiguous, as the two wildcard assignments seem to have equal priority:

• Highest priority— a:inst1|mynode
• Second priority— a* or * mynode
• Lowest priority— a:inst1

The Quartus^® Prime Standard Edition software manages such potential conflicts by applying the LogicLock Region Priority parameter when you create wildcard or path-based assignments. The LogicLock Region Priority parameter automatically assigns a number, establishing the wildcard or path-based assignment's relative priority. The Quartus^® Prime Standard Edition software automatically assigns the highest priority to the most recently created assignment. Hence, in the above example, * mynode would take precedence over a*, resulting in the following order of precedence:

• Highest priority— a:inst1|mynode
• Second priority— * mynode
• Third priority— a*
• Lowest priority— a:inst1

The Quartus^® Prime Standard Edition software inserts the LogicLock Region Priority parameter when you create assignments with the set_logiclock_contents Tcl command, with the LogicLock Region Properties dialog box, or by dragging and dropping a resource into a LogicLock region.