Как импортировать макросы SystemVerilog?

Я разрабатываю монитор SystemVerilog, который расширяет возможности ovm_monitor, и мне хотелось бы знать, как импортировать макросы ovm, которые я использую. Я использую:

`ovm_component_utils_begin
`ovm_field_string
`ovm_component_utils_end

Я пробовал следующее в верхней части моего файла, оба из которых не компилируются:

import ovm_pkg::ovm_monitor;
import ovm_pkg::ovm_macros;

и

import ovm_pkg::ovm_monitor;
`include "ovm_macros.svh"

Ошибка компиляции VCS:

Error-[SE] Syntax error
  Following verilog source has syntax error :
  "my_monitor.svh", 58 (expanding macro): token is '#'
  `ovm_component_utils_begin(my_monitor)
                                        ^

Следующее работает, но я считаю плохой практикой использовать * в операторе импорта:

import ovm_pkg::*

verilog system-verilog
person Victor Lyuboslavsky    schedule 29.02.2012    source источник
comment
Какая у вас ошибка компиляции? Оператор импорта не влияет на директивы препроцессора. Инструмент просто должен встретить их до вашего исходного кода.   -  person    schedule 01.03.2012
comment
Ошибка компиляции возникает, когда компилятор переходит к одному из макросов ovm, которые я использую, если я не использую import ovm_pkg::*   -  person Victor Lyuboslavsky    schedule 01.03.2012
comment
Да, но в чем ошибка компиляции? Вы должны указать точное сообщение в своем вопросе.   -  person    schedule 02.03.2012
comment
Обратите внимание, что вы не можете импортировать определения макросов, это директивы препроцессора компилятора, которые не принадлежат ни одному пакету.   -  person dave_59    schedule 10.10.2013

Ответы (4)


arrow_upward
3
arrow_downward

На самом деле лучше всего импортировать с *.

Импорт с * делает видимым все содержимое пакета, но не выполняет фактический импорт, пока не будет использован. Импорт функции по имени немедленно импортирует функцию, независимо от того, используется она или нет (это низшая практика).

Пользователи OVM или UVM проинструктированы никогда не определять какие-либо определяемые пользователем классы или макросы с использованием префикса «ovm_», поскольку будущие версии OVM могут добавлять больше ovm_classes или `ovm_macros, поэтому импорт пакетов OVM с * безопасен.

Если вы должны были импортировать два пакета со знаком * и если оба пакета имели одно и то же имя функции, если ваш код не использует эту функцию, проблем нет. Если вашему коду требуется функция, добавьте к функции префикс pkg2 :: function_name, что снова является наилучшей практикой.

С уважением - Клифф Каммингс - Verilog и SystemVerilog Guru

person Cliff Cummings    schedule 27.06.2012
comment
Импорт с * - лучшая практика только для SV. Обычно нам следует избегать загрязнения пространства имен, и импорт с использованием * нарушает это. SV + UVM немного не работает - следует использовать пакеты для разделения пространства имен или соглашения об именах (например, ovm_pkg::function() или ovm_function()), но использовать оба варианта просто некрасиво! - person Chiggs; 11.12.2013
comment
О, для правильных иерархических пространств имен, как у нас в Python! Я отправил предложение VHDL, возможно, мы сможем получить что-нибудь получше в следующий стандарт SystemVerilog? - person Chiggs; 11.12.2013

arrow_upward
1
arrow_downward

Похоже, что среди прочего отсутствует определение класса для ovm_component_registry. Я не являюсь настоящим пользователем OVM, но его обширное использование вложенных включений и макросов означает, что вам, вероятно, потребуется просмотреть предварительно обработанный вывод.

class top extends blah;



   typedef ovm_component_registry #(top,"top") type_id; 
           ^
   static function type_id get_type(); 
     return type_id::get(); 
   endfunction  

   const static string type_name = "top"; 
   virtual function string get_type_name (); 
     return type_name; 
   endfunction  

   static bit m_fields_checked = 0; 
   function void m_field_automation (ovm_object tmp_data__=null, 
                                     int what__=0, 
                                     string str__=""); 
   begin 
     top local_data__; /* Used for copy and compare */ 
     string string_aa_key; /* Used for associative array lookups */ 
     /* Check the fields if not already checked */ 
     if(what__ == OVM_CHECK_FIELDS) begin 
       if(! top::m_fields_checked) 
         top::m_fields_checked=1; 
       else 
         return; 
     end 
     /* Type is verified by ovm_object::compare() */ 
     super.m_field_automation(tmp_data__, what__, str__); 
     if(tmp_data__ != null) 
       /* Allow objects in same hierarchy to be copied/compared */ 
       if(!$cast(local_data__, tmp_data__)) return; 
     if(what__ == OVM_CHECK_FIELDS) begin 
       m_field_array.delete(); 
     end 

     end 
   endfunction(top)


endclass
person Community    schedule 02.03.2012

arrow_upward
1
arrow_downward

Это должен быть комментарий к ответу Adam12, но я не могу добавлять комментарии.

@Victor Lyuboslavsky, если вы не хотите использовать import ovm_pkg::*, вам нужно будет посмотреть на расширение макроса или развернутый код, созданный макросом, и import необходимые идентификаторы, например ovm_component_registry, ovm_object, OVM_CHECK_FIELDS (на основе ответа Adam12).

Однако в будущем макросы ovm_component_utils_* или ovm_field_* могут измениться, чтобы включить больше идентификаторов OVM, и тогда вам придется изменить код на import эти дополнительные идентификаторы.

person Paddu    schedule 17.05.2013

arrow_upward
0
arrow_downward

К сожалению, выбор импорта ovm_pkg :: * невелик. OVM не полностью квалифицирует все свои имена с именем пакета внутри, поэтому практически невозможно получить код для компиляции без него.

person Steve K    schedule 01.03.2012
comment
Я полагаю, вы имеете в виду, что макросы не соответствуют своим именам. Не имеет значения, нет ли в пакете кода. Я никогда не замечал, но не использовать полностью определенные имена - это довольно дрянно. Интересно, лучше ли UVM. - person Paul S; 02.03.2012