cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
1,055 Views
Registered: ‎01-03-2019

Failed build HW in vitis the SFP Block Design kernel.

Jump to solution

Hi,

I've tried to create a Block design kernel from RTL kernel template which include a SFP 25G ethernet subsystem IP and something else on the U50dd.

First I simulated the clock and SFP connection, passed simulation and HW emulation. Then I connected clock and SFP port to the board which is sfpdd1 1x and sfpdd2 1x, finally passed implementation in vivado.

Now I generated RTL kernel for vitis.

HW emulation build passed.

But finally, HW build failed. I get this error which I can't find any information. Please help to see what can it be.

This error log was found in: /Hardware/binary_container_1.build/link/vivado/vpl/prj/prj.runs/impl_1/runme.log

Thank you very much.

 

Command: place_design
Attempting to get a license for feature 'Implementation' and/or device 'xcu50'
INFO: [Common 17-349] Got license for feature 'Implementation' and/or device 'xcu50'
INFO: [DRC 23-27] Running DRC with 8 threads
INFO: [Vivado_Tcl 4-198] DRC finished with 0 Errors
INFO: [Vivado_Tcl 4-199] Please refer to the DRC report (report_drc) for more information.
Running DRC as a precondition to command place_design
INFO: [DRC 23-27] Running DRC with 8 threads
ERROR: [DRC UTLZ-1] Resource utilization: GTYE4_CHANNEL over-utilized in Pblock pblock_dynamic_region (This design requires more GTYE4_CHANNEL cells than are available in Pblock 'pblock_dynamic_region'. This design requires 6 of such cell types but only 4 compatible sites are available in Pblock 'pblock_dynamic_region'. Please consider increasing the span of Pblock 'pblock_dynamic_region' or removing cells from it.)
ERROR: [DRC UTLZ-1] Resource utilization: GTYE4_CHANNEL over-utilized in Top Level Design (This design requires more GTYE4_CHANNEL cells than are available in the target device. This design requires 22 of such cell types but only 20 compatible sites are available in the target device. Please analyze your synthesis results and constraints to ensure the design is mapped to Xilinx primitives as expected. If so, please consider targeting a larger device.)
ERROR: [DRC UTLZ-1] Resource utilization: GTYE4_COMMON over-utilized in Pblock pblock_dynamic_region (This design requires more GTYE4_COMMON cells than are available in Pblock 'pblock_dynamic_region'. This design requires 2 of such cell types but only 1 compatible site is available in Pblock 'pblock_dynamic_region'. Please consider increasing the span of Pblock 'pblock_dynamic_region' or removing cells from it.)
ERROR: [DRC UTLZ-1] Resource utilization: GTYE4_COMMON over-utilized in Top Level Design (This design requires more GTYE4_COMMON cells than are available in the target device. This design requires 6 of such cell types but only 5 compatible sites are available in the target device. Please analyze your synthesis results and constraints to ensure the design is mapped to Xilinx primitives as expected. If so, please consider targeting a larger device.)
INFO: [Vivado_Tcl 4-198] DRC finished with 4 Errors
INFO: [Vivado_Tcl 4-199] Please refer to the DRC report (report_drc) for more information.
ERROR: [Vivado_Tcl 4-23] Error(s) found during DRC. Placer not run.
INFO: [Common 17-83] Releasing license: Implementation
198 Infos, 562 Warnings, 28 Critical Warnings and 5 Errors encountered.
place_design failed
place_design: Time (s): cpu = 00:00:39 ; elapsed = 00:00:22 . Memory (MB): peak = 9779.043 ; gain = 8.004 ; free physical = 2374 ; free virtual = 13657
ERROR: [Common 17-39] 'place_design' failed due to earlier errors.

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
1,045 Views
Registered: ‎10-19-2015

Hi @sl82976818 

This is an interesting problem. 

I think what the error is saying is that your RTL kernel is trying to use logic that is reserved for the shell/platform logic. So the RTL kernel wizard and the RTL kernel is likely able to synthesize with no knowledge of the shell/platform. 

