artvvb

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

Hi @aleib_borgwarner
There are a bunch of ways to control the ports of a custom RTL module from Zynq PS. The topic in general is communication between Zynq PS and PL (FPGA fabric). What approach you pick heavily depends on the requirements of the interface you want to control. How often you need to provide new values every clock cycle and whether values need to be provided even when the processor is busy doing other things are both relevant.
A couple of options to look into, in roughly ascending order of complexity/difficulty:
1. AXI GPIO
2. "Hard" PS peripherals like GPIO connected to fabric through EMIO.
3. AXI stream FIFOs
4. A custom AXI controller
5. DMA
You could also connect ports to external hardware, potentially via the Pmod port.
As for permanent programming, the board can be booted from flash or an SD card - see this guide: https://digilent.com/reference/programmable-logic/guides/zynq-baremetal-boot
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.

Thanks Author!  That fixed the issues.

We'll take a look at the downloads. In the meantime, this link could be used as a workaround for that specific file: https://digilent.s3.us-west-2.amazonaws.com/Software/Adept2+Runtime/2.17.1/digilent.adept.runtime_2.17.1-amd64.deb
Thanks,
Arthur

Interesting, moreso that this board went through so many revisions (I have the original Arty, back from the days when it was called simply "Arty", not "Arty A7"), and yet this wasn't changed. But I guess don't fix what ain't broken 😉

I asked one of the design engineers involved. He doesn't recall any particular reason for those vias to be unmasked and indicated it was potentially just an oversight from the engineer who did the layout. They're connected to Pmod port JC or JD.

A lot of people are prototyping DSP algorithms in Python or Matlab because they have facilities for rapid prototyping, as well as great visualization tools which allow to quickly figure out if algorithm does what it's meant to do. The key here is not the language, but the algorithm itself. That's what I think he meant.

Hey Xband,
Ports and clocks referenced in constraints need to match ports and clocks in your design. Presumably, you have two instances of the ADC controller instantiated, which both have their own ports connected to input/output ports. This means that, for example, I'd expect that you would need to be constraining two instances of each port - let's say for example "ZmodA_dADC_Data_0[0]" and "ZmodB_dADC_Data_0[0]" instead of a single "dADC_Data_0[0]" twice.
Also note that the ports for the DAC controller, which are constrained to the Zmod B pins, aren't 1:1 matches with the ADC controller's; the clocks go in different directions for one example.
Broadly, how I'd approach it would be to start by copying the Zmod A constraints, update all of the package_pin locations to match corresponding locations in Zmod port B, then update all of the names in get_ports, get_pins, and get_clocks calls to match the names used by the second controller in the hardware design.
For an overview of constraints, you might check out these blog posts. They're not 100% applicable, and this is a very complex design to be trying to modify when starting out, but they might help with some terminology.
https://digilent.com/blog/the-constraints-file-also-known-as-magical-moving-stairs/ https://digilent.com/blog/constraining-ports-manually-via-xdc-file-vs-board-files/ Xilinx's UG903 covers everything in excruciating detail:
https://docs.xilinx.com/v/u/2019.1-English/ug903-vivado-using-constraints Thanks,
Arthur

There is a potential trap in this though when your buffer is not aligned to a cache line, in that the Xil_DCacheInvalidateRange function not only invalidates the cache lines, but it also flushed them if they were updated by CPU, which could mess with the data that shares the same cache line as other variables which were modified (because cache only tracks modifications on a level of cache lines, and not individual bytes/words of data within those lines). Please refer to this post for more details: https://support.xilinx.com/s/question/0D52E00006iHjkGSAS/zynq-invalidating-a-specific-area-of-data-cache-without-flushing-its-content?language=en_US One way to combat this is to allocate your buffer statically and ensure cache line alignment, but it's not always possible.

Invalidating the cache for the range that the data has been placed in could also be sufficient. The xil_cache.h driver has the necessary functions. It's a pretty common issue folks run into with DMA as well.
Thanks,
Arthur

No worries, I didn't mean to imply anything - I merely mention that because I've made that exact mistake myself more times than I'm willing to admit 🤐

It's working great now!
Thanks!

