Do let me know if I've missed something, but all the example Quartus projects for the MKR Vidor 4000 that I have seen are missing input timing constraints for the data bus from the SDRAM to the FPGA.
The vidor_s.sdc files I have seen do have constraints for the output timings (signals from the FPGA to the SDRAM), although these are just the SDRAM's setup and hold timings, and no allowance has been made for differences in the propagation delay of the output signals relative to the clock signal. I don't know whether these delays have been carefully matched on the PCB, or if this has just not been considered.
But there are no timing constraints at all for the data signals coming back from the SDRAM to the FPGA. As well as involving the output delay specs of the SDRAM, these constraints also need to include the sum of the clock and data signal propagation delays on the PCB, so it is more important to have PCB delay information here than for the output timing constraints.
This wouldn't matter so much if there was plenty of timing slack, but the example projects clock the SDRAM interface at 100MHz, and when I tried to add a full set of timing constraints using estimated PCB delays I was left with a minimum timing slack of around 0.5ns for the inputs and outputs, and this was after tuning the PLL to balance out the slack between the input and output signals. The timing seems so tight that I don't really want to be going on guesswork.
The information I think we need, to properly define the timing constraints on the SDRAM interface, is
PCB propagation delay on the clock signal from the FPGA to the SDRAM; ideally a min and max figure allowing for PCB fabrication variations
Minimum PCB propagation delay for the shortest non-clock signal between the FPGA and SDRAM
Maximum PCB propagation delay for the longest non-clock signal between the FPGA and SDRAM
Separate min and max delays for the dq bus would be a bonus.
I don't know what the chances are of getting this information, since the manufacturer seems to have stopped providing support in early 2020, but I'll ask anyway.
If it was my own PCB I would get the trace lengths from my PCB design software, and calculate a delay-per-inch value from the PCB stackup (this depends on the thickness and DK of the dielectrics in use), and multiply them to get the PCB propagation delays.
If I use the MKR Vidor 4000 module, I don't have access to the necessary information, so I'm calling on the manufacturer to provide it (either the trace length and PCB stackup info, or the timings calculated from them, I don't mind).
Without this information nobody can properly constrain the SDRAM signal timings, and the reliability of the interface is at risk.
Giving up on getting any support on this, I decided to make some conservative estimates of the minimum and maximum trace delays for the purpose of timing checks. Based on the relative placement of the FPGA and SDRAM, I reckon
The clock trace is somewhere between 8.5 and 13mm
The data bus (SDRAM outputs, FPGA inputs) has min trace length of 7.5mm, max of 18mm
The full SDRAM signal set (SDRAM inputs, FPGA outputs, excluding clock) has min trace length of 7.5mm, max of 18.5mm
And playing around with likely PCB stackups, I estimate the propagation delay of the traces is somewhere in the range 5.8 to 7.2 ns per metre. Multiplying the min and max lengths by the min and max prop. delays, the trace delays are actually quite short compared to the SDRAM setup and hold times and the FPGA internal delays, which means the exact trace delays are not that important. You won't get much better results by knowing the trace delays more exactly, so a conservative estimate is fine.
More surprisingly though, when I actually applied a full timing spec for the inputs and outputs and clock, I found that the fastest clock speed I could get timng closure on was only about 48MHz. And it required tuning of the PLL delay on the SDRAM clock to even get that. So it seems that while the example design running at 100MHz did run in practice, a proper worst-case timing analysis says it should really be run much slower.