artvvb

The block should be echoed back. If the TCP example receives a block of characters at once, it sends them all back at once. To confirm, you could print p->len in the recv_callback function. Yes, the echo server includes an internal buffer, which is located in DDR - all buffers and variables in the software application should be in DDR, you can check the linker script (lscript.ld) to confirm. I don't have personal experience with the UDP API. There are several template applications that should use it, but potentially no echo server example. Please review this guide: https://digilent.com/reference/programmable-logic/guides/zynq-baremetal-boot.

Hi Paul, If it was me, I'd likely try building out a microblaze system first, just because there are more drivers and example sources available. If too many FPGA resources are used, or if the latency involved in the processor receiving a request from hardware, reading data from flash, and forwarding it to the hardware, is too much, then I'd look into building out a custom controller or AXI master. In either case for custom RTL, there would be a fair amount of time spent with either the flash datasheets or AXI QSPI datasheets and simulating the design before going to actual hardware. I'm not sure which would be easier between the AXI design and SPI design - SPI itself is straightforward, but the complexity is in understanding the flash device's command set. I also admittedly have a bias towards processor-based designs. Thanks, Arthur

Looks like it updates a bit in SEQ04 and two bytes in SEQ05. This probably corresponds to the VP/VN channel and sixteen aux channels. The XADC documentation is a little bit frustrating, as it's typically talking about the DRP interface rather than AXI. Quote below is from the "Automatic Channel Sequencer" section of UG480. Offsets and addresses seem to be different for the AXI interface than DRP though, so those "4Ch and 4Dh" don't necessarily apply. It looks like PG019 is the actual document to be referencing: https://docs.amd.com/v/u/en-US/pg019_axi_xadc. I'm still reading, but haven't spotted if it details exactly what is in the SEQ04/SEQ05 registers yet.

Hi @alexplcguy There's no true standalone configuration for Digital Discovery - Analog Discovery Pro 3000-series is the only device that currently supports it. That said, you could run WaveForms on a cheap single-board computer: https://digilent.com/reference/test-and-measurement/guides/getting-started-with-raspberry-pi Thanks, Arthur

For others reading this in future, this thread continues over here:

Hi @stc Leuven Branch names in git are case sensitive - try the following for the out-of-box demo: Docs for it including setup instructions are here: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/oob. Same for demos for the AWG and Scope 1410 Zmods: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-awg, https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-scope. See the "setting up the baremetal projects" dropdowns. Thanks, Arthur

Hi @pdw For your outline as presented, in terms of complexity level, these steps concern me as they'd require building a custom AXI-lite master. If you're dead-set on using AXI Quad-SPI instead of a custom SPI controller, I would first put together a MicroBlaze design that uses it with the xspi drivers, so that you can build an understanding of what the IP's registers are doing and how you need to access them. It's currently undocumented on our reference site, but this demo was put together last year to write and read data from flash on a Nexys Video: Demo software main: https://github.com/Digilent/Nexys-Video-SW/blob/0987e797293f60b3caa27a400868bcf51b22c6a4/src/quad_spi/src/Flash_Memory_Test.c Demo release page: https://github.com/Digilent/Nexys-Video/releases/tag/QSPI%2F2023.1-1 A similar demo page which should include the bare bones for opening the project from a release: https://digilent.com/reference/programmable-logic/nexys-video/demos/axi-ps2. Generic git documentation: https://digilent.com/reference/programmable-logic/documents/git. Thanks, Arthur

There might be devices out there that can do the appropriate level translation, but that could get to the point of designing your own adapter from scratch. I'd recommend using a board with the connector.

Hi @Sergio Lopez How are you allocating buffers? If using something like malloc, you can increase the amount of memory available to the stack and heap in the linker script (lscript.ld). If you're using the predefined memory base address the demo uses, could you describe the errors you're running into? Thanks, Arthur

Hi digility, I'm not aware of performance impacts based on coding style, but the Language Templates in Vivado seem to use a single process (see the screenshot below). I'd recommend going through UG949, as it includes various other recommendations with definite performance impacts, like proper clocks, resets, RAM inference: https://docs.amd.com/r/2021.2-English/ug949-vivado-design-methodology/RTL-Coding-Guidelines. Thanks, Arthur

Hi @Bobsaito The Pmod specification is pretty loose about what can be defined as a GPIO Pmod. If something supports the defined electrical specifications, it's likely fine. Thanks, Arthur

Hi @Eran Zeavi Do other demo projects run successfully on your board? I would also confirm that the programming mode select jumper is set to JTAG and power cycling, as it could be related to a project actively running on the board while attempting to program it. Others have reported similar errors with other Zynq boards, and other threads may have useful troubleshooting tips, like here: Thanks, Arthur

Hi @Dniel.Schmid Digilent generally doesn't provide PCB design files for our products. Apologies. Thanks, Arthur

