artvvb

Hi @T106A81 What board are you using, Cora or Zybo? External pins may be connected to different aux channels depending on the board - VP/VN should be the same for either, but there might be some other IP configuration changes to apply. For tutorials, the Cora XADC demo is the only one Digilent provides that uses the XADC with an AXI interface: https://digilent.com/reference/programmable-logic/cora-z7/demos/xadc. Thanks, Arthur

Hi @jarvis A couple of thoughts: 1. Check the Run/Debug Configurations to make sure that the intended elf file is being loaded. There's a screenshot below from 2023.1. The UI differs between versions, but is where a lot of the specifics can be selected - like under "target setup", you can specify whether to reset the FPGA and put a new bitstream in when you click run. I think in older Xilinx SDK versions, you would pick a specific ELF file instead of picking a system project. 2. Whether you are building the ELF under a Debug or a Release build configuration could matter. Thanks, Arthur

Hi @PRALHADRAO Please take a look at the Zybo Z7's Pcam 5C demo: https://digilent.com/reference/programmable-logic/zybo-z7/demos/pcam-5c. The initialization sequence can be found in the demo's OV5640.h header: https://github.com/Digilent/Zybo-Z7-SW/blob/5d358aa3469869382f9fb515b65af3469775e3c8/src/Zybo-Z7-20-pcam-5c/src/ov5640/OV5640.h. You can see a variant configuration which narrows the width of the camera output by half here: https://github.com/Digilent/ZedBoard-FMC-Pcam-Adapter-Dual-Camera/blob/b286db9baca9092f234c3fe6a75d8a9ba755e9f4/sdk/appsrc/ZedBoard_FMC_Pcam_Adapter_DEMO/cam/OV5640.h#L344C22-L344C54. Otherwise, additional information can be found in the OV5640 datasheet. Thanks, Arthur

We've added some warnings/caveats about this to this and a couple of other affected guides, thanks for the suggestion.

Hi @Suprith The template XDC file for the Arty Z7-10 includes pin locations for the Pmod ports: https://github.com/Digilent/digilent-xdc/blob/master/Arty-Z7-10-Master.xdc. The schematics also include this information: https://files.digilent.com/resources/programmable-logic/arty-z7/arty-z7-d0-sch.PDF. Thanks, Arthur

Digilent-provided Petalinux material for the Arty Z7 is pretty out-of-date. I'd take a shot at running through Adam Taylor's or Whitney Knitter's posts on the topic: https://digilent.com/reference/programmable-logic/arty-z7/intro-to-fpga (2021.1) https://www.hackster.io/whitney-knitter/linux-on-zynq-arty-z7-linux-design-in-petalinux-2022-1-40c490 (2022.1) Note version numbers though, I'd expect 2023.2 to have some changes. Thanks, Arthur

Thanks for sharing your solution - the "Rev B demo image" text indicates it's booting from flash. There's also some concern that the C sources provided in the baremetal software tutorial need to change for 2023.2, since the way that xparameters passes information to device drivers has changed, but it sounds like that's not the case in the Classic UI. Thanks, Arthur

Hey @bloggins666, No worries. I've never touched FreeRTOS personally, and am only just seeing this kind of cmake error for the first time, but I'll take a stab at providing some suggestions on directions to look in. The exception in the migrate-error log 'Error in adding domain.'freertos10_xilinx' is an invalid os for the given platform.'' implies there's an incompatibility between the platform project and the software you want to run on it. Potentially missing required peripherals. CMake Error at libsrc/freertos10_xilinx/src/freertos10_xilinx.cmake:330 (message): A53, R5 or A72 FreeRTOS need a TTC in the system without it cannot work is weird, the ARM processors it mentions are not the A9, which feels like it implies that the error may be firing unnecessarily - if you've used FreeRTOS in previous versions, I assume this error or an equivalent does not appear there? Speculation aside, your best bet is to contact AMD/Xilinx support. Thanks, Arthur

