Timing Violations workaround strategy

First, short remark concerning forum policy ... quite frequently a posted message doesn't appear immediately, but is retained for approval.

And this approval can be as long as ... 24h. I asked for this issue to forum administration, but still didn't receive any answer.

It occurred once more time yesterday: I answered to Tricky, but my message is still "in approval".

Well let's return to subject ...

--- Quote Start ---

1. Check if there are any ignored constrains.

--- Quote End ---

Yes, there are 2 ignored constraints (as I've already exposed yesterday in my non-posted message).

Trying to resolve the violations issues on sdram data bus (blue cadre on the screenshot in 1st message),

I was thinking (probably wrongly) that the best solution here is to introduce multicycles, i.e. "open the window", using terminology of the ryan scoville's timequest user guide (at least as I understood it).

Looking at the Waveform diagram in "Timing Report" for SDRAM data [6] (left part of bottom screenshot in the 1st message), one can believe that problem can be fixed by shifting forward the "latch edge".

That is what I tried to do with the following commands:

set_multicycle_path -setup -to [get_nodes {nios_led2_sdram:u0|nios_led2_sdram_sdram:sdram|za_data[*]}] 2

set_multicycle_path -hold -to [get_nodes {nios_led2_sdram:u0|nios_led2_sdram_sdram:sdram|za_data[*]}] 1

And these commands were ignored by TimeQuest parser.

--- Quote Start ---

2. Check if there are any unconstrained paths.

--- Quote End ---

No, after applying your suggestions (in another thread), there is no more unconstrained paths

--- Quote Start ---

3. Check clock transfers and make sure that there are no invalid clock transfers analysed.

--- Quote End ---

At 1st glance NO ... at least there is nothing "in red"

--- Quote Start ---

Violations between unrelated clocks or paths - usually can be solved by setting clock groups or setting false path between unrelated paths.

Violations in register-to-register level - usually caused by bad coding style, go back to your VHDL/Verilog code and fix it.

Violations in I/O - can be solved by using PLL and clock phase shift, clock inversion ect.

--- Quote End ---

In my simple case there are only a few clocks: external clock, 2 PLL generated clocks and JTAG clock - altera_reserved_tck.

Concerning coding style - actually there is no code, only Qsys module instantiation.

So, perhaps, my case correspond to "Violations in I/O" ?

Here I have 2 questions:

1. The PLL module in Qsys has 2 ouput and one of them is phase-shifted. This phase shift isn't reflected in .SDC file ... I beleived that TimeQuest can handle this shift without .SDC modification (again probably I'm wrong)

2. So even in this case multicycles can't be considered as "reliable remedy"

Thanks once more.