Intradomain Skew Problem

I am trying to understand where is the critical path of my design to improve it. I believe (I could be wrong) that this issue is most related to the configuration of the tool (Quartus), than the way I created the logic (like the suggestions about long combinational path).

The timing report I attached is from the top failing path (torv32 is the processor, and "dmem" is the dual port RAM memory IP core). If that's not what you are asking, please correct me.

It was my first time using Timing Analyzer, so I used a .sdc file created by Quartus, and it only has these lines:

set_time_format -unit ns -decimal_places 3

create_clock -name {CLK} -period 1.000 -waveform { 0.000 0.500 } [get_ports {CLK}]

set_clock_uncertainty -rise_from [get_clocks {CLK}] -rise_to [get_clocks {CLK}] -setup 0.170
set_clock_uncertainty -rise_from [get_clocks {CLK}] -rise_to [get_clocks {CLK}] -hold 0.060
set_clock_uncertainty -rise_from [get_clocks {CLK}] -fall_to [get_clocks {CLK}] -setup 0.170
set_clock_uncertainty -rise_from [get_clocks {CLK}] -fall_to [get_clocks {CLK}] -hold 0.060
set_clock_uncertainty -fall_from [get_clocks {CLK}] -rise_to [get_clocks {CLK}] -setup 0.170
set_clock_uncertainty -fall_from [get_clocks {CLK}] -rise_to [get_clocks {CLK}] -hold 0.060
set_clock_uncertainty -fall_from [get_clocks {CLK}] -fall_to [get_clocks {CLK}] -setup 0.170
set_clock_uncertainty -fall_from [get_clocks {CLK}] -fall_to [get_clocks {CLK}] -hold 0.060