artvvb

Hi @engrpetero, The Vivado command warnings are largely irrelevant. The first one tells me that you have board files installed that make use of Xilinx part numbers that you don't have the device support for installed. As long as the specific board files it complains about aren't used in the project, these warnings are irrelevant. The second warning tells me you installed board files through the Digilent-recommended flow of copying files downloaded from GitHub into a folder in the Vivado install directory. The warning occurs in case there are differences between the 1.1 version of the board files in the XilinxBoardStore repo and the Digilent vivado-boards repo, which could cause problems if moving the project to another computer and not bringing that dependency with - but there shouldn't be differences. The IP packager warnings are related to config parameters for the clock and reset interfaces in the IP. These can be seen by double-clicking on the interfaces in the IP packager. To clear the warnings, the params should be updated to match the names of the actual ports of the IP, eg S_AXI_CLK's ASSOCIATED_RESET param should be changed to S_AXI_ARESETN. This could potentially affect parameter propagation between IPs, but I wouldn't expect this particular warning to cause issues with addressing. I could be wrong. Information about what's in the Customization Parameters and Addressing and Memory tabs of your IP could be helpful. The aforementioned tcl scripts in charge of managing the base address and high address parameters and passing them to parameters can be found in the File Groups tab. It could be easier to add your AXI controller to the project as an RTL module instead of an IP, since, given the correct signal names, Vivado can infer an AXI interface from the set of ports and hopefully not require you to mess around with the IP packager. That said, it's still painful when you need to manage parameters of the inferred interfaces in IPI - lots of random little bugs can still crop up, like not having the correct clock frequency set on an AXI interface. Thanks, Arthur

Hi @rad1vt, Instantiating Verilog modules in VHDL and vice versa is fairly straightforward - the languages can be mixed as desired in Vivado projects. More info here: https://support.xilinx.com/s/question/0D52E00006hplv1SAA/can-i-mix-between-vhdlverilog-on-vivado-?language=en_US, and here: https://www.edaboard.com/threads/can-i-mix-vhdl-and-verilog-in-my-design.132844/. UART controllers can also be pretty straightforward to implement, depending on what bells and whistles (like parameterized baud rate as an example) you want. Here's an example for both TX and RX with both languages: https://nandland.com/uart-serial-port-module/ Thanks, Arthur

@timmy Found it. Pretty big oversight on my part, apologies. The test_stream_sink and test_stream_source headers use the same protection macro, so only the first one is successfully included. I should have tried building with definitions from both headers actually in use last week. Change the first two lines in test_stream_sink.h as follows: And test_stream_source.h: Thanks, Arthur

Hi @Dennis Bingaman The error message means there aren't any IPs Vivado currently has access to with a Pmod interface. You would need to either add vivado-library to the IP repos for the project and use the various IP with Pmod ports found there, or manually enter constraints for those pins while using some other IP or custom RTL module. This guide covers one way of manually entering constraints for an arbitrary IP: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi. It shows this with an AXI GPIO, though any IP or custom module can be connected to external ports the same way. The latter is the better option to learn about, as it gives you much more control over what logic is connected to the Pmod ports. Thanks, Arthur

Odd, that type should be coming in through an "AxiStreamSourceMonitor.h" header in the BSP, if you're using the same platform, I'd expect it to be there. Are you seeing any errors in the platform build which might cause the library that's getting linked against not to complete a build? You can view the platform build console through the "display selected console" selector, see below. What are your includes, and have you copied all sources into the same app's src directory? I'd expect something like this to work - which builds on my machine, with no other changes to the scope example main.c file, for what it's worth. Thanks, Arthur

Hi @simmerj You can modify the Zynq PS configuration's "Clock Configuration" settings to add a 200 MHz clock. The Clocking Wizard IP can be used to configure MMCMs and PLLs - there are some catches here if you're feeding it from a Zynq PS fclk, you should make sure to set the input clock to "No buffer". If you're adding a PLL into custom HDL, refer to the Language Templates in the app for copy-pastable instantiation templates, though this is a complex option that requires close attention to datasheets. Thanks, Arthur

The links are fixed - thanks again for pointing it out.

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

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.

This has been cut from the page, thanks for the report. We've also removed the same incorrect feature callout from the USB104 A7 page. The I/O slices entry has also been cut from both, as it was a meaningless spec when looking at an FPGA board with all of the I/O pins routed (or not) to specific peripherals. They were likely due to a misreading of the 7-series product selection guide (https://docs.xilinx.com/v/u/en-US/7-series-product-selection-guide). As for the first question, I'm not sure and have passed it on to a coworker who might know more. Cheers, Arthur

If you don't have custom IP in the system, File -> Project -> Write Tcl could be sufficient to recreate your project. File -> Project -> Archive is typical and includes all dependencies - I assume this is what you used. In Vitis, File -> Export creates an archive that can be easily imported into a workspace. Any shot that the reversed rx & tx lines between the two UART peripherals might cause some issue? I hadn't noticed that piece of trivia before, and it seems kind of counterintuitive. It's also worth double-checking the xuartps_g.c file - this is where the device IDs are actually mapped to the different configuration sets. If which UARTs are enabled changes, this file potentially changes. Would you be able to share your AXI IP? Addressing parameters should be controlled and passed to Vitis through the UI Layout and Software Driver TCL scripts. UI Layout handles Vivado setting the config parameters which specify the addresses, while the Software driver script defines what gets included in parameters. You could technically modify these scripts to pass more params to the xparameters set if you really felt the need. Thanks, Arthur

It should be an input to the block design, an external port:

Sorry for the delay. An empty C app comes with a linker script. You don't need to generate one. You may want to customize the default one, like to increase stack or heap size, for example. Thanks, Arthur

