Перейти к содержанию

    

dxp

Свой
  • Публикаций

    3 510
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

1 Подписчик

Информация о dxp

  • Звание
    Adept

Информация

  • Город
    Novosibirsk

Посетители профиля

7 907 просмотров профиля
  1. А это тут причём? Эта логика очень далеко от I/O пинов - за несколькими слоями регистров и за парой аппаратных блоков. И даже если бы там пины тянули, то это не оправдание такого горбатого размещения. Нет, этого и близко нет. Там данные приходят через аппаратные GT трансиверы, проходят через аппаратный же PCEe блок и только после этого попадают на логику. Эти аппаратные блоки расположены в левом верхнем Clock Region, и по логике там же нужно размещать сопутствующую логику. В целом плейсер так и делает за некоторым исключением. Логика такого поведения не понятна.
  2. Вопрос задал не холивара ради, но понимания для. Поведение тула для меня несколько странное (с такой простой ситуацией не справляется), и нет уверенности, что делаю всё правильно (запихнув логику руками принудительно). Найдя путь и решив проблему, тем не менее хотелось понять, правильно ли сделал. Потому и интересуюсь у более знающих коллег. Вот.
  3. Стремление похвальное. Но не в ущерб же таймингам? Кому нужно хорошее распределение тепла по кристаллу при не рабочем проекте?
  4. Всем привет! С Xilinx ранее работать серьёзно не приходилось, всё больше была Altera, поэтому нахожусь в процессе набора опыта и познания особенностей FPGA Xilinx и её САПР Vivado. Текущий проект: Artix-7 xc7a200t, Vivado 2018.2. По результатам очередной сборки развалились времянки: тактовый домен 4 нс (250 МГц), слак по сетапу порядка 0.8 нс. Смотрю, на чём просело, вижу, задержку пути на логике 1.269 нс, на трассировке 3.229. Логики там реально немного, поэтому и странно, что не уложилось. Открываю Device, и вижу, что вивада утащила часть логики модуля в другой Clock Region, отсюда и такая конская задержка (плоховато, но видно беленьким показан путь). Никакими изменениями стратегий ситуацию исправить не удалось. Вообще, ситуация представляется достаточно простой - кристалл почти пустой, и места для логики в левом Clock Region и под ним полно. Зачем же плейсер рассовал логику так, что трассировщик потом уже ничего не может исправить? Ну, делать нечего, пришлось применить ручное назначение потрохов модуля в pblock. После этого всё получилось, времянки сошлись и на дивайсе всё выглядит компактно, логично и красиво. Собственно вопрос: это правильный подход и нормальная практика для Xilinx/Vivado или это костыльно и правильно всё же как-то вызвать интеллект САПР из сумрака, чтобы она сама соображала, как размещать, чтобы проект разводился без фейлов? Просто на Altera/Quartus не помню случая, чтобы приходилось фиксить работут фиттера - он всегда сам справлялся лучше (а попытки лезть к нему напрямую только мешали). P.S. Вдогонку штрих: без констрейна на pblock длительность сборки: синтез: 0:33 P&R: 2:19 и в итоге времянка не сходится. с pblock'ом: синтез: 0:33 P&R: 1:38 и времянка в норме.
  5. Насколько мне известно, там есть ограничение. И собирались его сделать 150 евров. Не в курсе, сделали или нет.
  6. Есть два нюанса, кмк. 1. Не придётся ли платить таможенную пошлину (30%) + НДС (18... или уже 20%)? 2. У Приста оно не совсем ровно то же самое. Они это подают под своим брендом АКИП и упирают на то, что дивайс прошёл испытания на метрологическое соответствие, имеет сертификат Госреестра СИ, т.е. может быть использован официально как средство измерения. Понятно, что личного использования в качестве показометра это очень актуально. Но тем не менее, эта работа проведена и за неё хотят денек.
  7. Такого не должно быть: в данном случае речь идёт не о setup/hold (как с входом флопа), а recovery/removal анализе, т.к. анализируется сигнал асинхронного сброса/пресета. Этот анализ STA выполняет и все задержки и требования видит и учитывает. Если тут что-то не в порядке, это будет видно в отчёте STA. Опасная ситуация именно с глитчами из-за гонок на комбинационной логике, которые STA не может на 100% просчитать. И именно про глитчи синтезатор предупреждение и выдаёт. Вот именно так, по ходу, и сделаю. Ну, это уже для настоящих ковбоев.
  8. Я бы согласился с вами, если бы между флопом-источником ресета и асинхронным входом сброса флопа-приёмника была бы комбинационная логика, которая, конечно, может порождать глитчи на выходе. Но в данном случае всё "стерильно": сигнал сброса генерируется синхронно и распространяется напрямую без всякой логики. Где тут источник глитчей (или других проблем)? Привожу картинку, как оно реально там синтезировалось:
  9. Всем привет! При сборке проекта всплыл набор предупреждений вида (подформатировал, ибо в оригинале совсем нечитабельно): Суть недовольства САПР в следующем: инстанс корки PCIe содержит внутри блочную память, на входы блоков которой приходит сигнал из недр другой корки - сигнал empty прокинут (через логику) из FIFO, при этом флоп, с которого выходит этот empty, имеет тип FDPE, что в переводе на русский означает, что этот флоп типа "D Flip-Flop with Clock Enable and Asynchronous Preset", и это сильно не нравится синтезатору, о чём он сообщает. Формально он прав - нехорошо, когда асинхронный сброс (пресет) используется - вдруг глитч на сигнале сброса... со всеми вытекающими. Но смотрю, откуда приходит сигнал сброса (пресета), а он приходит с другого флопа, который имеет тип FDRE (D Flip-Flop with Clock Enable and Synchronous Reset), т.е. никаких глитчей быть не может - флоп строго синхронен общему клоку данного домена. Вопрос: а чего он тогда ругается-то? Или у него просто не хватает глубины анализа? И второй вопрос: как быть? Оставить, как есть? Вроде оно безопасно, но неприятный варнинг портит настроение. Или всё же есть способ забороть корректно? P.S. Корка FIFO по умолчанию имеет настройку параметра Reset Type как Asynchronous. Попытался изменить на синхронный тип, появились два раздельных входа ресета (для обоих тактовых доменов - FIFO сконфигурировано с независимыми клоками), но картина не поменялась. Внутри корки флоп сигнала empty по-прежнему имеет тип FDPE, и варнинг, естественно, не уходит. Так понял, что тип сигнала сброса не влияет на реализацию отдельных логических частей, а влияет только на поведение корки в смысле внешнего ресета.
  10. Это потому, что там тулза генерит эти стопятсот тыщ строк. А эти "заморочки" языков нужны для человеческого выражения замыслов. Тулзой ессно куда проще нагененить тыщи строк, чем сделать так, чтобы она выдавала красивый, читабельный и сопровождаемый в дальнейшем код. Я бы, кстати, предпочёл именно этот вариант, а не эти тонны говнокода, которые выдают генераторы.
  11. Да вообще все HDL - фтопку! Схемы - вот то великое, с чего всё началось. Отказались от схем, теперь пожинают плоды! Это ж надо было додуматься схемы буквами описывать. "Дебилы, б.." (с).
  12. Наверное разогнали одну из команд: нам как-то не семинаре представитель Xilinx сообщил, что Vivado разрабатывает две разные команды, причём одна пилит нечётные версии, вторая - чётные. Вроде как так быстрее получается, а то одна команда не успевает. Поэтому, в частности, как сказал представитель, качество соседних билдов может быть очень разным. Мы очень удивлялись такому подходу - как можно при этом соблюдать целостность разработки. Ну, вот теперь, видимо, "чётную" команду ликвидировали. :)
  13. Пчёлы против мёда. :) Наверное имели в виду Cadence vs Mentor или Allegro vs Xpedition?
  14. Безальтернативно рекомендую в первую очередь https://fpgawiki.intel.com/uploads/3/3f/TimeQuest_User_Guide.pdf. Имхо, лучший документ для понимания основ (особенно Section 2: Timing Analysis Basics). Ориентировано на альтеровский инструмент, но принципы общие и описано очень хорошо.