there are indeed differences in the way RCP handles some of the nets and EDI. These differences are mostly related with signals such as reset, scan enable, high fanout nets, etc. In your case, the concerning aspect is that when things do not correlate, you would normally expect more optimism in synthesis and not the other way round as described in your example. The following report subcommands can provide you additional detail on the calculation
net_cap_calculation - reports how the capacitance of the net is calculated
net_delay_calculation - reports how the net delay is calculated
net_res_calculation - reports how the resistance of the net is calculated
nets - prints a nets report
The first thing I would look at are
(1) Version of RC
(2) Version of EDI
(3) Are u using same netlist ?
(4) Are u using same SDC ?
(5) Are all constraints accepted cleanly ?
(6) Are u looking at same corner ?
Remember when using RCP, the GUI can be very handy.
report timing -gui. . .
will show you the path in the GUI. Is it reasonably similar to what EDI is showing ? If not, why ?
Last but not least, be careful when you assumeRCP will reduce slack. RCP will determine the physical dependencies more accurately hence produce a better netlist (better util, TNS, power, etc.) That being said, if your critical path is a flop to a flop without logic in between, there is not much RCP can do to make that better. Hope this is useful.