artvvb

Hey @bloggins666 So the baseline issue is that the XUartLite examples aren't built to target Zynq chips, seeing as the PS UART controllers could be used instead. Given that, there are a couple options: First, EMIOs could be used to connect the spare PS UART controller to PL pins. This is likely the "more correct" approach in a vacuum since it uses fewer FPGA resources. It would entail editing the Zynq PS configuration in Vivado to enable the second PS UART, make its UART interface on the PS block external, and constrain the IOs. Care should be taken to use the right device IDs when loading the XUartPs examples as you would also have another PS UART enabled, which is used for standard input/output. Second, the XUartLite interrupt example could be adapted to use XScuGic instead of XIntc (the latter is the driver for the AXI interrupt controller commonly used with Microblaze systems). The below is a modified version of SetupInterruptSystem from xuartlite_intr_example, which is based on code from the xuartps interrupt example. It worked in a cursory test in hardware on another board for me, though I didn't scope the TX->RX loopback to check if signals were actually going out of the board. The only other change to the file needed was to replace the xintc.h inclusion with xscugic.h. The Get/SetPriorityTriggerType calls were recommended by this thread: https://support.xilinx.com/s/question/0D52E00006iI3urSAC/uartlite-interrupts-not-working-on-zynq. Edit: In case it matters, this is baremetal in Vivado/Vitis 2023.1. Hope this helps, Arthur

Please refer to the "ISE 14.1 Version" download under ZedBoard Configuration and Booting Guide in the Reference Designs tab of this page on Avnet's site: https://www.avnet.com/wps/portal/us/products/avnet-boards/avnet-board-families/zedboard/. Note that both because this is material developed outside of Digilent, and because it's very outdated - ISE is not supported on Windows 10 - we will be unable to provide much if any help if you run into issues with it. Thanks, Arthur

Hi @Leon18, You can find the user guide, schematics, etc, here: https://digilent.com/reference/programmable-logic/zedboard/start. As Zygot mentioned, it is a low-pin count connector. Thanks, Arthur

@engrpetero Mostly restating what Zygot already pointed out, but: For AXI in particular, you could trigger a state transition on a write strobe - when the address is already stored in a register and you receive a data beat on the write data interface, you have the write data's tready & tvalid signals high for that clock cycle, and'ed together (alongside a compare to determine that the right address is being written), they represent a "strobe" that is high for a single clock cycle. This also doesn't rely on setting or clearing any particular bits in the data itself, so it doesn't take much additional overhead. Alternatively, if more than one word of configuration data is required, setting a bit in another control register that clears itself after being written is a common pattern. Enabling a counter for as long as a state machine is in a particular state, and exiting that state when the counter rolls over, is also appropriate.

Worst case, creating a new workspace with a new platform created from the same XSA, and a new application project that includes the sleep header, will tell you whether the default BSP settings are sufficient.

Hi Darren, How are you interacting with the DMA controller? If using SimpleTransfers and either interrupts or polling to check when a transfer is complete and restart the DMA, there will be some downtime while the processor is accessing various peripherals. Interrupts should respond quicker than polling, but still involve some AXI lite accesses that take a bit of time. Two recommendations would be to check the FIFO size to see if it can be increased to cover the downtime, and to connect the DMA's AXI lite and AXI S2MM interfaces to the ILA to take a look at how and when the DMA is accessed and sending data to DDR. I may be misunderstanding the timing diagrams, but it looks like you're sending 8 words per transfer? One other possibility is that you could make transfers longer by sending multiple packets per transfer, by only sending a tlast bit for some of them, and modifying C sources as appropriate. This would reduce the frequency at which transfers need to be reinitiated. I'm also curious how you are setting up transfers in software - a full reset of the DMA between transfers would take quite a bit of time. Thanks, Arthur

Zynq-7000 supports the functions included in "sleep.h". Eclypse and other boards will support it without modifications to default BSPs - I've used usleep and sleep occasionally. Microblaze has been spotty with it depending on the tool version, but I think it works in recent versions (I recall it not having a complete implementation back in like 2016.4 or something). I am fairly sure that this driver relies on BSP settings like those mentioned to determine how to actually implement delays, but am unclear on the details. Thanks, Arthur

