Цитата(bogaev_roman @ Nov 30 2016, 13:57)
у vivado есть две временные модели - fast|slow, и в зависимости от технологического разброса/температуры и напряжения пути будут иметь разную задержку - для сетапа и холда рассчитываются они по разному. Таким образом производитель гарантирует работоспособность всех чипов в заданном температурном диапазоне и просадках по питанию.
я так понял, что не получится выполнить тайминги с моими условиями. я на свой вопрос получил на форуме xilinx такой ответ
Цитата
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...
Изменить временные требования я не могу. поэтому приходится что-то делать с граничными значениями. xilinx проводит проверку в slow process corner (высокая температура, низкое напряжение) и fast process corner (низкая температуры, высокое напряжение). Насколько схема будет работоспособна без этих граничных условий. как это можно проверить? Если я задаю
Код
config_timing_corners -corner fast -delay_type none
то у меня остаются ошибки в slow. и после задания
Код
config_timing_corners -corner slow -delay_type none
ошибки исчезают. но проводится ли какая-то проверка в этом случае?
выполнение таймингов, идеология расчетов ,xilinx, vivado
Nov 30 2016, 08:47
