artvvb

XScuGic_SetPriorityTriggerType's last parameter sets the trigger type - active-high level sensitive. Given this, I would expect that the interrupt handler would access the peripheral that triggered the interrupt to clear the interrupt bit, which would remain high until this access happens. I don't see the custom_int port in the verilog source, so can't confirm when it is cleared, but the behavior sounds like the interrupt goes high and stays high.

The DMAs are configured to handle 32-bit streams, increasing the width is possible, but would likely make it so that samples might be dropped. Adding another DMA configured to receive another 32-bit AXI stream is possible but involved. 1. How many bits wide are the concatenated stream and the accumulator outputs? 2. Do you *need* to move data from both channels and both accumulators into DDR, or is it acceptable to only send some of it up? Even using all of the AXI stream signals wouldn't be necessary if you aren't trying to pass stuff to the processor - the ready signal in the interface passing data to your logic could be tied high (or to a software enable bit if there isn't another one further upstream), and the valid signal could be used as an enable for your logic.

@engrpetero This doesn't sound like an issue I've run across before, any specific steps to reproduce on a fresh machine would be helpful. All I can immediately think of to check is whether you used Tools -> Report IP Status to do any kind of additional upgrading past what happened when you opened the project before editing the IP in the packager. Edit: Also, any TCL logs from the project might be helpful. Either console output from when you were working with the project, or log and journal files (found in the working directory, C:/Users/(user)/AppData/Roaming/Xilinx/Vivado on windows). Thanks, Arthur

Hi @GSAS - Karthick You can find warranty terms for all boards purchased through the Digilent web store here: https://digilent.com/shop/shipping-returns/#warranty. Please let me know if you have further questions about this. Thanks, Arthur

I spoke to the engineer who maintains Adept, and he indicated that programming SPI Flash devices indirectly through an FPGA is generally not supported. The way that Vivado handles indirect programming of these devices relies on it shipping with bitstreams for different FPGA devices that provide bridge logic to various flash memories, with a wide variety of combinations supported, Adept doesn't have the same support (largely due to development cost and redundant features compared to the existing Vivado support). Platform Flash devices directly attached to the JTAG interface ought to be supported. As I understand it, XCFS Platform Flash is not the same thing as general QSPI memories and refers to a largely-EOL line of programmable memories offered by Xilinx. https://www.xilinx.com/products/silicon-devices/configuration-memory/platform-flash.html. For some more context on what you are trying to use Adept to do, what device are you trying to program? Thanks, Arthur

Welcome to the forums! USB Standard-A, via something like a USB A to C cable, will work with some caveats. There's some more information in the spec sheet: https://digilent.com/reference/test-and-measurement/analog-discovery-3/specifications#usb_interfaces. Depending on the combination of cable and laptop port, you may need an external power supply: https://digilent.com/shop/5v-4a-switching-power-supply/. Digilent doesn't carry an appropriate A to C cable on the web store. Hope this helps. Thanks, Arthur

This list is made up of "module name (filename)" pairs, and two module names in the list match. One of the files needs to be edited to change the module name so that Vivado can tell which module should be used when it is instantiated in other sources.

I reproduced this and I think fixed it. Below 1446 bytes, the system only actually sends a single burst, indicated by the sent_callback only being entered once per client request. Above it, multiple callbacks would occur, but some data would be lost. What seems to be happening is that submitting more data to tcp_write than fits in a single segment (typically 1500 bytes, slightly lower for a reason I'm not sure of here) maybe causes the additional data to be lost or ignored. What worked for me to fix it was to replace the tcp_sndbuf(tpcb) calls in the sent and recv callbacks with tcp_mss(tpcb), so that no more data than fits into a single segment is included in a single tcp_write call. "MSS" in the function name stands for max segment size. I've revised the code in the blog post. Thanks! Arthur

Hi @aied Board files presented in the create project view show both those from the XilinxBoardStore and those that you've downloaded and installed manually. I suspect that you are selecting the uninstalled board store version. You can also install these files within Vivado by clicking the download button, but when doing so, you might not get the most recent version, as a specific version of the board files is locked in with a particular Vivado version, and changes may have occurred after that board file version was submitted. See the attached screenshot: Thanks, Arthur

Hi @Rich E From what I can see, MCS files are only supported for programming Platform Flash devices that are connected to a JTAG programmer directly. This means that MCS files are not supported for programming the SPI flash devices typically found on Digilent's 7-series FPGA boards. Hope this helps, Arthur

Hi @hsaad The user manual mentioned by the JTAG-USB is available in the Adept install directory, "C:\Program Files (x86)\Digilent\Adept\Adept Application User's Manual.pdf" on Windows, for example. It has, however, not been updated in some time. Thanks, Arthur

Hi @Deffe The constraint comments have been fixed in the digilent-xdc repo and I've confirmed that the schematic pin names are correct. I've attached the spreadsheet used to compare against xc7z020clg484pkg.txt, in case you want to double-check. Eclypse Pmod Constraints.xlsx Thanks, Arthur

Hi Dante, Apologies for the delay. QSPI_SCK is also connected to pin L16. Access to CCLK_0 could also be achieved using the STARTUPE2 primitive. https://digilent.com/reference/programmable-logic/arty-a7/reference-manual#quad-spi_flash We'll need to look into why a location constraint for L16 is missing from the template XDC file. I would expect the following to work: Thanks, Arthur

Hi @Mania, Some of the demos talk through booting a prebuilt petalinux image from SD: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-scope. Thanks, Arthur

Also, Whitney Knitter recently posted some tutorials for the Arty Z7 in 2023.2 that will likely be helpful: Vivado - https://www.hackster.io/whitney-knitter/getting-started-with-the-arty-z7-in-vivado-2023-2-26051a Vitis - https://www.hackster.io/whitney-knitter/getting-started-with-the-arty-z7-in-vitis-unified-ide-2023-2-1a8ee5

Hi @bloggins666 The xgpiops driver is used to control multiplexed input/output (MIO) GPIO pins in the Zynq Processing System (PS). These MIO pins are physically distinct from FPGA pins and are separate physical IOs on the chip. The xgpio driver is used to control an AXI GPIO peripheral. If you're using the board files to add an AXI GPIO to a block design, then that will control LEDs connected to FPGA pins on the programmable logic (PL) side of the chip. It's also possible to enable EMIO (extended MIO) pins that allow the hard GPIO controller in the Zynq PS to control pieces of the FPGA design, and then tie the EMIOs to FPGA IOs in the block design, so that LEDs that would normally be controlled by AXI GPIOs can be controlled by the PS GPIO controller. Probably clear as mud. All that is to say that, since you have axi_gpio controllers, use the xgpio (not xgpiops) drivers. Thanks, Arthur

We've seen before that the DMA's ready signal comes up pretty quickly after the IP comes out of reset rather than waiting until a transfer has been initiated, which would allow extra samples into the DMA's internal FIFO if the upstream IP is set to assert tvalid right out of reset. If this is happening, I'd guess that a software reset of the DMA is clearing the FIFOs and discarding the first couple of values that the IP passes in. When the IP then sends the first block of data to the DMA after the PS starts the DMA transfer, tlast is sent early, terminating the DMA transfer a couple of words earlier than expected, leaving the last few pieces of data in the DDR buffer unchanged. A way to fix this would be to add an enable bit to the upstream AXI4-stream IP, controlled by an AXI4-lite module so that the software can tell the stream IP when to start. The IP could then be started after the first DMA transfer has already been initiated - after the first SimpleTransfer call. It looks like for your IP, it would require modifying the state machine in the verilog source to wait to exit IDLE state until a new enable input port is high. I might be misremembering some details, but that's my best guess. Yeah, AXI lite is good for control and status registers that you hit infrequently or poll, but can't do fast burst transfers. It's great to hear you're having success with this, it's an area with a steep learning curve. You could also add logic so that whenever a single address is read, the data in the register associated with that address is updated, potentially from a FIFO. This might consist of, for example, driving a FIFO read enable pin with "tvalid & tready" from the AXI4-lite read data channel. Thanks, Arthur

Hi @werosic I assume based on previous threads that you are trying to use zmodlib and the lwip echo server template project together? I assume that you've replaced zmodlib with C (not C++) sources that accomplish similar things. Generally, the ADC sources and ethernet sources should not affect each other, except where shared resources are being accessed, or where performance concerns become a problem. I would check whether both the ADC library and the ethernet sources are initializing the GIC - the Zynq's interrupt controller, as it seems like the most likely potentially-shared system to cause an issue like this. If they both reset it and initialize it with their interrupt handlers, then the last subsystem initialized could cancel out part of the initialization of the other subsystem. Thanks, Arthur

Hi @Zebryk If you haven't seen, a mechanical drawing for the BNC adapter is available on the Reference site: https://digilent.com/reference/_media/reference/test-and-measurement/bnc-adapter-board/discovery_bnc_mech.pdf. Linked from the resource center, here: https://digilent.com/reference/test-and-measurement/bnc-adapter-board/start. If this is insufficient for your purposes, I can make a request for additional material. Thanks, Arthur

2-3 Mb/s is very doable with DMA. I've seen 125x4 MB/s streaming to DDR. I haven't seen this before but will attempt to reproduce. If possible, could you post your modified code? Is data moving from DDR to the FPGA or vice-versa? They work pretty similarly with the DMA, but there are different catches to designing the hardware for each direction. Xil_In32 and Xil_Out32 are "just" macros to replace single-word memory accesses. Meaning something like "Xil_Out32(BASEADDR, value);" is equivalent to "*((u32*)BASEADDR) = value;". When the device tries to read from or write to a memory address assigned to a peripheral, the processor translates it into an AXI transaction, which is routed through the PS and PL interconnects to the peripheral's AXI controller. It's worth noting that the bulk transfer using the DMA is handled by the DMA controller: you configure what the transfer will be by setting values in its config registers, start it, and wait for the DMA controller to finish performing AXI transactions to write the data it's receiving to other addresses (in DDR). The demo should be using the XAxiDma_SimpleTransfer function to do most of the heavy lifting, though the simple transfer function is not that complicated under the hood - if I recall correctly, it's effectively three or four register reads & writes. https://github.com/Digilent/Zybo-Z7-SW/blob/27cf9ab8a5dc18ca0bf9e4e551551a6c509055af/src/Zybo-Z7-10-DMA/src/audio/audio.c#L374 The meat is in the audio.c source file. fnAudioRecord sets up a DMA transfer using XAxiDma_SimpleTransfer, then sets several control registers in the audio controller - first a sample count, so that the controller knows when to assert the "tlast" signal on the AXI stream, indicating to the DMA that the transfer has finished. Second, clearing and then setting the bit index 1 of the transfer control register, which is tied to a receive enable signal. Third, enabling the stream to the DMA. VHDL sources for the AXI controller and stream controller can be found in the IP's sources: https://github.com/Digilent/Zybo-Z7-HW/tree/3d1cfeb56b83dc7f9314aa4e2f0456d9bfc4bf68/repo/local/ip/d_axi_i2s_audio_v2_0/src, particularly d_axi_i2s_audio_v2_0_AXI_L.vhd and i2s_stream.vhd. You can access IP sources in the project by right-clicking on the IP in the block design and selecting "Edit in IP packager". They're a lot to read through, and there are easier ways of implementing AXI communication - I'd point to CSR generator tools capable of creating AXI controllers. Cheby seems interesting, since it can create AXI4-lite interfaces in VHDL source files that can be added directly to a block design through "Add module": https://gitlab.cern.ch/be-cem-edl/common/cheby/-/tree/master/doc?ref_type=heads. Digilent doesn't have a specific tutorial for this kind of thing right now. Apologies, this was a bit of an info-dump. Thanks, Arthur

Hi @digility 1. I'm not sure what the highest tested resolution for the Basys 3 VGA port is, but the GPIO demo runs at 1280x1024 @ 60 Hz, which requires a faster pixel clock than 720p (108 MHz versus 74.25 MHz). https://digilent.com/reference/programmable-logic/basys-3/demos/gpio. 2. The Basys 3 would only support 4-bit greyscale images, due to each color component only having four bits - greyscale is achieved by setting R, G, and B outputs to the same value as each other for each pixel. You could always truncate off the bottom four bits of the image, obviously losing some information. Thanks, Arthur

As an example of writing an RTL module from scratch, the following is the pulse extender described above. Design source: `timescale 1ns / 1ps module extend_pulse #( parameter integer LENGTH = 10 ) ( input wire clk, input wire resetn, input wire trigger_in, output wire extended_trigger_out ); reg trigger_reg = 'b0; reg [$clog2(LENGTH-1)-1:0] counter = 'b0; // Register, set when trigger_in is high, clear LENGTH clock cycles later always @(posedge clk) begin if (resetn == 1'b0) begin trigger_reg <= 'b0; end else if (trigger_reg == 1'b0) begin trigger_reg <= trigger_in; end else begin // if trigger_reg == 1'b1 if (counter >= LENGTH-1) begin trigger_reg <= trigger_in; end // else stay high end end // Counter, clear when trigger_in is high, else increment when trigger_reg is high always @(posedge clk) begin if (resetn == 1'b0) begin counter <= 'b0; end else if (trigger_in == 1'b1) begin counter <= 'b0; end else if (trigger_reg == 1'b1) begin counter <= counter + 1'b1; end end assign extended_trigger_out = trigger_reg; endmodule Simulation source: `timescale 1ns / 1ps module pulse_sim; reg clk = 1'b0; initial begin #10 clk = 1'b1; forever #5 clk = ~clk; end reg resetn = 1'b0; initial begin // clear on the first clock edge @(posedge clk) resetn <= 1'b1; end reg trigger_in = 0; initial begin #400 trigger_in <= 1'b1; #20 trigger_in <= 1'b0; end wire trigger_out; extend_pulse #( .LENGTH(10) ) dut ( .clk(clk), .resetn(resetn), .trigger_in(trigger_in), .extended_trigger_out(trigger_out) ); endmodule Simulation results, showing the extended pulse going for an additional 10 clock cycles after the pulse: And a guide for simulation, which ought to let you reproduce the above: https://digilent.com/reference/programmable-logic/guides/simulation

Awesome! This means it's the newer board file version, which is good, don't need to suggest that readers revert to the old version or update the clock period setting. Should be able to have some links up in the next few days. I confirmed today that the test project I'd put together based on the tutorial functions in hardware, with a simple software app running out of DDR. Cheers, Arthur

I'm really sorry, I was caught up with several other tasks today. The trigger outputs stay high for one stream beat (one clock cycle). Additional hardware that could handle this would be a register that gets set when the trigger output is high, paired with a counter that counts until it reaches a predefined value at which point the register clears, functionally a pulse extender/stretcher.

Hi XBand, I'm actively taking a look through this and will have some more comments later this afternoon. Trying to break down the problem in a way that steps back a bit from the context of the DDR streaming demo, since I think that it is making things more complicated than needed. That said, some of the material in the demo project is still extremely necessary. The LabVIEW material looks interesting. A colleague also mentioned MATLAB, Simulink, and Model Composer as an option for this kind of DSP, but I have not used it myself, and it requires some licenses that you may or may not have access to. An accumulator will be able to perform the integration - this IP looks reasonable for it. Note that the output width probably needs to be large enough to fit the number 0xffff * 700 (assuming 700 us at 100 MS/s), so minimum 26 bits. Yes, it will be easier to treat each channel separately. Slicing off one of the channels so you can focus on designing the system for only one of them would also be appropriate. Also, you can treat tvalid on the AXI stream interface as an enable pin for downstream logic, as long as that logic needs to be run once every cycle - if you don't need extra control logic for the accumulator, maybe it's clock enable could just be tied to tvalid, for example. Would getting those scope captures of what a pulse looks like be possible? The paint diagrams below illustrate how I'm currently thinking about the shape of the pulses and timing: Charge threshold and voltage threshold would be specified separately. Thanks, Arthur