I copied the code back in from scratch, and yes, I see the bug again. Try the following edits to the python script? import socket client = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.connect(("10.0.0.128", 7)) # connect to the server; enter your server's IP and port here # number of bytes we're requesting from the server; change this as desired num_bytes = 2000 # arbitrary packet size, max number of bytes we'll receive at once packet_size = 500 # note: little endian is important, requirement for Zynq-7000 to easily translate the sent number to an int without reordering print(f"requesting {num_bytes.to_bytes(2, 'little')} bytes") client.send(num_bytes.to_bytes(2, 'little')) # request {num_bytes} bytes in response # loop while calling recv to receive data from the client until the expected number of bytes has been successfully transferred received = 0 errors = 0 value = 0 while received < num_bytes: data = client.recv(packet_size) for d in range(len(data)): if data[d] != 0xff & value: # validate data print(f"Error, data[{d}] ({data[d]}) != {0xff & value}") errors += 1 value += 1 received += len(data) print(received, len(data)) if errors == 0: print("All data received matched the expected values!") else: print(f"{errors} errors") This tracks the "value" separately from the index of the data in the buffer - changing packet sizes away from 256 or receiving amounts of data other than 256 in one block before would have caused the value that the script uses to compare against received data not to match. I'm out most of the week but will take a look at updating the post when I'm back. Thanks, Arthur

