You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that halting CPU this way prevents new instructions from executing but it does not delay results of the current and previous instruction being written to the GPR file.
This is not a problem from the CPU perspective, but in the project I'm working on, it desynchronises the series of program counters from its corresponding series of GPR file values. The project keeps shadow copy of the GPR file and records every program counter with its corresponding state of the GPR file.
Screenshot below shows what happens without halting CPU.
On the screenshot above the blue colour marks instruction that becomes "extended" when CPU is halted. While it's being "extended" (shown on image below) there are 2 writes to GPR file that would normally happen during different instructions.
(please ignore "2 clk past" on the image, it was self note hinting at naive not-working solution to shift any writes 2 cycles after the "extended" instruction).
My question is:
Is there a way to somehow delay any GPR file writes while halting variable is high?
The text was updated successfully, but these errors were encountered:
During normal execution (without halting from external source), the GPR address (rg_written_reg_name) becomes 0D while program counter (imem_rg_pc) is 800010E6. Also, the program counter is 800010E6 for 2 clock cycles.
When halting occurs, the GPR address becomes 0D while program counter is 800010EA. The program counter appears to be 800010E6 for only one non-halted clock cycle. So there are 2 options:
GPR address becomes OD 1 clock cycle too late
the 800010E6 program counter changes to 800010EA 1 clock cycle too early
It appears that adding "&& halting" to rl_pipe guard condition in CPU.bsv reduces the number of situations where this kind of mismatch happens, but it does not get rid of them completely.
Hello, I am using a slightly modified version of Flute which allows to set
halting
variable of CPU module from external source.https://github.com/michalmonday/Flute/blob/continuous_monitoring/src_Core/CPU/CPU.bsv#L791
I noticed that halting CPU this way prevents new instructions from executing but it does not delay results of the current and previous instruction being written to the GPR file.
This is not a problem from the CPU perspective, but in the project I'm working on, it desynchronises the series of program counters from its corresponding series of GPR file values. The project keeps shadow copy of the GPR file and records every program counter with its corresponding state of the GPR file.
Screenshot below shows what happens without halting CPU.
On the screenshot above the blue colour marks instruction that becomes "extended" when CPU is halted. While it's being "extended" (shown on image below) there are 2 writes to GPR file that would normally happen during different instructions.
(please ignore "2 clk past" on the image, it was self note hinting at naive not-working solution to shift any writes 2 cycles after the "extended" instruction).
My question is:
Is there a way to somehow delay any GPR file writes while
halting
variable is high?The text was updated successfully, but these errors were encountered: