Building the project for U280 failed.

[WuMinkang]

Hello, We are trying to build the project for U280.Our command is: make ips make create_prj_alveou280-fns-single-toe-iperf make implement_alveou280-fns-single-toe-iperf We found that Vivado 2018.3 IP Build 2404404 seems that doesn't support U280 so we used Vivado 2019.2 IP Build 2729494.However we get Combinatorial Loop Error. We wonder if we have made any mistake when building? Which version of Vivado you use when building the project for U280? Looking forward for your reply. Thank you and best wishes.

[mariodruiz]

Hi @WuMinkang,

No, you have not made any mistake. That is a known issue, and it is the reason of the note here https://github.com/hpcn-uam/Limago#introduction

You have two options:

1. Import the Alveo U280 board files to Vivado 2018.3, the steps are more o less specify here https://www.xilinx.com/support/answers/72033.html
2. Tell the DRC not to check these combinatorial loop as luyong6 wrote here https://github.com/hpcn-uam/Limago/issues/4#issuecomment-650563520

[WuMinkang]

We tried your advise 2 , telling the DRC not to check combinatorial loop and built the bitstream successfully while getting the error that it didn't meet timing requirement. Could it be a fatal error? Looking into your source code for U280 we found that the stack can only support communicating with the host using PCIe cause we only found the pinout with PCIe, while U200 and VCU118 can support communicating through QSFP and PCIe. We wound whether or not the code for U280 can support communicating through QSFP? We actually want to build a project that two cards of U280 can communicate with each other (with or withnot communicate with the host).

[WuMinkang]

Sorry for mistouching the close button when I want to comment orz.

[mariodruiz]

All the designs in this repository support QSFP communication, the PCIe is only use for control.

If you open the design you will see cmac connected. The constraint for the cmac clock are here https://github.com/hpcn-uam/Limago/blob/master/submodules/cmac/constraints/alveo_u280_qsfp0.xdc, while the actual GT pins are configured here https://github.com/hpcn-uam/Limago/blob/f5b1b82f2526a88ccf9e04d26f4235555e65a07f/submodules/cmac/scripts/xilinx_ips/cmac_uplus.tcl#L49

Mario

[WuMinkang]

Hello. The design still didn't meet timing. After we tried your advise 2 and didn't meet timing , we tried the test in Readme and found cmac_sync_0_cmac_aligned_sync signal was always '0'. We didn't find any method to fix that. So we tried Vivado 2018.3 as your advise 1 and still found the design didn't meet timing.why? Is there any method to lower the frequency the design run at?How to do that?

[mariodruiz]

What is your setup like?

How bad is the timing? You could lower the clock frequency, however, you need to change the clock source for the different IPs and include CDC logic.

[WuMinkang]

Like this.We are more familiar with verilog or chisel , not quite familiar with HLS. Thank you for your time.

[mariodruiz]

That's 10 picoseconds, you can safely ignore it. Coming back to your setup. How are you testing?

[WuMinkang]

cmac_sync_0_cmac_aligned_sync signal is just value '0' after the bitstream programmed on the U280 board.According to readme it declares the link isn't up.

[mariodruiz]

I meant the physical set up. How is the 100 GbE interface of the Alveo card connected? and Where is connected to?

To test this design you need more than the Alveo card, you need network equipment able to work at 100 GbE.

If the QSFP28 is not connected, you won't get link

[WuMinkang]

Sorry for the late reply, I got stuck by something else these days. Back to Limago. You pointed out the problem correctly. Our server was purchased recently and doesn't have QSFP28. We actually connect two QSFP28 of the Alveo card to each other.