The shell/platform tries to handle all the FPGA -> outside world connections. The SFPs and GTs are part of that so that's the PBlock issue. 

Really the design methodology would be to just generate the RTL that interfaces to the GTs, then use Vitis and v++ to connect the kernel to the GTs. 

We don't have a GT enabled shell at this time so you might have to go down a different path to put your logic on the board. 

Regards,

M

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

0 Kudos
12 Replies
Highlighted
Xilinx Employee
Xilinx Employee
1,046 Views
Registered: ‎10-19-2015

Hi @sl82976818 

This is an interesting problem. 

I think what the error is saying is that your RTL kernel is trying to use logic that is reserved for the shell/platform logic. So the RTL kernel wizard and the RTL kernel is likely able to synthesize with no knowledge of the shell/platform. 

The shell/platform tries to handle all the FPGA -> outside world connections. The SFPs and GTs are part of that so that's the PBlock issue. 

Really the design methodology would be to just generate the RTL that interfaces to the GTs, then use Vitis and v++ to connect the kernel to the GTs. 

We don't have a GT enabled shell at this time so you might have to go down a different path to put your logic on the board. 

Regards,

M

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

0 Kudos
Highlighted
Contributor
Contributor
1,017 Views
Registered: ‎01-03-2019

That's so sad...

0 Kudos
Highlighted
Contributor
Contributor
950 Views
Registered: ‎01-03-2019

Hi, @mcertosi 

At this time don't have GT enabled shell, but do you have this plan in the future?

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
940 Views
Registered: ‎10-19-2015

Hi @sl82976818 

Yes we do! We are currently in development of a QDMA enabled shell which allows for streaming object / interface creation in Vitis. Since most of our high speed Ethernet IP uses AXI-Stream interfaces, this will enable the GTs as well. 

It is close, but no official dates yet. 

It looks like developers on this forum have found other solutions to this gap and still were able to use the card, try searching the Xilinx answer records and other forum posts. 

Regards,

M

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Contributor
Contributor
896 Views
Registered: ‎01-03-2019

Hi @mcertosi ,

It is clear after check all the tickets in this Alveo forum that using QSFP ports need to use board custom flow. Once used custom flow XRT will not be available.

I have thought for days about what you said here "Really the design methodology would be to just generate the RTL that interfaces to the GTs, then use Vitis and v++ to connect the kernel to the GTs. ". Really don't know how to do that. So it can be integrated to the xrt and shell?

Once I connect SFP port, the reserved GTs will be used which generate the errors.. right?

And how to connect to the kernel by Vitis and V++? A memory connection? Or streaming connection? 

Please tell us a little more.

Thank you a lot.

0 Kudos
Highlighted
Observer
Observer
819 Views
Registered: ‎11-12-2019

Hi M,
In the QDMA enabled shell, How do you create a streaming interface to the GTs (Alveo U200) ? Do you have link to documents/instructions/sample code on how to do that ?

Thanks

0 Kudos
Highlighted
Contributor
Contributor
794 Views
Registered: ‎01-03-2019

Hi @mcertosi ,

At the end of the GT interface methodology I got this error.  Does it mean I will never finish it what ever I do?

