artvvb

Hi @mahinay, Welcome to the forums. Digilent doesn't provide a Pmod IP core for the Pmod SSD. That said, there should be examples out there which will fit your needs. What are you trying to practice? The route you take will differ pretty strongly depending on whether you want to get data from the Zynq processor on the ZC702 onto the display, or if you are trying to get data from elsewhere in the Zynq PL onto the display. Thanks, Arthur

Hi @ciaociao, Based on your screenshots, it looks like the board was successfully configured, but the connection between the PC and the GRMON hardware debugger isn't being established correctly. I'm not familiar with the methodology you're using here, but a Digilent JTAG module should not be needed for this - the documents linked indicate that the Arty's onboard JTAG programming circuitry is being used. I would recommend reaching out to Gaisler for further information on how to use this debugging method. Thanks, Arthur

Hi @shift838, No board information is expected, as I understand it, there aren't board files for many of the JTAG programmer modules - only the Config and Settings tabs showing up is expected. I reached out internally for some more information and got this: Could you post a screenshot of the Config tab after clicking on the "Initialize Chain" button? If your device shows up, you should be good to go. Thanks, Arthur

I don't see anything that looks off about the block design. It should be good. The DMA is likely configured for a 32-bit interface, which might be causing some conflicts when interface widths are propagated to the interconnect, since the Zynq's HP slave port is 64 bits. That said, I've seen designs that look pretty much just like this work before (that width mismatch shows up in many demos), so I wouldn't worry about it. I'd try using the bitstream in hardware to see if any errors crop up during runtime, and investigating whether these, or other, warnings might be the cause after an issue occurs. Vivado projects that use any IP have a tendency to spit out a lot of ignorable warnings. The project archive shouldn't be necessary. Thanks, Arthur

Hi @KellyW, got some more information on the center positions: Each Pmod port is spaced 0.90 inches apart, center to center, the same as the first pair on the left shown in the mechanical diagram earlier in this thread. As for Y coordinates, for each of the connectors, the center of the bottom row of pins (JA1-JA4, the topmost in the "Z" axis, for which the holes are further from the edge of the board) is 0.51" from the upper edge of board, so as to line the connector heads up with the edge of the board (with some wiggle room). With the standard 100mil spacing of the pins, the rest of the Y coordinates should be calculate-able. Hope this helps, Arthur

Hey Udayan, I wouldn't worry too much about these warnings. They're all related to "port width mismatches" which means that some individual port within an AXI interface has a different width on one side of the interface than the matching port on the other side of the interface. Typically if the downstream signal is narrower, the uppermost bits of the upstream signal get discarded. Similarly, if the downstream is wider, the extra bits at the top of the bus are pulled low. This *can* theoretically cause problems if the wrong signal gets truncated or zeros appended in, but it depends on what signal, and this kind of warning comes up in any number of example designs provided by various vendors. That said, the warnings are referring to the axi_mem_intercon interconnect connected to the Zynq HP0 port, which seems to not be pictured in the screenshot of the block diagram. Could you provide some more screenshots or a project archive? S_AXI_HP0 is on the left side of the Zynq block, which is offscreen. Thanks, Arthur

With Digilent IP, it's always possible to edit and repackage them to customize them for your own use, so you could use the AXI adapter as the starting point for your own design. See the screenshot below, which shows the right-click menu option that gives access to the IP Packager. Do note that the functionality of the AXI adapter is pretty tightly coupled to the DMA in the projects it's used in - the IP fills circular buffers while waiting for a trigger, then ships data out over DMA, and doesn't do both simultaneously - and the DMA in these projects is also data-bandwidth-limited, as a higher-throughput interface was not necessary for the small acquisitions performed by the IP. Thanks, Arthur

Hey @KellyW Apologies for the delay. Part numbers for the headers follow. I've reached out to the engineer who did the PCB layout to confirm the center coordinates and will let you know when I hear back. Thanks, Arthur

Hi @Metin Sunan The SMT2 supports Zynq Ultrascale parts, so it should work with the Kria, as the latter appears to expose its JTAG interface through the SoM headers. However, I'm not particularly familiar with the Kria, so I couldn't say for sure. Thanks, Arthur

You aren't doing anything wrong. The project works with those critical warnings even when the external calibration ports are enabled. I'll see if I can track it down regardless, there's an interface definition in the vivado-library IP repo that should be getting used by both the AWG and Scope IPs to describe those ports. The AWG IP uses the same interface, so it could be that it's what is causing the errors to appear currently. Thanks, Arthur