There are various potential things to troubleshoot for this: Does the power good indicator LED come on when it is powered up? Please try another USB cable in case your cable is not capable of transferring data. Please confirm whether USB drivers are installed on your system - there is a checkbox in the Vivado installer that can easily be missed. If you are using a Windows system, in the Device Manager, your board should show up as several USB serial converters and a COM port (see here: https://forum.digilent.com/topic/21713-brand-new-basys-3-user-cant-get-vivado-to-see-it/#comment-62685). You could also install Adept Runtime to quickly reinstall the drivers: https://digilent.com/reference/software/adept/start. Thanks, Arthur

For some additional reading, UG480 (the XADC user guide) talks about the dedicated interface between PS and XADC: https://docs.amd.com/r/en-US/ug480_7Series_XADC/Zynq-7000-SoC-Processing-System-PS-to-XADC-Dedicated-Interface. As does the Zynq technical reference manual: https://docs.amd.com/r/en-US/ug585-zynq-7000-SoC-TRM/Control-Interfaces. The two control interfaces described here are the two pieces of hardware underlying the two drivers. XSysMon is used to control XADC when XADC is instantiated in PL. XAdcPs must be used when an XADC isn't instantiated and has a slightly different hardware interface, reflected by the difference in drivers. There are likely various tradeoffs for which interface to use - choosing whether to "waste" FPGA resources or to disallow hardware in PL from using alarm signals comes to mind - but they're likely all pretty irrelevant for just getting the thing working. This is all to say, if you have an XADC instantiated in the design, you should be able to run the code I posted previously as-is.

In case I haven't mentioned, I'm working in Vitis 2023.1. XAdcPs_GetStatus does not exist in that API. XSysMon_GetStatus is defined in xsysmon.h and the mask macros are defined in xsysmon_hw.h. In general, if you have the code loaded into the IDE and the macro or function exists in scope, you can control-click on it to find declaration locations. I think this just prevents reading the same sample twice if the software is moving fast. Removing it works fine for me.

I'll need to check out the XAdcPs API. If you have an XADC instantiated in your block design, you ought to be able to use the XSysMon drivers by directly copying over the posted code. Guessing, but I think that XAdcPs represents direct PS access to the XADC core, while XSysMon is only pulled in when an XADC is included in block design. I'm not sure what the differences between the APIs are, or if the PS gets a different level of access if the XADC isn't hung off of the AXI bus. Given the existence of the XAdcPs drivers, it seems that it should be possible to use XADC without instantiating the IP - which might make XSysMon completely redundant for Zynq parts - but I'll need to try it out.

Please try switching the board into JTAG boot mode by moving jumper JP5 and power cycling it.

I suspect that the transfer function defined by XSysMon_RawToVoltage is not accurate for differential aux channels. The following comes from UG480 (https://docs.amd.com/r/en-US/ug480_7Series_XADC/ADC-Transfer-Functions), when it describes the bipolar mode transfer function. Whereas the power supply transfer function is "ADC Code / 4096 * 3V". I think this means that the XSysMon_RawToVoltage macro ("((((float)(AdcData))* (3.0f))/65536.0f)") lines up with the supply conversion, not the aux input conversion, which doesn't seem to be defined in the drivers. The following is working cleanly for me: #include "xsysmon.h" #include "xparameters.h" #include "sleep.h" #include "stdio.h" #include "xil_types.h" #define XADC_DEVICE_ID XPAR_XADC_WIZ_0_DEVICE_ID typedef struct ChannelInfo { u8 Channel; u32 Mask; char *Name; u8 IsDiff; // 0 or 1 } ChannelInfo; #define NUMBER_OF_CHANNELS 4 ChannelInfo Channels[NUMBER_OF_CHANNELS] = { {XSM_SEQ_CH_AUX_SHIFT + 14, XSM_SEQ_CH_AUX14, "AUX14", 1}, {XSM_SEQ_CH_AUX_SHIFT + 7, XSM_SEQ_CH_AUX07, "AUX07", 1}, {XSM_SEQ_CH_AUX_SHIFT + 15, XSM_SEQ_CH_AUX15, "AUX15", 1}, {XSM_SEQ_CH_AUX_SHIFT + 6, XSM_SEQ_CH_AUX06, "AUX06", 1} }; void Xadc_Init(XSysMon *InstancePtr, u32 DeviceId) { XSysMon_Config *ConfigPtr; u32 DiffChannels, EnabledChannels; u8 Index; ConfigPtr = XSysMon_LookupConfig(DeviceId); XSysMon_CfgInitialize(InstancePtr, ConfigPtr, ConfigPtr->BaseAddress); DiffChannels = 0; EnabledChannels = 0; for (Index = 0; Index < NUMBER_OF_CHANNELS; Index++) { EnabledChannels |= Channels[Index].Mask; if (Channels[Index].IsDiff) { DiffChannels |= Channels[Index].Mask; } } // Disable the Channel Sequencer before configuring the Sequence registers. XSysMon_SetSequencerMode(InstancePtr, XSM_SEQ_MODE_SAFE); // Disable all alarms XSysMon_SetAlarmEnables(InstancePtr, 0x0); // Set averaging for all channels to 16 samples XSysMon_SetAvg(InstancePtr, XSM_AVG_16_SAMPLES); // Set differential input mode for appropriate channels XSysMon_SetSeqInputMode(InstancePtr, DiffChannels); // Set 6ADCCLK acquisition time in all channels XSysMon_SetSeqAcqTime(InstancePtr, EnabledChannels); // Disable averaging in all channels XSysMon_SetSeqAvgEnables(InstancePtr, EnabledChannels); // Enable all channels XSysMon_SetSeqChEnables(InstancePtr, EnabledChannels); // Set the ADCCLK frequency equal to 1/32 of System clock XSysMon_SetAdcClkDivisor(InstancePtr, 32); // Enable Calibration XSysMon_SetCalibEnables(InstancePtr, XSM_CFR1_CAL_PS_GAIN_OFFSET_MASK | XSM_CFR1_CAL_ADC_GAIN_OFFSET_MASK); // Enable the Channel Sequencer in continuous sequencer cycling mode XSysMon_SetSequencerMode(InstancePtr, XSM_SEQ_MODE_CONTINPASS); } void Xadc_ReadData (XSysMon *InstancePtr) { u8 Index; s16 RawData; float VoltageData; printf("Waiting for EOS...\r\n"); // Clear the Status XSysMon_GetStatus(InstancePtr); // Wait until the End of Sequence occurs while ((XSysMon_GetStatus(InstancePtr) & XSM_SR_EOS_MASK) != XSM_SR_EOS_MASK); printf("Capturing XADC Data...\r\n"); for (Index = 0; Index < NUMBER_OF_CHANNELS; Index++) { RawData = XSysMon_GetAdcData(InstancePtr, Channels[Index].Channel); VoltageData = ((float)(RawData) * (1.0f) / 65536.0f); printf("Capturing Data for Channel %s: ", Channels[Index].Name); printf("%04hx = ", RawData); printf("%.3fV\r\n", VoltageData); } } int main () { XSysMon Xadc; Xadc_Init(&Xadc, XADC_DEVICE_ID); printf("Zybo Z7 XADC Initialized!\r\n"); while(1) { Xadc_ReadData(&Xadc); sleep(1); } } Results, with VAUX14P at 25 mV, VAUX14N at 100 mV, and the rest grounded:

Some progress, I can see changing values printed when running the attached code (a heavily modified version of the Cora XADC source), but am still figuring out how to interpret raw data readings and what the register configuration settings applied in the init function might need to be. (Edited to remove code after posting a followup)

Hi @AaronNowack Apologies for the delay. We reached out to the engineer who designed the front-end circuitry on both Zmods about your question. Their response is below: Hope this helps, Arthur

Hi DGISTKSJ, No, the MIG cannot be used to interface with DDR on the Eclypse, as the DDR is connected to the Zynq PS. However, you ought to be able to access DDR memory through the Zynq PS's AXI slave ports, which can be enabled in the PS configuration, as below. It isn't trivial to implement a custom full AXI master interface to control these ports, so we would normally recommend using IP like Xilinx's AXI DMA. Thanks, Arthur

I have not. There are some AMD resources on simulating the Zynq PS, but I'm not sure if they cover external HW like Ethernet or if they're primarily for simulating software in conjunction with FPGA gateware. I'm sure "It works on my machine" isn't the most helpful, but I was able to download the 2022.1 Vitis archive for the Zybo Z7-20 variant of the DMA Audio demo, open it in 2023.1, and run it in hardware. Which download did you use?

What raw data value does 0.790 V correspond to? If it's all zeros or some other notable bit pattern then something isn't being initialized. It's been quite a while since I worked on the Cora demo and I don't recall if the XADC device actually needs to be initialized in software, but that demo does it here: https://github.com/Digilent/Cora-Z7-SW/blob/d35d836848fed00dec917ff0784f6232862220f5/src/Cora-Z7-10-XADC_SW/src/main.c#L58. It also uses an "xsysmon" driver instead of xadcps, which might be a renamed version of the same drivers... Building out a project for Zybo to try it out.

Hey CEEJ38, This sounds like an electrical concern. The Zedboard's Pmod ports use 3.3V logic and the bank voltage cannot be changed (section 2.9.2 of the user guide covers it in brief, and DS187 covers it in extreme detail). You might look into using a level shifter circuit. Thanks, Arthur