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

Power optimization on CSR operations in a shadow of a TAKEN branch #566

Open
davideschiavone opened this issue Nov 4, 2020 · 0 comments
Labels
Component:RTL For issues in the RTL (e.g. for files in the rtl directory) Type:Enhancement For feature requests and enhancements WAIVED:CV32E40P Issue does not impact a major release of CV32E40P and is waived

Comments

@davideschiavone
Copy link
Contributor

When a branch is taken and a CSR operation is in the ID stage, the csr_access_ex_o flip flop gets updated to 1 as it is not gated by the deassert signal:

https://github.com/openhwgroup/cv32e40p/blob/master/rtl/cv32e40p_id_stage.sv#L1573

Even if this does not happen in any functional bug, it wastes dynamic power as it changes the csr_address in the CSR register file and the multiplexer in the Ex stage.

By only gating the csr_access_o in the decoder with

assign csr_access_o = (deassert_we_i) ? 1'b0: csr_access;

causes a non-LEC, as the ex_valid_o signal in the ex_stage does not rise 1 due to the following condition

https://github.com/openhwgroup/cv32e40p/blob/master/rtl/cv32e40p_ex_stage.sv#L427

(csr_access_i is not 1 anymore)

However, the cycle later ex_valid_o goes to 1 as the alu_en_i is by default set to 1

https://github.com/openhwgroup/cv32e40p/blob/master/rtl/cv32e40p_id_stage.sv#L1620

This cause a difference when, for example, an illegal CSR instruction is executed, as such instruction stays in the FLUSH_EX state in the controller for 2 cycles, one as before, plus another one because ex_valid_o is equal to 0 in the first cycle.

@davideschiavone davideschiavone added Component:RTL For issues in the RTL (e.g. for files in the rtl directory) Type:Enhancement For feature requests and enhancements labels Nov 4, 2020
@davideschiavone davideschiavone added the WAIVED:CV32E40P Issue does not impact a major release of CV32E40P and is waived label Dec 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component:RTL For issues in the RTL (e.g. for files in the rtl directory) Type:Enhancement For feature requests and enhancements WAIVED:CV32E40P Issue does not impact a major release of CV32E40P and is waived
Projects
None yet
Development

No branches or pull requests

1 participant