artvvb

There are a lot of ways to transfer data. Various serial protocols through the Zybo's Pmod ports, ethernet, physically moving a USB drive from one device to the other. In a vacuum, I'd recommend looking into figuring out how to get a UART connection between the boards. The Zybo can potentially do this via AXI UART Lite or EMIO GPIOs connected to Pmod pins.

Hi @orenderj The intended case would be to be able to use LevelTriggerAcquisition (&Pipe, GainTestRelays, 0b00010, 0x0000, dont_care);, as an example, to trigger an acquisition on a rising 0 V level on channel 1. The third argument, the trigger enables, is used to mask out unwanted triggers in hardware, so the manual trigger shouldn't be happening when it's disabled - I'm currently investigating this. There is currently a bug where the trigger generator incorrectly treats the stream data bits 0 to 15 as channel 1 and bits 16 to 31 as channel 2 instead of vice versa. I'm working on fixing this in hardware. A software workaround should be to switch the trigger enable bits and trigger levels being passed to LevelTriggerAcquisition. The trigger enables are ordered as follows: bit 0: manual bit 1: ch1 rising bit 2: ch1 falling bit 3: ch2 rising bit 4: ch2 falling Note the level triggers use a signed comparison to check whether the level is between two consecutive samples (or equal to the most recent sample). A code snippet from the sources: `ch1_rising = (ch1 >= ch1_level) && (ch1_prev < ch1_level)`. In the meantime, I've added some state diagrams here which may help to explain the mechanism: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/eclypse_platform_manual#trigger_detector In terms of when to set configuration regs, assert start, and wait for idle, the main thing is to start the detector last of all the modules in the input pipeline, since it acts as a final gate in front of the DMA. In general, set the config regs for the entire pipeline, start up the stuff upstream of the trigger detector, start the DMA transfer, start the detector. Then, wait for the trigger to fire, indicated by the DMA transfer completing and the detector going idle. Also, the "trigger enable"s should be considered config regs for these purposes. Thanks, Arthur

Hi @Aliabd Could you explain some more about what you are trying to do? What your application is and its specific requirements heavily affect how you might approach solving the problem. Thanks, Arthur

I've never looked into how exactly to do it, but Vivado's simulator should also be able to be controlled through TCL, and based on these posts, the simulator can be invoked separately from Vivado entirely through the xsim command.

Hi @PhantomDingBat The Genesys ZU's PCIe port was primarily intended to be used as an expansion connector for adding functionality through cards. I'm really not sure if this setup is possible. The ZU provides a reference clock for PCIe through a programmable oscillator, presumably you'd need to get a reference clock from the computer instead. The connector is also PCIe 2.0 X1, so might not be fast enough for your needs, even if it was able to be used like this. Good luck, Arthur

Understood, makes sense. Hardware changes are necessary in that case. The DMA implementation in the streaming project is capable of handling the full sample rate coming out of the low level IP, and can also handle arbitrarily slower sample rates, but is not able to reduce the sample rate on its own. The DMA IP has internal buffers which are used to store up data that is then sent to DDR in a burst when either that buffer is filled, or when a piece of data accompanied by a "last" signal indicating the end of the stream is sent. Data does not need to be sent to the DMA continuously. If data doesn't arrive, then the burst is just not sent until enough data has been received. The above might somewhat answer this question. One sample of data can be sent to the DMA at any time. However, it isn't sent to DDR until enough data has been pushed in behind it (or it is indicated to be the last in the stream). The Zmod Scope Controller is designed to provide data at a fixed sample rate, and the buffer inside of it is only intended to move data between the two clock domains. Reducing the sample rate requires additional hardware, sitting in the stream somewhere between the DMA and the Scope controller, to do the downsampling/decimation of the data. Hope this helps, Arthur

