artvvb

Hi Xband, Even using the script, you need to add location constraints to the template. Your best bet for Syzygy Port B constraints is to copy the Syzygy Port A constraints and switch out PACKAGE_PIN locations and port names for the port B equivalents. Going by the master XDC file, this would mean: Would be become: Where <sCh1CouplingL_portB> is your second Zmod ADC's equivalent external port's name. I'm also unsure as to why the Zmod DAC would be being referenced. It may help to reset IP output products in the Sources -> IP Sources pane, but I'm not certain. I'd probably need to see at least part of your sources hierarchy to say more. Thanks, Arthur

Hi @Zlxt Xilinx/AMD support may be able to provide more info about the DMAC than Digilent can. If I understand correctly, you want to repeatedly write to the same 8-bit register in a PL peripheral, using DMAC to copy data from an array in DDR. From what I can tell, this ought to be possible with DMAC. The actual typing of the array doesn't matter so much, since it's still fundamentally bytes in memory. As long as they are aligned and consecutive, there's no issue with casting a u8 array to a u16 pointer or a u16 array to a u8 pointer. So, the following should transfer a DMA_LENGTH length array located at Src to a single address. In this case, I tested it by DMAing to an AXI GPIO peripheral, gpio.BaseAddress is the data register for channel 1. A screenshot of a logic analyzer capture is attached. However, if there are gaps between the bytes you want to copy from the source array, XDmaPs_Cmd doesn't have a way of describing a way of describing an address increment other than the burst size. Either source data needs to be consecutive in memory, or you need to write your own version of XDmaPs_BuildDmaProg, effectively hand-coding your own DMA microprogram. AXI DMA should have some mechanisms to support this, but the drivers are structured very differently. Couple extra notes: You can also see in XDmaPs_GenDmaProg that the product of burst size and burst length for source and destination must match: Also, you might need to make sure that your AXI peripheral has a FIFO to buffer the data you're DMAing into it. The Zynq TRM has a couple of sections on how to approach this. See 9.4.3: https://docs.xilinx.com/r/en-US/ug585-zynq-7000-SoC-TRM Thanks, Arthur

Hi Michael, Thanks for the PR, we're looking into it, and I will update here once we've had a chance to review. -Arthur

Also, a tangentially related issue I've run into before, the default "single-ended clock capable pin" input source parameter of the clock wizard can lead to critical warnings in the implementation methodology reports. Using "global buffer" ought to resolve it. More info here: https://support.xilinx.com/s/question/0D52E00006hpQy0SAE/ps-clock-as-pll-input?language=en_US Thanks, Arthur

Hi @silverdiamond These measurements are all briefly described in the in-app help's Scope -> Measurements section (5.11): Some can also be seen as example code by "editing" predefined measurements in the app: For limiting max/min within a microsecond, careful placement of the acquisition window by setting your trigger, time position, and time base could work, making it so that the acquisition only covers a single period of the input signal is reasonable. The 3.20.27 beta's measurement "extent" feature also lets you limit the data measurements are applied to within a larger acquisition: Alternatively, filtering out the low-frequency signals could work: Thanks, Arthur

Hi @Marwa_Hassan, welcome to the forum! The short answer is that no, the Nexys A7 isn't directly supported by LabVIEW. That said, there may be some DIY solutions you could attempt, LabVIEW could potentially connect to the serial COM port associated with the Nexys A7 USBUART, for example. Digilent doesn't provide any demos of how you might be able to go about this Thanks, Arthur

Hi @Xband I gather from other threads that the particular connection here is from Zynq FCLK0_resetn to a clocking wizard reset input. There are a couple of options for handling the reset polarity after it enters PL: 1. The utility vector logic IP can be used to implement a one-bit not gate for the reset. Vivado will automatically use this IP to invert the polarity of an external reset if the reset polarity param in a clocking wizard preset associated with an external system clock doesn't match the reset's polarity. Vivado doesn't automatically do the same for Zynq reset pins, but it could be inserted manually. 2. The processor system reset IP, usually added by connection automation to ensure proper timing of resets for interconnects and peripherals, provides polarity settings that let it invert all of its inputs and outputs. 3. Easiest, in my opinion: The clocking wizard reset polarity can be configured. It's also worth pointing out that many of the other IP in your design (all of the AXI stuff, for example) will require active low resets. The issue you are looking at from AMD support is only relevant if you're trying to use the device without any software running in PS. Is this the case? Thanks, Arthur

