demidrol

Благодарю! А я в итоге использую клок USB3320 как опорный для PLL-ки, а свой линк сбрасываю сигналом ~locked от нее. Когда клок стабильный -- вроде PHY отключаться от команд по ULPI перестает.

@des00 Простите за некропостинг, но не подскажите, чем в итоге история закончилась? А то похоже, что я на те самые грабли наступаю, что и вы шесть лет назад :)

@Alex, в этом смысле у Xilinx ISE прикольно был сделан вывод утилит в режиме интеграции с IDE: оно плевалось XML-м. Очень удобно именно для машинной обработки, сортировки и QA. Увы, вендоры "серьезоного" софта не хотят или не могут осилить такое.

нет, для synopsys не подойдет. Их команды по умолчанию не бросают исключения в случае ошибок, а просто выдают 0. Вообще, у меня какая-то иррациональная нелюбовь к скриптам, которые при source-е что-то делают. Обычно в таких внешних скриптах я объявляю функции, переменные, неймспейсы и уж их из основного скрипта дергаю.

о, спасибо! Действительно, видел же, но напрочь забыл.

Как известно, tcl-шелл Synopsys DC имеет свое мнение по поводу обработок ошибок. А именно: произошла или нет ошибка в результате исполнения команды можно понять, проанализировав то, что эта самая команда выдала (0 -- ошибка, 1 -- успех). Обработку такого рода ошибок писать очень накладно (это считай каждую команду надо во что-то оборачивать, типа такого proc try {cmd} { set r [uplevel $cmd] if { $r != 1 } { error "Error in $cmd" } } и вызывать уже команды так: try {connect_net netname portname}) А вот нельзя ли как-то указать интерпретатору, что надо останавливать выполнение при первой возникшей ошибке? Иными словами, чтобы команды синопсиса не выделывались, а использовали стандартные тиклевские исключения (error -- catch).

ясно. Т.е. это DC ерундой страдает с иерархией? Хотя какие могут быть иерархические единицы в физдизайне, связанные с циклами или if-else блоками?

поскажите, можно ли как-то заставить Modelsim игнорировать в путях выражения типа generate? К примеру, чтобы пути к экземлярам core в приведенном коде core_inst: if CFG_CORE = 1 generate core_loop: for i in 0 to 3 generate core0 : core generic map (...) port map (...); end generate; end generate; выглядели так: /core0_0 /core0_1 /core0_2 /core0_3 А не так: /core_inst/core_loop(0)/core0 /core_inst/core_loop(1)/core0 /core_inst/core_loop(2)/core0 /core_inst/core_loop(3)/core0

yes да, QuestaSim вполне переваривает record'ы из vhdl package, используемые в SV-тестбенче. К примеру, нормально сожрал структуру ahb_mst_in_type/ahb_mst_out_vector оттуда. Проверил лично на примере grlib. Кстати, а какие типы у гайслера не до конца определены? У них же все границы векторов в константах package прописаны (типа AHBDW, TESTIN_WIDTH и прочих). Strob xilinx, intel, lattice меня не очень интересуют: 1. вендор-лок 2. только плис

господа, а не подскажите, какие из EDA-утилит поддеживают смешанный дизайн, в котором модули на SV используют типы (record, как правило), объявленные в VHDL package? А то есть большая библитека (grlib), написанная на VHDL, но свои модули, а особенно тесты к ним писать на нем же прямо больно. Знаю, что с симуляторами проблем не возникает. Во всяком случае, QuestaSim такое спокойно позволяет взять тип из VHDL-пакета. Больше интересуют утилиты для синтеза. Кажется, Synopsys DC в пролете? Как с этим дела у Cadence?

чего только не выдумывают люди, лишь бы не использовать verilog-mode. AUTOREG/AUTOWIRE знатно помогают создавать такие вот декларативные блоки.

классно, спасибо! Есть только пара "но" 1. Я так понял, что у вас не было вариантов разварки (т.е. все пады всегда выводились наружу) 2. А как было устроено документирование самого pinmux'а? Т.е. были ли у вас переназначаемые или многофункциональные пины, а если да -- то как указывались источники сигналов для мультиплексоров (сигнал ли это с выделенного пада или внутренний регистр, управляемый процессором).

спасибо отписавшимся! Понятно, будем велосипедить. А между прочим, в целях повышения уровня сознательности — не осталось ли у вас примерной "рыбы" экселевского файла? Понятно, что задачи у всех разные, но все же...

