06-29-2021 12:03 PM - edited 06-29-2021 02:24 PM
I am using a Trenz TE0710 board which has a Artix a7-35 installed as well as two ethernet PHY chips (TLK106RHB).
I built a minimal startup design in vivado including AXI EthernetLite and some peripherals: AXI Quad SPI (connected to the board's flash), AXI UartLite (connected to the board's uart for debugging).
When I take this design into Vitis and run the example code of LwIP echo server on it, everything works without problems. I even can have the auto-negotiation on with this PHY (some people report, that there are PHYs which do not work with auto-negotiation) as well as DHCP.
After adding any another AXI peripheral, like AXI GPIO or AXI Stream FIFO, the ethernet PHY can't be recognized by the processor leaving LwIP stuck inside "xemac_add", namely in function XEmacLite_PhyRead waiting for the completion of the transfer (Line 763 of xemaclite.c).This peripheral my be implemented with interrupt or without, the error is always the same.
I did already check register adresses of the FPGA design and the parameters.h, they are correct. I am already trying to solve this error for some days and can't find any clue how to proceed.
Something that I just discovered: The problem persists even when I remove the previoulsy added AXI peripheral.
What are the next steps to try?
07-09-2021 04:34 AM
Does anybody have a recommendation?
As the problem seems to be not related to the interrupts of the system, I am suspecting something that is not related to the c-Code. Is this correct?
07-09-2021 05:59 AM
Xilinx's AXI Ethernet Lite IP has some serious AXI bugs within it that show up in user testing, but not in Xilinx's internal testing. If you dig into their design, you can find these bugs without too much hassle. For example, if the interconnect doesn't initially raise RREADY (which the newer interconnects might not), the design will return the wrong data. The design might not set RLAST properly.
I could go on.
It does look like they've updated the design slightly since I last looked at it, but the bugs above are still present in Vivado 2021.1.
You might be successful if you switch interconnects, or perhaps just interconnect settings, but the design is still quite broken.
07-09-2021 08:00 AM
Thank you @dgisselq , when I look into the porum posts mentioning bugs in AXI ethernetlite, I can find a bunch now.
I did not understand correctly what you mean by switching interconnects or interconnect settings. Could you describe it a bit for me?
07-09-2021 08:33 AM
There were two settings with the pre-SmartConnect interconnect: an optimize for area setting and an optimize for performance setting. I'm unfamiliar with whether or not the SmartConnect interconnect has these settings or not. The optimize for area setting was a safe setting that only ever allowed a single burst through the interconnect at a time--whether read or write. In such cases, there was never any need for back pressure. Indeed, the verification requirements on the slave were quite minimal and many (broken) slaves would still work under this setting. I don't know if the SmartConnect interconnect has that setting anymore or not. (I don't normally use Xilinx's interconnects, choosing to use my own instead--so my knowledge of this matter is peripheral at best.)
07-09-2021 11:03 AM
I have several, but only a couple are AXI through and through. Most of my projects use Wishbone, although the bus compositor works equally well on Wishbone, AXI-lite, and AXI. Try this project--it's my axidmacheck project. It demonstrates an open source AXI DMA, S2MM, and MM2S. There's also an AXI block RAM memory controller there that nicely outperforms Xilinx's, etc. Most of my recent work has been in the zipcpu branch, where I've done some work running the ZipCPU in this environment. There are also (currently, in the zipcpu branch) performance monitors connected to all of the DMA's, the CPU, etc., so I can see how well the entire interconnect is handling things. The interconnect itself is built around an AXI crossbar, one I call axixbar. This crossbar, all of the DMAs, bus adapters, etc., can all be found in the wb2axip repository that you'll need to build the design.
Components are easy enough to add and remove. Connections are handled via AutoFPGA. (Yes, you'll also need the bus compositor, AutoFPGA, but that's also open source and found on github.) Each component has an AutoFPGA script file (see the autodata directory). "make" is then used to call AutoFPGA (autofpga <component_list*txt>) in order to compose those files together into a "main" design. Other files are created as well--to include an (optional) C++ test bench environment that can encapsulate external test bench models, a set of register definitions files which can be used when accesses the design from an external command line, as well as a .h file to tell the CPU software 1) which peripherals are present, 2) what their internal address maps look like, and 3) what addresses they've been assigned to. It even generates a linker script file, based upon a given prototype, so that any software you generate for the CPU can be placed in the right place--flash, RAM, both, etc.
Unlike Xilinx's approach, AutoFPGA is based upon human readable text files at every step of the way. Component configuration files are text files. They primarily consist of variable definitions, and snippets of logic to copy into the relevant Verilog / Make/ C / H files. The main and top level designs are simply Verilog files, etc. (Yes, AutoFPGA generates Verilog -- not VHDL, but that shouldn't be a big problem.)
I have an "intermediate" tutorial I've been working on, and zipcpu.com/tutorial, that goes over how to build several of these files and to therefore compose a design together.
No, the entirety isn't nearly as polished as Xilinx's is--there aren't any GUIs for example--but ... it's worked for me now for some time.