UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor dvdgardner
Visitor
2,272 Views
Registered: ‎04-17-2018

Vivado Support for SystemVerilog "Access to interface objects"

 

Section 25.10 of the systemverilog LRM, Access to interface objects, shows that we can have a typedef on an interface object, and that the typdef can be referenced with dot notation.  

 

This works with Vivado but only if I restrict the design to referencing the typdef once, in a single instance.  If fails if I have a second instance.

 

This seems like a Vivado bug.  Am I missing anything?  If not, how do we go about getting this fixed? 

 

The code below illustrates the problem.  Here are the key observations:

 

Note 1: This file will compile successfully if you comment out either of the passthrough instances, but fails when you have two instances.

Note 2: If both passthrough instances are included then Vivado 2017.4 & 2018.1 report the following error:
 [Synth 8-448] named port connection 'food_in\.food[bananahs]' does not exist for instance 'bananahs_passthrough' of module 'N_150D62B0' ["/home/dgardner/workspace/fpga/experiment/project_1/project_1.srcs/sources_1/new/top.sv":50]

Note 3: This code compiles and simulates in Modelsim 10.3d

Note 4: This code compiles and synthesizes in Quartus 16.1

 

`timescale 1ns / 1ps

typedef struct packed {
    logic [31:0] kernels;
} popcorn_t;

typedef struct packed {
    logic [15:0] bananahs;
} bananahs_t;


interface bananahs_if (); 
   typedef bananahs_t food_t; 
   food_t food;
endinterface

interface popcorn_if (); 
   typedef popcorn_t food_t; 
   food_t food;
endinterface


module passthrough
    (
      interface food_in,
      interface food_out
    );
    
    food_in.food_t food;
    
    assign food = food_in.food;
    assign food_out.food = food;
    
endmodule

module top
    (
      popcorn_if popcorn_in,
      popcorn_if popcorn_out,
      bananahs_if bananahs_in,
      bananahs_if bananahs_out
    );
    
    passthrough popcorn_passthrough (
      .food_in(popcorn_in),
      .food_out(popcorn_out)
    );
    
    passthrough bananahs_passthrough (
      .food_in(bananahs_in),  // <-- Ref Note 2.  This is the line vivado points to in the error message (line 50).  
      .food_out(bananahs_out)
    );
            
endmodule

 

12 Replies
Xilinx Employee
Xilinx Employee
2,212 Views
Registered: ‎01-11-2011

Re: Vivado Support for SystemVerilog "Access to interface objects"

I was able to take the sample RTL you provided and got the same results. The module referenced doesn't exist in the RTL, so user's would not be able to debug it. It is also odd that using only one instantiation of the module works, but not any more. I have filed a CR with development to analyze this further, and to see if there are ways to get around this error.

-------------------------------------------------------------------------
Please don’t forget to reply, kudo, and accept as solution!
-------------------------------------------------------------------------
Visitor dvdgardner
Visitor
2,182 Views
Registered: ‎04-17-2018

Re: Vivado Support for SystemVerilog "Access to interface objects"

Thanks for that.

 

How can track the status of this?  It's currently blocking some library design work.   

 

-David

0 Kudos
Xilinx Employee
Xilinx Employee
2,157 Views
Registered: ‎01-11-2011

Re: Vivado Support for SystemVerilog "Access to interface objects"

Hi David, in order to track this, you need to create an SR via the service portal, or contact your local FAE to create an SR.

 

The issue appears to be due to the generic 'interface' passthrough as module ports. If these are changed to specific interfaces, the error does not occur. However, if you are trying to use different widths for elements of the interface, it may be better to use parameterized interfaces as a potential workaround.

-------------------------------------------------------------------------
Please don’t forget to reply, kudo, and accept as solution!
-------------------------------------------------------------------------
Visitor dvdgardner
Visitor
2,107 Views
Registered: ‎04-17-2018

Re: Vivado Support for SystemVerilog "Access to interface objects"

 

This is crazy.  I've been trying for two weeks but Xilinx refuses to provide support to me.  Perhaps someone else can open an SR on my behalf while I try to work through the support issue?  All of the details necessary are in the original post.

0 Kudos
Historian
Historian
2,098 Views
Registered: ‎01-23-2009

Re: Vivado Support for SystemVerilog "Access to interface objects"

Perhaps someone else can open an SR on my behalf while I try to work through the support issue?

 

To be clear - @kmorris has already submitted a CR (change request) - so everything required to get the bug fixed has already been done.

 

The SR will only allow you to get an update on the status of the CR, which (assuming development agrees) will be fixed "at some point in the future". So you don't need to do anything else - the bug is already in the system. Maybe @kmorris can get you a status update...

 

Avrum

 

 

0 Kudos
Highlighted
Visitor dvdgardner
Visitor
1,830 Views
Registered: ‎04-17-2018

Re: Vivado Support for SystemVerilog "Access to interface objects"

I ran into another variation of this issue which is simpler that the previous sample code I posted.  Turns out the issue can occur even without accessing the typedef on the interface.  

 

`timescale 1ns / 1ps

interface bananahs_if (); 
   bit foo; 
endinterface

interface popcorn_if (); 
   bit bar;
endinterface


module passthrough
    (
      interface food_in,
      interface food_out
    );    
    assign food_in = food_out;
endmodule


module top
    (
      popcorn_if popcorn_in,
      popcorn_if popcorn_out,
      bananahs_if bananahs_in,
      bananahs_if bananahs_out
    );
    
    passthrough popcorn_passthrough (
      .food_in(popcorn_in),
      .food_out(popcorn_out)
    );
    
    passthrough bananahs_passthrough (
      .food_in(bananahs_in), 
      .food_out(bananahs_out)
    );
            
endmodule

@kmorris, can you provide an update on the existing CR?

