Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Systemverilog - Interface connections

Status
Not open for further replies.

Taher_Selim

Member level 5
Joined
Mar 26, 2008
Messages
83
Helped
11
Reputation
22
Reaction score
4
Trophy points
1,298
Location
Egypt
Activity points
1,801
Hello,
Does anyone have idea if we can connect more than 2 modules with an interface in systemverilog. I tried to do this, but my tool (Mentor Questa) is crashing always. So I am not sure if I am doing something wrong or it is a problem in the tool.

Thanks in advance,
Mohammed
 

Can you explain what you mean with "connect more than 2 modules with an interface" by a simple code example?
 

well, assume that you have DUT with the following ports: (clk, rst. d_in, d_out). and a systemverilog program to give stimuli (so it has the same ports). an interface connecting between them wil contain these ports.
Now I need to connect assertions module to that interface (so that to have direct access to our ports). but we can't bind assertions to interface in systemverilog. so I am thinking to define these assertions in separate module.
so I am having the problem that Questa crashes after it compiles this idea (i.e. it crashes after i defined assertions as a third module connected to the interface).
 

As long as only a single module drives any given signal (assuming this is an internal test - and you're not using tri-states) then you just connect all of your modules in the test harness. This includes the DUT, the driver and the interface checker.

But I think we really need a code example as this kind of setup is fairly normal and shouldnt crash questa (are you sure it's this setup thats crashing it - do you get any error messages?)
 

ok that is what I am doing in my testbench

Code:
//Define interface
hf_sv_interface  hf_tb_intf(clk_tb);

//Define DUT
   hf_field HF_DUT (
      .accept_data   (hf_tb_intf.accept_data_tb),
      .rst            (hf_tb_intf.rst_tb),
      .dout           (hf_tb_intf.dout_tb)
    );

//Define assertions module
sva_hf inst_sva_hf(hf_tb_intf);

//Define Testbench Program
    prog_hf prog_inst (
      .accept_data_pg   (hf_tb_intf.accept_data_tb),
      .rst_pg            (hf_tb_intf.rst_tb),
      .dout_pg(hf_tb_intf.dout_tb));

simply this configuration makes Questa crashes
 

why are you passing the entire interface into the sva_hf module? why not just pass the signals in?
 

Actually this is one of benefits of using interfaces in systemverilog, to act as bundle of your testbench signals. this is instead of writing down signals connections for each module it is connected with.
 

Actually this is one of benefits of using interfaces in systemverilog, to act as bundle of your testbench signals. this is instead of writing down signals connections for each module it is connected with.

I understand this - I have only ever seen it done the module way (all the AXI bus verifiers are modules for example)
What is the declaration of sva_hf ? does it use a virtual interface?

There are problems with interfaces - for example - interfaces dont allow polymorphism - so as I found out recently, defining identical behaviour on two interfaces connected to BFMs has to be done either via copy paste (not wanted) or defining a task in a package with inputs/outputs.
There is also the issue that there are multiple ways to do the same things in interfaces - there isnt really a standard, and it can become a mess (but this is the case across all of system verilog!)
 

Thank you all for your inputs, I really apperciate your way that helped me to clarify this issue.
 

I have not used SV for a while, so I am not aware of any recent changes in the language.

One thing I don't like with SV interfaces is that a default size must be specified for vectors with variable length/width.
This means that you will not get a compile error if you forget to specify the wanted width.
Because of this, it is probably better to set a crazy default value like 99999999 than a more reasonable like 8, 16, 32 or 64.

In my opinion the default value should be optional, and if not specified a compile error should be generated if a width isn't specified when the interface is created.
VHDL generics have the "correct" behavior.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top