cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
2,074 Views
Registered: ‎07-02-2019

Vivado 2019.1 [Synth 8-448] named port connection error on parameterized interface port

Jump to solution

Hi,

I got "[Synth 8-448] named port connection" error when I tried to synthesize following code.

Code:

interface test_if #(type PAYLOAD = logic);
  typedef PAYLOAD __payload;
  PAYLOAD payload;
  modport in(input payload);
  modport out(output payload);
endinterface

module sub_0 (
  test_if.in  in,
  test_if.out out
);
  assign  out.payload = in.payload;
endmodule

module sub_1 (
  test_if.in  in,
  test_if.out out
);
  typedef in.__payload  __payload;

  test_if #(__payload)  sub_if_in();
  test_if #(__payload)  sub_if_out();

  assign  sub_if_in.payload = in.payload;
  assign  out.payload       = sub_if_out.payload;

  sub_0 u_sub_0 (.in(sub_if_in), .out(sub_if_out));
endmodule

module top (
  input   logic [1:0] i_foo,
  output  logic [1:0] o_foo,
  input   logic [2:0] i_bar,
  output  logic [2:0] o_bar
);
  typedef struct packed {
    logic [1:0] foo;
  } foo_type;

  typedef struct packed {
    logic [2:0] bar;
  } bar_type;

  test_if #(foo_type) foo_in();
  test_if #(foo_type) foo_out();
  test_if #(bar_type) bar_in();
  test_if #(bar_type) bar_out();

  assign  foo_in.payload.foo  = i_foo;
  assign  o_foo               = foo_out.payload.foo;
  sub_1 u_foo (.in(foo_in), .out(foo_out));

  assign  bar_in.payload.bar  = i_bar;
  assign  o_bar               = bar_out.payload.bar;
  sub_1 u_bar (.in(bar_in), .out(bar_out));
endmodule

Error Message:

[Synth 8-448] named port connection 'in\.payload[bar]' does not exist for instance 'u_sub_0' of module 'sub_0' ["/home/ishitani/workspace/test/test_9515/test.sv":27]
[Synth 8-448] named port connection 'out\.payload[bar]' does not exist for instance 'u_sub_0' of module 'sub_0' ["/home/ishitani/workspace/test/test_9515/test.sv":27]
[Synth 8-6156] failed synthesizing module 'sub_1__parameterized0' ["/home/ishitani/workspace/test/test_9515/test.sv":15]
[Synth 8-6156] failed synthesizing module 'top' ["/home/ishitani/workspace/test/test_9515/test.sv":30]
[Common 17-69] Command failed: Vivado Synthesis failed

Is there any problem on above code?
I confirmed that other tool (SNPS VCS) can elaborate without error.

Regards,
Taichi Ishitani

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
1,566 Views
Registered: ‎02-16-2014

Hi @taichi730 

Thanks for pointing to this issue in other thread.

I am able to reproduce this issue in 2019.1 at my end.

I tested and confirmed that this issue is already fixed in next release of vivado.

Hope you can use the workaround that you have till next release is available for customers.

 

Thanks,

Manusha

View solution in original post

10 Replies
Highlighted
Instructor
Instructor
1,972 Views
Registered: ‎10-23-2018

@taichi730 

Here are a couple solutions that had the same error. Maybe they will give you some insight.

https://forums.xilinx.com/t5/Synthesis/quot-Synth-8-448-named-port-connection-clk-does-not-exist-quot/m-p/941955#M30074
https://forums.xilinx.com/t5/Synthesis/Understanding-Solving-Synth-8-4480-quot-The-timing-quot/m-p/693260#M17918

Hope that Helps
If so, Please mark as solution accepted. Kudos also welcomed. :-)

0 Kudos
Highlighted
Visitor
Visitor
1,960 Views
Registered: ‎07-02-2019

Hi @xilinxacct ,

Thank you for your advice. However I thik these could not be solutions because:

  • There are no dupulicated modules.
  • There are no warning and error except for [Synth 8-448].
  • There are no timing issue.

Port informatin used for top.u_foo.u_sub_0 is propergaed via top.u_foo.sub_if_in interface and port information used for top.u_bar.u_sub_0 is propergated via top.u_bar.sub_if_in interface. Therse port informatin should be different.
However it's seemed that wrong port information is propergated to top.u_bar.u_sub_0 and this wrong information is for top.u_foo.u_sub_0.

I think this issue is caued by Vivado's bug.

Regards,
Taichi Ishitani

0 Kudos
Highlighted
Scholar
Scholar
1,921 Views
Registered: ‎09-16-2009

I believe your failure has to do with the following line in sub_1:

 typedef in.__payload  __payload;

As far as I'm aware Vivado doesn't support pulling out a parameter (or typedef)  from within an interface outside to the enclosing module.  There's other threads in these forums talking about this restriction - those threads explicitly talk about parameters, as I recall, not typedefs per your example, but I believe the restriction is the same.

It's a shame really, because what you're doing really enables some compact, reusable, high-level object-oriented design.  

Search around the threads a little - if you can't find the threads let me know, I can dig and send references.

Regards,

Mark

0 Kudos
Highlighted
Visitor
Visitor
1,909 Views
Registered: ‎07-02-2019

Hi @markcurry ,

Thank you for your replay!

> typedef in.__payload __payload

Unlike the case of parameter, this type of typedef is legal (see IEEE 1800-2017 "6.18 User-defined types") and also is supported by Vivado.
In fact, top module below can be syntheiszed without error.

 

