Почему моделирование HDL (из исходного кода) должно иметь доступ к API симулятора?

Это вопрос, вдохновленный этой парой вопросов и ответов: вызывать команды questa sim из тестового стенда SystemVerilog

Вопросы задают вопрос, как код Verilog может управлять исполняющим симулятором (QuestaSim). Я видел похожие вопросы и подходы и для VHDL.

Итак, мой вопрос:

  • Почему симуляция (ведомое устройство) должна иметь мощность своего симулятора (ведущего)?
  • Каковы типичные варианты использования?

Дополнительная литература:


simulation verilog vhdl questasim
person Paebbels    schedule 20.06.2016    source источник
comment
Существует резкое сходство с функциональностью VPI или VHPI, для которых в проекте стандартной спецификации VHPI 4.7 1.1.1 требования и руководящие принципы процедурного интерфейса VHDL дали возможность разработки таких приложений, как: обходы проектирования, списки соединений, экстракторы связности, совместное моделирование. , интерфейсы объединительной платы, поведенческие модели, среды отладки, стенд для моделирования и проверки, профили кода VHDL и инструменты покрытия, декомпиляторы VHDL и калькуляторы задержки. Передача программного управления от симулятора к внешнему коду позволяет вам делать что угодно.   -  person    schedule 24.06.2016
comment
В nvc Ника Гассона есть оболочка Tcl, которую можно вызвать с помощью параметра командной строки, и накладные расходы на время выполнения моделирования составляют около 70 КБ. Кевин Тибедо не обновлял ничего, кроме документации для VerTCL (и vhdl-extras, вместе ~ 20 000 строк VHDL) с момента перехода на github (ожидая потери кода Google). Существует cocotb, который обеспечивает более высокий уровень абстракции, чем при использовании VHPI (или VPI, или FLI), напрямую преодолевая недостаток VHDL в функциях языка описания системы.   -  person    schedule 24.06.2016

Ответы (2)


arrow_upward
2
arrow_downward

Почему? Кто-нибудь может ответить «почему»? Что ж, возможно, разработчик продукта или разработчик в Mentor, который привел к созданию такого поведения, сможет ответить на этот вопрос. Но об отсутствии этого можно только догадываться. И вот что я здесь делаю.

Я могу придумать несколько возможных вариантов использования, но это не то, что нельзя сделать другим способом. Например, у кого-то может быть общий «контроллер тестового стенда», который в зависимости от обобщений / параметров может вызывать определенное поведение симулятора. (Изменить: перечитав одну из ваших ссылок, я вижу, что это точный вариант использования.)

Например, скажем, у меня есть этот «общий» код тестовой среды как:

module testbench;

parameter LOG_SIGNALS = 1'b0;

initial
begin
  if LOG_SIGNALS
  begin
    // Log all signals in the design
    mti_fli::mti_Cmd("add wave -r /*")
  end

endmodule

Тогда это можно было бы вызвать как:

vsim -c -gLOG_SIGNALS=1 work.testbench

Самый большой вариант использования для этого может быть, если vsim вызывается из некоторой среды. Если бы нужно было сделать do файл, я не уверен, что можно передать параметры в скрипт. Скажем, у одного был следующий do файл:

if {$log_signals} {
  add wave -r /*
}

Как установить $log_signals из командной строки? Я полагаю, что это можно сделать с помощью переменных окружения, таких как:

if { [info exists ::env(LOG_SIGNALS)] } {
  add wave -r /*
}

Другими вариантами использования могут быть включение / выключение сбора данных покрытия, файлов списков, возможно, даже необычный случай завершения моделирования.

Но, конечно, со всем этим можно справиться и по-другому. И манеры, на мой взгляд, намного яснее и легче в обслуживании.

Что касается VerTCL, я нахожу его захватывающим. Но неполный. Или хотя бы barebones. Я считаю, что сценарии тестирования чрезвычайно полезны (мы используем их там, где я работаю). И VerTCL - отличный способ сделать это (если вам нравится TCL). Но для считывания сигналов, управления сигналами и иного управления симуляцией требуется некоторая структура вокруг него.

person PlayDough    schedule 23.06.2016

arrow_upward
2
arrow_downward

В идеале вам не понадобится API-интерфейс симулятора, если HDL будет достаточно всеобъемлющим, чтобы выполнять все функции, которые в настоящее время возложены на симулятор. Вначале Verilog был реализован как интерпретируемый язык, а командная строка была языком Verilog вместо какого-либо другого интерфейса командной строки, который мы видим сегодня на основе Tcl.

Но по мере того, как симуляторы становились все более сложными, им требовались команды, которые взаимодействовали с файловой системой, платформой, ОС, а также другими функциями быстрее, чем стандарт HDL мог поддерживать. Стандарты IEEE HDL ограничиваются любыми конкретными деталями реализации.

Поэтому поставщики средств моделирования разработали интерфейсы командной строки (CLI) для удовлетворения потребностей пользователей в отладке и анализе. Эти интерфейсы командной строки достаточно надежны, чтобы создавать стимулы и проверять поведение, которое может перекрывать функциональность кода интерфейса командной строки и того, что находится в исходном коде вашей тестовой среды. Таким образом, наличие API для ваших симуляторов CLI может упростить управление потоком команд симулятору и избежать дублирования процедур.

Например, может быть, вы хотите начать регистрацию сигналов, чтобы добавить их к форме волны после того, как проект выйдет из состояния сброса. Из интерфейса командной строки вам нужно будет установить условие наблюдения для сигнала сброса, который выполняет команду регистрации, когда сброс становится неактивным. Используя API-интерфейс симулятора, вы можете просто поместить эту команду в свой стенд в том месте, где находится сброс релиза.

person dave_59    schedule 24.06.2016