Please check your block design sources tab, it should look something like the image below. Note that there are several files in the design sources. In this case (I don't have the same project open), there is a block design file (.bd), which is listed under an HDL top module (_wrapper.v). The wrapper file should be bolded, which indicates that it has been selected as the top layer of the design. RTL modules used in the design (like the test.v file in the screenshot) may be listed underneath the wrapper at the top level of the hierarchy, or nested underneath the block design file somewhere. These errors indicate to me that a different file has been selected as the top module, and the port names used in the constraints don't match what that top module expects - and the port names all match what I'd expect from one of the RTL modules in the design. Make sure the top module is actually a block design wrapper. This could happen if using checkout scripts in a Vivado version that is incompatible - in that case, the block design might only be partially complete or empty, where a wrapper can't be automatically created.

Did you also recreate IP in 2023.1, or are you using the same IP repo folder? Hopefully, the IP didn't also get modified when the upgrade happened, but it seems possible. The clock interface in the ports and interfaces view should have some "ASSOCIATED_BUSIF" parameters you can access by double-clicking on the clock in the port list. I'd guess the IP was modified such that the AXI interface shows up twice in here, but this is a really strange one I haven't seen before.

It looks like there are more callbacks that could also be used listed out in the tcp.h header - lines 60-134 for function prototypes and 414-421 for callback registration functions. The callback registration function implementations in tcp.c also have more information/documentation in their function headers. I'd take a look at either figuring out if tcp_err is called for the kind of disconnect event you are looking at, or implementing a timeout with tcp_poll.

Use the Zynq preset from the board files (which contains various required information like clock frequencies) and use a controller in the design IP for the pods you want to install (potentially required to get the pods initialized, but not required to power on the board). Following this guide will get you through the basic setup for the host board: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi. DNA is located on the pods/Zmods. In the case of the Zmod scope, this is implemented in an ATtiny MCU: https://digilent.com/reference/zmod/scope/reference-manual#mcu.

You would also need to modify echo.c on the board side. The way the blog code is structured makes it so that tcp_write is called from the recv_callback. If the server never receives a byte count to return, it never tries to send anything back to the client. You might call tcp_write (and set up the globals that manage how much is in the buffer) from like the interrupt handler servicing the AXI master, or just from main for testing purposes. You'd also want to make sure that the server doesn't try to send data before the connection is established, either by waiting for an accept_callback to occur before sending anything, or by starting the python script before running the app on the board.

You can manually wire ports within interfaces to other ports, the interfaces expand with the "+" button on the IP. Be aware of how clock signals are used. Latency through various modules will affect how accumulator data and adc data are aligned in the stream. For what it's worth, the following is the code for the create_tlast module in the above screenshot, which just ties the tlast of the m interface low.

What can be selected in the GUI depends on what device is targeted. MCS files are only supported when the target is explicitly "XCF02S", "XCF04S", or "XCF01S" devices.

Hi ManiS, Responded in your other thread: Thanks, Arthur

Hi @ManiS Sorry for the delay. I've passed your question on to another engineer with more Petalinux experience. For some more information, decutil (Digilent Eclypse utility) was renamed to dpmutil (Digilent platform management utility) some time back. You could potentially use it without the command line utility. Source code and an API that should be usable for both Petalinux and baremetal projects can be found in this repo: https://github.com/Digilent/dpmutil. You can find a baremetal example using it here: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/ddr-streaming, source code here: https://github.com/Digilent/Eclypse-Z7-SW/blob/b42fb15a8ab4c52a38db2c15918cd7263e84f65e/src/calibration_reader/src/main.c. Thanks, Arthur

DNA refers to an EEPROM on the daughter board connected to the Eclypse via I2C. If it exists - which it does for all Zmods - then the PMCU will read it before the Zynq is up and running. Mentioning pods without DNA was only intended to cover a case where a custom pod was in development and the EEPROM for it hadn't been added to a prototype yet, or its contents were still being worked out.

This thread is pushing the bounds of my knowledge a bit, so grain of salt, but yeah, it's possible. DDR is "just memory addresses", you can access peripherals via interconnect while in an ISR as well. I would just be aware that you're potentially either blocking other interrupts from starting for as long as you stay in the ISR (by disabling interrupts), or you're potentially getting interrupted by other things coming through. This isn't super relevant until you're pushing the processor hard. Like if you have an interrupt that requires that the processor intervenes within a short time, while the processor happens to be busy copying a big array of data from one location to another with interrupts disabled.

C sources should include xil_cache.h and call Xil_DCacheInvalidateRange before accessing the memory that the IP has written into. I think what's happening is that the data written on the first pass is being cached and the cached values are being read instead of new stuff in DDR on every subsequent pass. https://github.com/Digilent/Zybo-Z7-SW/blob/c21218c91e7d6dfd2018d35932a5f0d9d38eec9a/src/Zybo-Z7-20-DMA/src/demo.c#L262 is where the audio demo invalidates cache for received data. Your base address and byte count for the call will differ. You might call this in the handler or wherever in your C source you're reading that data.

Hi @Jerin James The PMCU handles configuring the adjustable voltage rails as the board is powered on. After powerup, the PMCU can be communicated with to change settings if necessary and to do things like control fan speed. If SYZYGY pods with DNA are installed, the PMCU reads out their power requirements and uses that to configure the supplies appropriately - in this case, no changes are necessary. If SYZYGY pods are installed that do not have DNA, their power rails will not be turned on, and the decutil/dpmutil utility will need to be used to set the voltages for relevant VIO supply groups. Thanks, Arthur

Without having read the verilog sources yet, it sounds like you might not be invalidating the cache across the range of addresses that you're transferring data into before accessing them.

IRQ_F2P interrupts are all "SPI", shared peripheral interrupts, from p45 of the Zynq TRM:

Since the interrupt output is connected to a port, are you checking it with a logic analyzer? You could also wire up various signals to an ILA and view them via the hardware manager. To add an ILA to the design, you'd right click on any nets you want to test, select debug (screenshot below), then run connection automation to connect them all to ILAs. Then, when the bitstream is loaded onto the board (maybe while debugging in Vitis), you can open the Vivado hardware manager, and once the board is connected, some internal logic analyzers should pop up. This would let you take a look at the waveforms for the interrupt signal and any AXI traffic into or out of your module (I think by default the window size is 1000 clocks, centered on a trigger). Apologies if this is vague, we don't currently have any step-by-step content on the topic.

Ah, yeah, my bad, looks like it's rising edge sensitive. I'll need to see if I can reproduce. The acronyms are defined in the Zynq TRM: https://docs.xilinx.com/r/en-US/ug585-zynq-7000-SoC-TRM/Private-Shared-and-Software-Interrupts