Jump to content

    

demidrol

Свой
  • Content Count

    113
  • Joined

  • Last visited

Community Reputation

0 Обычный

About demidrol

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

Контакты

  • Сайт
    Array
  • ICQ
    Array

Recent Profile Visitors

2296 profile views
  1. 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. только плис
  2. господа, а не подскажите, какие из EDA-утилит поддеживают смешанный дизайн, в котором модули на SV используют типы (record, как правило), объявленные в VHDL package? А то есть большая библитека (grlib), написанная на VHDL, но свои модули, а особенно тесты к ним писать на нем же прямо больно. Знаю, что с симуляторами проблем не возникает. Во всяком случае, QuestaSim такое спокойно позволяет взять тип из VHDL-пакета. Больше интересуют утилиты для синтеза. Кажется, Synopsys DC в пролете? Как с этим дела у Cadence?
  3. чего только не выдумывают люди, лишь бы не использовать verilog-mode. AUTOREG/AUTOWIRE знатно помогают создавать такие вот декларативные блоки.
  4. классно, спасибо! Есть только пара "но" 1. Я так понял, что у вас не было вариантов разварки (т.е. все пады всегда выводились наружу) 2. А как было устроено документирование самого pinmux'а? Т.е. были ли у вас переназначаемые или многофункциональные пины, а если да -- то как указывались источники сигналов для мультиплексоров (сигнал ли это с выделенного пада или внутренний регистр, управляемый процессором).
  5. спасибо отписавшимся! Понятно, будем велосипедить. А между прочим, в целях повышения уровня сознательности — не осталось ли у вас примерной "рыбы" экселевского файла? Понятно, что задачи у всех разные, но все же...
  6. Как правило, в корпусах ножки -- ограниченный ресурс, и поэтому приходится так или иначе их мультиплексировать (скажем, uart.tx, spi.sck и gpio). В целом, для маленьких корпусов написать мультиплексоры вручную -- не проблема, но когда их количество приближается к сотне-другой -- становится страшно что-то перепутать. Ну, и тесты пропорционально разбухают. Вопрос к знатокам -- а не придумало ли человечество какого-нибудь способа описывать такие вот мультиплексоры на ногах микросхем? Мол, у первой ножки -- функции такие-то, переключаются они таким-то битом в таком-то регистре. Да вот даже какой-нибудь XML? Профит очевиден -- из xml-подобного описания можно было бы сгенерировать как HDL для синтеза, так и BSDL-файл для скан-тестирования, так и заголовочные файлы для софта. Велосипед изобретать уж очень не хочется.
  7. О, так я просто такую весчь проглядел. Допилю, конечно же. Хотя не. Вопрос такой -- на целой SoC этот самый ls-fuse не сдохнет от жора памяти? Да и файлик с ls -lR выйдет гигабайтым. JSON-то для иерархии я выбрал как раз из соображений минимализма.
  8. Хочу тут немного свой велосипед попиарить. Репорты dc_shell по площади читать уж больно неудобно -- так сразу непонятно, кто больше всего ее отъедает. Наваял тут мелкий инструмент, немного упрощающий жизнь. https://github.com/dmitrodem/sizefs Состоит из двух скриптов. Тот, что на tcl -- запускается из top-level дизайна в dc_shell, на выходе получается json-файл с иерархией (с отмеченными площадями "листьев" -- блоков из библиотеки). Далее этот файл используется питоновским скриптом, реализующим sizefs -- файловую систему в FUSE, единственное назначение которой -- показывать структуру директорий и размеры файлов. Что мне понравилось -- на смонтированную ФС можно натравить утилиты для анализа дискового пространства (мне нравится кдеешный Filelight, но годится и xdiskusage. Да даже обычный du).
  9. а зачем блочную память (даже набранную из триггеров) включать в скан-цепочку? Почему ее обычными BIST не тестировать? я ж предлагаю по границе памяти поставить обычные триггеры. Понятно, что латчи требуют повышенной аккуратности.
  10. Пишу тут обертки для блочной памяти, для выбора наиболее оптимального варианта (регистры, 128x8, 2048x8) по площади. И вот возникает вопрос -- а почему, собственно, память на регистрах делают из D flip-flop'ов? Почему-то ни разу не встречал варианта, сделанного из latch'ей, хотя они по быстродействию и площади вроде бы гораздо предпочтительнее обычных триггеров. Да, как минимум на входы надо будет поставить DFF, но это ж мелочи (по сравнению с массивом). Так почему ее не делают из защелок? Сложности в статическом анализе таймингов?
  11. Благодарю! У меня просто получилась смешная ситуация, когда заказчики не выдали требований на внешние сигналы.
  12. Сижу и ломаю голову, как правильно было бы проводить синтез системы на кристалле: просто core-логику или ее же с прицепленными падами. Пока вижу такие особенности дизайна с падами 1. надо явным образом выписывать false paths для "медленных" сигналов (типа включить-выключить pull-up на двунаправленном паде) 2. можно забить на спецификацию input и output задержек (выставить их в 0) -- пады-то уже на месте. 3. можно точно так же не морочиться с set_drive/set_load по той же причине. 4. из минусов -- труднее протаскивать скан-цепочку (поскольку "пустые" пады для выходов тестовых векторов синтезатор, конечно же, прицепит куда-то -- или на 0, или на 1. И их придется отцеплять) В общем, хотелось бы послушать ваше мнение по этому вопросу.
  13. Подскажите, пожалуйста, где у Synopsys находится их Design Compiler Reference Manual? Смотрел содержимое syn_vA-2007.12-SP2, syn_vH-2013.03-SP1 и syn_vL-2016.03 -- из документации там только man-страницы. Сомневаюсь, что это и есть их рефмануал. Или он водится только в их SolvNet при наличии валидной лицензии?