0 Kudos
Scholar markcurry
Scholar
1,823 Views
Registered: ‎09-16-2009

Re: Vivado Support for SystemVerilog "Access to interface objects"

 

Interfaces cannot be assigned like a wire.  This isn't a Vivado issue, but a SystemVerilog language issue.  The spec doesn't even go into details as to what would be "type" compatible between different interfaces

 

The need is there to do what you're asking.  However, the language is lacking int this.  We've not found a reusable way of doing this, rather only interface specific.  I can go into more details if you like, but the method you're tackling it isn't how the language is designed.

 

Regards,

 

Mark

 

Xilinx Employee
Xilinx Employee
1,804 Views
Registered: ‎01-11-2011

Re: Vivado Support for SystemVerilog "Access to interface objects"

@dvdgardner, the CR has been fixed for the Vivado 2018.3 release. Using the original RTL no longer produces an error in this version.

-------------------------------------------------------------------------
Please don’t forget to reply, kudo, and accept as solution!
-------------------------------------------------------------------------
Scholar markcurry
Scholar
1,799 Views
Registered: ‎09-16-2009

Re: Vivado Support for SystemVerilog "Access to interface objects"

FYI - the suggestions I would make to the SystemVerilog Working group (anyone know if it still even exists?) would be to expand the "net alias" (Section 10.11) to also work with interfaces:

module passthrough
    (
      interface food_in,
      interface food_out
    );    
    alias food_in = food_out;

endmodule

Interfaces would need to be explicitly equivalent (i.e. exact same definition) for this to work, or an error would be indicated.

 

Where we really need this is when using ARRAYs of interfaces, and want to call out an individual index by name:

some_if some_if_array()[ N - 1 : 0 ];

some_if one_specific_if();
some_if another_specific_if();

alias one_specific_if = some_if_array[ 3 ];

localparam MY_INDEX = 2;
alias another_specific_if = some_if_array[ MY_INDEX ];

 

Regards,

 

Mark

0 Kudos
Visitor dvdgardner
Visitor
1,369 Views
Registered: ‎04-17-2018

Re: Vivado Support for SystemVerilog "Access to interface objects"

@kmorris  Thanks for the update.  Was hoping to see a fix in 18.2 but 18.3 is the next best thing :-)

 

@markcurry Yes, I realize I simplified that second scenario a bit too far.  Though it is interesting to note that it sill generated the same form of error as the original case.

 

 

Here's an updated version (Still not using the typedef on the interface)

 

`timescale 1ns / 1ps

interface bananahs_if (); 
   struct packed  {
      logic  foo;
   } payload;
endinterface

interface popcorn_if (); 
   struct packed  {
      logic  bar;
   } payload;
endinterface


module passthrough
    (
      interface food_in,
      interface food_out
    );    
    assign food_out.payload = food_in.payload;
endmodule


module top
    (
      popcorn_if popcorn_in,
      popcorn_if popcorn_out,
      bananahs_if bananahs_in,
      bananahs_if bananahs_out
    );
    
    passthrough popcorn_passthrough (
      .food_in(popcorn_in),
      .food_out(popcorn_out)
    );
    
    passthrough bananahs_passthrough (
      .food_in(bananahs_in), 
      .food_out(bananahs_out)
    );
            
endmodule

 

0 Kudos
Scholar markcurry
Scholar
1,358 Views
Registered: ‎09-16-2009

Re: Vivado Support for SystemVerilog "Access to interface objects"

Ah - that should work fine - even with Vivado 2018.1 I believe.  It doesn't?  I'll try your example on my end, and a few others (is it the structure within the interface that's the problem?). 

 

We're doing similar things in Vivado, and it's working.  The only difference I can see is we're using Modports on the module ports, instead of the raw interface.

 

Regards,

Mark

0 Kudos
Scholar markcurry
Scholar
1,324 Views
Registered: ‎09-16-2009

Re: Vivado Support for SystemVerilog "Access to interface objects"

Ok, I ran some tests.  This looks to be because of the attempt to make a generic interface feedthru, and Vivado doesn't like it.  If you create a interface specific feedthru, (with the EXACT same contents) it works.

 

I'm suspecting Vivado just doesn't handle generic interfaces on the portlists.  We use interfaces a lot, but dont use generic interfaces on portlists.  In fact we always use specifc modports, not specific interfaces on portlists.

 

It appears that Vivado, on the first instance of a "generic" interface on a port - is contextualizing the module port to that exact interface.  Even though "bananahs_if", and "popcorn_if" has an identical member "payload", Vivado is barfing.

 

Below works:

 

interface bananahs_if (); 
   struct packed  {
      logic  foo;
   } payload;
endinterface

interface popcorn_if (); 
   struct packed  {
      logic  bar;
   } payload;
endinterface


module passthrough_popcorn
    (
      interface food_in,
      interface food_out
    );    
    assign food_out.payload = food_in.payload;
endmodule


module passthrough_banana
    (
      interface food_in,
      interface food_out
    );    
    assign food_out.payload = food_in.payload;
endmodule

module if_test60
    (
      popcorn_if popcorn_in,
      popcorn_if popcorn_out,
      bananahs_if bananahs_in,
      bananahs_if bananahs_out
    );
    
    passthrough_popcorn popcorn_passthrough (
      .food_in(popcorn_in),
      .food_out(popcorn_out)
    );
    
    passthrough_banana bananahs_passthrough (
      .food_in(bananahs_in), 
      .food_out(bananahs_out)
    );
            
endmodule

As I mentioned in a previous post I believe this could all be solved in a different manner - with the "net alias" construct allowed to be used on interfaces.  But seeing as that requires a change in an LRM, then support by the tools - the likelihood of seeing this anytime soon is small.

 

Regards,

 

Mark

0 Kudos