2016-06-20 4 views
6

Это вопрос вдохновлены этим вопросом и ответом пары: call questa sim commands from SystemVerilog test benchЗачем нужно, чтобы симуляция HDL (из исходного кода) имела доступ к API-интерфейсу тренажера?

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

Так что мой вопрос:

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

Дальнейшее чтение:

+0

Существует острая схожесть с функциональностью VPI или VHPI, для которой VHPI Standard Specification Draft 4.7 1.1.1 Требования и руководящие принципы процедурного интерфейса VHDL дают возможность разработки таких приложений, как: обходные пути проекта, netlisters, экстракторы подключения, совместное моделирование, интерфейсы объединительной платы, модели поведения, среды отладки, тестовый стенд и проверка симуляции, профили кода VHDL и инструменты покрытия, декомпиляторы VHDL и калькуляторы задержки. Передача программного управления с симулятора на внешний код позволяет вам делать что угодно. – user1155120

+0

nvc Nick Gasson имеет оболочку Tcl, которая может быть вызвана опцией командной строки и имеет накладную нагрузку на время запуска моделирования около 70 КБ. Кевин Тибедо ничего не обновил, кроме документации для VerTCL (и vhdl-extras, а также ~ 20 000 строк VHDL) с момента перехода на github (ожидая потери кода Google). Есть кокотб, который позволяет получить более высокий уровень абстракции, чем вы могли бы использовать VHPI (или VPI или FLI), напрямую преодолевая недостатки функций языка описания системы VHDL. – user1155120

ответ

2

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

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

К примеру, у меня есть этот «общий» TestBench код как:

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, я нахожу его увлекательным. Но неполное. Или, по крайней мере, баребоны. Я нахожу скриптовые тестовые игры чрезвычайно полезными (мы используем их там, где я работаю). И VerTCL - отличный способ сделать это (если вам нравится TCL). Но для этого требуется какая-то фреймворк для считывания сигналов, сигналов возбуждения и, в противном случае, управления имитацией.

2

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

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

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

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