Arty-A7 and Microblaze

[matrixrifle]

Hi,

I am following the link verbatim to learn how to use microblaze with Arty-A7-100 board from digilent.

https://digilent.com/reference/learn/programmable-logic/tutorials/arty-getting-started-with-microblaze-servers/start

Bitstream generation gives the following error:

[DRC RTRES-1] Backbone resources: 1 net(s) have CLOCK_DEDICATED_ROUTE set to BACKBONE but do not use backbone resources. The problem net(s) are system_i/clk_wiz_0/inst/clk_out1.

Not sure what the problem is, I am pretty sure i followed the tutorial properly.

Regards

Arty_A7_lwip_echo.zip

[artvvb]

Hi @matrixrifle

Assuming you are using recent versions of Vivado and the board files, there have been some changes to both since that guide was written or last updated. In particular, where the MIG used to not throw errors when it's system clock input is downstream of a clocking wizard, it now does. The board files were updated to reflect this, and now require the reference clock input to be connected to a MIG output clock, and the system clock needs to be directly connected to an FPGA input pin. You can find more info and some alternate guides here: 

Thanks,

Arthur 

[asmi]

20 hours ago, artvvb said:

Assuming you are using recent versions of Vivado and the board files, there have been some changes to both since that guide was written or last updated. In particular, where the MIG used to not throw errors when it's system clock input is downstream of a clocking wizard, it now does.

That's not the problem with MIG, the problem is that the MIG config which is installed from Vivado store is incorrect. Here is what you need to do to make it work:

1. Change the "clock period" field on the page 3 ("Controller Options") to 3000 ps (for 333.33 MHz memory frequency).

2. Change the "input clock period" on the page 5 ("Memory Options") to 6000 ps (166.667 MHz). You can also untick "Select additional clocks" option.

3. Change the "System Clock" selection on the page 6 ("FPGA Options") to "No Buffer".

4. Go through the rest of pages without making any changes. You will need to click "Validate" to proceed past page 9 ("Pin Selection"), and you will need to accept a license agreement on the page 12 ("Simulation Options"). Once you click "Generate" on the last page, it will offer to perform out-of-context synthesis, cancel that and instead validate (it should succeed) and save your diagram, and then click "Generate Bitstream". The entire process should now complete without any errors:

 

I don't have the actual board to validate those changes in hardware, but I'm pretty sure it will work just fine. @artvvbsince you probably have access to the board, please validate those changes in hardware, and if everything checks out, update the MIG project in the Vivado store's repository.

Edited January 18, 2023 by asmi

[artvvb]

As of Vivado 2022.1, the board store includes both the updated and original version of the board files. The original version (1.0) is set up in the way you described, with a 166.667 MHz clock input. Rather than modifying the MIG manually, the older version can be picked up by selecting the 1.0 file version in the project settings, the "All board revisions" filter also needs to be selected in order to see it once installed. 1.0 is the only version available in the board store in previous versions of Vivado - though you can install board files manually and get 1.1.

I'm working on checking the guide steps with both the 1.0 and 1.1 versions of the files. We'll also look at getting the guide updated to support the updated clock architecture, this same change was implemented across a fair number of boards, while these ethernet guides haven't been touched in some years.

