cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
hgleamon1
Teacher
Teacher
662 Views
Registered: ‎11-14-2011

Xlconcat input pins are connected to different type of pins (redux)

Jump to solution

With specific regard to >this< message from some time ago, I also need to report that I cannot validate a block design because

"[xilinx.com:ip:xlconcat:2.1-10] /xlconcat_1Xlconcat input pins are connected to different type of pins"

If I run the TCL command get_property TYPE [get_bd_pins -filter {DIR == I} /xlconcat_1/*]

I get the following response:

undef undef undef

which looks like all the same type to me. The pins in questions are all sourced from custom VHDL modules as std_logic and the xlconcat is configured to autodetect the input width.

If I disconnect the pins one by one, I get the same error until I have deleted the entire Concat instance. If I try with a new instance of the IP, and connect the pins one by one, I get the same error after the second connection.

I haven't found a satisfactory response to this issue on the forums yet. Some assistance would be appreciated.

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
1 Solution

Accepted Solutions
florentw
Moderator
Moderator
608 Views
Registered: ‎11-09-2015

Hi @hgleamon1 

As per the other topic you mentioned, it is difficult to comment without a test case. If you have one I would be happy to have a look.

I guess the custom logic that you have is imported to the BD using the import module feature? Are all the inputs of your concat IP connected to your custom logic?

If the pins are supposed to be interrupt, I guess you can use an attribute to set it as such as mentioned in UG994.

-- Declare the attributes in the architecture section
ATTRIBUTE X_INTERFACE_INFO : STRING;
ATTRIBUTE X_INTERFACE_INFO of <interrupt_port_name>: SIGNAL is "xilinx.com:signal:interrupt:1.0 <interrupt_port_name> INTERRUPT";

Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**

View solution in original post

7 Replies
639 Views
Registered: ‎01-22-2015

Hi Howard,

I havn't used xlconcat  -  but maybe it is just as easy to roll your own? 

Does the following VHDL explain what you are trying to do?

 

bigbus(15 downto 8 )  <= littlebus1(7 downto 0);
bigbus(7 downto 0) <= littlebus2(7 downto 0);

 


Cheers,
Mark

 

0 Kudos
hgleamon1
Teacher
Teacher
629 Views
Registered: ‎11-14-2011

markg@prosensing.com 

Hello Mark,

It's beginning to feel like you are my personal support channel now

Yes, I could do that. I'm trying to concatenate signals into the Zynq PS irq inputs - I am not sure, under the Block Design, if the signals need to be of a certain "type" for that and, if so, how I designate that type to a simple VHDL signal. It's definitely one of things that is very unclear with Block Design that pure VHDL doesn't have to deal with (and that's saying something considering how strongly typed VHDL is!).

I had thought that one of the points of block design was how easy it would be to connect things up. Custom stuff seems to break that ease.

I'll try a homegrown version and see what happens.

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
hgleamon1
Teacher
Teacher
623 Views
Registered: ‎11-14-2011

Hmm. Suspicious.

Shutdown Vivado (2019.1, by the way). Started it all up again, and now the Block Design is validated, with nothing having changed from the shutdown. Some metafile got a bit confused somewhere and restarting cleared it all up again, I suppose.

I'll wait a while to see if some Xilinx bod can comment but, for now, it looks like it will be OK (at the worst, a workaround). 

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
florentw
Moderator
Moderator
609 Views
Registered: ‎11-09-2015

Hi @hgleamon1 

As per the other topic you mentioned, it is difficult to comment without a test case. If you have one I would be happy to have a look.

I guess the custom logic that you have is imported to the BD using the import module feature? Are all the inputs of your concat IP connected to your custom logic?

If the pins are supposed to be interrupt, I guess you can use an attribute to set it as such as mentioned in UG994.

-- Declare the attributes in the architecture section
ATTRIBUTE X_INTERFACE_INFO : STRING;
ATTRIBUTE X_INTERFACE_INFO of <interrupt_port_name>: SIGNAL is "xilinx.com:signal:interrupt:1.0 <interrupt_port_name> INTERRUPT";

Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**

View solution in original post

hgleamon1
Teacher
Teacher
601 Views
Registered: ‎11-14-2011

@florentw 

Hello,

Thanks for your response. As I just wrote above, I "fixed" it by restarting Vivado. I had not considered using the attribute string. I can certainly try that out.

I am happy to share a test case if you tell me what format you would like. I've just successfully completed synthesis on the design now, so there is no failure but perhaps you can see and understand things that I cannot from the correct files.  

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
florentw
Moderator
Moderator
592 Views
Registered: ‎11-09-2015

Hi @hgleamon1 

Yes I understand that this is fixed by restarting vivado. So I think it is fine if this is now working but I do not think this should be correct behaviour.

Yes I would a failing test case, so it would maybe be steps to recreate the issue. I am thinking this is linked with the import module feature. Maybe a quick test you can do:

In a new vivado project, import your IP and connect it to the concat IP and the concat IP to the zynq and hit validate. If you can get the error then you can just send me you custom HDL file (let me know if you need a link to our secured EZmove platform (so it is confidential)) and this should be enough.

Thanks


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
hgleamon1
Teacher
Teacher
578 Views
Registered: ‎11-14-2011

@florentw 

I will look at applying the attributes to the custom IP if I receive the error again. If it still persists after that, I can share the IP. For now, all is well.

Thanks, Howard

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos