Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Halting behaviour #43

Open
michalmonday opened this issue Aug 15, 2024 · 1 comment
Open

Halting behaviour #43

michalmonday opened this issue Aug 15, 2024 · 1 comment

Comments

@michalmonday
Copy link

michalmonday commented Aug 15, 2024

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.

image

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.

image

(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?

@michalmonday
Copy link
Author

Here is another, hopefully more clear example:

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.

image

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

image

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant