Escorial

Нет, есть версии указанных библиотек под SystemVerilog.

А Вам удалось там сделать русифицированный шаблон проекта?

У кого-нибудь есть опыт использования систем управления требованиями? Хочется для нового проекта попробовать использовать, но глаза разбегаются. Какую систему посоветуете? Насколько я понял из представленной в инете информации сейчас на рынке 4 основных игрока: 1) IBM Doors (бывшая Telelogic DOORS). - версия 8 представлена на FTP. 2) IBM Requisite PRO. 3) Borland CaliberRM 4) Polarion Requirements. Последние две радуют тем, что есть возможность работать через WEB-интерфейс, без установки специального клиента. Но лекартсва нет. ( RequisitePRO пощупать не получилось, но я так понял WEB-интерфейса там нет и сильно все завязано на другие инструменты от IBM т.е. ставить только ее нет смысла. DOORS - только через клиент, показалась очень тормознутой - на пустом проекте рисовала окошки секунд 10. Не думаю, что приживется. От системы хочется следующих основных качеств: 1) WEB интерфейс (или в крайнем случае мультиплатформенный клиент). 2) связь требований между проектами. 3) шаблоны требований для проектов/шаблоны проектов. 4) связь между требованиями и системой планирования задач, чтобы было возможно контролировать реализацию некоторых требований.

