cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
1,547 Views
Registered: ‎02-20-2017

designutils 20-1595 when using inout vector

Jump to solution

I have an ip (call it IP "A") that must be instantiated at the top level of my design; it cannot be placed in my block design (due to requirements for tandem/field updates). The IP has 2 AXI4 interfaces that I want to bring into my block design. Wiring two AXI buses from rtl into a block design is a little messy and inconvenient, so to make this process easier, I decided to create an IP "B" that encapsulates IP A and creates a inout vector containing all the signals from both AXI buses. I then created IP C that I instantiate inside my block design which breaks out the inout vector back into the two AXI buses for easy connection within the block design. Now rather than having to connect ~70 wires from IP A into my block design, I just have a single port to connect the inout vector from IP B outside the block desing to IP C inside the block design.

 

I am getting designutils 20-1595 on 5 of the connections. The message is:

In entity <IP A>, connectivity of net MAXI_AWREADY cannot be represented in VHDL. VHDL lacks syntax to connect the following inout terminals to a differently-named net: inout AXI_CABLE[10]. Resolution: Check whether terminals really need inout direction and substitute input or output as needed. It may also be possible to rename the net to match the terminal.

 

The target language of the project, IP B, and IP C are all verilog. I suspect IP A is VHDL (it is the ultrascale PCIe-AXI bridge) but I have a Verilog wrapper around it. The strange thing is I get 2 of these errors during ooc synthesis of IP B, 8 errors for ooc synth of IP C, but the project goes on to successful implementation and everything seems to work. Is there something I can do in code to prevent these errors? If not, can I just suppress these specific instances of the error or globally suppress the error?

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Moderator
Moderator
1,923 Views
Registered: ‎07-21-2014

Re: designutils 20-1595 when using inout vector

Jump to solution

@jonk

 

Can you share a testcase for us to check the design and its connection? Did you try using dont_touch attribute on these signals?

 

Also, flatten_hierarchy plays an important role here, can you please let us know what happens when you change the hierarchy settings?

 

Thanks

Anusheel

 

View solution in original post

5 Replies
Highlighted
Moderator
Moderator
1,501 Views
Registered: ‎07-21-2014

Re: designutils 20-1595 when using inout vector

Jump to solution

@jonk

 

Please check below thread once, as we have a CR around it:

https://forums.xilinx.com/t5/Synthesis/error-Designutils-20-1595-what-is-this/td-p/642316

 

Thanks

Anusheel

Highlighted
Adventurer
Adventurer
1,483 Views
Registered: ‎02-20-2017

Re: designutils 20-1595 when using inout vector

Jump to solution

Hi @anusheel,

 

I did see that thread but that did not seem to be the same issue. In my case the wires are not driven by 0 constants. They couldn't be optimized to 0 during ooc synth because they exist when used in the final design. Do you think it is still caused by the same issue?

 

Thanks,

Jon

0 Kudos
Highlighted
Moderator
Moderator
1,924 Views
Registered: ‎07-21-2014

Re: designutils 20-1595 when using inout vector

Jump to solution

@jonk

 

Can you share a testcase for us to check the design and its connection? Did you try using dont_touch attribute on these signals?

 

Also, flatten_hierarchy plays an important role here, can you please let us know what happens when you change the hierarchy settings?

 

Thanks

Anusheel

 

View solution in original post

Highlighted
Adventurer
Adventurer
1,464 Views
Registered: ‎02-20-2017

Re: designutils 20-1595 when using inout vector

Jump to solution

Hi @anusheel,

 

I attached a simple example of the design. The attached zip contains 2 simple ip definitions and an example project. Synthesizing this design produces 10 errors but synth still completes successfully.

 

IP A has a top level module that assigns the inout's to wires, before passing it into a sub module with proper port names and directions. I tried putting KEEP_HIERARCHY on the instantiation of that sub module but that didn't help. I have not yet tried DONT_TOUCH. I'll give that a shot.

 

Thanks for looking into this,

Jon

0 Kudos
Highlighted
Adventurer
Adventurer
1,453 Views
Registered: ‎02-20-2017

Re: designutils 20-1595 when using inout vector

Jump to solution

Hi @anusheel,

 

It seems that DONT_TOUCH helps! Actually I used KEEP. My understanding is that the only difference between KEEP and DONT_TOUCH is that the latter is forward annotated to implementation. This error was only happening during synth, so KEEP is good enough to fix it. I don't want to prevent the tool from having the freedom to optimize where it sees fit.

 

In IP B, the problem was fixed by virtue of having the top module (HSD_BASE_IO) route the inout signals to the internal module (HSD_BASE) with proper input output ports. The error was only happening on one signal that was manipulated within HSD_BASE_IO. I got rid of this error by moving the logic into HSD_BASE.

 

For IP C, I fixed the problem by putting (* KEEP = "TRUE" *) on all the AXI port definitions. Interestingly AR# 54778 suggests that KEEP doesn't apply to module ports but it fixes the problem for me. KEEP_HIERARCHY on the module definition did not fix the problem.

 

Thanks for the input!