Fix pipeline timing mismatch: sl_type delayed one cycle in load operations

[Copilot]

LoadStoreUnit processes load data with sl_type_MEM from current MEM stage, but synchronous DRAM output reflects previous cycle's read. This causes byte/halfword extraction to use wrong instruction's metadata.

Changes

• PR_MEM_WB: Added sl_type and alu_result ports to propagate load metadata to WB stage
• CPU_TOP: Instantiated second LSU in WB stage using registered signals (sl_type_WB, alu_result_WB, DRAM_data_WB)
• PR_EX_MEM: Fixed sl_type_mem_o reset width (was 3'b0, should be 4'b0)
• filelist.f: Added LoadStoreUnit.sv

Pipeline Flow

Before (buggy):

Cycle N:   MEM(LB) → DRAM read, sl_type_MEM=LB
Cycle N+1: MEM(ADD), WB(LB) → load_data_o uses sl_type_MEM=NOP ❌

After (fixed):

Cycle N:   MEM(LB) → DRAM read, sl_type_MEM=LB → [PR_MEM_WB registers]
Cycle N+1: MEM(ADD), WB(LB) → WB-LSU uses sl_type_WB=LB ✓

MEM-stage LSU handles stores; WB-stage LSU processes loads with temporally aligned metadata.

Original prompt

我的LoadStoreUnit单独测试时没问题，其作用是将进入WB级的数据处理后传给DRAM，控制DRAM位写使能，或是将DRAM读出的数据处理后送入WB级的MUX准备写回。其中，对于同步DRAM，DRAM的spo已经是寄存器输出，在WB级直接使用以避免多余延迟。但我使用LSU控制后，流水线读取出现问题，因MEM级的sl_type晚了一拍。你能帮我分析流水线结果，并帮我修复流水线问题吗？

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Zxis233]

@copilot 你能使用iverilog进行仿真，并分析波形文件帮我修改吗？