Ого, сколько Вы тут без меня написали. Спасибо за участие. :) Докладываю: SM Netlist самый что ни на есть транзисторный (tranif0 и т.д. в netlist'e), естественно без реальных значений задержек/параметров транзисторов. ALL Проще всего loop оказалось отследить в IUS 5.7 - там добавилась опция +gateloopwarn (или что-то в этом роде, из дома пишу не могу точное название проверить), с этой опцией симулятор спотыкается через небольшое время и позволяет посмотреть зацикленные сигналы командой а-ля "drivers active" (будет возможность, поправлю пост на точные варианты команд).

Спасибо, попробую покопать в этом направлении. SM, SDF'a нет - netlist с нулевыми задержками, задача подтвердить работу логической модели (схема на транзисторном уровне). Более того, в симуляторе стоит ключ notimingcheck. Но я не вижу как это может влиять на зависание в конкретной точке моделирования (первый фронт синхросигнала) - даже если все пути с нулевым временем распространения, верхний уровень с тестбенчем, формирующим воздействия все равно никуда не деется и время будет тикать, как это нужно тестбенчу. P.S. Кстати, если забыть подключить SDF задержки все же не будут нулевые, т.к. по умолчанию в либах в specify-блоках пишут значения для typical-случая.

Тогда это осложнение, связанное с тем, что некоторые триггера в дизайне изменят свою полярность в результате синтеза необходимо учитывать при использовании white box подхода.

В числе фич VMM прибыло - на vmmcentral.org выложили новую книгу и (возможно) базовые классы для Low-Power проектов с отключаемыми блоками.

Андрей, возможно у Вас ошибка (выделил жирным шрифтом). Извините за дотошность, но вдруг вы приведенные данные из исходных текстов у себя скопировали.

При цифровом моделировании netlist'a (RTL к нему увы отсутствует) симулятор ncverilog уходит в себя, начиная со скоростью мысли накручивать delta-циклы, но время моделирования при этом не продвигается. При этом место, на котором он повис почему-то не показывает. Подозреваю combinational loop'ы, можно ли их как-нибудь отследить? Другой симулятор, специальные lint-инструменты (какие именно)?

В качестве примера BFM-чекера, можете посмотреть на ассерты для шины AMBA3-AXI. По указанному адресу нужно зарегистрироваться и тогда можно будет скавчать саму спецификацию и набор assert'ов. http://www.arm.com/products/solutions/axi_spec.html P.S. В VCS_08 есть встроенные Assert'ы на стандартные интерфейсы (USB, I2C, OCP, AXI, PCI и т.д.). Тэгами синтеза вы запретили изменение полярности триггера? У меня было пару раз после синтеза на вход внутреннего триггера приходило инверсное значение (по сравнению с RTL) и на выходе тоже инвертор стоял, а т.к. тест ссылался на само значение триггера - получалось нехорошо - на RTL тест работал, на NETLIST'e нет.

Спасибо, статья хорошая, давно такую искал. Во многом критика на мой взгляд справедливая. Понравилась идея портов для всех компонентов тестбенча, причем правильность их соединения проверяется во время компиляции, в то время как за то, что попадает в vmm_channel отвечает сам пользователь и проблемы вылезут только на этапе runtime. Справедливая критика в отношении нарушения принципа инкапсуляции в vmm при создании конфигурации тестового окружения, когда некоторая законченная тестовая система блока СНК не может без модификации быть перенесена в состав тестовой системы всей СНК. Видимо действительно, OVM выигрывает в идеологическом плане в части следования концепциям ООП, но на данный момент по количеству встроенных возможностей, применимости, количеству документации и простоты освоения мне ближе VMM.

Если смотреть в сторону методологий, то в VMM есть Memory Allocation Manager, который отвечает за формирование в памяти неперекрывающихся структур и их удаления после использования. Либо можно взять его исходник и переделать под себя. http://vmmcentral.org/pdfs/using_memory_allocation_mger.pdf

Указанный в первом посте фильтр обновился до версии 2.2.0. заявлена поддержка Verilog-модулей, интерфейсов.

Спасибо всем ответившим, добавлю еще инфу почерпнутую с eda-board: NanoSim быстрее HSIM на больших проектах. Однако HSIM благодаря технологии выделения однотипных элементов быстрее при моделировании больших блоков памяти.

Здраствуйте, возникла необходимость моделирования большого проекта на транзисторном уровне с новыми spice-модллями транзисторов. По блокам проект разбить не получается - есть только flattern-топология, иерархия утеряна. Нужно проверить, что при использовании конкретных spice-моделей проект останется работоспособен. Всвязи с этим возник вопрос, какая программа сможет обеспечить приемлемое быстродействие на таком большом проекте? Пока склоняюсь к UltraSim, может есть что-то более шустрое в ущерб точности. Быть может есть какие-либо хитрости в самом UltraSim, чтобы ускорить процесс моделирования? Вариант mixed-mode в данном случае не подходит, т.к. есть только топология.

Здраствуйте, похожая задача стояла. В данном классе (vmm data stream scoreboard) есть методы: expect_in_order (ожидать пакет в том же порядке в котором был положен в скоребоард) expect_out_of_order (пакеты не по порядку). expect_with_losses (в моем случае пакеты теряться не могли, поэтому не использовал но по логике думаю при получении пакета, все исходящие пакеты, которые стояли до него удаляются из очереди). Но это только мои фантазии. Могу порекоммендовать зайти на сайт vmmcentral.org и скачать там руководство vmm scoreboarding от Janick Bergeron.

Думаю важно функции сравнивать, а не объем кода. Пока добавил файлик с базовыми классами, буду признателен если кто подхватит инициативу и дополнит его.vmm_vs_ovm.txt

1. Не совсем понятно в чем разница в первом примере если поставить automatic перед int k или убрать? 2. Насчет того, какой смысл в директиве automatic перед module/program - возможно все процедуры и функции в данном структурном элементе приобретут данный аттрибут. Смысл его в том, чтобы иметь возможность одновременно вызывать несколько раз один и тот же task к примеру с разными параметрами внутри одного fork_join цикла - т.е. при каждом вызове создается новая копия всех внутренних переменных task'a. 3. Соответственно в приведенном Вами примере не указана директива automatic перед task_good/task_bad. Следовательно при одновременном вызове данного task'a из разных процессов может произойти следующее: 1 процесс вызвал task, методом new создан объект, выделена память под него и создан указатель. Идет вызов из другого процесса, дошли до метода new - увидели что объект уже создан (task статический), указатель не поменяли. В это время первый процесс завершает свой task - память освобождается и запуск функции randomize вторым процессом приведет к ошибке.

Да. Для документирования RTL-кода он конечно не подходит пока. Именно про это я и говорил. Если вы посмотрите сам perl-фильтр ( idv_doxyfilter_sv.pl), вы увидите что делается со словом module. Нужно придумать, что делать с input'ами|output'ами. Вот к примеру, что делается с bit/wire/reg etc.: # Logic Types with defined widths # Looking for: # logic [10:4] foo ... # bit[1:0] wee ... # # Current Strategy: # - Convert to a C++ template class instance s/\b(logic|bit|wire|reg)\s*?\[(.+?):(.+?)\]\s*?/$1 <$2:$3> /g;

По поводу истории: концепции VMM на 90 процентов были обкатаны еще в RVM, которая создавалась когда стандарта TLM еще не было. Это, кстати, рассматривается OVM-пользователями как один из недостатков, т.к. собственная версия реализации TLM через класс vmm_channel потенциально может вылиться в проблемы со стыковкой с SystemC - окружением. Я этим не занимался, поэтому сложно судить. Понимаете, т.к. обе методологии заточены под стандартизованный язык, то со временем они обе будут полностью поддерживаться всеми производителями САПР. Свидетельством тому и VIP Technical Standart Commitee в Accellera. Пока, насколько мне известно все проблемы с переносимостью были вызваны плохой поддержкой стандарта языка отдельными производителями САПР (Cadence здесь, похоже, сильнее всех отстает). Знаю, что сегодня VMM работает на QuestaSim, по IUS нет данных. Единственное, где на мой взгляд могут возникнуть проблемы - это заточенность специальных вспомогательных тулзов под конкретную методологию. Т.е. в пакет Incisive могут включить графический инструмент для построения RAL-модели устройства для OVM, ясно что Synopsys под OVM ничто подобное никогда не выпустит.

Хотелось бы узнать, в какую сторону склонились участники форума в своем выборе методологии верификации и почему. По моему мнению, VMM стартовав раньше теперь будет всегда опережать OVM на пару шагов вперед. Это связано как с первоначальным лидерством (VMM появилась раньше AVM/UVM), так и с людьми, вовлеченными в ее развитие - например Janick Bergeron из Synopsys прекрасный тому пример. Преимущества VMM на мой взгляд: 1. RAL (Register Abstraction Layer) - был впервые предложен в VMM, появился только в OVM 2.0. Глубина поддержки не известна (поддерживается ли автоматический анализ функционального покрытия, формируются ли автоматически тесты для всех регистров, доступных через RAL - все это уже есть в VMM). 2. HAL (Hardware Abstraction Layer) - для работы с ускорителями. 3. Анализ загруженности ресурсов для анализа потенциальных узких мест в проекте. 4. Встроенные в базовые классы callback -методы. Возможно нижеперечисленные фичи VMM можно найти и в OVM, а может и нет: 1. Специальный класс для многопотокового скоребординга со встроенными методами сравнения полученных-отправленных пакетов, как строго по порядку, так и без строгого порядка, или даже с потерями. Буду признателен, если меня кто поправит/дополнит.

На vmmcentral.org опять втихую обновили VMM. Краткий список изменений: ** Standard Library - Added base class for testcases (vmm_test) - Introduced vmm_ms_scenario base class - Added multi-stream scenario generator (vmm_ms_scenario_gen) - Added by-name scenario registry to single-stream scenario generator - Added transactor iterator (vmm_xactor_iter) - Added ability to specified channel relationships - Added vmm_log::catch() - Added command-line option manager (vmm_opts) - Added short-hand macros for vmm_env, vmm_subenv and vmm_xactor ** Register Abstraction Layer - Added field value and address map coverage models. - Added hierarchical coverage directives to RALF ** Scoreboard - Added +vmm_sb_trace and +vmm_sb_debug command-line options ** Performance Analyzer (connected to SQL database) - First open source release

Спасибо за ссылку, давно искал фильтр для doxygen, который SV в C++ превращает. А что именно Вы хотите задокумментировать? Насколько я помню, на verificationguild в свое время шло обсуждение аналогичного парсера. Там довольно простые правила замены использовались, чтобы привести SV к C++. Поэтому если вы хотите Verilog-testbench описать (в плане параметров, передаваемым task'ам или функциям, я думаю у вас проблем не будет). В текущей версии модуль подменяется на С++ функцию, возвращающую тип module, так что распознаются не только классы. Если просто нужна документация для галочки - посмотрите Mentor Graphics HDL Designer - они поддерживают в последних версиях SV и формируют HTML документацию, однако по мне doxygen - удобнее, а для восприятия RTL гораздо нагляднее блок-схемы.

Спасибо большое, насколько я понимаю для Компас в таком случае нужен IDF-конвертор. Никто не подскажет где такой зверь обитает, может в закромах? :)

Maksya, в своей статье Вы ссылаетесь на книжку vhdl_cohen, нет ли у Вас ее в электронном виде и не могли бы вы ее выложить на фтп? По поводу статьи, мне кажется в ней есть фактическая неточность - PSL состоит из 2х частей - базиса (LTL-логика), и т.н. Optional Branching Extensions (CTL). Если сравнивать PSL и SVA, мне кажется в плане функционала выигрывают последние, т.к. позволяют использовать методологию coverage driven verification (т.е. когда определенная контрольная точка функционального покрытия выполнена, прекращаем формировать рандомные пакеты для заданного блока). Т.е имеем двунаправленную интеграцию формальные утверждения <-> тестбенч. В PSL можем гнать данные только в 1 конец. Кто-то интересовался синтезом ассертов, если коротко любая LTL-формула может быть представлена в виде автомата Бюхи. Есть САПРы которые синтезируют ассерты в виде некоторого блока, вставляемого в RTL, что позволяет их использовать в FPGA любого производителя. Контроль идет через специальный отладочный порт а-ля JTAG и спецсофт компании-разработчика. Посмотрите например, Dialite от Temento Systems.