search

ipbus / ipbus-firmware

Firmware that implements a reliable high-performance control link for particle physics electronics, based on the IPbus protocol
https://ipbus.web.cern.ch
Other
41 stars 32 forks source link

Detected runs in ERROR temac_gbe_v9_0_synth_1, gig_ethernet_pcs_pma_basex_156_25_synth_1 #190

Open giacomoCucciati opened 3 years ago

giacomoCucciati commented 3 years ago

Hi IPBus team, I have a problem following the instructions reported at:

https://ipbus.web.cern.ch/doc/user/html/firmware/exampleDesigns.html#build-instructions

using as board the kcu105 model

In particular the command 

lpbb vivado make-project

can arrive to the end with a critical warning

CRITICAL WARNING: [Coretcl 2-1280] The upgrade of 'IP gig_ethernet_pcs_pma_basex_156_25' has identified issues that may require user intervention. Please verify that the instance is correctly configured, and review any upgrade messages.

But then, with command

ipbb vivado synth -j4 impl -j 4

I get a blocking error:

ERROR:
Detected runs in ERROR temac_gbe_v9_0_synth_1, gig_ethernet_pcs_pma_basex_156_25_synth_1. Exiting
Aborted!

I am using Vivado 2019.1

I am adding the two logs obtained by the commands

log_synth.txt vivado_synth.log log_make.txt vivado_make-project.log

Thank you in advance Giacomo

alessandrothea commented 3 years ago

Ciao Giacomo,

Unfortunately the attached log files don't provide much insight on the source of the error as the OOC runs logs are elsewhere: 

/home/gcucciat/Documents/xilinx_example/proj/kcu105/kcu105/kcu105.runs/temac_gbe_v9_0_synth_1/runme.log
/home/gcucciat/Documents/xilinx_example/proj/kcu105/kcu105/kcu105.runs/gig_ethernet_pcs_pma_basex_156_25_synth_1/runme.log

Anyways, based on the fact that ipbus is regularly built against Vivado 2019.2, I suspect that it might be a Vivado licence issue (those 2 cores can't be synthesised w/o a licence). Can you check and let us know?

Alessandro

dpcsankey commented 3 years ago

On the nail...

WARNING: [IP_Flow 19-650] IP license key @.***' is enabled with a Design_Linking license.

You need a TEMAC license, Xilinx University Program usually will give you one for free.

Dave

On 6 Apr 2021, at 13:21, Alessandro Thea @.***> wrote:

Ciao Giacomo,

Unfortunately the attached log files don't provide much insight on the source of the error as the OOC runs logs are elsewhere:

/home/gcucciat/Documents/xilinx_example/proj/kcu105/kcu105/kcu105.runs/temac_gbe_v9_0_synth_1/runme.log /home/gcucciat/Documents/xilinx_example/proj/kcu105/kcu105/kcu105.runs/gig_ethernet_pcs_pma_basex_156_25_synth_1/runme.log

Anyways, based on the fact that ipbus is regularly built against Vivado 2019.2, I suspect that it might be a Vivado licence issue (those 2 cores can't be synthesised w/o a licence). Can you check and let us know?

Alessandro

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.

giacomoCucciati commented 3 years ago

Ciao Alessandro!

Thanks for the support. I had a look into the log files you have suggested and they both report the problem with the license.

Starting synth_design
Attempting to get a license for feature 'Synthesis' and/or device 'xcku040'
WARNING: [Common 17-348] Failed to get the license for feature 'Synthesis' and/or device 'xcku040'. Explanation: The license feature Synthesis could not be found.
Resolution: Check the status of your licenses in the Vivado License Manager. For debug help search Xilinx Support for "Licensing FAQ".
0 Infos, 1 Warnings, 0 Critical Warnings and 1 Errors encountered.
synth_design failed
ERROR: [Common 17-345] A valid license was not found for feature 'Synthesis' and/or device 'xcku040'. Please run the Vivado License Manager for assistance in determining
which features and devices are licensed for your system.
Resolution: Check the status of your licenses in the Vivado License Manager. For debug help search Xilinx Support for "Licensing FAQ". If you are using a license server, verify that the license server is up and running a version of the xilinx daemon that is compatible with the version of Xilinx software that you are using. Please note that Vivado 2017.3 and later requires upgrading your license server tools to the Flex 11.14.1 tools. Please confirm with your license admin that the correct version of the license server tools are installed.
INFO: [Common 17-206] Exiting Vivado at Tue Apr  6 11:22:26 2021...

I don't know the software so sorry in advance for the naive questions but... Is there something I can do with the License? Would installing Vivado 2019.2 be a solution?

jhegeman commented 3 years ago

Hi Giacomo,

If you are at CERN and using linux, then export XILINXD_LICENSE_FILE="2112@licenxilinx" should set things up to use the CERN Xilinx licences from the main server. (I'm not sure if the above licenses are in there, but I suspect they are.)

Cheers, Jeroen

giacomoCucciati commented 3 years ago

Thanks Dave, Jeroen. I have done:

export XILINXD_LICENSE_FILE="2112@licenxilinx"
ipbb vivado make-project
ipbb vivado synth -j4 impl -j 4

and I managed to arrive to 

kcu105: Implementation completed successfully.

Even if some warnings have been reported during both the make and the synth commands like

make-project | WARNING: [IP_Flow 19-2162] IP 'gig_ethernet_pcs_pma_basex_156_25' is locked:
...
make-project | WARNING: [IP_Flow 19-2162] IP 'temac_gbe_v9_0' is locked:

and many of 

synth | ... Unused sequential element ...

or 

synth | ... has unconnected port ...

I hope nothing important that blocks the main functionalities. I will test it on the board and let you know the results! :)

Thanks ad cheers Giacomo

dpcsankey commented 3 years ago

You get the IP_Flow 19-2162 messages as the initial version is out of date, but then later in make-project we update the cores.

So in my kc705 project I saw:

[heplnw061] ~/firmware/dhcp/proj/kc705_gmii % grep -i mac_fifo_axi4 vivado_make-project.log import_files -norecurse -fileset sources_1 /data/dpcs/firmware/dhcp/src/ipbus-firmware/components/ipbus_eth/firmware/cgn/mac_fifo_axi4.xci /data/dpcs/firmware/dhcp/src/ipbus-firmware/components/ipbus_eth/firmware/cgn/temac_gbe_v9_0_gmii.xci WARNING: [IP_Flow 19-2162] IP 'mac_fifo_axi4' is locked:

The Synth 8-6014 messages seem to be an artefact of my coding style of having a variable in a process driving a signal which Vivado maps onto a register which it then subsequently removes.

The Synth 8-3331 messages essentially reflect that we have a hierarchical address space so not all address bits are meaningful at every instantiation of a register.

Dave

On 6 Apr 2021, at 14:18, giacomoCucciati @.***> wrote:

Thanks Dave, Jeroen. I have done:

export @.***" ipbb vivado make-project ipbb vivado synth -j4 impl -j 4

and I managed to arrive to

kcu105: Implementation completed successfully.

Even if some warnings have been reported during both the make and the synth commands like

make-project | WARNING: [IP_Flow 19-2162] IP 'gig_ethernet_pcs_pma_basex_156_25' is locked: ... make-project | WARNING: [IP_Flow 19-2162] IP 'temac_gbe_v9_0' is locked:

and many of

synth | ... Unused sequential element ...

or

synth | ... has unconnected port ...

I hope nothing important that blocks the main functionalities. I will test it on the board and let you know the results! :)

Thanks ad cheers Giacomo

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.

giacomoCucciati commented 3 years ago

Hi Dave, ok the lock message you have reported is similar to the one in my output (of course considering the different hardware). Also the part related to the "Upgraded ..." is similar with my "Upgraded temac_gbe_v9_0..."

Even if in for gig_ethernet_pcs_pma_basex_156_25 I have:

Upgrading 'gig_ethernet_pcs_pma_basex_156_25'

followed by

WARNING: [IP_Flow 19-3501] Upgraded gig_ethernet_pcs_pma_basex_156_25 from 1G/2.5G Ethernet PCS/PMA or SGMII 15.1 to 1G/2.5G Ethernet PCS/PMA or SGMII 16.1, with warnings. Please review the message log
CRITICAL WARNING: [Coretcl 2-1280] The upgrade of 'gig_ethernet_pcs_pma_basex_156_25' has identified issues that may require user intervention. Please verify that the instance is correctly configured, and review any upgrade messages.

I hope not so critical :)