Some additional insights from another engineer here that could help for debugging: On question #2, there aren't any other requirements for the AWG reset input. On question #1: If resets are occurring frequently enough, there may not be time for the output relay to click, if the initialization sequence for the DAC is interrupted. This depends on when sDAC_EnIn is asserted. sInitDoneDAC would tell you whether the initialization sequence is complete. Connecting your resets (peripheral_aresetn, ext_reset_in, possibly the PS fclk reset, as XBand mentions above) and clock wizard lock to FPGA pins to forward to an external monitor would let you compare the timing of these signals between JTAG and SD card boot. As previously mentioned, extracting the parallel data being sent to the DAC and looking at it on a logic analyzer would be helpful, whether pulling it out of the IP as discussed, or by forwarding it from the AXI stream interface at the IP input. Thanks, Arthur

In addition to project settings, I believe Tools -> Settings -> IP Defaults will add the IP repo to all future projects. Might not always be desired, if you're managing multiple versions of the same repo or IPs, but it's an option.

Local memory is limited by BRAM resources in the FPGA in addition to the Microblaze implementation - 225 kb tops even if you store data in addressable BRAM that isn't part of the Microblaze local memory. Consider taking a look at the SRAM memory on the Cmod to see if it can fit your data. The OOB demo implements a memory test for the SRAM, for an example of how to begin instantiating it in your project: https://digilent.com/reference/programmable-logic/cmod-a7/demos/oob. Thanks, Arthur

To confirm - have you cloned or downloaded the master branch of vivado-library and gone into your new project's settings to add it to the list of IP repositories? Are you trying to use an original Zmod ADC controller IP found in older demos or the ZmodScopeController contained in the master branch? Thanks, Arthur

Hi @btoschi Apologies for the delay. As you've seen, Digilent doesn't provide the USBUART circuitry, as it's part of the JTAG programming solution. The IC between the FPGA and FT2232H is a non-inverting buffer that is only enabled when PGOOD from the power supplies is high. For some alternate ideas: 1. You could forward the UART signals to other pins, like on a Pmod connector. 2. Instead of an oscilloscope, you could use an ILA wired up to RX and TX inside of the FPGA to get a view of the waveforms. Thanks, Arthur

Hi @Stefanski881 Per the calibration section (on page nine) of the ZmodScopeController manual: This means that data passed through into the DMA is effectively the full 16 bits, instead of just the lowest 14. The same shift is applied in test mode, where the incoming raw data is padded with two zero bits at the bottom of the vector. In both cases, this means the 14 bits you want to treat as the sample are the top 14 of your `number` variable, not the bottom 14. There's a baremetal application in this under construction demo that uses dpmutil to read calibration coefficients out of DNA, which may also be helpful: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/ddr-streaming Thanks, Arthur

Routing the ODDR outputs to other FPGA logic would lead to the same error as marking them for debug. Debugging ODDR inputs might be the better move, or some other signal further back along the signal path. Given that the ILA uses the same clock as the logic it's looking at, there's likely additional complexity around making sure it's out of reset when you want to capture data. It also wouldn't be helpful as much in production as it would be for debugging at the desk. It ought to be worthwhile in particular to check the data going into the IP. The output waveforms look like what might happen with some inverted bits. For editing the VHDL sources, using the IP packager would be recommended. There are some checksums and IP version/revision numbers that get updated when you repackage. The packager is also required to add new ports (outside of manually editing generated XML). Thanks, Arthur

Hi @Todd-Kairos I've passed your questions on internally to get some more insight on the reset behavior and startup process. We don't directly support the Brain-1 and haven't tested with it. That said, there shouldn't be any primitive differences between the XC7Z012S part and the Eclypse's XC7Z020 that would cause the described behavior. For #3, from the synthesized design, you can mark signals inside of the IP for debug with an ILA: https://docs.xilinx.com/r/en-US/ug936-vivado-tutorial-programming-debugging/Adding-Debug-Nets-to-the-Project. Thanks, Arthur

Hi @Striker Please make sure the port names in your constraints precisely match the names in the top module and that all top module ports are constrained. 1. Several necessary constraints are commented out, like J2_mod[6], see the leading "#" character on its line. 2. Bus syntax should not be mixed with single-bit port syntax, as in Good_G, which should not include the [0] in the constraints. Thanks, Arthur

