scorp

А позвонить на него с другого телефона не вариант?

Использую как вспомогательный инструмент для преобразования массивов данных там, где не хватает скилов применить Excel :)

ФИО и контактная информация тоже не будут лишними :)

В директориях установки - нигде, Syn0psys не кладёт их туда. Если не нашли ничего полезного из того, что выдал гугл на первой странице поиска по запросу "design compiler reference manual filetype:pdf", скажите что конкретно нужно.

А как же НИИЭТ?? Там же есть свой дизайн-центр. Проектируют ASIC, осваивают ARM'ы...

Нет, не пробовал. Пока нахожусь на завершающем этапе разработки RTL и неспешно продумываю детали синтеза, DFT, BSD. Когда пишут "top-level design", а не просто "design", волей-неволей представляется дизайн на конкретном уровене иерархии, в данном случае "верхнем". Думаю придётся и мне вытащить это в TOP, чтобы Не спорю. На определенном этапе разработки при описании сущности модуля иногда удобно видеть пады, связанные с этой сущностью в этом же модуле. Не всегда этот модуль оказывается рядом с "топом", а пады при этом могут быть "продвинутыми", с большой кучей режимных входов (подтяжки к vdd, gnd, отключаемые глитч-фильтры, триггеры Шмитта и т.д.). Для управления всем этим приходится тащить шины наверх, перегружая промежуточные уровни иерархии вязанками проводов.

Спасибо. В данном случае речь не только о JTAG-падах, но и об остальных функциональных. Можно ли через hookup рассказать о них BSD compiler'у, чтобы он их нашёл и правильно соединил с BS-ячейками? Если да, то как? В user guide на BSD Compiler в разделе Design Requirements есть пункт: В связи с этим и возник вопрос №2 из первого поста.

День добрый! Собираюсь имплементировать проект. Применяю тулы 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? Спасибо!

Здравствуйте! Подскажите, кто знает, как ведёт себя Keil в демо-режиме (тот что с ограничением в 32 Кб) при компиляции проекта, когда размер прошивки превышает 32 Кб? Что на выходе? Error? Или ущербный bin с предупреждением?

upd: Вчера дошли до трассировки проекта. На этапе создания клокового дерева обнаружились невыправляемые виоляции по hold'у. Детальное рассмотрение кода заказчика показало, что в этом месте клок переходит в цепь данных (!!!) :maniac: Что-то мне подсказывает, такая "технология" не приведёт ни к чему хорошему. А это как-то можно диагностировать заранее??

Дальше переходы между доменами производятся по rising edge. CDC-переходов нет, да и ни к чему они вроде бы при таком способе формирования клоков – источник клока один, сами клоки синхронные, задержка на триггерах при формировании 25 МГц и 12.5 МГц должна учитываться при STA, надо только правильно законстрейнить generated клоки.

Вопрос, озвученный выше, возник как раз в процессе перевода чужого проекта из ПЛИС в ASIC.

Приветствую! Вопрос знатокам. Помогите правильно задать 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] Какой вариант правильнее?

к сожалению, никаких SDC, значение тактовой частоты и клоковый пин, указанные в ТЗ – всё что есть :) Самое интересное начинается когда случайно обнаруживаются внутренние generated-клоки, полученные делением основного клока, о которых никто из ПЛИСоводов, с кем я работал, обычно не считает нужным предупредить. В связи с этим вопрос - есть ли тул, позволяющий выявить и законстрэйнить эти штуки сразу на этапе согласования исходных данных без лишней головной боли и разъяснений автору RTL, что это необходимо? Fmax диктует заказчик, проектные нормы - руководство. Так и работаем ) в точку ;)