I have pretty minimal experience with actual DSP. The below is from a very broad view of the subject from some stuff that I've played around with over the years. I'm also definitely repeating a bunch of what asmi and zygot have already said. Learn some Python. Any algorithms you implement in hardware are probably best prototyped in some other area first, and numpy and matplotlib are pretty easy to pick up, and free. I think the Octave tool zygot mentioned is similar? Also MATLAB. As mentioned previously, you can do FPGA design without hardware; simulation is invaluable for debugging and proving that your design works as intended. It might not feel as satisfying as getting "real" signals in and out of a board, but a lot of the actual work of creating a project can be done before spending money (ignoring debugging). When you get to hardware, the pitch for the Basys 3 and Nexys A7 is that they're intended to be best for brand new users of FPGAs, and provide a decent learning curve in the peripherals provided - blink an LED, implement some basic ALU that uses a bunch of switches as input and a bunch of LEDs as output, send characters back to a host over UART, maybe design a VGA controller. That said, I'm honestly not sure how well-suited they are. Quite some time ago, an intern designed a music looper project on a Nexys Video, that would also probably be doable on a Nexys A7, so there are definitely relevant projects which could be done with it. Also note, the only substantial improvement the Nexys A7 brings over the Basys for this is DDR memory. If you don't need the "trainer peripherals", the Cmod A7-35T is cheaper, has the same size of FPGA as the Basys, and has a Pmod port. The Cmod S7 is cheaper and smaller. Thanks, Arthur

Hi @uFedor In Figure 1, everything within the "Zmod Scope" box is external to the FPGA, while the "Zmod Scope Controller" box is IP internal to the FPGA - lines running between these boxes are all routed through FPGA pins and the SYZYGY connector. The FPGA treats the Zmod DcoClk as an input, which also needs to be constrained to appropriate pin locations for whichever physical Zmod port the instantiated controller is to be connected to. Thanks, Arthur

Instructions for rebuilding the Vivado project can be found here: https://digilent.com/reference/programmable-logic/eclypse-z7/git In short: Recursively clone the Eclypse-Z7 repo (which includes both HW and SW sources) targetting the zmod_adc_dac/master branch. Then, in Vivado TCL console, source the digilent_vivado_checkout.tcl script found in the hw subfolder's scripts folder to reproduce the project. Thanks, Arthur

The Pmod I2S2 project is relatively simple compared to other FPGA demos. It only consists of a couple of parameterized Verilog modules, plus customized constraint files and preconfigured clocking wizards for each board it supports directly. There aren't any dependencies that would prevent a port to the Basys 3 - the parameters, clocking wizard, and constraints are the only things that need checking, everything else should work as is. Getting it up and running in a recent version of Vivado could be annoying if it's something you haven't done before (the latest releases are provided for 2018.2). That said, trying out the setup process, up to the step where the board is programmed, is absolutely something you can do before purchasing any hardware. Thanks, Arthur

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

Hi @drkome There are a bunch of potential options, which depend on your final application. BRAMs can be pre-filled with data when you create the bitstream, if you're implementing them through Verilog, this might take the form of an initial block with a $readmem statement of some kind that pulls data from a file. There are other techniques to manually load them, which can be seen here: https://support.xilinx.com/s/article/63041?language=en_US You can add hardware to write to the BRAMs after the bitstream is programmed into the FPGA. This is very open-ended. Making the BRAMs a dual port with one port be addressable by the Zynq PS through an AXI interface is one option. Forwarding data received from PS UART through an EMIO interface is another option. Thanks, Arthur

For what it's worth, it looks like the problem of trying to get C and C++ to play nice in the same project is not an uncommon issue, there are a couple of Xilinx support forum threads on the topic: https://support.xilinx.com/s/question/0D52E00006hpOeeSAE/vitis-combining-c-and-c-in-a-project?language=en_US https://support.xilinx.com/s/question/0D52E00006hpjZ8SAI/tips-for-sdk-c-projects-using-c-source-files?language=en_US Thanks, Arthur

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

Apologies for the confusion, to be clear, when I said that there's a bug in the DMA implementation, I intended to say that the selections we had made for the DMA configuration were incorrect - for exactly the reason you stated, that it needs the transfer length in bytes - not that there's a problem with the Xilinx IP.

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

Ah, you're correct, my mistake, the buffer should be 16,384 samples per channel - the actual implementation in hardware uses one 18k BRAM to create one 16,384x1 dual port RAM per bit, for all 28 bits of the two 14-bit channels, with a 14-bit counter for addressing to read data back out. I've reproduced the issue of data after the first 4096-ish being zeroed and am investigating further whether there's a bug in zmodlib or in the AXI controller IP. Thanks, Arthur

Welcome to the forums. Official support is for 2019.1 and older, pre-Vitis. The sources from the vivado-library master branch are most likely to work, but there hasn't been thorough testing in any version newer than 2019.1. There are a couple of known issues: SD and WIFI do not work in Vitis, since it introduced some compiler changes (not sure of exact details) when it first came out that broke all of the software drivers. Most of the drivers were updated some time after that to fix that particular bug, but those two were not fixed. If you do run across this - it can present as generic "makefile errors" but is related to wildcard patterns in how the makefile figures out which headers/sources to use - one way to work around it is to copy all driver sources into an application project's src folder, and potentially modify include paths. This is painful to try for the two mentioned Pmods though, since they involve pretty extensive driver sources. Board tab automation has problems in some versions, which can show up as either the bottom four pins of a Pmod port failing to have constraints applied (as seen here: https://forum.digilent.com/topic/24263-critical-warning-regarding-board-value/#comment-71596). Workarounds like making the Pmod port external and manually constraining it can work, as seen in the linked thread. Thanks, Arthur