Hi @Moshe_va, welcome to the forums.
acquireTriggeredPolling makes use of trigger hardware built into the AXI controller IP in order to detect signal conditions on either scope input channel; it doesn't accept external triggers.
An external trigger could be brought into the FPGA PL through a Pmod port - in which case it would need to be LVCMOS3V3 compatible. If you need hardware timing for it, then the AXI controller for the Zmod ADC and zmodlib sources would need manual modification, and the FPGA image and Petalinux image would need to be rebuilt.
If you don't need hardware timing, you could potentially use an AXI GPIO or an EMIO GPIO connected to a Pmod port, with or without an interrupt - the FPGA image would still need rebuilt, and drivers for whichever GPIO was used would need to be represented in Petalinux. In this situation, the Zynq PS would detect a GPIO event and manually trigger an acquisition, using acquireImmediatePolling.
Thanks,
Arthur

Hi @timmy,
There's a bug in the DMA implementation in Vivado. The "Width of Buffer Length Register" parameter in the DMA configuration should be increased to 16 bits from 14 bits, to increase the amount of data that a single DMA transfer is capable of sending to the circle buffers - this value reflects a maximum number of bytes that can be transferred. Currently, when the length of the transfer is written to the DMA, the top two bits are masked off, and only a quarter of the maximum amount of data can be sent.
Once the hardware is regenerated and the new HDF file has been used to update the hardware platform, no software changes are required to get it working.
Updated sources should be available on Github soon, at least for the baremetal projects.
Thanks,
Arthur

Hello @artvvb 
Thank you for the explanation.
Thank you for the reference to the demo project. In the meantime I looked a bit at the datasheet of the AD5541A and I think the effort of viewing that demo project is too big compared to the effort of reading the relevant timings from the datasheet. When I wrote that comment I lost myself a bit in the documents searching for a proper IP. 
Physically the Pmod and the Zmod do not collide. I already tested that. 
When it comes to the maximum timing I will have to figure it out. But that is something I will look at after I come back after my vacations. 
Thank you too, 
Philipp Brogli

Hey @artvvb

Thank you for the quick response and pointing me in the right direction! I will take a look at the "low-level filter demo" and start moving my efforts towards redesigning the HW; I didn't realize the limited access I had with a SW approach.

Will keep you posted if there's anything else I have questions about!

Thanks again!

Hello,
I've added the Nexys Video to my nine-part FPGA Graphics tutorial series.
https://projectf.io/posts/fpga-graphics/
You can also follow the tutorials on Arty A7-35T, iCEBreaker, and Verilator/SDL simulation you can run on PC/Mac.
All the designs are open source and available on GitHub: https://github.com/projf/projf-explore/

Ok I found the solution I needed to pick Zybo en not z7-10 in the beginning of making the vivado project.
Thank you for your help!!!

Just for information's sake, I was able to get the demo working pretty much right after posting. Silly connection oversight caused a DHCP timeout, can't remember exactly what since it was a few days ago. Thanks for the reply, though. 

Thanks a lot. I recall doing this a while ago on another project, but forgot. It works.

Some project releases require that you source a script in the TCL console, usually located in a "proj" folder in order to recreate an XPR file. Readmes you might find in the extracted ZIPs can provide more info. In the case of the Nexys 4 OOB, the process is documented online, start here: https://digilent.com/reference/learn/programmable-logic/tutorials/nexys-4-user-demo/start
Note that pretty much all project releases are supported only in specific versions of the tools.
Thanks,
Arthur

There are a lot of resources around on how to learn Verilog, this one seems decent at a glance: https://www.chipverify.com/verilog/verilog-tutorial. Folks may also be able to recommend some good textbooks.
Thanks,
Arthur

Hi @zoodle
You are correct, that looks to be a mistake in the guide. If you continue through the guide to the point where an HDL wrapper is created and open the HDL wrapper, you will be able to see the top-level port names in the port list, these top-level ports are the names that the constraints must match. The port will appear as either gpio_tri_io, gpio_tri_i, or gpio_tri_o, depending on whether the GPIO IP is set to tristate, all input, or all output. The three ports you see on the IP end up getting automatically connected to a tristate buffer in the final design.
Thanks
Arthur

Yeah, current PC RAM marketing is all over this. But since FPGA designs are very close to hardware, it's important to be more precise even with marketing materials, because I think the kind of people who buy these boards are tech savvy enough for the most part to know the difference between "marketing" MHz and real ones.