What do your modified constraints look like? I'd expect the following to correct the error, assuming your block design is identical. set_property PACKAGE_PIN N22 [get_ports {diZmodADC_Data_0[0]}] set_property PACKAGE_PIN L21 [get_ports {diZmodADC_Data_0[1]}] set_property PACKAGE_PIN R16 [get_ports {diZmodADC_Data_0[2]}] set_property PACKAGE_PIN J18 [get_ports {diZmodADC_Data_0[3]}] set_property PACKAGE_PIN K18 [get_ports {diZmodADC_Data_0[4]}] set_property PACKAGE_PIN L19 [get_ports {diZmodADC_Data_0[5]}] set_property PACKAGE_PIN L18 [get_ports {diZmodADC_Data_0[6]}] set_property PACKAGE_PIN L22 [get_ports {diZmodADC_Data_0[7]}] set_property PACKAGE_PIN K20 [get_ports {diZmodADC_Data_0[8]}] set_property PACKAGE_PIN P16 [get_ports {diZmodADC_Data_0[9]}] set_property PACKAGE_PIN K19 [get_ports {diZmodADC_Data_0[10]}] set_property PACKAGE_PIN J22 [get_ports {diZmodADC_Data_0[11]}] set_property PACKAGE_PIN J21 [get_ports {diZmodADC_Data_0[12]}] set_property PACKAGE_PIN P22 [get_ports {diZmodADC_Data_0[13]}] set_property IOSTANDARD LVCMOS18 [get_ports {diZmodADC_Data_0[*]}]

Hi @CapperLabs Please make sure the port names used in your constraints match the port names in the block design and generated HDL wrapper. Looking at this post, diZmodADC_Data_0 may have been renamed to ADC_DATA_0 between taking screenshots and writing the provided constraints. The same goes for ADC_DcoClkIn / DcoClkIn_0. Thanks, Arthur

Hi @madding Unfortunately, Digilent doesn't provide 3D models for either of these Pmods. Apologies, Arthur

Hi @MRMDN You can use dpmutil to check and potentially modify fan speed settings. See here: Thanks, Arthur

Hi @edost This is not a supported use case - the Pmod I2S2 uses an I2S interface over the Pmod connector, while it looks like the AAFP connector is intended for use with the HD Audio standard. Thanks, Arthur

Hi @aceuno The links are fixed and a dedicated utilities previous versions page has been created: https://digilent.com/reference/software/adept/utilities-previous-versions. The SDK previous versions link was taken down since 2.4.2 is the only version we're currently hosting. You may need to go back to either 2.3.2 or 2.4.1 - they're the latest versions that explicitly list Ubuntu 14.04 in their readmes. The engineer who worked on Adept indicated that he thinks you might need 2.3.2. Thanks, Arthur

Here's the project I used: cmod_a7_spi.xpr.zip vitis_export_archive.ide.zip A journal file of a session where I programmed flash successfully is attached. You could potentially run TCL commands from that file to perform the same actions. File paths are specific to my system, but that's easy enough to correct. Keep in mind with Hello World that if it's printed at the start as in the above project, a serial monitor might miss it, due to taking longer to connect to the device than the device and application take to boot. Thanks, Arthur vivado.jou

Hi @Kvass, Master SPI x4 not being set or some issue with the device selection dropdown in the Quad SPI IP configuration would have been my first thoughts. Since the device is running your program successfully when booting via JTAG, it isn't something like the processor being held in reset due to an incorrect reset polarity. I managed to get a project booting following James' instructions, though I have a Cmod A7-35T with Micron flash and am using 2021.1 with a simple hello world project - neither of which is quite the same as your setup. I've ordered another board to hopefully be able to test with the Macronix part next week. Thanks, Arthur

For the C side of things, AXI peripherals all get mapped to specific memory addresses in Vivado. As long as you know the base addresses and register map, you can do reads/writes to an AXI controller's registers by just doing reads/writes to their memory addresses. This could be as simple as something "value = (*my_register_address);" for a read. In Xilinx drivers, this is usually abstracted away through a bunch of macros and an API, with some hardware-design-specific information (like base addresses) coming in through xparameters.h.