dpcsankey commented 3 years ago

Digging at this I see that Xilinx have changed a parameter PHYADDR ("PHY address for the core”, which was set to 1) in 1G/2.5G Ethernet PCS/PMA or SGMII version 15.1 to an input port phyaddr[4:0] in version 16.0 on…

Looking at page 170 in the new version of PG047 (p 176 in the previous version) this appears to relate to MDIO management interface for the PHY, which we don’t use…

D

On 6 Apr 2021, at 15:53, giacomoCucciati @.***> wrote:

Hi Dave, ok the lock message you have reported is similar to the one in my output (of course considering the different hardware). Also the part related to the "Upgraded ..." is similar with my "Upgraded temac_gbe_v9_0..."

Even if in for gig_ethernet_pcs_pma_basex_156_25 I have:

Upgrading 'gig_ethernet_pcs_pma_basex_156_25'

followed by

WARNING: [IP_Flow 19-3501] Upgraded gig_ethernet_pcs_pma_basex_156_25 from 1G/2.5G Ethernet PCS/PMA or SGMII 15.1 to 1G/2.5G Ethernet PCS/PMA or SGMII 16.1, with warnings. Please review the message log CRITICAL WARNING: [Coretcl 2-1280] The upgrade of 'gig_ethernet_pcs_pma_basex_156_25' has identified issues that may require user intervention. Please verify that the instance is correctly configured, and review any upgrade messages.

I hope not so critical :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.

giacomoCucciati commented 3 years ago

Thanks for the investigation! 👍

giacomoCucciati commented 3 years ago

Hi all, I think I managed to compile and load the firmware. Now I have plugged in the SFP0 case a SFP RJ45 and then connected it to the computer we use for programming the card with ethernet cable. We tried to ping the board at address: 192.168.200.16 (all switches are low) but I don't get any answer.

I have checked few more things:

Maybe you have a suggestion on what kind of debugging I can do... Is there a possibility to test the board in one of your test benches where you are sure that a kcu105 is working?

Thank you in advance Cheers

tswilliams commented 3 years ago

Hi,

One problem people have encountered in the past with the KCU105 is the reference clock being at the wrong frequency [1]; have you set that to 156.25 MHz?

If you're still seeing problems after setting that, then the quickest way to debug the problem may be to add an ILA to monitor the signals out of the ethernet block. If packets are arriving at that level and no packets are being sent out, then it could be an ipbus issue. If no packets arrive, then it could either be a problem in the communication between the board and the switch, or between the FPGA and the SFP.

Cheers, Tom

[1] https://github.com/ipbus/ipbus-firmware/issues/52

giacomoCucciati commented 3 years ago

Thanks for the suggestion! I am not sure about the clock frequency, so I will start from that as soon as I will have the setup back in the lab.

Cheers