Connecting a test-bench for a multi device design via an array of interfaces

[Erling]

Say we have a design connected to an UVM test-bench via an interface, i.e. a setup similar to the dut_dummy/xbus_if of the xbus example of UVM, and we wanted to connect multiple such design/interface pairs to some other (singleton) design. A new test-bench would be needed to verify the multi device design, and one should think that it would be a good idea to reuse the passive components and slave agents of the original test-bench to monitor and check activity on each interface. This appears to be easier said than done, however.

I have been thinking about a generate loop to instantiate and connect multiple design/interface pairs, but I have difficulty connecting the interfaces to the driving singleton device, since handles to the interfaces exists inside the generate loop only. The singleton design does not exist a that point, since it can't be instantiated until all interfaces have been created. Problem seems to be that instantiation and connection have to be done in one operation. Another thing is that the test-bench would have to work on an array of interfaces, and this seems to require even more magic since procedural assignment isn't supported inside a generate loop.

Am I missing something obvious, or is the interface construct not suitable for interfacing? Ideas?

Thank you for your time.

Erling

[jadec]

A code example would be useful (what are interface and dut module declarations?), but here's some things that should help:

1) Use a named generate block to access the internally declared instances from outside.

2) You CAN use non-procedural assign in generate (SV allows such assigns to work on interface variables).

[uwes]

hi,

i think the main problem behind your question is: whats wrong with an array of interfaces? and why cant i access them via an index expression?

basically the point is that an interface is an "static" entity similar to a module. when iterating over it it would be hard to ensure that the type (the structure of it) of each of the elements of that array are the same and the access to members is valid. (each of the if instances could be structural different based upon parameters, generates, if, etc).

one way to handle it is to assign the if array to a virtual-if array. the virtual-if array can be used the normal way (because each element has a fixed structure).

the attached code shows the non-working and the virtual interface way

interface test55i;
   bit a;
endinterface

`define NUM 4

module test55;
   virtual test55i my_v_ifs[`NUM];

   generate 
       genvar l;
       for(l=0;l<`NUM;l++) begin: gen_l
           test55i myif();   

           initial my_v_ifs[l] = myif;         
       end
   endgenerate

`ifdef BAD_IF_ARRAY
// this doesnt work because the cnt in gen_l[cnt] has to be a elab time CONSTANT 
// you could reference gen_l[2].myif.a 
// but not something like gen_l[<some non constant>].myif.a 
   initial begin  
       int cnt;      
       for(cnt=0;cnt<`NUM;cnt++)
           gen_l[cnt].myif.a <= 1;
   end      
`endif      

`ifdef VIF_ARRAY
   function void set(virtual test55i some[`NUM]);
       foreach(some[idx])
           some[idx].a <= '1;
   endfunction

   initial begin
       #1 set(my_v_ifs);
   end    
`endif      
endmodule

[Erling]

Thank you for the sample code. Sorry for the unclear problem statement. Going from one design, one interface, one testbench, to a generated design hierarchy with multiple interfaces was perplexing at first.

By the way, is it necessary to have a separate process store each generated interface in the array? It would seem a function call should work, for example:

function int add_v_if(virtual test55i vif);

static int count;

assert(count < `NUM)

my_v_ifs[count++] = vif;

return 1;

endfunction

And then, in the generate loop, replace:

initial my_v_ifs = myif;

with:

int ok = add_v_if(myif);

This should make sure the array is built before any processes are started.

A possible improvement could be to make add_v_if a static member of a class parameterized on the interface type (and the size of the array), so that the add_v_if function wouldn't have to be repeated for each interface type.

Regards,

Erling

[jadec]

UVM takes some care to start only after time 0 blocks have run. You shouldn't have any problem using an initial block to setup the virtual interfaces.

[uwes]

hi,

i would not use the function add_v_if you wrote. this function has bad side effects and the order of actual if's within the my_v_ifs depends on the calling order of your add_v_if function. and this calling order is undetermined (when called from different processes/initial/...)

[Erling]

Agreed. The genvar would have to be passed to the function to have this work correctly.