That's accurate. The alternative would be to buffer everything in BRAM, but that's a pretty limited resource. Using all of it, 630 kB, with each sample from each channel taking up 2 bytes, means a single channel buffer length of ~3.20 ms, if I did the math right. You could still discard samples before they go into the memory as I attempted to describe above, so the buffer would be split up over multiple acquisitions. You likely also want to continue using the low level IP, since it does a lot of the heavy lifting of getting the ADC on the Zmod initialized. If you were to go to a PL-only design, You should still use this. The low pass filter demo might provide some insight into how to use the IP in a PL-only system. Commenting out the prints is a good call, I missed it. Saves a *bunch* of time in the loop. There might be a similar thing going on with the mallocing and freeing of the block descriptor space for the DMA in the S2mmAttachBuffer and S2mmCleanup functions. The inability to recall pending blocks from the DMA, which is what brings in the requirement to reset it, is really painful. Here's how I'm using the xtime header to measure the time between acquisitions currently: const u32 buf1_length = 0x1000; u32 buf1[buf1_length * 50]; u32 buf1_head; memset(buf1, 0, buf1_length * sizeof(u32)); XTime func_time_clocks; XTime time0[50], time1[50]; double func_time_us; u32 trig_en = 0b00001; // manual only for (u32 acq = 0; acq < 50; acq++) { XTime_GetTime(&(time0[acq])); buf1_head = only_meas(buf1 + acq * buf1_length * sizeof(u32), buf1_length, &Pipe, GainTestRelays, trig_en, 0x0000, 0x01F0); XTime_GetTime(&(time1[acq])); } for (u32 acq = 0; acq < 50; acq++) { func_time_clocks = (time1[acq]-time0[acq]); func_time_us = 1.0 * (func_time_clocks) / (COUNTS_PER_SECOND / 1000000); xil_printf("Acquisition %d:\r\n", acq); xil_printf(" %llu clocks\r\n", func_time_clocks * 2); xil_printf(" %d.%02d us\r\n", (int)func_time_us, (int)((int)(func_time_us * 100) % 100)); } Note that I haven't looked at what the data actually looks like after acquisition. With (most) prints removed from the loop, It's taking ~5000 us for the first acquisition, then ~2700 us for subsequent ones on my machine. I'm also currently getting some errors that indicate there's a problem with subsequent acquisitions after a reset, that indicate there might be problems with the data in my implementation. IMO, the best option would be to make limited hardware changes that allow the DMA to take a single acquisition to let it be continuously run without reset, by inserting a module into the input stream that discards samples that aren't cared about. This is what I previously described. Are triggers necessary for the captures taking place after the first burst, or would you prefer to have them take place at fixed times after the initial event? The latter ought to be easier to implement, as it wouldn't require modification of the trigger module. Either way, doing stuff in PL gives you tight control over when each "sub-acquisition" starts, by using some counters to toggle the tvalid signal in the axi stream after the trigger module high and low as needed. Thanks, Arthur

Hi @LLL, welcome to the forums! The low-level Scope IP's datasheet also lists a minimum sampling clock frequency of 10 MHz (section 4.3): https://github.com/Digilent/vivado-library/blob/zmod/v2/2019.1-2/ip/Zmods/ZmodScopeController/docs/ZmodScopeController.pdf Decimation of data coming into the FPGA at a faster rate down to a slower rate might be the way to go if you need to go slower than 10 MS/s. Thanks, Arthur

