Jump to content

    

demidrol

Свой
  • Content Count

    119
  • Joined

  • Last visited

Community Reputation

0 Обычный

About demidrol

  • Rank
    Частый гость

Контакты

  • Сайт
    Array
  • ICQ
    Array

Recent Profile Visitors

2398 profile views
  1. @Alex, в этом смысле у Xilinx ISE прикольно был сделан вывод утилит в режиме интеграции с IDE: оно плевалось XML-м. Очень удобно именно для машинной обработки, сортировки и QA. Увы, вендоры "серьезоного" софта не хотят или не могут осилить такое.
  2. нет, для synopsys не подойдет. Их команды по умолчанию не бросают исключения в случае ошибок, а просто выдают 0. Вообще, у меня какая-то иррациональная нелюбовь к скриптам, которые при source-е что-то делают. Обычно в таких внешних скриптах я объявляю функции, переменные, неймспейсы и уж их из основного скрипта дергаю.
  3. Как известно, 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).
  4. ясно. Т.е. это DC ерундой страдает с иерархией? Хотя какие могут быть иерархические единицы в физдизайне, связанные с циклами или if-else блоками?
  5. поскажите, можно ли как-то заставить 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
  6. 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. только плис
  7. господа, а не подскажите, какие из EDA-утилит поддеживают смешанный дизайн, в котором модули на SV используют типы (record, как правило), объявленные в VHDL package? А то есть большая библитека (grlib), написанная на VHDL, но свои модули, а особенно тесты к ним писать на нем же прямо больно. Знаю, что с симуляторами проблем не возникает. Во всяком случае, QuestaSim такое спокойно позволяет взять тип из VHDL-пакета. Больше интересуют утилиты для синтеза. Кажется, Synopsys DC в пролете? Как с этим дела у Cadence?
  8. чего только не выдумывают люди, лишь бы не использовать verilog-mode. AUTOREG/AUTOWIRE знатно помогают создавать такие вот декларативные блоки.
  9. классно, спасибо! Есть только пара "но" 1. Я так понял, что у вас не было вариантов разварки (т.е. все пады всегда выводились наружу) 2. А как было устроено документирование самого pinmux'а? Т.е. были ли у вас переназначаемые или многофункциональные пины, а если да -- то как указывались источники сигналов для мультиплексоров (сигнал ли это с выделенного пада или внутренний регистр, управляемый процессором).
  10. спасибо отписавшимся! Понятно, будем велосипедить. А между прочим, в целях повышения уровня сознательности — не осталось ли у вас примерной "рыбы" экселевского файла? Понятно, что задачи у всех разные, но все же...
  11. Как правило, в корпусах ножки -- ограниченный ресурс, и поэтому приходится так или иначе их мультиплексировать (скажем, uart.tx, spi.sck и gpio). В целом, для маленьких корпусов написать мультиплексоры вручную -- не проблема, но когда их количество приближается к сотне-другой -- становится страшно что-то перепутать. Ну, и тесты пропорционально разбухают. Вопрос к знатокам -- а не придумало ли человечество какого-нибудь способа описывать такие вот мультиплексоры на ногах микросхем? Мол, у первой ножки -- функции такие-то, переключаются они таким-то битом в таком-то регистре. Да вот даже какой-нибудь XML? Профит очевиден -- из xml-подобного описания можно было бы сгенерировать как HDL для синтеза, так и BSDL-файл для скан-тестирования, так и заголовочные файлы для софта. Велосипед изобретать уж очень не хочется.
  12. О, так я просто такую весчь проглядел. Допилю, конечно же. Хотя не. Вопрос такой -- на целой SoC этот самый ls-fuse не сдохнет от жора памяти? Да и файлик с ls -lR выйдет гигабайтым. JSON-то для иерархии я выбрал как раз из соображений минимализма.
  13. Хочу тут немного свой велосипед попиарить. Репорты dc_shell по площади читать уж больно неудобно -- так сразу непонятно, кто больше всего ее отъедает. Наваял тут мелкий инструмент, немного упрощающий жизнь. https://github.com/dmitrodem/sizefs Состоит из двух скриптов. Тот, что на tcl -- запускается из top-level дизайна в dc_shell, на выходе получается json-файл с иерархией (с отмеченными площадями "листьев" -- блоков из библиотеки). Далее этот файл используется питоновским скриптом, реализующим sizefs -- файловую систему в FUSE, единственное назначение которой -- показывать структуру директорий и размеры файлов. Что мне понравилось -- на смонтированную ФС можно натравить утилиты для анализа дискового пространства (мне нравится кдеешный Filelight, но годится и xdiskusage. Да даже обычный du).
  14. а зачем блочную память (даже набранную из триггеров) включать в скан-цепочку? Почему ее обычными BIST не тестировать? я ж предлагаю по границе памяти поставить обычные триггеры. Понятно, что латчи требуют повышенной аккуратности.