Error de restricción de temporización interna de FPGA

Actualmente estoy intentando implementar un IP-Core en un Cyclone V 5CSEBA6U23I7 del sistema FPGA-HPS con Altera Quartus II y TimeQuest Analyzer.
El código Verilog pegado a continuación produce un problema de tiempo, es decir, la asignación fifo_wdata_289[255:0] <= {fifo_out,fifo_wdata_289[255:16]}; , que escribe la salida de un FIFO en otra matriz de registros FIFO.
Los FIFO en uso son asíncronos, pero las señales utilizadas están en el mismo dominio de reloj.
Se está colocando en el chip con un sesgo de reloj de -2.255 ns , que es un poco menos que un período completo ( 288 MHz clock = > 3.47 ns ) , y hace que TimeQuest se queje, de que se están violando las restricciones.
La recomendación de TimeQuest es Reducir los niveles de lógica combinacional para la ruta (Emitir Ruta combinada larga ) con niveles adicionales de lógica combinacional = 1.

El reloj de 288 MHz se genera a través de PLL y estoy usando archivos de Timeconstraint (sdc) con los comandos derive_pll_clocks y derive_clock_uncertainty.

Mi pregunta ahora es cómo resolver este problema, ya que solo tengo una capa de lógica combinatoria (Demuxer y enrutamiento, como lo sugiere la asignación) y, por lo tanto, no tengo idea de cómo reducir eso. ¿Hay alguna otra manera en que pueda asegurarme de que se cumpla el requisito de tiempo, o hay una mejor manera de programar esta máquina de estadísticas? Gracias por tu ayuda.

            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

EDITAR:

Las rutas que fallan en TimeQuest se ven así:
Slack:
-3.178

Desde el nodo:
soc_system: u0 | CamConnector: camconnector_0 | FIFO_289: FIFO_inst_289 | dcfifo: dcfifo_component | dcfifo_6up1: auto_generated | wrptr_g [0]

Al nodo:
soc_system: u0 | CamConnector: camconnector_0 | fifo_wdata_289 [267]

EDIT2:
Actualmente estoy usando celdas MLAB como almacenamiento FIFO, que están clasificados para 290 MHz.
Ambos FIFO son asíncronos y tienen una configuración de sincronización de 3.
El tiempo de cierre Las recomendaciones de TimeQuest informan los dos problemas siguientes:

1. lógica combinacional desequilibrada
2. Senda Combinacional Larga