Timequest SDRAM input: unconstrained and working vs closed and broken

https://alteraforum.com/forum/attachment.php?attachmentid=14800&stc=1 Hi folks,

I have an interesting problem that I'm failing to make headway with. I'm working on a Cyclone V design (DE0-CV platform, but also reproducible on Cyclone IV) using single data rate, edge aligned SDRAM and get corrupted data back sometimes leading me to believe that I'm not meeting timing. This also seems to be very sensitive to different place and route - changing the design slightly or the PLL phase shift can get things working again, but I really want something that works reliably.

The basic setup is:

• 50 MHz input clock

• ALTPLL in normal mode (also tried source synchronous), first output 50MHz, -2.7ns phase shift to SDRAM, second output 50MHz 0ns phase shift to the rest of the logic

• Fast input/output registers for all SDRAM signals, no warnings about any of those being ignored except the signals that are static 0/1.

Simplified constraints are:

set_time_format -unit ns -decimal_places 3
create_clock -period 20.000 -name clk clk
derive_pll_clocks
set sdram_pll "SysPLL|altera_pll_i|general.gpll~PLL_OUTPUT_COUNTER|divclk"
set sys_clk   "SysPLL|altera_pll_i|general.gpll~PLL_OUTPUT_COUNTER|divclk"
derive_clock_uncertainty
set sdram_input_delay_min        2.7
set sdram_input_delay_max        6.5
set sdram_output_delay_min       -0.8
set sdram_output_delay_max       1.5
create_generated_clock 
        -name sdram_clk 
        -source $sdram_pll 
        
set sdram_outputs 
    s_addr
    s_cs_n
    s_data
    s_banksel
}]
set_output_delay -clock sdram_clk -min $sdram_output_delay_min $sdram_outputs
set_output_delay -clock sdram_clk -max $sdram_output_delay_max $sdram_outputs
set sdram_inputs }]
set_input_delay -clock sdram_clk -min $sdram_input_delay_min $sdram_inputs
set_input_delay -clock sdram_clk -max $sdram_input_delay_max $sdram_inputs
set_multicycle_path -setup -end -from sdram_clk -to  2
set_multicycle_path -hold -end -from sdram_clk -to  1

When the design works it seems robust, when it fails it's reproducible but not for every read. Things that have made the problem go away include:

• Removing the multicycle paths: this results in a setup violation of 7-9ns depending on phase shift, but sensitive to PAR

• Disabling OPTIMIZE_HOLD_TIMING: the design still meets timing and works reliably, but at a lower Fmax

The hold timing optimization makes me wonder if it's hold related but as the design still meets timing I don't have a lot to go on. I've attached a setup report for the SDC above which looks right to me - the data is launched and then latched a full period later, and then another build with the multicycle removed showing the timing failure. But the one that meets timing gets corrupted data, the one that fails timing works reliably. I've been through lots of old posts about this sort of thing and many of the Altera app notes, but can't seem to make any progress, so hopefully it's something fairly fundamental.

Any pointers most gratefully received!

Jamie