Constrained clock appears as unconstrained input

--- Quote Start ---

Yes, I know that with PLL it works, but actually I'm trying to do without PLL, as board manufacturer states that at 50MHz no phase shift needed between SDRAM chip clock and SDRAM controller clock.

So is it possible without PLL ?

--- Quote End ---

Yes and no...

In one of my designs, I do basically that. I feed a clock into a CPLD, which is used to generate some data, which is then fed to a DAC, together with the clock (from a CPLD I/O pin). It works, but obviously the clock skew inside the CPLD will vary between compilations, even though timing closure is achieved. And I get warnings that what I'm doing is not optimum with regards to jitter. None of that matters for my application; so, yes, it can work, depending on what you want.

In another design, I have an FPGA with SDR-SDRAM. Sounds more like your application. That SDRAM is more strict with regards to setup and hold time. In my case, it' was impossible to get timing closure without using a PLL that can fine-tune the clock phase. With another SDRAM controller, another SDRAM chip, another clock frequency, it might have worked without tweaking the phase. However, I have to mention that it practically works with a 180° clock phase (i.e. internally invert the clock, assume routing delay is negligible), even though the timing analyzer complains (I verified the functionality with a FSM that writes PRBS-patterns and reads them back). Why did I use a PLL then? Because that's a commercial product, where I cannot risk that some unit doesn't work because the timings hit the worst-case.

In conclusion, I agree with what sstrell wrote. Use a PLL, and use it as a zero-delay buffer. Get your timing constraints to work without warnings. If a timing violation occurs, one option might be to add some phase shift with the PLL instead of doing zero-delay.

Uh, well, unless you just want to play with some eval board. Then I personally would be a bit more pragmatic... you mentioned the board manufacturer's recommendation; if you have a way to verify the functionality of the SDRAM, and it just works, I would just call it a day. Sorry for ruining the fun of playing with the timing constraints then... :)

But I think we drifted away from the topic a bit, didn't we? The original problem was the SDC file that complained about unconstrained paths...?