Command: write_bitstream -force -cell pfm_top_i/L1/L1_URP pfm_top_i_L1_L1_URP_my_rm_partial.bit
Attempting to get a license for feature 'Implementation' and/or device 'xcu50'
INFO: [Common 17-349] Got license for feature 'Implementation' and/or device 'xcu50'
INFO: [Common 17-83] Releasing license: Implementation
215 Infos, 549 Warnings, 27 Critical Warnings and 1 Errors encountered.
write_bitstream failed
ERROR: [Common 17-69] Command failed: This design contains one or more cells for which bitstream generation is not permitted:
pfm_top_i/L1/L1_URP/BD_2CLK_FSP_Interface_1/BD_2CLK_FSP_Interface_bd_i/ethernet_1_10_25g_0/inst/i_BD_2CLK_FSP_Interface_bd_ethernet_1_10_25g_0_0_top_1/i_BD_2CLK_FSP_Interface_bd_ethernet_1_10_25g_0_0_mac/inst/i_BD_2CLK_FSP_Interface_bd_ethernet_1_10_25g_0_0_xxv_eth_mac_top_0/i_BD_2CLK_FSP_Interface_bd_ethernet_1_10_25g_0_0_xxv_eth_mac_CORE (<encrypted cellview>)
pfm_top_i/L1/L1_URP/BD_2CLK_FSP_Interface_1/BD_2CLK_FSP_Interface_bd_i/ethernet_1_10_25g_0/inst/i_BD_2CLK_FSP_Interface_bd_ethernet_1_10_25g_0_0_top_0/i_BD_2CLK_FSP_Interface_bd_ethernet_1_10_25g_0_0_mac/inst/i_BD_2CLK_FSP_Interface_bd_ethernet_1_10_25g_0_0_xxv_eth_mac_top_0/i_BD_2CLK_FSP_Interface_bd_ethernet_1_10_25g_0_0_xxv_eth_mac_CORE (<encrypted cellview>)
If a new IP Core license was added, in order for the new license to be picked up, the current netlist needs to be updated by resetting and re-generating the IP output products before bitstream generation.
INFO: [Common 17-206] Exiting Vivado at Fri Feb 7 09:34:26 2020...

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
773 Views
Registered: ‎10-19-2015

Hi @sl82976818 

I'll elaborate a little on my previous statement: 

Really the design methodology would be to just generate the RTL that interfaces to the GTs, then use Vitis and v++ to connect the kernel to the GTs. 

This would require an AXI stream enabled shell to do this. To create streaming objects in Vitis you'll need a QDMA enabled shell. I'm not sure what the process is to get one, if you have a Xilinx FAE or contact in Xilinx Marketing they may be able to direct you. 

QDMA enabled shells are not publicly available and I do not believe what is currently early access is available on all platforms. (as of 2/7/2020)

So you can go the custom flow route, but yes you are correct then XRT, V++, OCL defined kernels, are all much more difficult to build since you would have to build all that infrastructure yourself. 

Xilinx is aware that this is a gap in our current offering and we are working to enable these features. 

Regards,

M

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Contributor
Contributor
767 Views
Registered: ‎01-03-2019

Thank you @mcertosi ,

I 'm glad to know the answer is IT CANNOT BE DONE for now, so I will not waste time on it. 

 

 

0 Kudos
Highlighted
Contributor
Contributor
219 Views
Registered: ‎01-03-2019

Hi, 

Really, I haven't given up to build the SFP port in XDMA shell.

Can you kindly tell me why SFP can't be use in XDMA shell? 

I have created a project which connected 25G ethernet IP to Memery mapped read and write master whith a async FIFO. Then connect the free run clock, gt_ref clock and QSFP seriel port to the shell. It have finished to build hardware.

Finally it didn't work. I really don't understand why.

Thanks

0 Kudos
Highlighted
Visitor
Visitor
139 Views
Registered: ‎10-18-2018

My project also encountered the same problem. I hope to continue with Vitis. Now does The rtl Kernel of Vitis support GT?When can you support it? https://developer.xilinx.com/en/articles/designing-a-transceiver-based-application-with-vitus.html  How is the RTL Kernel implemented in this design?thank you!

0 Kudos
Highlighted
Contributor
Contributor
124 Views
Registered: ‎01-03-2019

Hi, Mr. Zhu @zhujun ,

I 'm glad to find a colleague studying the same topic. I want to solve it too.

Have you tried the GT project you attached from Xilinx developer? I think it will not work. 

v++ should report a error of  "NO STREAMING RESOURCE". This GT project is strange. It should work with QDMA shell.

 

 

0 Kudos