According to the spec, always blocks run in parallel to the behavior of the instruction. This leads to undefined behavior when modifying the same variables in the architectural state, as also pointed out in #103 (Which was related to dependencies between an always block and instruction behavior). This issue, on the other hand, is regarding the handling of multiple always blocks which depend on each other.
A real-world example is the following:
Always Block 1: implicit_pc_increment implemented in RISCVBase (i.e. PC = PC + 4;)
Always Block 2: hwlp_0 implemented inXHwlp extends RISCVBase (i.e. if (PC == hwlp_end) { PC = hwlp_start; })
Optional: Some Jump/Branch instruction (i.e. PC = target_addr;)
Let's assume that previous changes to the PC are not visible to the following behavior blocks (see #103). Otherwise, we do not have a way to dismiss the implicit_pc_increment before/after a jump/branch instruction.
There are 3!=3*2*1=6 possible execution orders for the situation above and only one of them yields the correct behavior:
1. -> 2. -> 3.
How we deal with this is currently tool-specific. M2-ISA-R would currently generate 2. -> 1. -> 3. due to the traversal order of the hierarchy. Reversing the order of always block would be required for the specific example above but might not be a generic solution. Should the spec define a defined order of execution or should we offer a way to customize the order (if required) by the user?
According to the spec, always blocks run in parallel to the behavior of the instruction. This leads to undefined behavior when modifying the same variables in the architectural state, as also pointed out in #103 (Which was related to dependencies between an always block and instruction behavior). This issue, on the other hand, is regarding the handling of multiple always blocks which depend on each other.
A real-world example is the following:
implicit_pc_incrementimplemented inRISCVBase(i.e.PC = PC + 4;)hwlp_0implemented inXHwlp extends RISCVBase(i.e.if (PC == hwlp_end) { PC = hwlp_start; })PC = target_addr;)Let's assume that previous changes to the
PCare not visible to the following behavior blocks (see #103). Otherwise, we do not have a way to dismiss theimplicit_pc_incrementbefore/after a jump/branch instruction.There are
3!=3*2*1=6possible execution orders for the situation above and only one of them yields the correct behavior:How we deal with this is currently tool-specific. M2-ISA-R would currently generate 2. -> 1. -> 3. due to the traversal order of the hierarchy. Reversing the order of always block would be required for the specific example above but might not be a generic solution. Should the spec define a defined order of execution or should we offer a way to customize the order (if required) by the user?
@eyck @AtomCrafty @wysiwyng