artvvb

No SREC bootloader required. They're typically used to copy a larger application from flash into DDR and then jump to start running the copied application. In that scenario, the bootloader would be merged with the bitstream similar to how the ELF file is merged here (though I believe Vitis/SDK will do that part under the hood, not positive) so that it starts running as soon as the bitstream is programmed into the FPGA. Whatever program runs on startup has to fit in Microblaze local memory, which an SREC bootloader can, but those larger apps running out of DDR cannot. Hope this helps.

Welcome to the forum!

Hi @jaberroteran10, Welcome to the forums! I ran through this guide with a Cmod A7-35T today and it worked fine in Vivado/Vitis 2023.1 for me: https://www.instructables.com/Flashing-a-MicroBlaze-Program/. A couple of notes: 1. It's easy to miss the bitstream configuration settings, like setting master SPI x4 mode, so please be sure to pay close attention to those steps. 2. A "Tristate CCLK pin during configuration" setting has been added to the Edit Device Properties -> Configuration screen. I left this as default. 3. The ELF file can be found in the application project binaries folder in Vitis after build: 4. I built the software app for Debug configuration, which could make a difference, and haven't tested building for Release. Thanks, Arthur

Looking into it. The calibration reader app expects the names to be "Zmod ADC 1410-105" and "Zmod DAC 1411-125", based on the original names of the products before a rebrand. The EEPROM contents that store the product model name must have been changed. Changing lines 23:27 and 53:57 of main.c in the calibration_reader app as follows should clear the issue, using this as the point of comparison if you've made any changes: https://github.com/Digilent/Eclypse-Z7-SW/blob/ddr-streaming/src/calibration_reader/src/main.c. Thanks, Arthur

I'm not sure if I understood your question - a SYZYGY pod is a separate physical PCB from the Eclypse baseboard, and is mounted on top prior to the board powering on. If no pods are present, there is no DNA, and the VADJA and VADJB rails aren't enabled by the PMCU, as they aren't used to power anything on the baseboard other than FPGA banks that aren't used when there are no pods present. The diagram from the manual refers to DNA located on pods connected to the corresponding Zmod ports - the I2C bus passes through the SYZYGY connectors.

My two cents: Zygot has posted about using EMIO for this kind of communication before and IIRC had posted a guide in the project vault. There are several different CSR generator tools floating around online that make it quite a bit easier to create AXI peripherals and drivers. From personal experience (personal opinion about the subset I've tried), cheby (https://gitlab.cern.ch/be-cem-edl/common/cheby/-/blob/master/doc/cheby-ug.pdf?ref_type=heads) and rggen (https://github.com/rggen/rggen) are easiest to use when also doing block design work, since VHDL files can be added to a project and directly instantiated as RTL modules, and generated drivers can be directly copied into a Vitis workspace. Cheby uses pretty simple YAML definitions of a register map and can be invoked from a command line like git bash (I'm primarily a Windows user at this point). AXI GPIO can also be used to directly control ports of RTL modules as well. This one is clunky and feels like a workaround though. See the screenshot below.

Hi @evers4 The blog post has been updated with corrected sources. The original "fix", to use tcp_mss instead of tcp_sndbuf, was not required, as the bug turned out to be a combo of how the python script was validating the data coming back as well as some additional issues with pointer/buffer management. There's some possibility the buffer issue in C was causing your more recent issues; I was seeing integer underflows causing some data to be re-sent. A push_data helper function was added to the blog that looks to address this. Apologies, and thanks again. Happy new year, Arthur

Happy new year! This question was responded to over here: Thanks, Arthur

Hi @Mavitaka Modifiable in what way? By a human tweaking amplitudes in real-time, setting amplitudes from software on a computer, or selection based on some FPGA input? The first two could potentially be accomplished via a custom waveform in the WaveForms app (see below, where the third harmonic of a wave is set to 0.3x of the original wave's amplitude) or WaveForms SDK. The last would require a custom design in Vivado potentially adapting one of the demos, which would not be trivial. If you haven't bought hardware, you can try out the WaveForms app without it. Edit to add: Note that any WaveForms-compatible device with analog output (like AD3, which is cheaper) is capable of this, ignoring any other specifications that might be necessary for your application. Thanks, Arthur

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