Open lighteningfingers opened 3 years ago
Thanks for pointing this out. This is indeed an issue that we have seen in silicon. In the usual case where dmactive = 0
, all the registers are constantly written with soft-reset values, leading to significantly elevated power consumption of the dm.
I will take a closer look at your proposed fix and create a MR.
care should be taken when considering synchronous resets. for a synthesis flow where clockgate insertion is required, clockgate enables are derived from the RTL. Consider the dmactive synchronous reset in dm_csrs.sv. It enables clocks to registers such as control_q whenever dmactive = 0. what happens for the scenario where dmactive is low for many cycles. control_q is reset on the first cycle, then for clock cycles after, control_q current state = "reset", next state = "reset". In this situation, after the first cycle, conrtol_q reg no longer needs clocking until dmactive changes.
instead of: if (!dmcontrol_q.dmactive) consider: if (dmi_req_ready_o && dmi_req_valid_i && dtm_op == dm::DTM_WRITE && dm_csr_addr == dm::DMControl && !dmcontrol_d.dmactive && dmcontrol_q.dmactive)
in this refined code (which could be pulled out as a wire, thus easier to debug), the synchronous reset is only applied for the single cycle when dmactive 1 and is written to 0
As this synchronous reset fans out to several large registers, for periods where dmactive is low, there should be a positive saving in power consumption. I wouldnt expect a large overhead in power consumption for the predictor function (the clockgate enable) nor a large detrimental effect on timing closure.