Всем привет!
Имеем
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 регистрами, то для шины это надо будет учесть для значительно большего числа регистров и ручные способы уже недопустимы.
Вот собственно такие мысли меня одолевают.... Кто что посоветует?
Полная версия этой страницы: Временные констраины синхронных интерфейсов
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
картинка для увеличения понятности
Отвечу вообще не по теме.
Если вы хотите работать как прозрачный прокси с подменой на пути spi master-slave, то про синхронную схему можно забыть в тех случаях, когда клок прокси сопоставим по частоте с клоком spi. В таком случае делаем счетчик битов и комбинационку на каждый разряд, профит.
Если же у вас Fproxy >>> Fspi, то тоже не понятно откуда является проблема. Клок мастера spi элементарно синхронизируется с Fproxy, и работа с spi-slave идет синхронно с Fproxy, соотв-но можно разложить сигналы по тактовой сетке как угодно.
Если же вы делаете непрозрачный прокси, то работайте со слейвом от имени прокси и кидайте в буфер актуальное значение, которое по запросу мастера будете отдавать.
Если вы хотите работать как прозрачный прокси с подменой на пути 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 предполагает задачу времянки относительно внешнего клового сигнала, а не внутреннего который схема генерит сама...
Реальность такова, если смотреть на картинку в момент 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.
Цитата(Golikov A. @ Nov 18 2015, 13:37) 
...
TSLave - знаю из документации, А оценки разницы клоков нету, и в этих констраинах она не учитывается...
TSLave - знаю из документации, А оценки разницы клоков нету, и в этих констраинах она не учитывается...
Учитывается - skew для клокового дерева учитывается автоматом при контроле constains - посмотрите любой time репорт.
Код
Clock Path Skew: -0.218ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 1.817ns = ( 7.971 - 6.154 )
Source Clock Delay (SCD): 2.192ns
Clock Pessimism Removal (CPR): 0.157ns
Clock Uncertainty: 0.056ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
Total System Jitter (TSJ): 0.071ns
Discrete Jitter (DJ): 0.086ns
Phase Error (PE): 0.000ns
Destination Clock Delay (DCD): 1.817ns = ( 7.971 - 6.154 )
Source Clock Delay (SCD): 2.192ns
Clock Pessimism Removal (CPR): 0.157ns
Clock Uncertainty: 0.056ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
Total System Jitter (TSJ): 0.071ns
Discrete Jitter (DJ): 0.086ns
Phase Error (PE): 0.000ns
Успехов! Rob.
Не могу с Вами согласиться так как это только если есть источник и цель пути и оба этих элемента висят на клоке. А в рассматриваемом случае 2 ячейки формально независимы, и потому между ними никто не рассматривает SKEW, ведь FPGA то не знает что данные на входе одной появляются от действий другой... это же внешняя схема
А есть какие-то данные сколько clock skew через весь кристалл? Хотя бы оценочные?
То есть насколько может разбежаться по времени клок на 2 разных элементах в разных частях плис, в одной части плис?
То есть насколько может разбежаться по времени клок на 2 разных элементах в разных частях плис, в одной части плис?
Цитата(Golikov A. @ Nov 19 2015, 10:32)
Может стоит вначале принять данные, а потом отправить.
Тогда будет синхронная схема...
Как бы так коректнее и логичнее (мое мнение)
Цитата
FPGA данные по SPI принимает - передает как мастер, и пробрасывает через себя (от внешнего мастера, внешнему слейву), подменяя некоторые данные.
Тут 2 SPI - 1 мастер и 1 slave + промежуточная логика подмены данных и не забываем про использование фифо при кросдомене
Тогда на каждый SPI накладывается отдельный констрейн
Да, будет задержка на несколько тактов (подмена + передача данных с одного SPI в другой)
Да но только мастер SPI может запросить данные и ждать их на следующем клоке, и на схеме с 2 SPI все развалится.
На самом деле вопрос даже не в пробросе данных, можно забыть вообще об исходной задаче.
SPI мастер - прием данных.
Мы генерим клок, это выходной сигнал. По нему slave отдает данные это входной сигнал. Мы внутри мастера защелкиваем данные.
Задача - проверить что данные успели выставиться на входе верными при заданной частоте клока.
На самом деле вопрос даже не в пробросе данных, можно забыть вообще об исходной задаче.
SPI мастер - прием данных.
Мы генерим клок, это выходной сигнал. По нему slave отдает данные это входной сигнал. Мы внутри мастера защелкиваем данные.
Задача - проверить что данные успели выставиться на входе верными при заданной частоте клока.
Приветствую!
Xilinx наверное меня съест раз я раскрываю его самые страшные секреты
ds182 Kintex-7 FPGAs Data Sheet: DC and AC Switching Characteristics Table 40: Duty Cycle Distortion and Clock-Tree Skew
Успехов! Rob.
Цитата(Golikov A. @ Nov 19 2015, 10:32)
А есть какие-то данные сколько clock skew через весь кристалл? Хотя бы оценочные?
То есть насколько может разбежаться по времени клок на 2 разных элементах в разных частях плис, в одной части плис?
То есть насколько может разбежаться по времени клок на 2 разных элементах в разных частях плис, в одной части плис?
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 и пути выхода этого регистра наружу...
Вот я взял даташит на 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
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.
| 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 и пути выхода этого регистра наружу...
А что насчет того чтобы для двух регистров (t1 и t2 на картинке) поставить constrain IOB = TRUE и поместить их в IO блок максимально близко к падам.
В таком случае и разница в clock skew для этих регистров будем минимальная и constrains от регистра до пада и от пада до регистра ставить не надо.
Нужно только правильно рассчитать "доверительное" окно, когда на регистре t2 можно захлопывать данные.
В таком случае и разница в clock skew для этих регистров будем минимальная и constrains от регистра до пада и от пада до регистра ставить не надо.
Нужно только правильно рассчитать "доверительное" окно, когда на регистре t2 можно захлопывать данные.
Это как я понимаю позволит минимизировать время ввода-вывода, а вот позволит ли это что-то контролировать и главный вопрос надо ли что-то контролировать еще....
Цитата(Golikov A. @ Nov 19 2015, 13:55)
Это как я понимаю позволит минимизировать время ввода-вывода, а вот позволит ли это что-то контролировать и главный вопрос надо ли что-то контролировать еще....
Конечно надо. Разводку каждой платы, на которой это все будет стоять
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.