Hi @Mark K Unfortunately, Digilent doesn't offer any variants of the Scope with different input ranges. Is the resolution loss from using the Scope high gain mode significant for your application? Thanks, Arthur

Hey Lowell, welcome to the forums! Storing your project in flash can differ depending on what kind of project it is. Are you using Microblaze, and if so, are you using external memory (as in, not the on-chip BRAM)? If not-MicroBlaze, there are some steps presented in this reference page that should be helpful: https://digilent.com/reference/learn/programmable-logic/tutorials/cmod-a7-programming-guide/start The screenshots are fairly old, but the process used to flash the board should largely remain the same in even the newest versions of Vivado. Thanks, Arthur

Hey @ral0711 If you detach the board, does that COM port go away? Also, please check your baud rate - Tera Term's default for new connections is 9600, while Zybo designs typically use 115.2k. In Tera Term, this shows up in the Setup -> Serial Port menu. Otherwise, the following thread has some general troubleshooting tips for USB connections to Digilent FPGA boards from Windows hosts: Thanks, Arthur

Hey @Lee Tavrow Unfortunately the SD boot process is a little different from what you might expect. For the Nexys A7, the MCU used to handle JTAG programming also has the ability to read data out of USB and SD media and program it into the FPGA, after which the SD card-connected pins can be accessed from a user design in the FPGA. The MCU firmware is closed source and isn't written in Verilog or VHDL. There are no direct Digilent-provided VHDL/Verilog examples for the Nexys A7's SD card connectivity. Depending on the version of Vivado/Vitis/SDK you are using, you might be able to connect the Pmod SD IP core (which is a wrapper for a Xilinx AXI QSPI) to the Nexys A7's SD card pins. This would however likely require using MicroBlaze. The board's Reference Manual has some more information. Thanks, Arthur

Hey @openlogger-mz As this is a legacy product, Digilent might not be able to provide much help at this point. If you haven't, check out the reference material for the OpenLogger here: https://digilent.com/reference/test-and-measurement/openscope-mz/start The intended behavior of the Digital I/O is described in this video: https://digilent.com/reference/learn/instrumentation/tutorials/openscope-mz/gpio-logic-analyzer Thanks, Arthur

Hey @Marv, Welcome to the Forum! Yes, there are a couple of old pieces of example code originally written for ISE that should be helpful even these days. Links are in the AD2's resource center: https://digilent.com/reference/pmod/pmodad2/start. Look for "Nexys 3 VHDL Example". The Pmod AD2 IP core (which may or may not support the version of Vivado you are using) wraps Xilinx's AXI IIC core, if you happen to be using a Microblaze system in the right version, it could be easier to use than rolling a custom core. Thanks, Arthur

Hey @KellyW Digilent generally doesn't provide full BOMs for our products. Which connectors are you looking for? I should be able to pull the specific part numbers for you. Thanks, Arthur

