При этом Source Clock Path и Destination Clock Patch первые 3 составляющие пути одни и те же. Но считаются для Source Clock Path по максимально быстрому , а для Destination Clock Patch по максимально медленному. Собственно именно здесь и получается большая часть ошибки тайминга. Но ведь это один и тот же фронт в одно и то же время. И не может быть разного прохождения именно этих 3-х участков.

Но ведь это один и тот же фронт в одно и то же время. И не может быть разного прохождения именно этих 3-х участков

... в зависимости от технологического разброса/температуры и напряжения пути будут иметь разную задержку - для сетапа и холда рассчитываются они по разному. Таким образом производитель гарантирует работоспособность всех чипов в заданном температурном диапазоне и просадках по питанию. ... т.к. допустим при минус 40 градусах время распространения сигнала будет существенно отличаться от него же при плюс 100.

т.е. если что-то не так , то это "не так" одинаково скажется на данных и частоте. А дальше остальной путь, конечно, нужно считать по разному.

У Altera в TimeQuest есть вот такой параметр

Посмотрите что-то похожее у Xilinx.
Может быть, что этот параметр у Вас выключен.

- тактируемая частота обычно в кристалле идет по клоковой дорожке, задержки на которой отличаются от обычной дорожки, по которой идут данные, соответственно утверждение о том что при повышении температуры задержка на пути данных и пути частоты увеличатся на одинаковую величину ошибочно,

Вы бы привели полностью пути по расчету сетапа и холда для конкретного пути и сказали, какое место с Вашей точки зрения не корректно рассчитывается. А так на самом деле уточню пару моментов:

тут мне непонятно следующее. параметр clock pessimism на самом деле уравнивает время в точке раздвоения.

мне непонятны знаки времени до этой точки.

при этом если Destination Clock Patch считается по макс. времени , а Source Clock Path по миним. времени

clock pessimism должен бы вычитаться. но счет идет не так. но в любом случае с учетом clock pessimism время уравнено.

В Вашем случае clock pessimism получился отрицательным, почему - не знаю, надо у фиттера спросить.

Для setup есть запас и вроде бы он немного съелся. а для hold минус тоже должен уменьшиться, но он вырос. И только в 3-м проекте уменьшился. Но там уже setup не выполняется. Вот таблица.

setup и hold взаимосвязаны, если у Вас будет увеличиваться запас по setup, то будет уменьшаться запас по hold - это нормально. Теперь вопрос - что на максимальное быстродействие для DDR написано в даташите для конкретного чипа?

..И я решил подвигать частоту, идущую на данные. ...

Кстати, распиновка у Вас фиксированная? Смотрю путь тактовой частоты - начало в координате x0y1 (это для клок контрола), а конец x0_y174, для данных x0_y192. Попробуйте вообще отвязать от пинов или подвинуть их ближе друг к другу и к переходу на клоковое дерево.

Можно еще попробовать частоту пускать на прямую - без перехода на клоковый буфер.

Лучше буферы в данные добавлять.

но когда я ставлю 1 bufg ( 1-й ---> 2-й) , то setup - запас уменьшается 0.867 ->0.656 , а hold запас тоже уменьшается -0.455 -> -0.709

В этих выходных буферах есть программируемая задержка (у артикса в некотрых банках есть такая возможность)?

у vivado есть две временные модели - fast|slow, и в зависимости от технологического разброса/температуры и напряжения пути будут иметь разную задержку - для сетапа и холда рассчитываются они по разному. Таким образом производитель гарантирует работоспособность всех чипов в заданном температурном диапазоне и просадках по питанию.

From your constraints you are asking the tools to provide an edge aligned DDR interface with no more than -100ps to +300ps of skew. The tools are telling you (clearly and categorically) that it can't be done.

Without the ODDR, the tools are telling you that the total violation (setup slack + hold slack) is consistently around 980ps, meaning that it cannot give you a skew of less than 980ps plus the 400 you are asking for (around 1300ps of skew).

With the ODDR, the total violation is decreased - its around 450ps plus the 400 you are asking for, so 850ps.
So, no matter what, this will fail. From these numbers alone it is clear that there is no phase that can meet both the setup max and min skew. Furthermore, you are adjusting the skew in increments of 30 degrees - so 1/12 of your clock period. At 400MHz, this is therefore increments of 208ps - again, this is confirmed by your results (the difference in timing between, say, 90deg and 120dec is moving 208ps of slack from setup to hold). You also get into some launch/capture edge changes as you move from 0degrees to 30degrees (which can be fixed, but is not the root of your problem).

If you want to minimize skew, forget about trying to use different clocks on different phases of the MMCM - clock both the forwarded clock and forwarded data on the same clock using the same BUFG. This will minimize the skew (but likely still won't meet your requirements). Using different outputs of the MMCM add skew (about 200ps total) and using different BUFGs adds a fair bit of additional skew (as compared to using a single BUFG).

You might get (slightly) better results using a BUFH instead of a BUFG if your MMCM and all your outputs are in the same bank. There might even be a way to use a BUFIO, which could be slightly better yet. But, again, its not likely that any of these are going to meet your tight requirement.

That being said, Vivado is fairly pessimistic in these situations. The way it handles "on chip variation" is chip wide; the difference in timing between the longest and shortest paths it uses for timing (which is really what is creating all this skew) is the same ratio, regardless of whether the two structures are right beside each other or on opposite corners of the chip. So, if your forwarded clock and data are all in the same bank (ideally with the clock in the middle of the cluster of data), then the skew is going to be better (maybe even a fair bit better) than what the tools predict. Unfortunately, no one can really tell you "how much better".

So, if you really need the tightest possible skew, then just put everything in the same bank and use the same clock to clock both the forwarded clock (using the ODDR) and the output data (using an ODDR or OSERDES) - nothing you can do in the FPGA is better than that. If that isn't good enough, then (basically) you are out of luck...

ошибки исчезают. но проводится ли какая-то проверка в этом случае?

Раз уж подняли тему констейнов.... Не могли бы вы подсказать можно ли констнейны задавать кусками ?
Например у меня есть 3 модуля, которые я объединяю в модуле верхнего уровня. Могу ли я написать констрейны для каждого из модулей ? Или я должен писать только для верхнего уровня ?

Вивадо и квартус поддерживают в ограничениях стандарт sdс. Ни с какими ограничениями в задании constraint в подмодулях я не сталкивался. Нужно только следить за иерархической структурой - если название поменяется или сама структура проекта, то их придется или переназначать или переписывать пути.

...А как мне входные и выходные порты этих модулей обконстрейнить ? ...