Constraining ic delays

The clock skew is just as important as the data delay, so you want to work with report_timing. That's what drives the fitter and really determines if your design works. (If report_path showed the data path was 3.5ns, which would meet the 4ns clockperiod, but there were -1ns of skew, the design would fail report_timing and would not work).

That being said, there's some strange stuff going on in the analysis that needs to be resolved.

1) The Data Required Path does not show the clock tree to this point. Normally it would look similar to the clock path on the Data Arrival Time, i.e. start with the clock coming in on pin AK22, through a global buffer, etc. This would balance out the clock skew. Instead the clock just appears at the memory.

2) The Data Required Path has an oExt delay, which always comes directly from a set_output_delay. Is this maybe a virtual pin or something like that? For internal paths you normally don't see that.

I think there is something wrong with the .sdc causing this, but to be honest don't know what it is, but I would definitely figure out why those two issues are occuring and try to fix them first. After that, the datapath is actually Memory -> Logic, so it should be able to meet timing.