Временные констраины синхронных интерфейсов, Что надо и не надо констраинить и как это делать Опции

[Golikov A.]

Всем привет!

Имеем
SPI интерфейс и синхронный интерфейс с шинной данных.

FPGA данные по SPI принимает - передает как мастер, и пробрасывает через себя (от внешнего мастера, внешнему слейву), подменяя некоторые данные.

Интересует как это все правильно в необходимой степени законстраинить, пусть будет для Xilinx.

1. Для выходных сигналов я могу написать констраин
OFFSET = OUT 10 ns AFTER "global_clk" REFERENCE_PIN "spi_clk";
тут все понятно, я хоть и пишу относительно входного клока, но указывая опорный пин, все пересчитается для него и все счастливы.
1.1 что делать с входными сигналами? Входного то клока относительно которого написать констраин нету!
Формально мне надо обозначит путь данных от внешней ноги до защелкивающего регистра, с учетом пути данных от выходного клокового регистра.
То есть когда я меняю регистр управляющий клоком из 1 в 0, через какое-то время внешнее устройство увидит этот сигнал, выставит по нему данные, и данные попадут на вход регистра приемника.

Вот как такое правильно описать?
Пробовал написать FROM:TO от FFs до PADs и обратно, но в таком раскладе не учитывается разница между временем прихода клоков на выходной регистр и входной.


2. При пробросе данных возникает проблема и с выходными данными. Мне надо чтобы внешний мастер общался с внешним слейвом, а я иногда влезал в этот обмен и подменял данные.

Тут уже нет опорного выходного клока, я формирую и клок и данные, копируя поведение мастера, и может быть такая штука. Я защелкиваю данные в регистре выходных данных, и данные лезут наружу. Потом я защелкиваю клок в регистре, и они опять же идет наружу. Я могу обозначить время от регистра до ноги, но я опять не могу задать разницу между клоками этих регистров, и теоретически может так оказаться что сигнал клока придет не после, а до данных. И вот что блин с этим всем делать?

Какова вообще в цифрах может набегать разница во времени, когда поднимается клок на разных регистрах?

3. Ну и на закуску, если у нас не SPI а параллельный синхронный интерфейс. Тут же надо еще следить за тем чтобы шина не расползлась до клока. То есть если даже есть какой-то способ руками учесть разницу прохождения клока между 2 регистрами, то для шины это надо будет учесть для значительно большего числа регистров и ручные способы уже недопустимы.

Вот собственно такие мысли меня одолевают.... Кто что посоветует?

[Golikov A.]

А как пользоваться этой табличкой?

Вот я взял даташит на Spartan6, нашел там запись
TCKSKEW - Global Clock Tree Skew
с пометкой

The TCKSKEW value represents the worst-case clock-tree skew observable between sequential I/O elements. Significantly less clock-tree skew exists
for I/O registers that are close to each other and fed by the same or adjacent clock-tree branches. Use the Xilinx FPGA Editor and Timing Analyzer
tools to evaluate clock skew specific to your application

в таблице вижу по грайдам

XC6SLX100 0.22 0.22 0.22 0.21 ns

для моего грейда -0.22

А теперь я смотрю отчет о после разводки проекта

+---------------------+--------------+------+------+------------+-------------+
| Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max Delay(ns)|
+---------------------+--------------+------+------+------------+-------------+
| clk_40MHz | BUFGMUX_X2Y4 | No | 3439 | 0.690 | 2.343 |
+---------------------+--------------+------+------+------------+-------------+
| clk_60MHz | BUFGMUX_X2Y2 | No | 721 | 0.141 | 1.809 |
+---------------------+--------------+------+------+------------+-------------+
| clk_100MHz | BUFGMUX_X3Y13| No | 97 | 0.148 | 1.815 |
+---------------------+--------------+------+------+------------+-------------+

* Net Skew is the difference between the minimum and maximum routing
only delays for the net. Note this is different from Clock Skew which
is reported in TRCE timing report. Clock Skew is the difference between
the minimum and maximum path delays which includes logic delays.

и что теперь делать? Кому верить? Уже в 3 раза больше даташита, при 30% загрузке кристалла, или это я не то смотрю или это я не то понимаю?



А кто нибудь смог воспользоваться констраином
OFFSET = OUT value AFTER in_clk REFERENCE_PIN?
Я смог добиться чтобы reference_pin не игнорировался в тайминг анализе, но он никак не меняет времянку... то есть все равно OFFSET OUT считается как (clock path + data path + uncertainty)
без какого-либо учета клокового пути до регистра который делает REFERENCE_PIN и пути выхода этого регистра наружу...

[Mad_max]

А что насчет того чтобы для двух регистров (t1 и t2 на картинке) поставить constrain IOB = TRUE и поместить их в IO блок максимально близко к падам.
В таком случае и разница в clock skew для этих регистров будем минимальная и constrains от регистра до пада и от пада до регистра ставить не надо.
Нужно только правильно рассчитать "доверительное" окно, когда на регистре t2 можно захлопывать данные.