Jump to content

    

scorp

Свой
  • Content Count

    80
  • Joined

  • Last visited

Community Reputation

0 Обычный

About scorp

  • Rank
    Частый гость
  • Birthday 11/10/1986

Контакты

  • Сайт
    Array
  • ICQ
    Array

Recent Profile Visitors

1863 profile views
  1. А позвонить на него с другого телефона не вариант?
  2. Использую как вспомогательный инструмент для преобразования массивов данных там, где не хватает скилов применить Excel :)
  3. ФИО и контактная информация тоже не будут лишними :)
  4. В директориях установки - нигде, Syn0psys не кладёт их туда. Если не нашли ничего полезного из того, что выдал гугл на первой странице поиска по запросу "design compiler reference manual filetype:pdf", скажите что конкретно нужно.
  5. А как же НИИЭТ?? Там же есть свой дизайн-центр. Проектируют ASIC, осваивают ARM'ы...
  6. Нет, не пробовал. Пока нахожусь на завершающем этапе разработки RTL и неспешно продумываю детали синтеза, DFT, BSD. Когда пишут "top-level design", а не просто "design", волей-неволей представляется дизайн на конкретном уровене иерархии, в данном случае "верхнем". Думаю придётся и мне вытащить это в TOP, чтобы Не спорю. На определенном этапе разработки при описании сущности модуля иногда удобно видеть пады, связанные с этой сущностью в этом же модуле. Не всегда этот модуль оказывается рядом с "топом", а пады при этом могут быть "продвинутыми", с большой кучей режимных входов (подтяжки к vdd, gnd, отключаемые глитч-фильтры, триггеры Шмитта и т.д.). Для управления всем этим приходится тащить шины наверх, перегружая промежуточные уровни иерархии вязанками проводов.
  7. Спасибо. В данном случае речь не только о JTAG-падах, но и об остальных функциональных. Можно ли через hookup рассказать о них BSD compiler'у, чтобы он их нашёл и правильно соединил с BS-ячейками? Если да, то как? В user guide на BSD Compiler в разделе Design Requirements есть пункт: В связи с этим и возник вопрос №2 из первого поста.
  8. День добрый! Собираюсь имплементировать проект. Применяю тулы syn0psys. Возникла пара вопросов. 1. В какой очередности правильно выполнить DFT и BSD insertion? - если DFT ==> BSD, то сгенерированная BSD-логика будет несканируемой, что неизбежно снизит тестовое покрытие; - если BSD ==> DFT, то скан-цепи охватят всю логику, включая BSR + TAP, однако участие BSR ячеек в ATPG-тесте свалит его. Думаю в этом случае можно запретить логике BSR и(или) TAP участвовать в создании скан-цепей (dont_touch), но опять же ценой снижения тестового покрытия. Интересуют общепринятые подходы. Syn0psys предлагает user guides на каждый тул по отдельности, но информации об очередности их применения и нюансах не нашёл. 2. Пады в дизайне собраны в отдельном модуле (не в TOP). Можно ли рассказать BSD Compiler о том, где они есть? Или же они обязательно должны быть в TOP? Спасибо!
  9. Здравствуйте! Подскажите, кто знает, как ведёт себя Keil в демо-режиме (тот что с ограничением в 32 Кб) при компиляции проекта, когда размер прошивки превышает 32 Кб? Что на выходе? Error? Или ущербный bin с предупреждением?
  10. upd: Вчера дошли до трассировки проекта. На этапе создания клокового дерева обнаружились невыправляемые виоляции по hold'у. Детальное рассмотрение кода заказчика показало, что в этом месте клок переходит в цепь данных (!!!) :maniac: Что-то мне подсказывает, такая "технология" не приведёт ни к чему хорошему. А это как-то можно диагностировать заранее??
  11. Дальше переходы между доменами производятся по rising edge. CDC-переходов нет, да и ни к чему они вроде бы при таком способе формирования клоков – источник клока один, сами клоки синхронные, задержка на триггерах при формировании 25 МГц и 12.5 МГц должна учитываться при STA, надо только правильно законстрейнить generated клоки.
  12. Вопрос, озвученный выше, возник как раз в процессе перевода чужого проекта из ПЛИС в ASIC.
  13. Приветствую! Вопрос знатокам. Помогите правильно задать SDC констрейн. В проекте есть 3 клоковых домена - 50 МГц, 25 МГц и 12.5 МГц. Частоты 25 МГц и 12.5 МГц получены путём деления исходной частоты 50 МГц со входа clk с помощью триггеров (см. картинку). С констрейном для частоты 25 МГц проблем нет, обычный generated клок. А для задания клока 12.5 МГц вижу 2 варианта: create_generated_clock -name i_clk_12_5MHz \ -source [get_ports clk] \ -divide_by 4 \ [get_pins clk_12_5_reg/q] либо create_generated_clock -name i_clk_12_5MHz \ -source [get_pins clk_25_reg/q] \ -divide_by 2 \ [get_pins clk_12_5_reg/q] Какой вариант правильнее?
  14. к сожалению, никаких SDC, значение тактовой частоты и клоковый пин, указанные в ТЗ – всё что есть :) Самое интересное начинается когда случайно обнаруживаются внутренние generated-клоки, полученные делением основного клока, о которых никто из ПЛИСоводов, с кем я работал, обычно не считает нужным предупредить. В связи с этим вопрос - есть ли тул, позволяющий выявить и законстрэйнить эти штуки сразу на этапе согласования исходных данных без лишней головной боли и разъяснений автору RTL, что это необходимо? Fmax диктует заказчик, проектные нормы - руководство. Так и работаем ) в точку ;)
  15. Не соглашусь. Простой пример – в ПЛИС начальное состояние триггера, в которое он устанавливается при подаче напряжения питания м/с может быть предопределено. Если функционал проекта завязан на это конкретное начальное состояние, то зашитая ПЛИС будет работать в приборе как положено. В ASIC начальное состояние несброшенного триггера не детерминировано. Типичная ситуация: многие ПЛИС-разработчики передают для миграции в ASIC проект без полноценных функциональных тестов, подкрепляя это тем, что "проект выверен и отработан на ПЛИС в составе приборе". В этом случае недетерминированное начальное состояние триггеров в кремнии приведёт к неработоспособности м/с в соответствии с задуманными алгоритмами. Разумеется да. Но опять же тестовые структуры не спасают от ситуаций, наподобие тех, что описаны выше. Были и такие проблемы, когда переводили проект в ASIC 0.35 мкм. Не хватало быстродействия - виоляции по путям от rising edge до falling edge. Впоследствии выяснилось, что решения о защёлкивании по rise или по fall разработчиком описания принимались неосознанно и никакого влияния на функционал не оказывало. Проект был отправлен на переработку. Вывод: быстродействие современных зарубежных ПЛИС "прощает" эти ляпы в данном случае. Вывести интерфейс к блокам памяти для их тестирования снаружи? Или встроить логику для их тестирования внутри по заданным алгоритмам?