module top (
  input   logic [1:0] i_foo_0,
  output  logic [1:0] o_foo_0,
  input   logic [1:0] i_foo_1,
  output  logic [1:0] o_foo_1
);
  typedef struct packed {
    logic [1:0] foo;
  } foo_type;

  test_if #(foo_type) foo_in_0();
  test_if #(foo_type) foo_out_0();
  test_if #(foo_type) foo_in_1();
  test_if #(foo_type) foo_out_1();

  assign  foo_in_0.payload.foo  = i_foo_0;
  assign  o_foo_0               = foo_out_0.payload.foo;
  sub_1 u_foo_0 (.in(foo_in_0), .out(foo_out_0));

  assign  foo_in_1.payload.foo  = i_foo_1;
  assign  o_foo_1               = foo_out_1.payload.foo;
  sub_1 u_foo_1 (.in(foo_in_1), .out(foo_out_1));
endmodule

Regards,
Taichi Ishitani

 

 

0 Kudos
Highlighted
Scholar
Scholar
1,881 Views
Registered: ‎09-16-2009

Taichi,

Typedefs, and parameterized types are supported by Vivado, and have been for some time.

What is NOT supported by Vivado, and what's missing from your second example here, is pulling the value (or type) from within an interface outside to the module's scope.

I.e. In this second example, "foo_type" is explicitly defined in the scope of module "top", and hence is allowed by Vivado.

However, In your original:

typedef in.__payload  __payload;

Within the scope of the module "sub_1", type "__payload" is NOT explictly defined.  You're attempting to pull the definition from the within the interface that is passed to that module.  While this is legal verilog, it has not been properly supported in Vivado.  I believe this is the root cause of your problem.

Regards,

Mark

0 Kudos
Highlighted
Visitor
Visitor
1,863 Views
Registered: ‎07-02-2019

Hi @markcurry ,

Thanks for you replay.

this second example

This is a part of exmaple and whole exmaple is below.

 

interface test_if #(type PAYLOAD = logic);
  typedef PAYLOAD __payload;
  PAYLOAD payload;
  modport in(input payload);
  modport out(output payload);
endinterface

module sub_0 (
  test_if.in  in,
  test_if.out out
);
  assign  out.payload = in.payload;
endmodule

module sub_1 (
  test_if.in  in,
  test_if.out out
);
  typedef in.__payload  __payload;

  test_if #(__payload)  sub_if_in();
  test_if #(__payload)  sub_if_out();

  assign  sub_if_in.payload = in.payload;
  assign  out.payload       = sub_if_out.payload;

  sub_0 u_sub_0 (.in(sub_if_in), .out(sub_if_out));
endmodule

module top (
  input   logic [1:0] i_foo_0,
  output  logic [1:0] o_foo_0,
  input   logic [1:0] i_foo_1,
  output  logic [1:0] o_foo_1
);
  typedef struct packed {
    logic [1:0] foo;
  } foo_type;

  test_if #(foo_type) foo_in_0();
  test_if #(foo_type) foo_out_0();
  test_if #(foo_type) foo_in_1();
  test_if #(foo_type) foo_out_1();

  assign  foo_in_0.payload.foo  = i_foo_0;
  assign  o_foo_0               = foo_out_0.payload.foo;
  sub_1 u_foo_0 (.in(foo_in_0), .out(foo_out_0));

  assign  foo_in_1.payload.foo  = i_foo_1;
  assign  o_foo_1               = foo_out_1.payload.foo;
  sub_1 u_foo_1 (.in(foo_in_1), .out(foo_out_1));
endmodule

 

Vivado can synthesis above code without error.
Vivado would report the same error if Vivado doens not support "typedef in.__payload __payload". Therefore, I think error for 1st example is due t Vivado's bug.

Regads,
Taichi Ishitani

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
1,567 Views
Registered: ‎02-16-2014

Hi @taichi730 

Thanks for pointing to this issue in other thread.

I am able to reproduce this issue in 2019.1 at my end.

I tested and confirmed that this issue is already fixed in next release of vivado.

Hope you can use the workaround that you have till next release is available for customers.

 

Thanks,

Manusha

View solution in original post

Highlighted
Adventurer
Adventurer
391 Views
Registered: ‎01-31-2020

I see a similar issue with Vivado 2020.1. In which version of Vivado is it fixed? I there a workaround instead of waiting for a new release? Thanks.

0 Kudos
Highlighted
Visitor
Visitor
312 Views
Registered: ‎07-02-2019

I think adding 'type' parameter to the sub_1 module like this is easiest workaround.

module sub_1 #(
  parameter type PAYLOAD = logic
)(
  test_if.in  in,
  test_if.out out
);
  test_if #(PAYLOAD)  sub_if_in();
  test_if #(PAYLOAD)  sub_if_out();

  assign  sub_if_in.payload = in.payload;
  assign  out.payload       = sub_if_out.payload;

  sub_0 u_sub_0 (.in(sub_if_in), .out(sub_if_out));
endmodule

module top (
  input   logic [1:0] i_foo,
  output  logic [1:0] o_foo,
  input   logic [2:0] i_bar,
  output  logic [2:0] o_bar
);
  typedef struct packed {
    logic [1:0] foo;
  } foo_type;

  typedef struct packed {
    logic [2:0] bar;
  } bar_type;

  test_if #(foo_type) foo_in();
  test_if #(foo_type) foo_out();
  test_if #(bar_type) bar_in();
  test_if #(bar_type) bar_out();

  assign  foo_in.payload.foo  = i_foo;
  assign  o_foo               = foo_out.payload.foo;
  sub_1 #(foo_type) u_foo (.in(foo_in), .out(foo_out));

  assign  bar_in.payload.bar  = i_bar;
  assign  o_bar               = bar_out.payload.bar;
  sub_1 #(bar_type) u_bar (.in(bar_in), .out(bar_out));
endmodule

 

0 Kudos