Bagaimana cara mengimpor makro SystemVerilog?

Saya sedang mengembangkan monitor SystemVerilog yang memperluas ovm_monitor dan saya ingin mengetahui cara mengimpor makro ovm yang saya gunakan. Saya menggunakan:

`ovm_component_utils_begin
`ovm_field_string
`ovm_component_utils_end

Saya mencoba yang berikut ini di bagian atas file saya, keduanya tidak dapat dikompilasi:

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

Dan

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

Kesalahan kompilasi 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)
                                        ^

Berikut ini berfungsi, tetapi saya menganggap penggunaan * dalam pernyataan import sebagai praktik yang buruk:

import ovm_pkg::*

verilog system-verilog
person Victor Lyuboslavsky    schedule 29.02.2012    source sumber
comment
Apa kesalahan kompilasi Anda? Pernyataan import tidak mempengaruhi arahan praprosesor. Alat ini harus menemukannya sebelum kode sumber Anda.   -  person    schedule 01.03.2012
comment
Kesalahan kompilasi terjadi ketika kompiler datang ke salah satu makro ovm yang saya gunakan kecuali saya menggunakan import ovm_pkg::*   -  person Victor Lyuboslavsky    schedule 01.03.2012
comment
Ya, tapi apa kesalahan kompilasinya? Anda harus menyertakan pesan yang tepat dalam pertanyaan Anda.   -  person    schedule 02.03.2012
comment
Perhatikan bahwa Anda tidak dapat mengimpor definisi makro, itu adalah arahan pra-prosesor kompiler yang bukan milik paket apa pun.   -  person dave_59    schedule 10.10.2013

Jawaban (4)


arrow_upward
3
arrow_downward

Mengimpor dengan * sebenarnya adalah praktik terbaik.

Mengimpor dengan * membuat semua isi paket terlihat tetapi tidak melakukan impor sebenarnya sampai digunakan. Mengimpor suatu fungsi berdasarkan nama akan segera mengimpor fungsi tersebut baik digunakan atau tidak (itu adalah praktik yang lebih rendah).

Pengguna OVM atau UVM diinstruksikan untuk tidak pernah mendefinisikan kelas atau makro apa pun yang ditentukan pengguna menggunakan awalan "ovm_" karena versi OVM mendatang mungkin menambahkan lebih banyak ovm_classes atau `ovm_macros, jadi mengimpor paket OVM dengan * aman.

Jika Anda mengimpor dua paket dengan * dan jika kedua paket memiliki nama fungsi yang sama, jika kode Anda tidak menggunakan fungsi tersebut, tidak ada masalah. Jika kode Anda memerlukan fungsi tersebut, awali fungsi tersebut dengan pkg2::function_name, yang sekali lagi merupakan praktik terbaik.

Salam - Cliff Cummings - Verilog & SystemVerilog Guru

person Cliff Cummings    schedule 27.06.2012
comment
Mengimpor dengan * hanyalah praktik terbaik untuk SV. Biasanya kita harus menghindari polusi namespace dan mengimpor menggunakan * melanggar hal ini. SV+UVM agak rusak - harus menggunakan paket untuk perbedaan namespace atau konvensi penamaan (yaitu ovm_pkg::function() atau ovm_function()) tetapi menggunakan keduanya jelek! - person Chiggs; 11.12.2013
comment
Oh untuk namespace hierarki yang tepat seperti yang kita miliki di Python! Saya mengirimkan proposal VHDL, mungkin kita bisa mendapatkan sesuatu yang lebih baik ke dalam standar SystemVerilog berikutnya? - person Chiggs; 11.12.2013

arrow_upward
1
arrow_downward

Sepertinya ada definisi kelas yang hilang untuk ovm_component_registry, antara lain. Saya bukan pengguna OVM yang sesungguhnya, namun penggunaan makro dan penyertaan bersarang yang ekstensif berarti Anda mungkin perlu melihat keluaran yang telah diproses sebelumnya.

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

Ini seharusnya menjadi komentar atas tanggapan Adam12 tetapi saya tidak dapat menambahkan komentar.

@Victor Lyuboslavsky, Jika Anda tidak ingin menggunakan import ovm_pkg::*, Anda harus melihat perluasan makro, atau kode perluasan yang dihasilkan oleh makro, dan import pengidentifikasi yang diperlukan, misalnya. ovm_component_registry, ovm_object, OVM_CHECK_FIELDS (berdasarkan jawaban Adam12).

Namun di masa depan, makro ovm_component_utils_* atau ovm_field_* dapat berubah untuk menyertakan lebih banyak pengidentifikasi OVM dan Anda harus mengubah kodenya menjadi import pengidentifikasi tambahan ini.

person Paddu    schedule 17.05.2013

arrow_upward
0
arrow_downward

Sayangnya, tidak banyak pilihan untuk melakukan import ovm_pkg::*. OVM tidak sepenuhnya memenuhi syarat semua namanya dengan nama paket secara internal sehingga hampir tidak mungkin mendapatkan kode untuk dikompilasi tanpanya.

person Steve K    schedule 01.03.2012
comment
Saya berasumsi maksud Anda makro tidak memenuhi syarat namanya. Tidak masalah jika kode dalam paket tidak. Saya tidak pernah menyadarinya, tetapi tidak menggunakan nama yang sepenuhnya memenuhi syarat adalah hal yang buruk. Saya ingin tahu apakah UVM lebih baik. - person Paul S; 02.03.2012