Corrected the swapped n and p bits in the ALU nzp computation, and the unsigned subtration overflow.

[Torrey0]

The previous line flipped the location of the bits for n and p. The ISA states they are nzp, but the comparison: alu_out_reg <= {5'b0, (rs - rt > 0), (rs - rt == 0), (rs - rt < 0)};
checks postive, zero, negative.

The sample code for matMul, which used a BRn, worked by coincidence.
CMP R9, R2
BRn LOOP
The computation appeared to work for both cases (k<N and k=N) that it needed to:

For iterating, when k < N, for example, k = 1, N = 2:
{0, (1 - 2) > 0, (1 - 2) == 0, (1 - 2) < 0}
= {0, (255) > 0, 1 == 0, 1 < 0}
= {0, 1, 0, 0}

This comes out ok, matching the targeted nzp, but only because 1-2 is computed unsigned, resulting in 255.

As an example where the old HDL gives incorrect results:
Inverting both the comparison and branch should result in the same behavior. However, if the sample code did this, and performed:
CMP R2, R9
BRzp LOOP

The results would be different. The computation would be:
{0, (2-1) > 0, (2-1) == 0, (2-1) < 0}
= {0, 1, 0, 0}

Now, this does not match the zp flag, and matMul will exit on the very first iteration, and not be computed correctly.

The new version computes the bits in the correct order and avoids any unsigned subtraction overflow.