Hi @suung33 You need to modify the data being sent to the device. Currently, in the posted code, a 132-byte-long buffer filled with the sequence 0,1,2,3,... is being sent. You should refer to the I2C Serial Interface Communication section of the MCP4725 datasheet to determine what bytes you should be sending (https://www.microchip.com/en-us/product/MCP4725). Both the buffer contents should be changed to match whatever you need to send to the device and the buffer size argument passed the XIicPs_MasterSendPolled function should be modified to match the number of bytes you want to send. For example, from an initial skim of the datasheet, a general call reset should be able to be issued with the following snippet (though I haven't tested it), which sends two bytes, a 0x0 followed by a 0x6. u8 SendBuf[2]; SendBuf[0] = 0; SendBuf[1] = 0x6; XIicPs_MasterSendPolled(&Iic, SendBuf, 2, IIC_SLAVE_ADDR); Arduino sources can't be run directly on the Zybo, but you might use those projects to figure out what bytes you should be sending and receiving. Thanks, Arthur

Hi @AJ25000 What issues do you seem to be running into? Are SDK or Vitis throwing any particular error messages? Thanks, Arthur

Hi @fdabairros, Unfortunately, Digilent isn't going to be able to help much with this. ISE hasn't been updated since 2013, and the Atlys has also been since retired. The Atlys features a Spartan 6 part that isn't supported in Vivado, so you'd need to install some version of the ISE tools that might work with CentOS 7. Here are a couple of links that might serve as a starting point: Xilinx's ISE installer archive: https://www.xilinx.com/downloadNav/vivado-design-tools/archive-ise.html A forum thread commenting on somethings that might need to be changed to get the installation to work: https://www.eevblog.com/forum/fpga/xilinx-ise-14-7-to-support-windows-10-by-the-end-of-the-year-(time-machine-)/ Thanks, Arthur

Hi @Reji Joseph The Basys 3 uses an XC7A35T-1CPG236C part, which is covered by the 7 Series -> Artix-7 group of devices in the installer. Thanks, Arthur

Hi @Yamini Patel We don't provide any examples demonstrating audio over HDMI. It's possible to do. There's a link below to an older thread from this forum where it comes up (though one of the links is dead). Thanks, Arthur

Hey, sorry for the delay, I've needed to pull some numbers to better answer this, which I still don't fully have yet. From some initial timing of the modified only_meas, it looks like the turnaround time from the start of one transfer to the start of the next transfer, including a DMA reset and reinitialization (which appears to be taking place surprisingly fast), is somewhat less than 50 ms. I should have more info on this later this week. I'm confident that hardware changes would solve the issue, but will be potentially complicated and specific to your application. A state machine and several counters, integrated into the trigger detector module, could be used to allow some incoming stream beats to pass through to the DMA while the rest are discarded. Essentially, after a start signal, all samples are passed on to DMA until counter rollover at a software-settable limit occurs. Then, the counter is reset and counts up to another limit while samples are discarded. The process then repeats as needed. There are some unused AXI4-lite-connected registers (if I recall correctly, four "outputs" & four "inputs") included in the project that could be used to wire something like this up, but there would still need to be some amount of communication state machine that would need to be designed - depending on the number of "transmit and then block periods" required, it might be necessary to do something like polling a bit that asks the processor to provide a new counter rollover value. This is of course more complex and specific than finding a better solution in software. For what it's worth, it would also only require a single s2mm transfer be performed which would grab all of the data you intend to pull in, making the software side potentially quite a bit less complex. An immediate trigger (enable and set the manual trigger bit before starting the detector) would allow you to specify a fixed transaction length for the whole thing. More complex trigger behavior (like if each subsequent period that a capture takes place in needs to start at a new trigger event) would require more extensive modifications. Hopefully that roughly 50 ms start-of-acquisition to start-of-next-acquisition time is sufficient. I'll see if I can provide some better information on that property of the system in the coming days. Thanks, Arthur

Hi @analog57 You can check the Vivado project out from cloned sources using the process described here: https://digilent.com/reference/programmable-logic/eclypse-z7/git#vivado_hw_repositories. The Vivado project sources are in the hw folder of the root repo that is cloned in the demo project setup instructions, like here: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-scope. The projects provided through GitHub only have a single Zmod Scope connected up in hardware. Thanks, Arthur

Hi @Eminem Welcome to the Forums! Here are a couple of good blog posts on this exact topic: https://www.starwaredesign.com/index.php/blog/63-fpga-meets-devops-xilinx-vivado-and-git https://www.starwaredesign.com/index.php/blog/64-fpga-meets-devops-xilinx-vivado-and-jenkins-with-docker Running build scripts written in TCL from the command line via Vivado's batch mode is the way to go. The first post above discusses this topic in some detail. The checkout script in digilent-vivado-scripts also optionally builds the checked out project, but that requires following the same file structure as Digilent's Vivado projects on Github. We haven't used this with Jenkins or Docker before, so I couldn't comment on how easy that would be to use as a starting point. Thanks, Arthur

Hi @Sayali Choudhari Welcome to the Forums! Digilent doesn't directly provide any stepper motor example projects. You can find all of the documentation on using the Nexys 4 board here: https://digilent.com/reference/programmable-logic/nexys-4/start And the Nexys A7 (an updated version of the product) is documented here: https://digilent.com/reference/programmable-logic/nexys-a7/start You will likely need to develop your own project in Vivado. Instructions for installing and using it can be found in the resource centers linked above. This instructable working through using a Basys 3 to do the same looks like a good starting point as well, as the Basys 3 and Nexys are fairly similar boards for this application: https://www.instructables.com/How-to-Control-a-Stepper-Motor-With-an-FPGA/ Thanks, Arthur

Hi @RobertTrout The Zybo Z7 has a flash part that can be programmed with a boot image. Check out the configuration section of the reference manual and the guide for booting baremetal projects from SD cards or flash: https://digilent.com/reference/programmable-logic/zybo-z7/reference-manual#zynq_configuration https://digilent.com/reference/programmable-logic/guides/zynq-baremetal-boot Thanks, Arthur

Hi @Anthocyanina, From the FPGA's perspective, the seven segment anodes and cathodes are active low. By default, when the FPGA is configured, Vivado applies a weak pulldown to each of the unused I/O pins - pulling the outputs to ground while allowing an external pullup resistor to override it if necessary. It might have been possible when designing the board to avoid the 7seg illuminating in this situation by including pullup resistors on the nets connecting the FPGA pins to the display, but these were not included. Before programming the bitstream into the board, the IO pins are left floating - no pull up or down - so there's no path to push current through the display. The default after configuration can be changed, either by including ports for the anodes or cathodes and pulling them high, or by setting the default pull for unused pins to either pullup or pullnone (which could make other stuff happen, like illuminating unused LEDs, since doing so affects everything). See here for more info: https://support.xilinx.com/s/question/0D52E00006hpZVASA2/what-is-the-pin-state-if-i-didnt-use-them?language=en_US Thanks, Arthur

MIO peripherals - the various hard cores in PS - don't require constraints unless you are routing them through the PL via EMIO. These are dedicated multiplexed input/output lines that get routed to specific pins depending on the configuration of the Zynq Processing System. That is to say, the ethernet already gets enabled when you apply the Zynq preset from the board files. This is effectively the same as how you would enable a UART connection through the USBUART bridge, the UART0 and UART1 controllers are also PS peripherals that route through MIO. Thanks, Arthur

Hi @silantyeved As you noticed, some of the guides are pretty out of date. Where specifically did you run into trouble with the hello-microblaze project? Of the stuff posted on Reference, this one should be the closest to what you are trying to do: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi I don't think it's been tested with the Arty A7-100T in 2022.1 specifically. For this kind of guide, there should no substantial difference between the A7-100T and the A7-35T, other than the board file you pick when you create the project. Thanks, Arthur

Hi Todd, To my knowledge, that's not a common VGA resolution. I'd typically recommend something like http://www.tinyvga.com/vga-timing to find the values to set for the timing parameters in these demos. Does the manufacturer of the display provide any timing specifications or examples for other dev boards to control it? Thanks, Arthur

Hi @Gabriel Uribe Romero, The Makefile for the AXI PS/2 IP's drivers was updated with the suggested fixes a while back, though it's possible that you downloaded a different version of it. What were the contents of the file before editing? The most-up-to-date version of this IP is the one at the head of the master branch: https://github.com/Digilent/vivado-library/archive/refs/heads/master.zip Could you provide the contents of the build console for the hardware platform? Makefile errors can be pretty obscure, and the context around where they show up in the log makes it a lot easier to tell what went wrong. I've attached a screenshot showing how to get the build log. In a vacuum, I'd recommend resetting the BSP sources (open platform.spr, open each Board Support Package and pick Reset BSP Sources) or recreating the workspace from scratch, including the hardware platform, since sometimes links can get broken between projects. Vitis's occasional use of absolute paths mean that trying to manually move a workspace around a filesystem (for example) can break links between projects, causing files to not get delivered to the compiler or linker properly. Thanks, Arthur

Here's one possible option for getting around this: Successive acquisitions by attaching new buffers is tricky, and the s2mm_transfer implementation needs more work to better support it. In the meantime, the DMA IP can be reset and reinitialized between acquisitions. When a buffer is "attached" to the S2mm interface, a block of memory is allocated to hold the block descriptors for the DMA, which isn't easily switched out between acquisitions. The blocks described in this memory are "submitted" to hardware, which then uses them to figure out which memory addresses to write to while performing transfers. In order to pull transactions that haven't been completed from hardware, it seems to be necessary to reset the DMA wholesale - I need to look into this some more. For more reading and documentation on the DMA mechanisms specifically, of what I've seen, there are various blog posts that can be found across the web, which are pretty often narrow for a specific application. Most importantly, there's Xilinx PG021 (https://docs.xilinx.com/r/en-US/pg021_axi_dma), which is focused on the hardware, and comments in driver headers like xaxidma.h. It's unfortunately pretty sparse. For FPGA in general, there are plenty of decent intro materials, but this particular project is more complicated than you'd learn about in most intro materials, as, realistically, is anything involving a processor. From what I've seen, it's mostly just a matter of spending time getting used to Xilinx's IP ecosystem. Changes to make to your code to do the reset follows: Main was somewhat modified so that I could get a quick estimate of the latency between successive transfers. From this provided code, uncommenting the AxiStreamSourceMonitorSetSelect line hands control of the data element of the AXI4-stream going into the DMA over to a hardware counter (running at 125 MHz), which I used to estimate the downtime between two successive transfers (without the use of a sleep function in only_meas) to be about 40 ms - measured from the start of one acquisition to the start of the next. This includes the reset of the DMA core that occurs in the S2mmInitialize call. It's technically longer, depending on when a trigger actually occurs. Mostly the changes just move S2mmInitialize into only_meas, make sure that an additional reset isn't performed in S2mmCleanup, and make sure that the end index of the buffer is computed before block descriptor memory for the attached buffer is freed in S2mmCleanup. u32 only_meas(UINTPTR Buffer, u32 BufferLength, InputPipeline *InstPtr, ZmodScopeRelayConfig Relays, u32 TrigEnable, u16 Ch1Level, u16 Ch2Level) { xil_printf("entered in function\r\n"); S2mmTransferHierarchy *S2mmPtr = &(InstPtr->S2mm); ManualTrigger *ManPtr = &(InstPtr->Man); TriggerControl *TrigPtr = &(InstPtr->Trig); AxiStreamSourceMonitor *TrafficGenPtr = &(InstPtr->TrafficGen); ZmodScope *ScopePtr = &(InstPtr->Scope); UserRegisters *LevelTriggerPtr = &(InstPtr->LevelTrigger); const u8 TestMode = 0; WriteZmodScopeRelayConfig(ScopePtr, Relays, TestMode); S2mmInitialize(S2mmPtr, DMA_ID); // Create a Dma Bd Ring and map the buffer to it S2mmAttachBuffer(S2mmPtr, Buffer, BufferLength); // Flush the cache before any transfer Xil_DCacheFlushRange(Buffer, BufferLength * sizeof(u32)); const u32 TriggerPosition = 0;//BufferLength / 4; // Configure the trigger TriggerSetPosition (TrigPtr, BufferLength, TriggerPosition); TriggerSetEnable (TrigPtr, TrigEnable); u32 Levels = ((u32)(Ch1Level) << 16) | (Ch2Level); // u32 Levels = ((u32)(Ch2Level) << 16) | (Ch1Level); UserRegisters_WriteReg(LevelTriggerPtr->BaseAddr, USER_REGISTERS_OUTPUT0_REG_OFFSET, Levels); // AxiStreamSourceMonitorSetSelect(TrafficGenPtr, SWITCH_SOURCE_GENERATOR); xil_printf("Initialization done\r\n"); // Start up the input pipeline from back to front // Start the DMA receive S2mmStartCyclicTransfer(S2mmPtr); AxiStreamSourceMonitorSetEnable(TrafficGenPtr, 1); // Start the trigger hardware TriggerStart(TrigPtr); // FIXME: Start the data source first to ensure that the pipeline is flushed into an idle trigger module? // Start the Zmod data stream; only gets started once ZmodScope_StartStream(ScopePtr); // Apply a manual trigger // sleep(1); ManualTriggerIssueTrigger(ManPtr); // Wait for trigger hardware to go idle xil_printf("Waiting for trigger...\r\n"); while (!TriggerGetIdle(TrigPtr)); // FIXME: maybe wait a bit to ensure that the RXEOF frame transfer has completed u32 *BufferHeadPtr = S2mmFindStartOfBuffer(S2mmPtr); if (BufferHeadPtr == NULL) { xil_printf("ERROR: No buffer head detected\r\n"); } u32 BufferHeadIndex = (((u32)BufferHeadPtr - (u32)Buffer) / sizeof(u32)) % BufferLength; u32 TriggerDetected = TriggerGetDetected(TrigPtr); xil_printf("Buffer base address: %08x\r\n", Buffer); xil_printf("Buffer high address: %08x\r\n", ((u32)Buffer) + ((BufferLength-1) * sizeof(u32))); xil_printf("Length of buffer (words): %d\r\n", BufferLength); xil_printf("Index of buffer head: %d\r\n", BufferHeadIndex); xil_printf("Trigger position: %d\r\n", TriggerPosition); xil_printf("Index of trigger position: %d\r\n", (BufferHeadIndex + TriggerPosition) % BufferLength); xil_printf("Detected trigger condition: %08x\r\n", TriggerDetected); // Invalidate the cache to ensure acquired data can be read Xil_DCacheInvalidateRange((UINTPTR)Buffer, BufferLength * sizeof(u32)); S2mmCleanup(S2mmPtr); xil_printf("Transfer done\r\n"); return BufferHeadIndex; } XStatus print_serial(UINTPTR* Buffer, u32 BufferLength, u32 BufferHeadIndex, ZmodScopeRelayConfig Relays){ xil_printf("Entered in printing\r\n"); for (u32 i = 0; i < BufferLength; i++) { u32 index = (i + BufferHeadIndex) % BufferLength; float ch1_mV = 1000.0f * RawDataToVolts(Buffer[index], 0, ZMOD_SCOPE_RESOLUTION, Relays.Ch1Gain); float ch2_mV = 1000.0f * RawDataToVolts(Buffer[index], 1, ZMOD_SCOPE_RESOLUTION, Relays.Ch2Gain); // const u16 ch1_raw = ChannelData(0, Buffer[index], ZMOD_SCOPE_RESOLUTION); // const u16 ch2_raw = ChannelData(1, Buffer[index], ZMOD_SCOPE_RESOLUTION); xil_printf("@%08x\t%08x\t%d\t%d\r\n", (u32)Buffer + index*sizeof(u32), Buffer[index], (int)ch1_mV, (int)ch2_mV); } return XST_SUCCESS; } int main () { // Initialize device drivers InputPipeline Pipe; // Initialize IP driver devices // S2mmInitialize(&(Pipe.S2mm), DMA_ID); TriggerControl_Initialize(&(Pipe.Trig), TRIGGER_CTRL_BASEADDR); ManualTrigger_Initialize(&(Pipe.Man), MANUAL_TRIGGER_BASEADDR); AxiStreamSourceMonitor_Initialize(&(Pipe.TrafficGen), SOURCE_MONITOR_BASEADDR); ZmodScope_Initialize(&(Pipe.Scope), SCOPE_BASEADDR); UserRegisters_Initialize(&(Pipe.LevelTrigger), LEVELTRIGGER_BASEADDR); ZmodScopeRelayConfig GainTestRelays = {1, 0, 0, 0}; xil_printf("Done initializing device drivers\r\n"); const u32 buf1_length = 0x1000; u32 buf1[buf1_length]; u32 buf1_head; const u32 buf2_length = 0x1000; u32 buf2[buf2_length]; u32 buf2_head; memset(buf1, 0, buf1_length * sizeof(u32)); memset(buf2, 0, buf2_length * sizeof(u32)); xil_printf("BUF1 ACQUISITION STARTED\r\n"); buf1_head = only_meas(buf1, buf1_length, &Pipe, GainTestRelays, 0b00011, 0x0000, 0x01F0); xil_printf("BUF1 ACQUISITION ENDED\r\n"); xil_printf("BUF2 ACQUISITION STARTED\r\n"); buf2_head = only_meas(buf2, buf2_length, &Pipe, GainTestRelays, 0b00011, 0x0000, 0x01F0); xil_printf("BUF2 ACQUISITION ENDED\r\n"); print_serial(buf1, buf1_length, buf1_head, GainTestRelays); print_serial(buf2, buf2_length, buf2_head, GainTestRelays); // LevelTriggerAcquisition (&Pipe, GainTestRelays, 0b00011, 0x0000, 0x01F0); // MinMaxAcquisition(&Pipe, CouplingTestRelays); // MinMaxAcquisition(&Pipe, GainTestRelays); } In order to reset the DMA before each transfer, and to clean up the block descriptor space afterwards, change the S2mmCleanup function in s2mm_transfer.c as follows. void S2mmCleanup(S2mmTransferHierarchy *InstPtr) { // // Spin down the hardware. // XAxiDma_Pause(&(InstPtr->Dma)); // XAxiDma_Reset(&(InstPtr->Dma)); // while (!XAxiDma_ResetIsDone(&(InstPtr->Dma))); // Clean up Bds and deallocate the BdSpace InstPtr->BufferBaseAddr = NULL; InstPtr->BufferLength = 0; InstPtr->NumBds = 0; free((void*)(InstPtr->BdSpace)); // FIXME: throws data abort exception InstPtr->BdSpace = NULL; }

Hi Udayan, We haven't created any examples demonstrating how to set up a system with GeniCam or GigE Vision. They might exist elsewhere on the web, however it's unlikely that anyone has done it with the Eclypse before. There's more of a chance there's something out there for the Zybo. You might be able to port some other example that uses another board with a Zynq-7000 part to Eclypse, but I don't have any recommendations on where to start. This sounds like a big project. Thanks, Arthur