Hi @Udayan Mallik The code block below is a snippet of the comment header that goes with the function definition of dpmutilSetFanConfig in dpmutil.c (pulled from here: https://github.com/Digilent/dpmutil/blob/master/dpmutil.c). More information about the specific capabilities of the Eclypse's PMCU can be found in the PMCU specification: https://files.digilent.com/resources/programmable-logic/eclypse/Eclypse-PMCU-Specification-Public.pdf ** Description: ** Modify one or more field of the Platform MCU (PMCU) ** FAN_n_CONFIGURATION register. The FAN_n_CONFIGURATION register is ** used to specify the settings of the associated fan. This may include ** the enable state of the fan, the fan's speed, and the associated ** temperature probe. Please note that not all fan ports support ** enable/disable, fixed speed control, or automatic speed control ** (temperature based). Changes to a FAN_n_CONFIGURATION register ** will be restricted to the be within the supported capabilities of ** the port and take effect immediately after the register is written. ** Additionally, the FAN configuration is written to EEPROM and will ** restored each time the PMCU is reset or power cycled. ** ** The "fanid <0...3>" parameter must be used to specify ID of the ** fan configuration to be modified. ** ** The "enable <fTrue,fFalse>" parameter can be used to enable or disable the ** associated fan. ** ** The "speed <0...3>" parameter can be used to specify the speed of ** the associated fan. Please note that not all fans support this ** functionality and some ports that do support this functionality ** may not support automatic fan speed control. ** 0 - minimum ** 1 - medium ** 2 - maximum ** 3 - auto ** ** The "-probe <0...4>" parameter can be used to specify the ** temperature probe associated with a fan if that fan supports automatic ** speed control. ** 0 - none ** 1...4 - probe[1...4] Thanks, Arthur

Hey Riccardo, In order to open this project in a newer version of Vivado, you would need to first install the version it was designed in (2019.1), check it out in order to get the XPR project file generated, then open that project file in your newer version of Vivado. From there, you need to upgrade all IPs to whatever newer version Xilinx has included in the install, and hope that nothing has changed so significantly that the project breaks. I ran through this process a while back for 2020.2 and posted an archive with the resulting XPR. You can download that file and open it in 2021.1, then follow the same update process described above - this lets you skip installing that older version. Thanks, Arthur

Hi @orenderj Found the bug that is causing the issues you are seeing. The register that the levels are sent to hardware through was written, however, an additional register write which is required to trigger the "UserRegisters" module to pass that register value through its CDC handshake mechanism to the trigger generator was omitted, causing the levels at the trigger detector to never be updated from the default 0. To correct this, UserRegisters_IssueApStart should be called after the WriteReg call. Here's a snippet from the corrected LevelTriggerAcquisition with the surrounding context: // Configure the trigger TriggerSetPosition (TrigPtr, BufferLength, TriggerPosition); TriggerSetEnable (TrigPtr, TrigEnable); u32 Levels = ((u32)(Ch1Level) << 16) | (Ch2Level); UserRegisters_WriteReg(LevelTriggerPtr->BaseAddr, USER_REGISTERS_OUTPUT0_REG_OFFSET, Levels); UserRegisters_IssueApStart(LevelTriggerPtr); // ADD THIS LINE AxiStreamSourceMonitorSetSelect(TrafficGenPtr, SWITCH_SOURCE_SCOPE); To answer the question about the data format: The stream data consists of two signed 16-bit values, one for each channel. Channel 1 is bits 31:16 and Channel 2 is bits 15:0. These are the output of the calibration modules in the ZmodScopeController. The 14-bit ADC samples are padded prior to going through the calibration module. The trigger levels are encoded the same way as the data: essentially 14-bit twos-complement ADC data, padded up two bits. There's some more information on the calibration scheme in the ZmodScopeController's User Guide, pages 6-10. Figure three may be particularly helpful. This function, which I've quickly tested with a 0.5V level trigger, should let you calculate the raw levels: u16 VoltsToTriggerLevel (float data, u8 resolution, u8 gain) { #define IDEAL_RANGE_ADC_LOW 25.0f #define IDEAL_RANGE_ADC_HIGH 1.0f float vMax = gain ? IDEAL_RANGE_ADC_HIGH : IDEAL_RANGE_ADC_LOW; return (u16) (data * (float)(1 << (resolution - 1)) / vMax) << (16 - resolution); } It's effectively the inverse of the data to raw floating point volt conversion functions, plus a two bit pad. Thanks, Arthur

Hi @newuser11 There are a couple of old example projects listed on the Pmod CLP resource center: https://digilent.com/reference/pmod/pmodclp/start The projects themselves are ancient, but contain VHDL source files which you may find helpful. Thanks, Arthur

Hi @Lee Tavrow Please check that you have both the UART and PROG ports plugged into your computer. Additionally the naming conventions in the XDC can be somewhat confusing with regards to which is TX and which is RX from the perspective of the FPGA. Please confirm you are using the right pin. From there, I'd recommend setting up a loopback project - wiring TX directly to RX - to confirm whether the issue is due to the logic in your project rather than the hardware. Thanks, Arthur

Hey @Anusree If you're on Windows, please check this thread to confirm whether your device is getting detected by the operating system at all. This will tell us whether there's an issue with the device, or an issue with the device drivers on the host. If you're on Linux, please check this thread instead: Thanks, Arthur

Hey @StanDaMan If you're on Windows, please check this thread to confirm whether your device is getting detected by the operating system at all. This will tell us whether there's an issue with the device, or an issue with the device drivers on the host. If you're on Linux, please check this thread instead: Thanks, Arthur

This might depend on the Arduino board. The Zybo's Pmod ports use 3.3 V LVCMOS33 logic. Level shifters could be required.