FPGA Internal Timing Constraint fehlgeschlagen

Ich versuche derzeit, einen IP-Core auf einem Cyclone V 5CSEBA6U23I7 FPGA-HPS-System mit Altera Quartus II und TimeQuest Analyzer zu implementieren.
Der unten eingefügte Verilog-Code erzeugt ein Timing-Problem, nämlich die Zuweisung fifo_wdata_289[255:0] <= {fifo_out,fifo_wdata_289[255:16]};, die die Ausgabe eines FIFO in ein anderes FIFO-Registerarray schreibt.
Die verwendeten FIFOs sind asynchron, aber die verwendeten Signale befinden sich in derselben Taktdomäne.
Dies wird mit einem Taktversatz von -2,255 ns auf den Chip gebracht , was etwas weniger als eine ganze Periode ist ( 288-MHz-Takt => 3,47 ns ), und TimeQuest beschwert sich, dass die Einschränkungen verletzt werden.
Die Empfehlung von TimeQuest lautet, die Ebenen der kombinatorischen Logik für den Pfad zu reduzieren(Issue Long Combinational Path ) mit zusätzlichen Ebenen der kombinatorischen Logik = 1.

Der 288-MHz-Takt wird über PLL generiert und ich verwende Timeconstraint-Dateien (sdc) mit den Befehlen derive_pll_clocks und derive_clock_uncertainty.

Meine Frage ist nun, wie ich dieses Problem lösen kann, da ich nur eine Schicht kombinatorischer Logik (Demuxer und Routing, wie von der Aufgabe vorgeschlagen) habe und daher keine Ahnung habe, wie ich das reduzieren kann. Gibt es eine andere Möglichkeit, um sicherzustellen, dass die Timing-Anforderung erfüllt ist, oder gibt es eine bessere Möglichkeit, diese Zustandsmaschine zu programmieren?
Vielen Dank für Ihre Hilfe.

            case(stateProc)
                2'b00:
                begin
                    if(~fifo_empty&~fifo_full_289)
                    begin
                        fifo_wdata_289[255:0] <= {fifo_out,fifo_wdata_289[255:16]};
                        fifo_wdata_289[287:256] <= {2'b11,fifo_wdata_289[287:258]};
                        if(imgSize >= maxImgSize - 32'd2)//image done, transmit data and fire irq
                        begin
                            fifo_wdata_289[288] <= 1;
                            stateProc <= 2'b01;
                            imgSize <= 32'd0;
                        end
                        else if(fifo_wdata_289[258])//process transfer without irq //258 high means that 256 has been written in this cycle and 258 in the previous cycle
                        begin
                            fifo_wdata_289[288] <= 0;
                            stateProc <= 2'b01;
                            imgSize <= imgSize + 32'd2;
                        end
                        else//accumulate more data
                        begin
                            fifo_wdata_289[288] <= 0;
                            stateProc <= 2'b00;
                            imgSize <= imgSize + 32'd2;
                        end
                    end
                    else
                    begin
                        fifo_wdata_289 <= fifo_wdata_289;
                        imgSize <= imgSize;
                        stateProc <= 2'b00;
                    end
                end
                2'b01:
                begin
                    fifo_wdata_289 <= fifo_wdata_289;
                    imgSize <= imgSize;
                    stateProc <= 2'b11;
                end
                2'b11:
                begin
                    fifo_wdata_289 <= 0;
                    imgSize <= imgSize;
                    stateProc <= 2'b00;
                end
            endcase

BEARBEITEN:

Die Fehlerpfade von TimeQuest sehen meistens so aus:
Slack:
-3.178

From Node:
soc_system:u0|CamConnector:camconnector_0|FIFO_289:FIFO_inst_289|dcfifo:dcfifo_component|dcfifo_6up1:auto_generated|wrptr_g[0]

To Node:
soc_system:u0|CamConnector:camconnector_0 |fifo_wdata_289[267]

EDIT2:
Ich verwende derzeit MLAB-Zellen als FIFO-Speicher, die für 290 MHz ausgelegt sind.
Beide FIFOs sind asynchron und haben eine Synchronisationseinstellung von 3.
Timing Closure Recommandations von TimeQuest meldet die folgenden zwei Probleme:

1. Unausgeglichene kombinatorische Logik
2. Langer kombinatorischer Pfad