parsa-epfl / knockoutkraken Goto Github PK

In BitPatters.scala, we should add the following instructions and ensure their execution.

Execute.scala has the module that enables to process them as DataProc3S.

  // 31 | 30 29 | 28 27 26 25 24 | 23 22 21 | 20 19 18 17 16 | 15 | 14 13 12 11 10 | 09 08 07 06 05 | 04 03 02 01 00 | Instruction Page | Variant
  // sf |  op54 |  1  1  0  1  1 |   op31   |       Rm       | o0 |       Ra       |       Rn       |       Rd       |                  |
  //  0 |  0  0 |  1  1  0  1  1 |  0  0  0 |       Rm       |  0 |       Ra       |       Rn       |       Rd       | MADD             | 32-bit
  //  0 |  0  0 |  1  1  0  1  1 |  0  0  0 |       Rm       |  1 |       Ra       |       Rn       |       Rd       | MSUB             | 32-bit
  //  1 |  0  0 |  1  1  0  1  1 |  0  0  0 |       Rm       |  0 |       Ra       |       Rn       |       Rd       | MADD             | 64-bit
  //  1 |  0  0 |  1  1  0  1  1 |  0  0  0 |       Rm       |  1 |       Ra       |       Rn       |       Rd       | MSUB             | 64-bit
  def DP3S = BitPat("b?0011011000?????????????????????")
  def DP3S_MADD32 = BitPat("b00011011000?????0???????????????")
  def DP3S_MSUB32 = BitPat("b00011011000?????1???????????????")
  def DP3S_MADD   = BitPat("b10011011000?????0???????????????")
  def DP3S_MSUB   = BitPat("b10011011000?????1???????????????")

At present, the software side (the event handler and the memory management logic) is embedded in the QEMU. It's better to consider the paradigm used by QFlex: Dynamically linked library
Maybe some reference is like plugin.

After fix #67, we cannot synthesize the design under 125MHz clock frequency.

void HELPER(dc_zva)(CPUARMState *env, uint64_t vaddr_in) in target/arm/helper-a64.c modifies memory.

Ensure that page is transplanted correctly before call in translation-a64.c

Failed instruction CLZ:
dac010e5 clz x5, x7
Mismatched register 5 is detected: QEMU: 40, FPGA: 3f

The root cause of this problem is that we wrongly implement the floating-point load and store and it evicts the same page twice in a very short distance, and we observe the deadlock. Further observation is required to find the deeper bug.

We tried running select-sort regression tests, but for some reason the program is able to progress without having a Page Fault for the data.

This implies that for some reason the dTLB received a translation allowing it to not page fault.

The program results in an EXCP, where we believe comes from the page fault, on instruction 0x60.

In order to troubleshot this, we must add some hardware probes on the iTLB and dTLB to see whenever it is receiving a transaction. And to the Message queue to see if it's generated two insertions from a single message.

We have pinpointed the call that fails using the FPGA:

We should get to that point in simulation to better understand what lead to the failure.

It is always the same instruction that fails and the error is deterministic.

Given the arrival of new developers to the Team, we need a way to maintain consistency through the code different team members are working on in parallel

Currently there's no convention regarding what style should be used for naming

Chisel being somewhat of a mixture of RTL and Scala has two naming conventions that conflict each other, and special specifications related to the code generation part of Chisel.

1. In the Java/Scala world, people tend to follow the naming convention of writing variables like fooBar
2. In the RTL world, people tend to follow c-like naming things like foo_bar
3. Verilog (and VHDL) being constrained by physical requirements, developers make use of suffixes to hint what kind
   of hardware element is behind a name with _i,_o,_r corresponding to IO ports, and Register
4. Chisel generated code tends to add a _ on every Scala attribute, module port name. such as

val myBun = new Bundle {
   val a = UInt
   val b = new Bundle { 
        val c = Bool
        val d = Bool 
   }
}

will generate

myBun_a
myBun_b_c
myBun_b_d

Taking the best from both worlds, we should keep the good hits hardware developers use to ease readability while taking into consideration the heritage of Scala and the Chisel code generation

There's a architectural error:

When working on a PageTableSet (16 translation entries), we buffer the set inside the PageMissHandler module.

But, decisions on that module might trigger TLB evictions, and extra page walks.

Those decisions will not modify the buffered working set, but will actually refetch the set from DRAM and modify it there, making it such as the latest version of the set is not updated correctly.

See pic below, the page table set is full (FFFF) although we already evicted those entries previously.

Several steps:

• The fetch stage should also do permission checking and pass the exception along the pipeline.
• QEMU needs to give the maximum page permission when handling the page fault.
• QEMU controls which cache to flush.

It fails on Rafael's computer, but times out on Github CI.

In disas_ldst_atomic, in case o3_opc == 014, then we are missing the qflex_post_mem:

    GEN_QFLEX_HELPER(qflex_mem_trace_gen_helper(), GEN_HELPER(qflex_pre_mem)( 
					 cpu_env, clean_addr, tcg_const_i32(MMU_DATA_LOAD), tcg_const_i32(1 << size)));
    GEN_QFLEX_HELPER(qflex_mem_trace_gen_helper(), GEN_HELPER(qflex_pre_mem)( 
					 cpu_env, clean_addr, tcg_const_i32(MMU_DATA_STORE), tcg_const_i32(1 << size)));

    if (o3_opc == 014) {
        /*
         * LDAPR* are a special case because they are a simple load, not a
         * fetch-and-do-something op.
         * The architectural consistency requirements here are weaker than
         * full load-acquire (we only need "load-acquire processor consistent"),
         * but we choose to implement them as full LDAQ.
         */
        do_gpr_ld(s, cpu_reg(s, rt), clean_addr, size, false,
                  true, rt, disas_ldst_compute_iss_sf(size, false, 0), true);
        tcg_gen_mb(TCG_MO_ALL | TCG_BAR_LDAQ);
        return;
    }

    tcg_rs = read_cpu_reg(s, rs, true);
    tcg_rt = cpu_reg(s, rt);

    if (o3_opc == 1) { /* LDCLR */
        tcg_gen_not_i64(tcg_rs, tcg_rs);
    }

    /* The tcg atomic primitives are all full barriers.  Therefore we
     * can ignore the Acquire and Release bits of this instruction.
     */
    fn(tcg_rt, clean_addr, tcg_rs, get_mem_index(s), mop);

    if ((mop & MO_SIGN) && size != MO_64) {
        tcg_gen_ext32u_i64(tcg_rt, tcg_rt);
    }
    GEN_QFLEX_HELPER(qflex_mem_trace_gen_helper(), GEN_HELPER(qflex_post_mem)( 
					 cpu_env, clean_addr, tcg_const_i32(MMU_DATA_LOAD), tcg_const_i32(1 << size)));
    GEN_QFLEX_HELPER(qflex_mem_trace_gen_helper(), GEN_HELPER(qflex_post_mem)( 
					 cpu_env, clean_addr, tcg_const_i32(MMU_DATA_STORE), tcg_const_i32(1 << size)));

Test select-sort-15-threads Infinite loop.

Force qflex_singlestep to execute an instruction in case the first try didn't.

The FPGA fails asserts if QEMU has been compiled without the --debug flag enabled.

At present, the normal mode does not consume the icount credit.

When running in DevteroFlex debug mode and the user presses a button, it will trigger an IRQ. This IRQ will cancel the instruction execution that was intended to be checked against DevteroFlex state.

The final result is DevteroFlex state not matching QEMU's state as QEMU executed the IRQ instead of the expected instruction.