Slack violation in Vivado synthesis for zcu-102

[RenatoBelmonte]

I followed the README file in the root directory to perform the synthesis of pulpissimo with Vivado. While the bitstream was generated successfully, the timing report revealed a slack violation:

Copyright 1986-2022 Xilinx, Inc. All Rights Reserved. Copyright 2022-2023 Advanced Micro Devices, Inc. All Rights Reserved.
--------------------------------------------------------------------------------------------------------------------------------------------------
| Tool Version      : Vivado v.2023.2 (lin64) Build 4029153 Fri Oct 13 20:13:54 MDT 2023
| Date              : Sun Apr 21 14:48:28 2024
| Host              : rohan running 64-bit unknown
| Command           : report_timing -nworst 1 -delay_type max -sort_by group -file reports/pulpissimo-zcu102.timing.rpt
| Design            : xilinx_pulpissimo
| Device            : xczu9eg-ffvb1156
| Speed File        : -2  PRODUCTION 1.30 05-15-2022
| Design State      : Physopt postRoute
| Temperature Grade : E
--------------------------------------------------------------------------------------------------------------------------------------------------

Timing Report

Slack (VIOLATED) :        -7.068ns  (required time - arrival time)
  Source:                 i_pulpissimo/soc_domain_i/pulp_soc_i/i_soc_interconnect_wrap/i_axi_lite_to_apb/i_axi_lite_to_apb/gen_req_ft_reg.i_req_ft_reg/i_fifo/i_fifo_v3/status_cnt_q_reg[1]/C
                            (rising edge-triggered cell FDCE clocked by clk_out1_xilinx_clk_mngr  {[email protected] [email protected] period=50.000ns})
  Destination:            i_pulpissimo/soc_domain_i/pulp_soc_i/i_soc_interconnect_wrap/i_axi64_to_lint32/axi64_2_lint32_i/i_axi_write_ctrl/FSM_sequential_CS_reg[0]/D
                            (rising edge-triggered cell FDCE clocked by clk_out1_xilinx_clk_mngr  {[email protected] [email protected] period=50.000ns})
  Path Group:             clk_out1_xilinx_clk_mngr
  Path Type:              Setup (Max at Slow Process Corner)
  Requirement:            50.000ns  (clk_out1_xilinx_clk_mngr [email protected] - clk_out1_xilinx_clk_mngr [email protected])
  Data Path Delay:        57.157ns  (logic 5.941ns (10.394%)  route 51.216ns (89.606%))
  Logic Levels:           66  (CARRY8=4 LUT1=14 LUT2=15 LUT3=7 LUT4=4 LUT5=12 LUT6=10)
  Clock Path Skew:        0.182ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    4.265ns = ( 54.265 - 50.000 ) 
    Source Clock Delay      (SCD):    3.645ns
    Clock Pessimism Removal (CPR):    -0.438ns
  Clock Uncertainty:      0.117ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Discrete Jitter          (DJ):    0.224ns
    Phase Error              (PE):    0.000ns
  Clock Net Delay (Source):      1.932ns (routing 0.922ns, distribution 1.010ns)
  Clock Net Delay (Destination): 1.984ns (routing 0.844ns, distribution 1.140ns)

I've come across a discussion (#379 (comment)) suggesting that this violation may not be critical, as it might not be a real-time path. However, I would appreciate clarification on whether adjusting the clock period could resolve this issue and ensure proper functionality.