Accuracy tests for multiplication and addition fails!

[ersin-cukurtas]

When I try to run

./sim --gtest_filter=PIMKernelFixture.mul
./sim --gtest_filter=PIMKernelFixture.add

At certain indices, the simulated matrix returns 0's while the pre-calculated values are not. Any reason why that might be?

[hunjunlee]

The reason for the wrong functionality is due to the "PIMCmd(PIMCmdType::NOP, 0)".

The PIM microkernel for the element-wise pim operations indicates the following procedure where the commands 1~7 (see the pseudo code with the comments below) are iterated by the number of tiles.

Iterate num_tile times:

      // Executed with the transaction BANK_TO_GRF (targeting the EVEN BANK)
      1: PIMCmd(PIMCmdType::FILL, PIMOpdType::GRF_A, PIMOpdType::EVEN_BANK),

      // Executed with the transaction ADD (targeting the EVEN BANK)
      2: PIMCmd(pimType, PIMOpdType::GRF_A, PIMOpdType::GRF_A, PIMOpdType::EVEN_BANK, 1),

      // Executed with the transaction GRF_TO_BANK (targeting the EVEN BANK)
      3: PIMCmd(PIMCmdType::NOP, 7),

      // Executed with the transaction BANK_TO_GRF (targeting the ODD BANK)
      4: PIMCmd(PIMCmdType::FILL, PIMOpdType::GRF_B, PIMOpdType::ODD_BANK),

      // Executed with the transaction ADD (targeting the ODD BANK)
      5: PIMCmd(pimType, PIMOpdType::GRF_B, PIMOpdType::GRF_B, PIMOpdType::ODD_BANK, 1),

      // Executed with the transaction GRF_TO_BANK (targeting the ODD BANK)
      6: PIMCmd(PIMCmdType::NOP, 7),

      // ? => Causes a single-cycle stall
      7: PIMCmd(PIMCmdType::NOP, 0),

The commands 1 to 6 refer to (1) loading the data from the EVEN/ODD BANK to the GRF, (2) performing element-wise operations (ADD / MUL), and (3) storing the data from the GRF to the EVEN/ODD BANK.

Also, the commands are executed by the transactions listed in computeAddOrMul function (see the comments in the pseudo code above).

However, I do not understand why "PIMCmd(PIMCmdType::NOP, 0)" exists (There must be some reasons, so I hope the contributors comment on this issue) and the transaction to trigger the command does not exist either.

Therefore, the command incurs a single-cycle stall, and thus, the transactions are not properly mapped to the commands after the first iteration.

So, the most simple way to ensure correct functionality is to remove "PIMCmd(PIMCmdType::NOP, 0)".

[iamshcha]

In a previous commit fddc44a, we removed the dummy code from the PIMKernel, which should have also removed the PIM CRF code, but we seem to have missed it. we've updated the latest commit to fix this bug.