Like the mutually_exclusive rule attribute, the conflict_free rule attribute is a way to overrule the scheduler's deduction about the relationship between two rules. However, unlike rules that are annotated mutually_exclusive, rules that are conflict_free may fire in the same clock cycle. Instead, the conflict_free attribute asserts that the annotated rules will not make method calls that are inconsistent with the generated schedule when they execute.

For example, two rules may both conditionally enqueue data into a FIFO with a single enqueue port. Ordinarily, the scheduler would conclude that the two rules conflict since they are competing for a single method. However, if they are annotated as conflict_free the designer is asserting that when one rule is enqueuing into the FIFO, the other will not be, so the conflict is apparent, not real. With the annotation, the schedule will be generated as if any conflicts do not exist and code will be inserted into the resulting model to check if conflicting methods are actually called by the conflict_free rules during simulation.

It is important to know that the conflict_free attribute's capabilities and limitations. The attribute works with more than method calls that totally conflict (like the single enqueue port). During simulation, it will check and report any method calls amongst \conflict_free rules that are inconsistent with the generated schedule (including registers being read after they have been written and wires being written after they are read). On the other hand, the conflict_free attribute does not overrule the scheduler's deductions with respect to resource usage (like uses of a multi-ported register file).

Example

(* conflict_free = "r1, r2, r3" *)

This example specifies that every pair of rules that are in the annotation (i.e (r1, r2), (r1, r3), and (r2, r3)) is a conflict-free rule pair.