Не соглашусь. Простой пример – в ПЛИС начальное состояние триггера, в которое он устанавливается при подаче напряжения питания м/с может быть предопределено. Если функционал проекта завязан на это конкретное начальное состояние, то зашитая ПЛИС будет работать в приборе как положено. В ASIC начальное состояние несброшенного триггера не детерминировано. Типичная ситуация: многие ПЛИС-разработчики передают для миграции в ASIC проект без полноценных функциональных тестов, подкрепляя это тем, что "проект выверен и отработан на ПЛИС в составе приборе". В этом случае недетерминированное начальное состояние триггеров в кремнии приведёт к неработоспособности м/с в соответствии с задуманными алгоритмами. Разумеется да. Но опять же тестовые структуры не спасают от ситуаций, наподобие тех, что описаны выше. Были и такие проблемы, когда переводили проект в ASIC 0.35 мкм. Не хватало быстродействия - виоляции по путям от rising edge до falling edge. Впоследствии выяснилось, что решения о защёлкивании по rise или по fall разработчиком описания принимались неосознанно и никакого влияния на функционал не оказывало. Проект был отправлен на переработку. Вывод: быстродействие современных зарубежных ПЛИС "прощает" эти ляпы в данном случае. Вывести интерфейс к блокам памяти для их тестирования снаружи? Или встроить логику для их тестирования внутри по заданным алгоритмам?

Fat Robot, спасибо Вам за развёрнутый и подробный ответ! Передо мной стоит задача перевода чужого проекта, отработанного на ПЛИС, в ASIC. В ходе работы наткнулся на проблемы с отсутствием сброса многих триггеров, которые привели к неработоспособности дизайна уже на этапе моделирования нетлиста в базисе библиотеки. В этой связи стало интересно, есть ли кроме отсутствия сброса ещё какие-то моменты, типичные для ПЛИСоводов и неприемлемые для ASIC.

Вопрос ко всем разработчикам проектов на FPGA, кому приходилось переводить проект на ASIC. С какими проблемами столкнулись и что пришлось исправить/доработать? Не случайно размещаю тему в этом разделе. Речь идёт не о применении встроенных мегафункций ПЛИС, требованиях к быстродействию или площади кристалла, а именно о походах к созданию поведенческого описания в части тактирования, сброса т.д.

спасибо. в моём случае периферийное устройство - тоже стронний IP-блок, у которого, к сожалению, настройки вида прерываний нет :( В ядре имеется тот самый NVIC, думал что посредством его настройки можно ему как-то объяснить, что определённую линию прерываний нужно обрабатывать как "прерывание по перепаду"...

В том-то и дело, что MCU проектирую сам. За обработку прерываний обвечает ядро. Ядро в исходниках.

Всем вечер добрый! Подскажите, пожалуйста, как работать с прерываниями не по уровню, а по перепаду. Ядро - Cortex-M4F. Прочитал документацию, не обнаружил настроечного регистра, который бы настроил линию прерывания для работы по перепаду... Есть периферийный блок, который устанавливает прерывание в активное состояние на несколько тактов, после чего сам же его деактивизирует. Возможна ситуация, когда обработчик прерывания завершится и выйдет в основную программу раньше чем случится деактивизация сигнала прерывания и тогда случится повторное выполнение обработчика прерывания, которое нежелательно. Необходимо сделать так, чтобы переход в обработчик прерывания происходил только по фронту сигнала прерывания.

флеш параллельная 256Кх16, Am29LV400B, подключена к внешней системной шине процессора TMS320C546

Подскажите пожалуйста, а ещё лучше поделитесь примером реализации программатора микросхем flash памяти прямо на плате, не выпаивая микросхему?

Всем привет! Проблема в кратце, возникла необходимость передать заказчику IP-блоки для интеграции в его систему, моделирования и отладки. Не хотелось бы светить rtl... Есть ли способы создать из rtl-описания некую зашифрованную модель, которую можно будет беспрепятственно промоделировать, но при этом сохранить в секрете реализацию и обеспечить непригодность для синтеза. Если есть, то в каких симуляторах работает? Есть ли универсальное средство, подходящее для всех симуляторов? Спасибо!

Не видно конкретики в вашем вопросе, что хотите сделать и на какой результат нацелены? Универсальных волшебных решений не существует. Если проект готовый и отлаженый и сделан по канонам opencores, скорее всего в нем есть директория sim, поищите в ней скрипт запуска симуляции.

К сожалению, ссылки уже не актуальны, а материалы нужные и полезные. Не могли бы "освежить" ссылки? Или положить на фтп? Спасибо!