Hi @Yatharth Gupta As Jcolvin mentioned, mig.prj files are only to be used with a memory interface generator IP, which is intended to be used with FPGA IO pins connected to DDR memory. The Arty Z7 doesn't have DDR memory that is connected in this way, so a MIG and mig.prj file cannot be used. You may be able to access Zynq-connected DDR via the Zynq PS's high-performance (HP) AXI slave ports - this would involve AXI buses in the RISC-V design normally connected to the MIG to these ports. That said, this is not a use case we support or have actively tested, so you may run into various unforeseen issues. I would anticipate needing to run some software in the PS to make sure that it is configured correctly, including running the DDR interface and its associated clocks. You will also need to ensure that there are not memory conflicts between the program running in PS and the RISC-V processor. Normal access to other peripherals, like a UART serial connection may also need to be forwarded through the Zynq PS. Lab two in this coursework put together by a third party (https://digilent.com/reference/programmable-logic/arty-z7/intro-to-fpga) goes over how to instantiate a MicroBlaze soft-core processor in Zynq fabric, and some of the concerns involved, though it does not touch accessing DDR. Still, it may be helpful. Best of luck, Arthur

Hi @Suprith Please review section 11, Clock Sources, of the Arty Z7 reference manual. When using Zynq PS software, FCLK pins inside of the chip can be used to clock FPGA fabric. Otherwise, the 125 MHz ethernet reference clock connected to H16 can be used. Thanks, Arthur

Hi @jayasha Yes, saving and processing images in software should be possible without modifications to the Vivado project. Thanks, Arthur

Adam Taylor posted a detailed blog post with a lot of good information on the UI differences yesterday. It looks like there are changes to how example programs initialize and interact with peripheral drivers in addition to the new component model of abstraction. Link here: https://www.adiuvoengineering.com/post/microzed-chronicles-introducing-vitis-unified-ide Thanks, Arthur

We don't currently have a blind time benchmark or estimate for how long it would take for the demo to rearm a trigger. Fully resetting the DMA may be required, due some potential bugs - if I recall correctly, this would be on the order of tens or hundreds of milliseconds between acquisitions. Changes to the hardware design could accomplish this but would require designing your own modules to add to the design. Some kind of component sitting between the Scope Controller and trigger mechanism might be able to do it, but would get tricky - an additional trigger mechanism to limit data flowing to the DMA module, a buffer to hold data that arrives before a trigger, summing consecutive samples as they arrive and storing them in a register, then potentially passing the contents of that register to the DMA via AXI stream once the entire trigger has come through. Some documentation on the functionality of the hardware in the existing design can be seen in this page: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/eclypse_platform_manual#trigger_detector. Also, this is the source code for the level trigger mechanism, for reference: https://github.com/Digilent/Eclypse-Z7-HW/blob/ddr-streaming/src/hdl/level_trigger.v.The trigger detector section might be most helpful, though do note, the doc is incomplete. It might also be just as easy to start working from the Low-level Low-pass Filter example instead. When you say that you want to react to a level, how quickly do you need to react, and how what form does that reaction take? Messaging the host PC via serial, or by setting an AWG level or digital output? One additional note, once it's in the FPGA, data flows through the AXI stream interface, shown in orange in the below, reading up on AXI streams might be handy. AXI streams are probably what a lot of the LabVIEW material is based on, at least for how it handles inputs and outputs. I'm not familiar enough with LabVIEW FPGA to really comment though.

Yes, changing the sampling rate would require hardware changes to modify the clock frequency. It can only go so low though, depending on the requirements of the FPGA clocking circuitry, and calibration could potentially be affected. Decimation of data could also help, either after the fact on the host or in PS software, or with hardware changes to do the decimation in FPGA fabric - the demo doesn't include this though. Edit to add - the commented lines were originally intended for calculating the buffer length based on a specified acquisition period and should likely be removed.

Hi @Xband Please review the RawDataToVolts implementation in main.c - huge numbers are likely due to the decimal number representing ADC counts instead of Volts. Pages 7-10 of the ZmodScopeController user manual also have some good insight on the conversion math: https://github.com/Digilent/vivado-library/blob/master/ip/Zmods/ZmodScopeController/docs/ZmodScopeController.pdf. For not seeing a sine wave in the acquired data, the buffer currently being captured is 4096 samples long - when running at 100 MS/s, this covers about 40 microseconds of capture time. This is indicated by the "Length of buffer (words): 4096" line in the printout. You can increase this by changing line 497 of main.c, where the "BufferLength" constant is set. Alternatively, you might send a faster test signal. Thanks, Arthur

Hi @Anthocyanina, The same seven-segment behavior can be seen here: The config voltage warnings are unrelated, but you could include the following lines from the Basys 3 template XDC file for completeness: Thanks, Arthur

Hi @connoisseur_de_mimi An STP file for the enclosure kit is now available here: https://files.digilent.com/resources/programmable-logic/eclypse/Eclypse_Z7_Enclosure.stp Thanks, Arthur

Hey Gonçalo, Check the "Width of Buffer Length Register" setting in the DMA configuration. The default value, 14 bits, only allows 2**14 (4096) bytes to be sent in a single transfer. Thanks, Arthur

For the jumper, just leave it disconnected so that the FTDI can't drive reset events. C18 could be manually constrained and connected to something like an AXI GPIO pin. See the template constraints here: https://github.com/Digilent/digilent-xdc/blob/master/Arty-S7-50-Master.xdc. How to use it is covered by this guide: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi#add_gpio_peripherals_to_a_block_design. Thanks, Arthur

Digilent doesn't currently provide mechanical dimensions for the faceplate directly, but I reached out internally to request them. If you haven't yet, please also review the Zmod and Eclypse mechanical diagrams, as they should help with some of the required dimensions: https://digilent.com/reference/programmable-logic/eclypse-z7/start#additional_resources https://digilent.com/reference/zmod/scope/start#additional_resources https://digilent.com/reference/zmod/awg/start#additional_resources Thanks, Arthur

Yes, that's correct.

Both need to be enabled simultaneously for data to flow through the AXI stream interface. There is a small FIFO in the data path, but if both of these signals are high, at least some data should be moving. If ready is held low and enable is held high, I would expect that the overflow pin would assert. So I would recommend tying both of these pins off to '1', at least until you have something working. A scenario that could cause all zeroes to be read is if external calibration coefficients aren't disabled or connected to anything (and thus tied off to zeroes) and test mode is not used to bypass calibration. This would cause all incoming data to be multiplied by zero. If this is happening, disabling external calibration coefficients in the Scope controller would solve it.

With the jumper disconnected, C18 is functionally just another button input to the FPGA, it's not tied to any circuitry that resets the FPGA itself or the power supply. The jumper just connects an FTDI output pin to the same FPGA input as the button. User designs need to connect the input to logic inside the FPGA - it's just intended to reset soft-core processors. If pin 3 of the ethernet shield's power header accepts an active low reset, the button might already just work to trigger a reset without affecting the Arty.

Hi @Fadi Both CCLK_0 and EMCCLK are connected to the QSPI SCK pin. E9 is used during boot, while L16 can be used after a bitstream has been programmed in to access Flash without using special primitives. Quoting the manual's QSPI section: Thanks, Arthur

Hi @connoisseur_de_mimi See example code here: https://github.com/Digilent/Eclypse-Z7-SW/blob/b42fb15a8ab4c52a38db2c15918cd7263e84f65e/src/calibration_reader/src/main.c Thanks, Arthur