Как правило, в корпусах ножки -- ограниченный ресурс, и поэтому приходится так или иначе их мультиплексировать (скажем, uart.tx, spi.sck и gpio). В целом, для маленьких корпусов написать мультиплексоры вручную -- не проблема, но когда их количество приближается к сотне-другой -- становится страшно что-то перепутать. Ну, и тесты пропорционально разбухают. Вопрос к знатокам -- а не придумало ли человечество какого-нибудь способа описывать такие вот мультиплексоры на ногах микросхем? Мол, у первой ножки -- функции такие-то, переключаются они таким-то битом в таком-то регистре. Да вот даже какой-нибудь XML? Профит очевиден -- из xml-подобного описания можно было бы сгенерировать как HDL для синтеза, так и BSDL-файл для скан-тестирования, так и заголовочные файлы для софта. Велосипед изобретать уж очень не хочется.

О, так я просто такую весчь проглядел. Допилю, конечно же. Хотя не. Вопрос такой -- на целой SoC этот самый ls-fuse не сдохнет от жора памяти? Да и файлик с ls -lR выйдет гигабайтым. JSON-то для иерархии я выбрал как раз из соображений минимализма.

Хочу тут немного свой велосипед попиарить. Репорты dc_shell по площади читать уж больно неудобно -- так сразу непонятно, кто больше всего ее отъедает. Наваял тут мелкий инструмент, немного упрощающий жизнь. https://github.com/dmitrodem/sizefs Состоит из двух скриптов. Тот, что на tcl -- запускается из top-level дизайна в dc_shell, на выходе получается json-файл с иерархией (с отмеченными площадями "листьев" -- блоков из библиотеки). Далее этот файл используется питоновским скриптом, реализующим sizefs -- файловую систему в FUSE, единственное назначение которой -- показывать структуру директорий и размеры файлов. Что мне понравилось -- на смонтированную ФС можно натравить утилиты для анализа дискового пространства (мне нравится кдеешный Filelight, но годится и xdiskusage. Да даже обычный du).

а зачем блочную память (даже набранную из триггеров) включать в скан-цепочку? Почему ее обычными BIST не тестировать? я ж предлагаю по границе памяти поставить обычные триггеры. Понятно, что латчи требуют повышенной аккуратности.

Пишу тут обертки для блочной памяти, для выбора наиболее оптимального варианта (регистры, 128x8, 2048x8) по площади. И вот возникает вопрос -- а почему, собственно, память на регистрах делают из D flip-flop'ов? Почему-то ни разу не встречал варианта, сделанного из latch'ей, хотя они по быстродействию и площади вроде бы гораздо предпочтительнее обычных триггеров. Да, как минимум на входы надо будет поставить DFF, но это ж мелочи (по сравнению с массивом). Так почему ее не делают из защелок? Сложности в статическом анализе таймингов?

Благодарю! У меня просто получилась смешная ситуация, когда заказчики не выдали требований на внешние сигналы.

Сижу и ломаю голову, как правильно было бы проводить синтез системы на кристалле: просто core-логику или ее же с прицепленными падами. Пока вижу такие особенности дизайна с падами 1. надо явным образом выписывать false paths для "медленных" сигналов (типа включить-выключить pull-up на двунаправленном паде) 2. можно забить на спецификацию input и output задержек (выставить их в 0) -- пады-то уже на месте. 3. можно точно так же не морочиться с set_drive/set_load по той же причине. 4. из минусов -- труднее протаскивать скан-цепочку (поскольку "пустые" пады для выходов тестовых векторов синтезатор, конечно же, прицепит куда-то -- или на 0, или на 1. И их придется отцеплять) В общем, хотелось бы послушать ваше мнение по этому вопросу.

вроде все нашлось, sold на местном ftp водится.

спасибо, поглядим

Подскажите, пожалуйста, где у Synopsys находится их Design Compiler Reference Manual? Смотрел содержимое syn_vA-2007.12-SP2, syn_vH-2013.03-SP1 и syn_vL-2016.03 -- из документации там только man-страницы. Сомневаюсь, что это и есть их рефмануал. Или он водится только в их SolvNet при наличии валидной лицензии?

да никаких проблем, так и делаю. Просто концептуально это неправильно как-то.

ну, этот разъем припаивается на плату. Собственно, футпринт -- схема расположения металлизированных отверстий и контур той площади, что разъем занимает на печатной плате, плюс расположение монтажных отверстий под него.