What we can do to fix the timing failure inside the Altera IPs?

[Altera_Forum]

I have design which use multiple DDR3 UniPHY controller in the qsys system. I compiled the design and the design failed timing. I checked the failed paths, and I can see some paths are inside the DDR3 controller IPs. So I wonder if we confront timing issues inside IPs, what we can do to fix it except ask Altera assistance? Based my limited understanding, I can't do too much since the IP is mostly like a black box for us.  

 Meanwhile, if the timing failed inside the generated files from qsys, what should we do? I don't think editing the generated files directly is a good idea, since if we have any changes later and regenerated, the changes we did will lost. So it looks like the proper solution is understanding the timing issue clearly, then add some custom logics into qsys design is a right way. Any idea?  Thanks in advance.

[Altera_Forum]

some ips allow you pipeline settings of your own or even fool it with higher clk speed. Your overall design and constraints may also affect fitting inside ips.

[Altera_Forum]

--- Quote Start ---  some ips allow you pipeline settings of your own or even fool it with higher clk speed. Your overall design and constraints may also affect fitting inside ips.  --- Quote End ---    I agree " overall design and constraints may also affect fitting inside ips", but it seems is difficult to conclude a common way that how to fix when we confront the timing issues inside IPs.

[Altera_Forum]

--- Quote Start ---  I agree " overall design and constraints may also affect fitting inside ips", but it seems is difficult to conclude a common way that how to fix when we confront the timing issues inside IPs.  --- Quote End ---    Assume that the Altera IP is perfect, and even if you had written the module yourself with intimate understanding of all the inner workings, at this stage no further source modification would have any impact at all on your result. This sets you up mentally to go about fixing the problem using all of the other techniques and tools from the training and documentation.  For what it's worth, your requirements and description of your system isn't very clear, but if you're talking about having multiple DDR3 soft controllers inside a single Qsys system, one common trick is to put Avalon-MM pipline and/or clock crossing bridges in front of the DDR3 avalon slave port. My experience has been that Fmax in the soft DDR3 may be higher when connected only to a single master.

[Altera_Forum]

--- Quote Start ---  Assume that the Altera IP is perfect, and even if you had written the module yourself with intimate understanding of all the inner workings, at this stage no further source modification would have any impact at all on your result. This sets you up mentally to go about fixing the problem using all of the other techniques and tools from the training and documentation.   --- Quote End ---    In my design, I did use a Avalon-MM to connect Nios as master, then another side, conects with multiple clock crossing bridge then DDR3 controller. But I don't understand what you mentioned "at this stage no further source modification would have any impact at all on your result", do you mean in this case, the modification in RTL level won't help, I have to use tool to have a better job in synthesis, fitter?  Thanks.