While reviewing the controller logic, I noticed a potential issue in the instruction address misalignment check.
Relevant code:
https://github.com/colluca/schnizo/blob/schnova/hw/schnizo/src/schnizo_controller.sv#L216-L219
// Unaligned address check
assign instr_addr_misaligned_o = (instr_decoded_i.is_branch ||
instr_decoded_i.is_jal ||
instr_decoded_i.is_jalr)
&& (consecutive_pc[1:0] != 2'b0);
As far as I understand, this logic is intended to check whether the target PC after a control-flow instruction is properly aligned.
However, for jal and jalr, the next PC is not taken from consecutive_pc. Instead, the target address is derived from the ALU result (since these instructions compute a PC-relative jump target).
Because of this, the alignment check for jal/jalr might be using the wrong address (consecutive_pc) rather than the actual computed jump target.
While reviewing the controller logic, I noticed a potential issue in the instruction address misalignment check.
Relevant code:
https://github.com/colluca/schnizo/blob/schnova/hw/schnizo/src/schnizo_controller.sv#L216-L219
As far as I understand, this logic is intended to check whether the target PC after a control-flow instruction is properly aligned.
However, for jal and jalr, the next PC is not taken from
consecutive_pc.Instead, the target address is derived from the ALU result (since these instructions compute a PC-relative jump target).Because of this, the alignment check for jal/jalr might be using the wrong address (consecutive_pc) rather than the actual computed jump target.