Всем привет!

Имеем
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 регистрами, то для шины это надо будет учесть для значительно большего числа регистров и ручные способы уже недопустимы.

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

картинка для увеличения понятности

Отвечу вообще не по теме.
Если вы хотите работать как прозрачный прокси с подменой на пути spi master-slave, то про синхронную схему можно забыть в тех случаях, когда клок прокси сопоставим по частоте с клоком spi. В таком случае делаем счетчик битов и комбинационку на каждый разряд, профит.

Если же у вас Fproxy >>> Fspi, то тоже не понятно откуда является проблема. Клок мастера spi элементарно синхронизируется с Fproxy, и работа с spi-slave идет синхронно с Fproxy, соотв-но можно разложить сигналы по тактовой сетке как угодно.

Если же вы делаете непрозрачный прокси, то работайте со слейвом от имени прокси и кидайте в буфер актуальное значение, которое по запросу мастера будете отдавать.

Даже если забыть вообще о прокси. Для медленных SPI где между выставлением и захватом данных проходит вечность проблем нет, а для быстрых она либо есть, либо я ее придумал.

Реальность такова, если смотреть на картинку в момент GCLK2 наружу лезет клок, через T_out оно приходит на слейв, через
TOut + TSlave появляются данные, через TOut + TSlave + TIn данные приходят обратно.
Если T_GCLK2 + (TOut + TSlave + TIn) - T_GCLK1 меньше периода клока, все получиться, если больше не получится. А у меня нет инструмента позволяющего учесть T_GCLK2 - T_GCLK1, то есть разницу между клоками на 1 и 2 триггере.
TOut, TIn я могу задать,
TSLave - знаю из документации, А оценки разницы клоков нету, и в этих констраинах она не учитывается...

OFFSET IN предполагает задачу времянки относительно внешнего клового сигнала, а не внутреннего который схема генерит сама...

Приветствую!



Учитывается - skew для клокового дерева учитывается автоматом при контроле constains - посмотрите любой time репорт.


Успехов! Rob.

Не могу с Вами согласиться так как это только если есть источник и цель пути и оба этих элемента висят на клоке. А в рассматриваемом случае 2 ячейки формально независимы, и потому между ними никто не рассматривает SKEW, ведь FPGA то не знает что данные на входе одной появляются от действий другой... это же внешняя схема

А есть какие-то данные сколько clock skew через весь кристалл? Хотя бы оценочные?
То есть насколько может разбежаться по времени клок на 2 разных элементах в разных частях плис, в одной части плис?

Может стоит вначале принять данные, а потом отправить.
Тогда будет синхронная схема...
Как бы так коректнее и логичнее (мое мнение)


Тут 2 SPI - 1 мастер и 1 slave + промежуточная логика подмены данных и не забываем про использование фифо при кросдомене

Тогда на каждый SPI накладывается отдельный констрейн

Да, будет задержка на несколько тактов (подмена + передача данных с одного SPI в другой)

Да но только мастер SPI может запросить данные и ждать их на следующем клоке, и на схеме с 2 SPI все развалится.
На самом деле вопрос даже не в пробросе данных, можно забыть вообще об исходной задаче.

SPI мастер - прием данных.
Мы генерим клок, это выходной сигнал. По нему slave отдает данные это входной сигнал. Мы внутри мастера защелкиваем данные.
Задача - проверить что данные успели выставиться на входе верными при заданной частоте клока.

Приветствую!



Xilinx наверное меня съест раз я раскрываю его самые страшные секреты
ds182 Kintex-7 FPGAs Data Sheet: DC and AC Switching Characteristics Table 40: Duty Cycle Distortion and Clock-Tree Skew

Успехов! Rob.

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

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


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



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

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





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



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

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

Это как я понимаю позволит минимизировать время ввода-вывода, а вот позволит ли это что-то контролировать и главный вопрос надо ли что-то контролировать еще....

Конечно надо. Разводку каждой платы, на которой это все будет стоять