Dev CSR Update: Fixes for DCCM Stall and TL Combinational loop

[shahzaibk23]

This PR resolves the following issues:

• Core not waiting for DCCM response as addressed in DCCM response stalling feature disabled #81
• Occurrence of combinational loop on the IF_Stall logic implemented for stalling the core until div and rem instructions finish their execution
  • Since this logic was implemented as a combinational logic, hence it was getting in loop with the Tilelink bus.
  • Fixed it by converting the logic to sequential and controlling the core to resume operations, just from the point stall was detected.
  • Question to why the controlling of core was necessary is because:
    • SRAM responds to the given requests every half cycle, hence when making the logic sequential, IF was fetching the next instruction as well before coming to a halt, making the PC stop as well after an additional +4/+2
    • Henceforth, a controlling logic was required to reset the PC to it's previous state, where the original stall would have detected (half a cycle back) and flushing the if_reg, so the extra instruction which was fetched cannot move any further in the pipeline.

[Talha-Ahmed-1]

Remove the commits made my Hassan and Rauf

[5hayanB]

LGTM

[shahzaibk23]

Remove the commits made my Hassan and Rauf

@Talha-Ahmed-1 We need to have Rauf's commit as it contains the logic for dccm response issue. I think we can revert hassan's commit as @5hayanB already has a stable riscof flow in dev_fpu branch which will be merged in dev_csr

What's your take on this @5hayanB ? Should we revert it or merge it for now?

[5hayanB]

As @Talha-Ahmed-1 suggested, we can remove Rauf's commit as well, as in dev_fpu, the DCCM stall issue had been resolved with the resolution of the combinational loop bug of IF_stall, resulting in no extra code dedicated for DCCM stalls