Timing violation in default Gemmini configuration at 3 ns clock period

Description

I am running timing analysis on the default Gemmini configuration without any RTL modifications.

With a target clock period of 3 ns (~333 MHz), I am seeing a significant setup timing violation on a path within the Gemmini scratchpad/accumulator scaling logic.

I am trying to understand whether this timing path is expected in the default configuration and what the recommended approach is for analyzing or optimizing it.

Timing result

The worst path reported is:

Path 1: VIOLATED (-3334 ps) Setup Check with Pin
i_gemmini/spad/acc_scale_unit/pipe_out_p_stages_0_resp_data_6_0_reg_5_/CP->D

View: view_typ
Group: F2F_PATHS

Startpoint:
(R) i_gemmini/spad/norm_unit_passthru_q_wrap_1_reg/CP

Clock:
(R) gemmini_clk

Endpoint:
(R) i_gemmini/spad/acc_scale_unit/pipe_out_p_stages_0_resp_data_6_0_reg_5_/D

Clock:
(R) gemmini_clk

Full timing information:

                     Capture       Launch
       Clock Edge:+    3000            0
       Src Latency:+      0             0
       Net Latency:+      0 (I)         0 (I)
          Arrival:=    3000            0

            Setup:-       26
       Uncertainty:-     600
     Required Time:=    2374
       Launch Clock:-       0
          Data Path:-    5708
             Slack:=   -3334

Configuration

Gemmini configuration: default
RTL modifications: None
Target clock period: 3 ns
Target frequency: approximately 333 MHz
Analysis view: view_typ
Path group: F2F_PATHS

Question

I would appreciate some guidance on this timing path.

In particular:

Is this timing violation expected with the default Gemmini configuration at a 3 ns clock period?
Is the norm_unit_passthru → acc_scale_unit path normally expected to be one of the critical paths in Gemmini?
What is the recommended way to analyze this path to determine which RTL operation is responsible for the 5708 ps data path delay?
Are there existing pipeline/register boundaries or configuration parameters that are intended to address this path?
If achieving ~333 MHz is a reasonable target, what would be the recommended approach for optimizing this path without changing the functional behavior of the default Gemmini configuration?

I have not yet compared this result against a timing report from the original/reference Gemmini implementation, so I would also appreciate knowing whether this path is known to be timing-critical in the default design.

Navigation Menu

Repository navigation

Timing violation in default Gemmini configuration at 3 ns clock period #405