Section "System Clock, PLL and MMCM Locations, and Constraints" of the MIG 4.2 user guide (starting on page 194 here: https://docs.xilinx.com/v/u/en-US/ug586_7Series_MIS) has some more info on the clocking recommendations. That said, I think the 1.0 board file MIG preset for the Arty A7 likely still works, just need to test it.

Thanks,

Arthur

 

[artvvb]

Good info, thanks. For what it's worth, there are also some pretty gnarly GUI bugs that started showing up in the MIG at some point where it wouldn't keep the previous settings when you go in to change things. I'm not sure if Xilinx has fixed it or not (had seen it some time around the early 2020 versions), but I expect not. The Arty S7 had a bunch of related issues a while back, which is where the change got started off from. It's a different board, so using it to justify changes for this one might not have been the best practice.

I tested both today, and the v1.1 and 1.0 board files can both be used to create ethernet designs that work in hardware with the lwip echo server example. The clock architecture for version 1.1 can be seen here:

I manually constrained sys_clk_i instead of using the board file interface, as noted in the guide I previously linked. The clk_wiz_0 IP is configured to automatically pick up the input frequency, have an active low reset, and have a 25 MHz output frequency.

Version 1.0 as well, for good measure:

It uses the recommendations from the guide.

Thanks,

Arthur

[asmi]

32 minutes ago, artvvb said:

Section "System Clock, PLL and MMCM Locations, and Constraints" of the MIG 4.2 user guide (starting on page 194 here: https://docs.xilinx.com/v/u/en-US/ug586_7Series_MIS) has some more info on the clocking recommendations. That said, I think the 1.0 board file MIG preset for the Arty A7 likely still works, just need to test it.

Yeah, I know about these recommendations, but I've designed a fair amount of boards which drive MIG's clock from another MCMM, and there has never been a problem with that. Also there were no changes in MIG for a VERY long time (at least several years), they even refuse to fix any problems with it (like it's not possible to create a controller for dual-rank memory layout, other than to pick some dual rank memory module and hack it around to fit your memory layout).

[asmi]

17 hours ago, artvvb said:

Good info, thanks. For what it's worth, there are also some pretty gnarly GUI bugs that started showing up in the MIG at some point where it wouldn't keep the previous settings when you go in to change things. I'm not sure if Xilinx has fixed it or not (had seen it some time around the early 2020 versions), but I expect not. The Arty S7 had a bunch of related issues a while back, which is where the change got started off from. It's a different board, so using it to justify changes for this one might not have been the best practice.

I had these issues in the past, and I traced them to a realtime backup solution I used (OneDrive). Apparently the likes of OneDrive (also Dropbox, Synology Drive and others) somehow interfere with MIG, but once I've gotten rid of it (by moving my projects outside of OneDrive replicated folder), all problems went away. To make sure my projects are still backed up, I set up the Synology Drive (I have a Synology NAS in my network, so using their solution was an obvious choice for me) to perform backup daily during the night when I'm not using my PC instead of realtime backups. So if you still experience those and use any of those things I mentioned above, try moving your projects outside of them and see if problem still persists.

[matrixrifle]

Hi,

I am using Vivado v2022.2, vitis v2022.2, My digilent Arty board revision is E and i have tried with both versions of board files 1.1 and 1.0. I can confirm that the issue with the bitstream generation is no longer there although i dont understand why the clocking is different between 1.1 and 1.0 given that the physical board is the same.

However, the bigger problem is that now running the lwip example leads to the following messages on the uart

-----lwIP TCP echo server ------

TCP packets sent to port 6001 will be echoed back

link speed: 100
unable to determine type of EMAC with baseaddress 0x40E00000
Error adding N/W interface

 

Not sure what the problem is now.

To try and debug the issue with my limited knowledge of ethernet i tried some of the examples in

https://github.com/Xilinx/embeddedsw/tree/master/XilinxProcessorIPLib/drivers/emaclite/examples

and i successfully ran Emaclite selftest Example,  Emaclite interrupt Example and the Emaclite phy loopback Example.

When i tried to run the xemaclite_ping_reply_example.c (from the above github examples link), the router successfully recognised the device and the IP and MAC corresponded to what i had in the code, however, i could not get a ping response from my computer to the board.

My computer IP was set to 192.168.1.64 and the board IP address as set in the code was 192.168.1.66. I did not change the MAC address and it was kept the same as default in the code.

The router did not have any other device on the network and is disconnected from the internet.

I also tried to follow the same steps as shown in the youtube video : "Microblaze & Ethernet on ARTY A7" if you search the youtube site, but i still got the unable to determine the type of EMAC error.

lwip is lwip211_v1_8.

Running with the lwip debug options enabled lead to following on the serial terminals

-----lwIP TCP echo server ------
TCP packets sent to port 6001 will be echoed back
netif: netmask of interface  set to 255.255.255.0
netif: GW address of interface  set to 192.168.1.1
netif_set_ipaddr: netif address being changed
XEMacLite detect_phy: PHY detected at address 1.
XEMacLite detect_phy: PHY detected.
link speed: 100
netif: added interface xe IP addr 192.168.1.10 netmask 255.255.255.0 gw 192.168.1.1
unable to determine type of EMAC with baseaddress 0x40E00000
Error adding N/W interface

Please help.

 

 

 

Edited January 22, 2023 by matrixrifle

[manjagu]

Hi All, I'm trying to replicate what was done above by the OP with my Arty A7-35 on Vivado 2022.2.1. When I use the default mig.prj ver 1.1, I get stuck without the chip option MT41K128M16JT-125. The default is the -15E, which has some speed limitations, and the MIG wizard won't let me proceed to take the clock speed up. I double checked my board and it is populated with the -125.

I've tried a few work-arounds, including manually editing the mig.prj file, and I just get myself into various other sticky places. I'm trying to use the new Xilinx "recommended" clocking scheme rather than putting the PLL before the MIG.

Any recommendations?

[matrixrifle]

@manjagu I just used the digilent board files and installed them. Didn't play with the mig.prj file as I didnt fully understand the settings. Use the board files and you don't need to modify the settings except the different mig clock connection between version 1 and 1.1 which I still don't understand why its different given the physical board is the same.

https://github.com/Digilent/vivado-boards

[Mafra81]

On 1/21/2023 at 8:08 PM, matrixrifle said:

Hi,

I am using Vivado v2022.2, vitis v2022.2, My digilent Arty board revision is E and i have tried with both versions of board files 1.1 and 1.0. I can confirm that the issue with the bitstream generation is no longer there although i dont understand why the clocking is different between 1.1 and 1.0 given that the physical board is the same.

However, the bigger problem is that now running the lwip example leads to the following messages on the uart

-----lwIP TCP echo server ------

TCP packets sent to port 6001 will be echoed back

link speed: 100
unable to determine type of EMAC with baseaddress 0x40E00000
Error adding N/W interface

 

Not sure what the problem is now.

To try and debug the issue with my limited knowledge of ethernet i tried some of the examples in

https://github.com/Xilinx/embeddedsw/tree/master/XilinxProcessorIPLib/drivers/emaclite/examples

and i successfully ran Emaclite selftest Example,  Emaclite interrupt Example and the Emaclite phy loopback Example.

When i tried to run the xemaclite_ping_reply_example.c (from the above github examples link), the router successfully recognised the device and the IP and MAC corresponded to what i had in the code, however, i could not get a ping response from my computer to the board.

My computer IP was set to 192.168.1.64 and the board IP address as set in the code was 192.168.1.66. I did not change the MAC address and it was kept the same as default in the code.

The router did not have any other device on the network and is disconnected from the internet.

I also tried to follow the same steps as shown in the youtube video : "Microblaze & Ethernet on ARTY A7" if you search the youtube site, but i still got the unable to determine the type of EMAC error.

lwip is lwip211_v1_8.

Running with the lwip debug options enabled lead to following on the serial terminals

-----lwIP TCP echo server ------
TCP packets sent to port 6001 will be echoed back
netif: netmask of interface  set to 255.255.255.0
netif: GW address of interface  set to 192.168.1.1
netif_set_ipaddr: netif address being changed
XEMacLite detect_phy: PHY detected at address 1.
XEMacLite detect_phy: PHY detected.
link speed: 100
netif: added interface xe IP addr 192.168.1.10 netmask 255.255.255.0 gw 192.168.1.1
unable to determine type of EMAC with baseaddress 0x40E00000
Error adding N/W interface

Please help.

 

 

 

Hello, 

I'm receiving the exact same message through UART when running the lwip echo_server application. My software version for Vitis and Vivado, and the lwip library have the same version as yours.

To produce the .xsa file used to build a platform for this application I've followed the recent tutorial at Digilent: Digilent Guides - Getting Started with IPI

As the guide above didn't include the implementation of AXI ethernetlite, I did that similarly to the old "Getting started with MicroBlaze servers" that was mentioned in this thread.

Both this design and the one suggested by @artvvb lead to the same issue reported by you when trying to connect to DHCP. 
I'm still going to try with a fixed IP address, if it works I'll update this message (it didn't). 

Have you, or anyone else, found the solution to this problem?

My kindest regards,

Edited April 5, 2023 by Mafra81
Wasn't concise enough and didn't provide any relevant information. Added a new result.

[Mafra81]

Hi again,
 

(Update)

Turns out that the lwip211 v1.8 has a bug in the xadapter.c file. (../libsrc/lwip211_v1_8/src/contrib/ports/xilinx/netif/xadapter.c) 

Essentially, in the library source file mentioned above, due to a default clause 2 case statements fail to take action and leads to yielding the error that @matrixrifle reported. The most simple solution is to place 2 break statements after each of those cases, so that the default clause doesn't intervene.

 

In more detail: (below line 137 of xadapter.c)

		switch (find_mac_type(mac_baseaddr)) {
			case xemac_type_xps_emaclite:
#ifdef XLWIP_CONFIG_INCLUDE_EMACLITE
				nif = netif_add(netif, ipaddr, netmask, gw,
					(void*)(UINTPTR)mac_baseaddr,
					xemacliteif_init,
#if NO_SYS
					ethernet_input
#else
					tcpip_input
#endif
					);
#else
				nif = NULL;
#endif
			break;
			case xemac_type_axi_ethernet:
#ifdef XLWIP_CONFIG_INCLUDE_AXI_ETHERNET
					nif = netif_add(netif, ipaddr, netmask, gw,
					(void*)(UINTPTR)mac_baseaddr,
					xaxiemacif_init,
#if NO_SYS
					ethernet_input
#else
					tcpip_input
#endif
					);
#else
				nif = NULL;
#endif
			break;

This enabled me to run an echo server on my designs, including those proposed by Arthur. 

Best regards,

Edited April 6, 2023 by Mafra81
Included the line where the code is at.

[zzzhhh]

I encountered the same problem days ago and I solved this problem by adding a line into Arty-A7-100-Master.xdc file:

set_property CLOCK_DEDICATED_ROUTE TRUE [get_nets system_i/clk_wiz_0/inst/clk_out1]

See https://support.xilinx.com/s/article/75692

 

[zzzhhh]

artvvb's reply reveals the root cause. The original design in which I got the same BACKBONE error sends clock signal from a clock wizard to MIG, not from MIG to clock wizard required by the recent Vivado (like Vivado 2022.2.2 I am using). After I reverse the clock path, the BACKBONE error disappears.

artvvb, can you please, however, explain to us why we should send clock signal from MIG to other downstreaming components if we don't wanna see the BACKBONE error? Also, I have another question about picking clock connection here: Why "Do not select the system clock input to the MIG"? Can you please answer? I'm a verified buyer of Digilent product. Thanks a lot.

[jarvis]

I just went through the following today: Googled for the Digilent Arty A7 Microblaze Ethernet example, looked like a very nice tutorial so I tried going through it, got implementation errors, searched the forums for quite some time where the topic of MIG errors come up quite often, could never really get a concise set of instructions, but piecemeal actions/ideas. I finally got to this thread where artvvb posted the correct block design and then vaguely described "manually constraining sys_clk_i". Also there was a mention of an updated tutorial in a link to a different forum post, but as far as I can tell it doesn't show anything related to the MIG or Ethernet, and references a Zynq PS instead.

Does an updated A7 Microblaze Ethernet tutorial exist? Is there any reason not to delete the older tutorial since it will not build?

[tato_siePT]

Jeesh!!! I just went through an ordeal to get this to work.

I have VIVADO 2022.2

First I got the "BACKBONE" error which I tried first fixing by setting the CLOCK_DEDICATED_ROUTE to TRUE. Then I was able to produce a netlist, but when I ran the LWIP Echo Server there was no output even throught the SERIAL port!!!!

Then I tried changing the board file version to 1.0. Finally the Serial port started to work. But I then got the "unable to determine type of EMAC with baseaddress 0x40E00000" error which I was able to fix by changing the xadapter.c code as suggested above.

What I don't understand is why using the V1.1 of the board file, I was not able to even get the serial port to work. Really strange!!!!

I'm going to try the UDP function. Let's hope!!!

Thanks!!!