Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
У меня в черновиках уже год лежит недописанная статья, основной посыл которой — в настоящее время констрейны на I/O уже практически не нужны. Потому что
Понятное дело, что это весьма грубое приближение, но тем не менее.
- Медленные интерфейсы типа SPI на 1-20 МГц работают by design;
- Гигабитные интерфейсы являются самосинхронизирующимися (моя прелесть!);
- Скоростные интерфейсы имеют варьирование параметров едва ли не большее чем период частоты. То есть формально они вообще не работоспособны. В итоге их реализуют за счет калибровки-автоподстройки по передаваемым паттернам;
- И остаются только всякие умирающие среднескоростные интерфейсы на сотню-другую мегагерц для которых калибровка не предусмотрена протоколом. И с ними приходится мучиться (кому приходится).
Понятное дело, что это весьма грубое приближение, но тем не менее.
Собственно, для того, чтобы выйти на уровень неписания констрейнов, вам пришлось пройти путь их написания, ведь так? Сначала понять что вообще физически такое эти ограничения и почему интерфейсы вообще могут не работать. И не соглашусь например насчет первого пункта. Если ляпать медленный интерфейс совсем не глядя, то вполне возможно выйти из рабочих окон. Например, если на линии медленного интерфейса стоят гальваноразвязки. Туда-обратно двойная задержка 40 нс — и вот уже приходится разбираться и считать времянки.
Мне бы хотелось почитать вашу статью об этом, надеюсь что вы ее допишите.
Мне бы хотелось почитать вашу статью об этом, надеюсь что вы ее допишите.
Собственно, для того, чтобы выйти на уровень неписания констрейнов, вам пришлось пройти путь их написания, ведь так? Сначала понять что вообще физически такое эти ограничения и почему интерфейсы вообще могут не работать.
Тут как с программистами — почти никто давно не занимается ручным выделением памяти и написанием кода на ассемблере, но знание того, как это работает, и умение написать вручную может существенно облегчить жизнь в частных случаях.
И остаются только всякие умирающие среднескоростные интерфейсы на сотню-другую мегагерц
Да ладно вам, тот же Gigabit Ethernet живее всех живых. На форумах Xilinx постоянно мурыжат тему констрейтов под этот интерфейс. Хоть местные гуру несколько раз её разбирали до болтов и гаек, она продолжает всплывать.
В целом утверждение верное, «но есть нюансы». Хотя наверное подходит под п.4 чуть более чем полностью, но тем не менее :)
В одном из проектов, в котором я участвовал полтора года назад, реализовывался SPI-интерфейс на частоты в районе 200-400 МГц, при этом интерфейс тянулся на множественные устройства от мастера через несколько переходных плат, и суммарная задержка по CLK->MISO набегала где-то в два периода синхросигнала. Вследствие чего как раз понадобилось всё, описанное в статье. В частности, итоговая реализация предполагала приём данных на задержанном клоке, такой метод реализуется в т.ч. с помощью макро-IP на платах Xilinx, насколько помню.
В одном из проектов, в котором я участвовал полтора года назад, реализовывался SPI-интерфейс на частоты в районе 200-400 МГц, при этом интерфейс тянулся на множественные устройства от мастера через несколько переходных плат, и суммарная задержка по CLK->MISO набегала где-то в два периода синхросигнала. Вследствие чего как раз понадобилось всё, описанное в статье. В частности, итоговая реализация предполагала приём данных на задержанном клоке, такой метод реализуется в т.ч. с помощью макро-IP на платах Xilinx, насколько помню.
Хотелось бы статью с примером.
Например, пишем простой SPI интерфейс и для него описываем констрейны.
И второе. В описанных схемах не проще ли было бы сделать так, чтобы передатчик выдавал данные на спаде CLK (задний фронт), а приемник фиксировал их на нарастании сигнала CLK (передний фронт). Тогда часть проблем с метастабильностью регистра ушла бы. Еще где-то читал, что это не очень удачная практика, так как большинство FPGA вносят задержку на инверсию сигнала CLK и лучшей практикой является организация двух сигналов CLK, сдвинутых на 180° по фазе относительно друг-друга.
Например, пишем простой SPI интерфейс и для него описываем констрейны.
И второе. В описанных схемах не проще ли было бы сделать так, чтобы передатчик выдавал данные на спаде CLK (задний фронт), а приемник фиксировал их на нарастании сигнала CLK (передний фронт). Тогда часть проблем с метастабильностью регистра ушла бы. Еще где-то читал, что это не очень удачная практика, так как большинство FPGA вносят задержку на инверсию сигнала CLK и лучшей практикой является организация двух сигналов CLK, сдвинутых на 180° по фазе относительно друг-друга.
Поддержу DX168B. В будущих статьях хочется перейти от теории к практике. Какие проблемы бывают и как с ними с помощью констрейнтов можно справиться.
Еще можно было бы описать и интерфейсы с двунаправленными линиями связи. С одной стороны формулы можно выписать по приведенным примерам. С другой, из-за взаимного влияния (типа выкручиваешь в одном месте — загибается в другом) приходится искать неописанные тут решения, типа, использовать разные фазы на двух устройствах (как опять написал предыдущий комментатор). Хотя я опять перешел к практике! ;)
Еще можно было бы описать и интерфейсы с двунаправленными линиями связи. С одной стороны формулы можно выписать по приведенным примерам. С другой, из-за взаимного влияния (типа выкручиваешь в одном месте — загибается в другом) приходится искать неописанные тут решения, типа, использовать разные фазы на двух устройствах (как опять написал предыдущий комментатор). Хотя я опять перешел к практике! ;)
>Рис. 4. Передача данных наружу по собственному клоку ПЛИС.
Ноу оффенс, но я всю жизнь считал, что это и есть source synchronous transfer — работа интерфейса по передаваемому вместе с данными клоком. А у вас все наоборот. Давайте загуглим:
en.m.wikipedia.org/wiki/Source-synchronous
Соответственно, то, что у вас названо SS — это просто работа от глобального клока.
Ноу оффенс, но я всю жизнь считал, что это и есть source synchronous transfer — работа интерфейса по передаваемому вместе с данными клоком. А у вас все наоборот. Давайте загуглим:
en.m.wikipedia.org/wiki/Source-synchronous
technique of having the transmitting device send a clock signal along with the data signals.
Соответственно, то, что у вас названо SS — это просто работа от глобального клока.
Спасибо за замечание. Я опирался на другой источник, в котором сказано:
«System Synchronous — это интерфейсы, в которых тактовая частота идет непосредственно с ПЛИС на интерфейсное устройство. Source Synchronous — это интерфейсы, в которых тактовая частота идет от отдельного генератора (в качестве которого может выступать само интерфейсное устройство) к ПЛИС.». Причем подчеркивалось, что это не зависит от направления передачи данных. И слово source понимается в этом определении как внешний источник синхронизации, а не источник данных.
Ваше замечание заставило меня усомниться. Сейчас поищу другие источники, разберусь.
«System Synchronous — это интерфейсы, в которых тактовая частота идет непосредственно с ПЛИС на интерфейсное устройство. Source Synchronous — это интерфейсы, в которых тактовая частота идет от отдельного генератора (в качестве которого может выступать само интерфейсное устройство) к ПЛИС.». Причем подчеркивалось, что это не зависит от направления передачи данных. И слово source понимается в этом определении как внешний источник синхронизации, а не источник данных.
Ваше замечание заставило меня усомниться. Сейчас поищу другие источники, разберусь.
Посмотрел мануалы Альтеры и там понимают под Source Synchronous источник случай, когда источник данных является и источником клок. Противоположностью называется Common Clock Network. Уберу совсем английские термины, чтобы не путаться наверняка.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Временные ограничения для внешних интерфейсов ПЛИС