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: 
Adventurer
Adventurer
5,814 Views
Registered: ‎12-18-2012

Implementation ingnoring custom IP made with HLS

Jump to solution

Hello,

 

I am not entirely sure if this an implementation problem or an HLS problem but i will try here first. I have a microblaze system alongside a custom IP that has memory interfaces for I/O made by HLS. Since I begun using the memory interface in the custom IP the Vivado implementation  ingnore the HLS IP completely (synthesis is completed correrctly). When i used to use other interfaces for IP this problem was  not present. 

 


The IP is conencted to the AXI bus as such:

Screenshot from 2013-10-17 15:53:31.png

 

The only issue I see is that the address width of the BRAM generator and the IP is 32 while for the AXI-BRAM controller is 14 bits and some pins are left unconnected. But i do not understand why this would make implementation ingnore the custom IP...

 

Thank you!

George

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
9,509 Views
Registered: ‎12-18-2012

Re: Implementation ingnoring custom IP made with HLS

Jump to solution

It was removed in implementation. That is what my initial idea was too. A connectivity issue. Some of the connectivity with the BRAM blocks was actually problematic. But I got no warnings or messages in implementation on the issue to highlight the problem, so it is actually very easy to miss.


Also what do you mean that every core that is it not driving an off-chip signal is removed in impelmentation? What if an IP only changes on-chip memory for example and the only interaction with the outside would be its control, clock and reset?.  And this issue only happened with the memory I/O interfaces of the HLS IP. If I removed these ports and just kept the controls signals of the IP, the implementation included the IP normally. 

 

I tried to redo the same thing in the new version of vivado that has automatic routine to connect BRAMS and their AXI-controller but the automated routines also did things that should not be allowed. 

 

For example, as I understand the allowed memory blocks of RAM are 4K. Yet the automated tool had no problem connecting 8K or creating 8K memory block RAMs and controllers on an previously defined memory I/O port from an HLS ip,  that had 8K ports. The IP thenselves come with an 8K port by default when added in the schematic. Then the design validation would, on its own, change the BRAM controller and only the port of the BRAM that is was connected to a 4K port. If you do not know this before hand, the validation considers everything is fine and one could easily end up with an incorrect design following just the automation.    

 

 

EDIT: If the BRAM connections with the contriller are configured correctly partitioned in 4K blocks,  implementation is done correctly. 

 

0 Kudos
2 Replies
Xilinx Employee
Xilinx Employee
5,776 Views
Registered: ‎07-01-2008

Re: Implementation ingnoring custom IP made with HLS

Jump to solution

What do you mean by "ignore"? If the core is simply not present in the design (check the synthesized design) then the problem is upstream of implementation. If the core is being removed by implemetation  (during sweep phase of opt_design) then the problem is the connectivity of the design. If the core is not driving an active signal off-chip then it is considered to be unused and will be removed. You can block that behavior with dont_touch properties or by skipping the sweep phase.

0 Kudos
Highlighted
Adventurer
Adventurer
9,510 Views
Registered: ‎12-18-2012

Re: Implementation ingnoring custom IP made with HLS

Jump to solution

It was removed in implementation. That is what my initial idea was too. A connectivity issue. Some of the connectivity with the BRAM blocks was actually problematic. But I got no warnings or messages in implementation on the issue to highlight the problem, so it is actually very easy to miss.


Also what do you mean that every core that is it not driving an off-chip signal is removed in impelmentation? What if an IP only changes on-chip memory for example and the only interaction with the outside would be its control, clock and reset?.  And this issue only happened with the memory I/O interfaces of the HLS IP. If I removed these ports and just kept the controls signals of the IP, the implementation included the IP normally. 

 

I tried to redo the same thing in the new version of vivado that has automatic routine to connect BRAMS and their AXI-controller but the automated routines also did things that should not be allowed. 

 

For example, as I understand the allowed memory blocks of RAM are 4K. Yet the automated tool had no problem connecting 8K or creating 8K memory block RAMs and controllers on an previously defined memory I/O port from an HLS ip,  that had 8K ports. The IP thenselves come with an 8K port by default when added in the schematic. Then the design validation would, on its own, change the BRAM controller and only the port of the BRAM that is was connected to a 4K port. If you do not know this before hand, the validation considers everything is fine and one could easily end up with an incorrect design following just the automation.    

 

 

EDIT: If the BRAM connections with the contriller are configured correctly partitioned in 4K blocks,  implementation is done correctly. 

 

0 Kudos