jarvis

Have you been able to get this application to boot up from QSPI and run properly? After a cold boot, I'm required to either manually press the re-config button once, or I have to hold down the reset button while I apply power, keep it held for a few seconds, and then let go. If I just plug in USB cable for power and do nothing else, I can tell that the fabric is configured and running, but looks like the Microblaze gets stalled. Any ideas?

Well I'll play the devil's advocate here: If you put a DDR chip on a board, then obviously at least one application goal is to use the MIG/DDR memory controller, and if that's the highest speed speed device you have on the PCB, then I'd think extra care would be taken to make sure it's following all the rules. But I think I get your general gist: these boards were a quick and cheap design, extra design care comes with extra development costs. Is the cost of an extra oscillator really a valid point, because wouldn't the optimal fix to be to just route the existing oscillator to a pin in the proper bank? Or is there some other downside to doing that? I'm happy to accept that "it is what it is", but really my question was: What exactly is the official/accepted workaround here? Just include the BACKBONE constraint, or something else?

I'm seeing mixed instructions depending on all the various examples online and on the forum regarding Arty A7: I have the 100 MHz sys_clk pin directly tied to the MIG's sys_clk_i port (nothing else trying to use this clock directly), then the MIG uses ui_clk for AXI/Microblaze stuff, and the MIG's ui_addn_clk goes to a clock wizard for eth_ref_clk. When I build, it complains about sub-optimal placement, indicating that these things should be in the same clock region but are not (was this a schematic design oversight?): specifically sys_clock_IBUF_inst (IBUF.o) locked to IOB_X1Y76, and the MIG's plle2_i (PLLE2_ADV.CLKIN1) locked to PLLE2_ADV_X1Y0. It says I can add the <set_property CLOCK_DEDICATED_ROUTE BACKBONE [get_nets sys_clock_IBUF]> constraint to work around this, but it warns that this is highly discouraged. I just wanted to confirm that adding the constraint is indeed what I must do, or if there's a different/best practices solution?

I'm still having issues, and I don't see any glaring difference. Are you able to call out the frequencies of the different clocks used in your block design? Did you have to add the BACKBONE constraint to get through implementation?

Awesome @JColvin, thanks again!

Which file in the ports/xilinx/netif folder did you modify?

Thanks for looking into this. I will definitely try out this change.

I'm on an Arty A7 35T and I have a microblaze with the standard SDK lwip examples running. When the app runs, I very quickly see the normal echo server printout stuff: "link speed: 100, Board IP: 192.168...blah blah. TCP echo server started @ port 1022" Despite seeing no error messages, when I try to ping the board from my PC, I get absolutely no responses for about 60 seconds, but then it clears up and ping/TCP starts working fine. Maybe one out of every 6 bootups, it never clears up and I have to hit the reset button and try again. Any ideas what might be going wrong? I'm just running example design stuff so I haven't manipulated code.

I'm on an Arty A7 35T, creating microblaze applications to run out of DDR. I'm not 100% sure why, but when I try to use SDK's run or debug application (TCF), I'm seeing absolutely nothing happen in the terminal or LEDs, as if the code isn't running. I don't get any error messages or stuck progress bars, I see text scrolling in the "SDK Log" window when I click debug/run, but other than that I get no execution. However, if I go through the process of creating a SREC bootloader and boot the DDR application from QSPI, everything works fine. So it seems the problem is specifically trying to run the code from SDK. I can successfully program the bitstream from SDK, and I can tell the clocks are running correctly and nothing is held in reset. It's programming the microblaze with "bootloop". Any ideas how to diagnose this issue?

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?