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

Nix_86

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

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Частый гость
  • День рождения 10.11.1986

Контакты

  • Сайт
    http://
  • ICQ
    2016140
  1. Использую как вспомогательный инструмент для преобразования массивов данных там, где не хватает скилов применить Excel
  2. Прошу feedback по резюме

    ФИО и контактная информация тоже не будут лишними
  3. аккаунт в pudn

    Цитата(moofi @ Apr 22 2017, 12:59) У меня компьютер напрочь отказывается загружать файлы на pudn.com, с какого бы браузера не пробовал-зависает и все, поэтому не могу активировать свой аккаунт. Прошу и умоляю выручить меня, залив эти файлы, у кого есть такая возможность. Буду очень благодарен человеку с огромным сердцем, который меня спасет) http://en.pudn.com/downloads157/sourcecode...l698882_en.html http://en.pudn.com/downloads157/sourcecode...l698945_en.html http://en.pudn.com/downloads686/sourcecode...2769840_en.html http://en.pudn.com/downloads695/sourcecode...2800766_en.html http://en.pudn.com/downloads773/sourcecode...3065534_en.html http://en.pudn.com/downloads455/doc/filefo...1915279_en.html http://en.pudn.com/downloads705/doc/detail2834654_en.html http://en.pudn.com/downloads763/sourcecode...3031045_en.html https://yadi.sk/d/vxIsMGyO3HEkod
  4. Цитата(demidrol @ Apr 14 2017, 14:11) Подскажите, пожалуйста, где у Synopsys находится их Design Compiler Reference Manual? Смотрел содержимое syn_vA-2007.12-SP2, syn_vH-2013.03-SP1 и syn_vL-2016.03 -- из документации там только man-страницы. Сомневаюсь, что это и есть их рефмануал. Или он водится только в их SolvNet при наличии валидной лицензии? В директориях установки - нигде, Syn0psys не кладёт их туда. Если не нашли ничего полезного из того, что выдал гугл на первой странице поиска по запросу "design compiler reference manual filetype:pdf", скажите что конкретно нужно.
  5. Цитата(ethdvl @ Apr 1 2017, 14:52) На периферии. г.Воронеж. Тут найти работу по SoC вообще не реально, нет таких предприятий. А как же НИИЭТ?? Там же есть свой дизайн-центр. Проектируют ASIC, осваивают ARM'ы...
  6. Цитата(Shivers @ Mar 24 2017, 20:41) А Вы пробовали так делать? Нет, не пробовал. Пока нахожусь на завершающем этапе разработки RTL и неспешно продумываю детали синтеза, DFT, BSD. Цитата(Shivers @ Mar 24 2017, 20:41) Про иерархию в этой цитате нет ни слова. Когда пишут "top-level design", а не просто "design", волей-неволей представляется дизайн на конкретном уровене иерархии, в данном случае "верхнем". Цитата(Shivers @ Mar 24 2017, 20:41) Я только с таким представлением и работаю. Думаю придётся и мне вытащить это в TOP, чтобы Цитата(Shivers @ Mar 24 2017, 20:41) это было красиво и корректно Цитата(Shivers @ Mar 24 2017, 20:41) Просто это очень криво, утапливать пады. Плохой стиль. Не спорю. На определенном этапе разработки при описании сущности модуля иногда удобно видеть пады, связанные с этой сущностью в этом же модуле. Не всегда этот модуль оказывается рядом с "топом", а пады при этом могут быть "продвинутыми", с большой кучей режимных входов (подтяжки к vdd, gnd, отключаемые глитч-фильтры, триггеры Шмитта и т.д.). Для управления всем этим приходится тащить шины наверх, перегружая промежуточные уровни иерархии вязанками проводов.
  7. Цитата(Shivers @ Mar 24 2017, 19:11) 2. можно. Они ведь через hookup цепляются. Тул сам пробьет иерархию к ним, добавив новые порты и провода Еще можно принудительно указать иерархию, куда располагать Тар и BS Спасибо. В данном случае речь не только о JTAG-падах, но и об остальных функциональных. Можно ли через hookup рассказать о них BSD compiler'у, чтобы он их нашёл и правильно соединил с BS-ячейками? Если да, то как? В user guide на BSD Compiler в разделе Design Requirements есть пункт: Цитата2. The top-level design must have I/O pad cells for all functional ports. The pad cells must be linked to the core design pins. There must be a one-to-one correspondence to top-level ports and core pins В связи с этим и возник вопрос №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 тупит или я?...

    Здравствуйте! Подскажите, кто знает, как ведёт себя Keil в демо-режиме (тот что с ограничением в 32 Кб) при компиляции проекта, когда размер прошивки превышает 32 Кб? Что на выходе? Error? Или ущербный bin с предупреждением?
  10. upd: Вчера дошли до трассировки проекта. На этапе создания клокового дерева обнаружились невыправляемые виоляции по hold'у. Детальное рассмотрение кода заказчика показало, что в этом месте клок переходит в цепь данных (!!!) Что-то мне подсказывает, такая "технология" не приведёт ни к чему хорошему. А это как-то можно диагностировать заранее??
  11. Цитата(krux @ May 24 2015, 15:39) а там дальше в проекте переходы между этими 50 - 25 -12.5 производятся в каких условиях? если используется same edge, в расчете на деленный клок, - то это одно, если все развязано нормальными CDC-переходами - то другое. в ASIC-е все это будет сильно на клоковые деревья влиять. Дальше переходы между доменами производятся по rising edge. CDC-переходов нет, да и ни к чему они вроде бы при таком способе формирования клоков – источник клока один, сами клоки синхронные, задержка на триггерах при формировании 25 МГц и 12.5 МГц должна учитываться при STA, надо только правильно законстрейнить generated клоки.
  12. Цитата(Dr.Alex @ May 24 2015, 00:42) в плисине нужно делить не триггерами, а клок-буферами Вопрос, озвученный выше, возник как раз в процессе перевода чужого проекта из ПЛИС в 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. Цитата(Torpeda @ May 15 2015, 08:56) Интересно, такие розработчики SDC передают, или у них проект както сам компилился и прошивался? к сожалению, никаких SDC, значение тактовой частоты и клоковый пин, указанные в ТЗ – всё что есть Самое интересное начинается когда случайно обнаруживаются внутренние generated-клоки, полученные делением основного клока, о которых никто из ПЛИСоводов, с кем я работал, обычно не считает нужным предупредить. В связи с этим вопрос - есть ли тул, позволяющий выявить и законстрэйнить эти штуки сразу на этапе согласования исходных данных без лишней головной боли и разъяснений автору RTL, что это необходимо? Цитата(Torpeda @ May 15 2015, 08:56) Понижайте Fmax или переходите на 0.18 Fmax диктует заказчик, проектные нормы - руководство. Так и работаем ) Цитата(Torpeda @ May 15 2015, 08:56) ЗЫ "защёлкивании по rise или по fall разработчиком описания принимались неосознанно" а я смотрю технология "дизайн не приходя в сознание" становится всё популярнее в точку
  15. Цитата(Torpeda @ May 14 2015, 10:10) Тут кстати перевод в ASIC нипричём - както-же в ПЛИС это работало. Не соглашусь. Простой пример – в ПЛИС начальное состояние триггера, в которое он устанавливается при подаче напряжения питания м/с может быть предопределено. Если функционал проекта завязан на это конкретное начальное состояние, то зашитая ПЛИС будет работать в приборе как положено. В ASIC начальное состояние несброшенного триггера не детерминировано. Типичная ситуация: многие ПЛИС-разработчики передают для миграции в ASIC проект без полноценных функциональных тестов, подкрепляя это тем, что "проект выверен и отработан на ПЛИС в составе приборе". В этом случае недетерминированное начальное состояние триггеров в кремнии приведёт к неработоспособности м/с в соответствии с задуманными алгоритмами. Цитата(Torpeda @ May 14 2015, 10:10) Ну и по поводу перевода в ASIC - незабудьте встроить тестовые структуры для производства. Разумеется да. Но опять же тестовые структуры не спасают от ситуаций, наподобие тех, что описаны выше. Цитата(Torpeda @ May 14 2015, 10:10) Тактирование по обеих фроттах - никаких поблем.... Были и такие проблемы, когда переводили проект в ASIC 0.35 мкм. Не хватало быстродействия - виоляции по путям от rising edge до falling edge. Впоследствии выяснилось, что решения о защёлкивании по rise или по fall разработчиком описания принимались неосознанно и никакого влияния на функционал не оказывало. Проект был отправлен на переработку. Вывод: быстродействие современных зарубежных ПЛИС "прощает" эти ляпы в данном случае. Цитата(Torpeda @ May 14 2015, 10:10) ... ну и встроить схему их тестирования при производстве... Вывести интерфейс к блокам памяти для их тестирования снаружи? Или встроить логику для их тестирования внутри по заданным алгоритмам?