DS 0 20 июля, 2017 Опубликовано 20 июля, 2017 · Жалоба Как побороть ситуацию, при которой Vivado "нагоняет" искусственную задержку на входных сигналах больше периода клока ? Клок задерживается на BUFG, поэтому, с точки зрения Vivado, строб попадает на "предыдущий" клок. Но поскольку клок непрерывный, это не имеет никакого значения. С другой стороны, если поставить false path или maxdelay, то можно попасть в область нестабильности - проверки не будет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bogaev_roman 0 20 июля, 2017 Опубликовано 20 июля, 2017 · Жалоба Как побороть ситуацию, при которой Vivado "нагоняет" искусственную задержку на входных сигналах больше периода клока ? Клок задерживается на BUFG, поэтому, с точки зрения Vivado, строб попадает на "предыдущий" клок. Но поскольку клок непрерывный, это не имеет никакого значения. С другой стороны, если поставить false path или maxdelay, то можно попасть в область нестабильности - проверки не будет. С формальной точки зрения он делает все правильно, посмотрите в сторону мультициклов (как задать в вивадо - не знаю). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
TRILLER 0 20 июля, 2017 Опубликовано 20 июля, 2017 · Жалоба С ультраскейл не работал, однако бегло глянув на ug572, я бы попробовал захватывать данные клоком не с глобального буфера, а непосредственно с пина. "Thus, the 7 series regional clock buffers have been replaced by new clock buffers with more global reach while automatically utilizing local clock buffers for local distribution of the clocks." Идея, возможно, в том, чтобы люди жали на кнопки и ни о чём не думали.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DS 0 20 июля, 2017 Опубликовано 20 июля, 2017 · Жалоба Увы, мне надо два разных региона синхронизировать потом. Multicircle с 0, такое ощущение, что работает неправильно. Т.е. отсчитывать он начинает от правильного фронта, но строит что-то жуткое, и радостно рапортует от промахе больше, чем на период. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DS 0 21 июля, 2017 Опубликовано 21 июля, 2017 · Жалоба set_multicycle_path правильно работает для входов, если проделать неочевидные манипуляции с hold. Научился управлять через него. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bogaev_roman 0 21 июля, 2017 Опубликовано 21 июля, 2017 · Жалоба set_multicycle_path правильно работает для входов, если проделать неочевидные манипуляции с hold. Научился управлять через него. Вообще, если это истинно синхронный интерфейс с стробирующим входным клоком, то можно еще попробовать воспользоваться ограничениями set_input_delay - max/min и Ваш период к этим значениям прибавить. Таким образом, временной анализатор будет считать, что данные в нулевой точке анализа будут задержаны на один период. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dimidrol 0 21 июля, 2017 Опубликовано 21 июля, 2017 · Жалоба А виртуальный клок не для этого придуман? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DS 0 21 июля, 2017 Опубликовано 21 июля, 2017 · Жалоба Есть забавная вещь с прибавлением - убавлением лишнего периода клока при расчете hold (то ли глюк, то ли на всякий случай). Т.е. просто прибавление времени или цикла вызывает схождение роутера с ума на holdе. Поэтому работает только мультицикл с ручным выставлением hold. Виртуальный клок нужен в основном для наглядности работы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Beby 8 22 июля, 2017 Опубликовано 22 июля, 2017 · Жалоба К сожалению, в обсуждении этой темы я не заметил конкретных цифр: периода тактовой, величин задержек в BUFG (для обоих крайних случаев), да и про данные, которые необходимо принимать - тоже мало что сказано. А частичное описание проблемы, типа: Клок задерживается на BUFG, поэтому, с точки зрения Vivado, строб попадает на "предыдущий" клок. Т.е. просто прибавление времени или цикла вызывает схождение роутера с ума на holdе.очень похоже на проблему, с которой я сталкивался в ISE при работе с Virtex-6 LX240T/SX315T: огромная неопределённость прохождения сигнала по BUFG. Для расчёта Setup бралась величина от 3 до 5 нс (от ПЛИС зависело), а для расчёта Hold - около 0.5 нс. Естественно, при временном анализе проекта для передачи данных где-то на 200 MT/s получалась херня: по Setup улетаем на следующий период, а по Hold остаёмся в текущем. У Вас, случаем, не подобная ситуация ? И, пожалуста, если не сложно, укажите конкретные цифры. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DS 0 22 июля, 2017 Опубликовано 22 июля, 2017 · Жалоба Тактовая 300 Мгц, внутри местами 600 Мгц. Проблема в способе отсчета фронта для hold по умолчанию - это описано в документации. Когда набегает задержка, сравнимая с периодом, это приводит к ошибке, если явно не задавать. Это, кажется, Vivado-специфичная вещь. И второе, что не описано - если используется PLL с обратной связью через BUFG (phase aligned), похоже, для расчета setup прибавляется целый период, а при расчете hold - не прибавляется. (Я и от входного клока пробовал тактировать, и от PLLльного). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Beby 8 22 июля, 2017 Опубликовано 22 июля, 2017 · Жалоба И второе, что не описано - если используется PLL с обратной связью через BUFG (phase aligned), похоже, для расчета setup прибавляется целый период, а при расчете hold - не прибавляется. (Я и от входного клока пробовал тактировать, и от PLLльного).Вот я как раз и хотел посоветовать работать от PLL'ного Clock'а, с компенсацией кривизны BUFG, за счёт обратной сзязи. Но без конкретных цифр, это было бы неправильно. Проблема в способе отсчета фронта для hold по умолчанию - это описано в документации. Когда набегает задержка, сравнимая с периодом, это приводит к ошибке, если явно не задавать. Это, кажется, Vivado-специфичная вещь.К сожалению, с Vivado-специфичными бякостями я пока помочь не смогу - мне ещё не приходилось работать с Vivado. Так случилось, что сейчас меня используют на схемотехку вокруг ПЛИС (в т.ч. US/US+), а вот до внутренностей у меня руки пока ещё не дошли: есть другие люди, которые могут работать внутри ПЛИС и совсем не могут проектировать внешнюю обвязку. Тактовая 300 Мгц, внутри местами 600 Мгц.И по такой входной частоте проконсультироваться не у кого из знакомых: либо передаём совсем медленные сигналы (до 50 MT/s), либо уже используем более высокоскоростные интерфейсы (DDR3/4) с тренировкой (подбором входной задержки). В обоих случаях на constraint’ы для I/O ног забивается. Ещё, конечно, очень активно используются MGT – но они к этой теме никак не относятся. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DS 0 30 июля, 2017 Опубликовано 30 июля, 2017 · Жалоба Вот я как раз и хотел посоветовать работать от PLL'ного Clock'а, с компенсацией кривизны BUFG, за счёт обратной сзязи. Но без конкретных цифр, это было бы неправильно. Аккуратная проверка с калькулятором показывает, что это самый плохой вариант, хотя интуитивно он кажется самым лучшим. Разница best/worst case для задержек в линиях превышает период для 300 Мгц, поэтому и сигнал где-то да и попадет в зону метастабильности. Оптимальный вариант - стробировать входные входным же клоком, а то, что после PLL, считать асинхронным. При использовании PLL Vivado честно пытается "накрутить" трассы для компенсации ухода задержек по клок во всем диапазоне. В общем, работает, как задумано, но результат не соответствует усилиям. Если нужно фиксировать фазу между входным и выходным клоком, надо это делать динамически с использованием iserdes/oserdes и приличного количества логики. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 30 июля, 2017 Опубликовано 30 июля, 2017 · Жалоба А Вы бы констрейнты свои запостили сюда. И тайминг-репорты, которые сомнения вызывают. Дело в том, что set_input_delay надо констрейнить с обоими ключами max и min, как было сказано выше, причем max констрейнится по сетапу, а min - по холду от предыдущего цикла. То же касается и малтисайклов - они обычно используется парой по сетапу и холду, причем по холду указывается цифра на единичку меньше. Несоблюдение этих тонкостей иногда приводит к расколбасу в STA. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DS 0 30 июля, 2017 Опубликовано 30 июля, 2017 · Жалоба Я разобрался, у меня сейчас сомнений нет и все работает. Мультициклы в данном случае использовать просто нельзя. Они заставят пропустить софт возможные метастабильные состояния. По умолчанию он правильно считает и пытается скомпенсировать разбег клоков длиной пути (причем не с целью выровнять время, а с целью уменьшить разбег setup-hold), но при больших задержках в клоке это не помогает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться