JColvin

Hi @A.O,
If you are using Vitis, there is a checkbox during project creation called Generate Boot Components while selecting your .xsa that will include the FSBL for you already in the BOOT.bin (as noted in this guide here: https://digilent.com/reference/programmable-logic/guides/zynq-baremetal-boot), so you do not have to manually create it yourself.
I don't have a Cora Z7-10 to directly test this, but I created a matching design for the Cora Z7-7S (the single core processor version of the Cora Z7) which was able to successfully boot up with the two buttons lighting up the RGB LEDs to a single color (one red, one green) when pressed, and an external UART setup where any character typed in the host PC's serial terminal is sent out Pmod JA2 and any character received on Pmod JA1 is then sent to the host PC's serial terminal.
I connected Pmod JA1 and JA2 with a flexible breadboard jumper wire to turn the UART setup into an external loopback.
I attached the Vivado 2020.1 project that I used as well as the main.c and BOOT.BIN that I used in Vitis (all designed for the Cora Z7-10). Make sure that when you are booting from the SD card that it is in a FAT32 file format and that jumper JP2 is loaded.
I know that when booting from the SD card that if the serial terminal is not already connected to the board (perhaps because of a power cycle), you may miss the first "peripherals have been initialized" message.
Let me know how this works for you.
Thanks,
JColvin
CoraZ710-extUart_GPIO-20.1.zip

Hi @Robert.o,
The change you noted is due to supply constraints (of course); there's a little bit more detail about that in the Product Change Notice available on the Arty A7 Resource Center: https://digilent.com/reference/programmable-logic/arty-a7/start#documentation.
I'm not certain if there is a way to get Vitis to recognize the other flash memories. I am not certain how large your application is (and I have personally never gotten the SREC bootloader to work) would be to follow the instructions I put in this post (associating the .elf file of the application project with MicroBlaze) and then loading the .bin file to the flash from Vivado), the post was for the Cmod A7, but the steps are effectively the same and Vivado should recognize the memory just fine (though if going through the Getting Started with IPI guide, you would of course follow the "with DDR" version of course):
Let me know if you have any questions.
Thanks,
JColvin

Hi @tian,
The reason you are running into issues is because vauxp0/vauxn0 and vauxp1/vauxn1 are not the A0 and A1 pins on Arty A7 100.
The channel number differences are a little wonky admittedly, but the table at the end of the Arty A7 Reference Manual tells you which pin on the shield connector is associated with which vaux channel number on the Artix FPGA, https://digilent.com/reference/programmable-logic/arty-a7/reference-manual#shield_analog_io. So, for example if you want to use A0 and A1 as single ended analog inputs, you would need to enable vauxp4/vauxn4 & vauxp5/vauxn5, respectively.
The .xdc for the Arty A7 may be a bit easier to read in terms of pin assignment, https://github.com/Digilent/digilent-xdc/blob/master/Arty-A7-100-Master.xdc#L120; it looks like you have the approach already with the making the pins external, you just ended up constraining them not to the correct pins.
For reference, V_P is located on J10 and V_N is located on K9. So their constraints would look something like:
#set_property -dict { PACKAGE_PIN J10 IOSTANDARD LVCMOS33 } [get_ports { Vp_Vn_0_v_p }]; #VP_0 ChipKit pin=V_P #set_property -dict { PACKAGE_PIN K9 IOSTANDARD LVCMOS33 } [get_ports { Vp_Vn_0_v_n }]; #VN_0 ChipKit pin=V_N Note however that this analog input pair, like the other analog input pairs, do not have any sort of voltage divider (like on the single ended inputs dividing from 3.3 V logic to 1.0 V) so the voltage difference applied needs to be within the allowed voltage range of 0 V to 1 V in unipolar mode and -0.5 V and +0.5 V in bipolar mode.
Let me know if you have any questions about this.
Thanks,
JColvin

Hi @Udayan Mallik,
I will ask about the BOMs getting released, though my gut reaction is that they will not be available considering that the filter and amplifier portions of the schematic were chosen to be obfuscated.
On the other hand, 3D models for the Eclypse Z7 were finally created; there are two different models available in the Additional Resources section of the Resource Center: https://digilent.com/reference/programmable-logic/eclypse-z7/start#additional_resources. The STP 3D model has some more details, but fewer visible components, whereas the STP Altium export has a lot more visible components but they are instead just blocky extrusions from the main PCB; less detail but the dimensions for the physical "keep-out" areas will be accurate.
Thanks,
JColvin

Hi @John92,
It's been awhile, but I got the chance to test out the Pmod DA4 hierarchy (https://github.com/Digilent/vivado-library/tree/hierarchies/hierarchies) that Digilent made in Vivado/SDK 2019.1 for the Zybo Z7-10 and was able to get it working as is.
Some instructions for getting the hierarchy up and running can be found here: https://digilent.com/reference/programmable-logic/guides/hierarchical-blocks.
Please let me know if you have any questions.
Thanks,
JColvin

Hi @Zynq,
Which micro USB port are you connected to with the micro USB cable? The correct port for the UART/serial connectivity is J6 the one labeled PROG (as opposed to J5 labeled USB which is used for USB Host connectivity).
If you are connected to the PROG port (since your description of the board's behaviors with the IP address and LEDs is what I would expect out of a working device), could you let me know what the Windows Device Manager sees when you connect the Eclypse Z7? It should show up under the Unviersal Serial Bus controllers dropdown as USB Serial Converter A and USB Serial Converter B (each of them with a Bus reported device description property under the Details tab as a "Digilent USB Device").
Thanks,
JColvin

Hello,
I do not have any evidence for iMPACT working on newer Linux distributions in conjunction with the Basys 2, so at this point I would say it does not work.
I suspect (much like you do) that there is a driver issue of some kind at play here, but the engineer most familiar with Digilent's Adept software and the plugin that I linked earlier is not intending to invest time to figure out what the root cause might be.
Regarding your earlier question of does iMPACT from ISE 14.7 work with the latest Fedora and Debian distributions, Digilent does not have a conclusive answer for this as we have not tested this particular compatibility with the Xilinx software. I have not checked, but I suspect Xilinx has not made any deliberate efforts to check this either.
Thank you,
JColvin

Hi @Nathan Miller,
I asked the engineer most familiar with our JTAG line about this and they let me know that the maximum length of that string is different between the FT2232H and FT232H, so some Digilent devices have the longer more descriptive string and others have the shorter one ("Digilent USB Device").
Regardless, they confirmed to me that this string value on the JTAG-HS2 has never been changed, so the value of "Digilent USB Device" you are seeing on your system (and what I confirmed to see on my own JTAG-HS2) is accurate.
Thank you,
JColvin

Hi @osman,
I don't think you will have to; I talked to one of my co-workers who remembered having a similar issue and they were able to help me find the bug in the Xilinx software driver that is causing the issue (this bug is fixed in later versions of SDK/Vitis).
Basically, there a bug in the xvtc_intr.c source file in the XVtc_IntrHandler function (in 2019.1) where it has a line that says
/* Spurious interrupt has happened */ if (PendingIntr | XVTC_IXR_SPURIOUS_INTR_MASK) { ErrorStatus = 0; XVtcPtr->ErrCallBack(XVtcPtr->ErrRef, ErrorStatus); return; } But that bitwise OR function always returns false no matter what the parameters are, so it needs to be changed to an AND, i.e.
/* Spurious interrupt has happened */ if (PendingIntr & XVTC_IXR_SPURIOUS_INTR_MASK) { ErrorStatus = 0; XVtcPtr->ErrCallBack(XVtcPtr->ErrRef, ErrorStatus); return; } You can permanently fix this in your 2019.1 installation by finding the file in your Vivado installation and making the change. For me, this file was in
You can verify which numbered version of the VTC is being used by checking the BSP folder in the libsrc folder (screenshot attached oh what you will be looking for).
After you make this change in the actual Vivado installation, you should just be able to right-click on the bsp folder in SDK and choose "Re-generate BSP Sources". The project should then be able to run and capture source frames from the host computer (or at least it is working for me on my setup).
Let me know if you have any questions.
Thanks,
JColvin
 

Hi @osman,
I don't think you will have to; I talked to one of my co-workers who remembered having a similar issue and they were able to help me find the bug in the Xilinx software driver that is causing the issue (this bug is fixed in later versions of SDK/Vitis).
Basically, there a bug in the xvtc_intr.c source file in the XVtc_IntrHandler function (in 2019.1) where it has a line that says
/* Spurious interrupt has happened */ if (PendingIntr | XVTC_IXR_SPURIOUS_INTR_MASK) { ErrorStatus = 0; XVtcPtr->ErrCallBack(XVtcPtr->ErrRef, ErrorStatus); return; } But that bitwise OR function always returns false no matter what the parameters are, so it needs to be changed to an AND, i.e.
/* Spurious interrupt has happened */ if (PendingIntr & XVTC_IXR_SPURIOUS_INTR_MASK) { ErrorStatus = 0; XVtcPtr->ErrCallBack(XVtcPtr->ErrRef, ErrorStatus); return; } You can permanently fix this in your 2019.1 installation by finding the file in your Vivado installation and making the change. For me, this file was in
You can verify which numbered version of the VTC is being used by checking the BSP folder in the libsrc folder (screenshot attached oh what you will be looking for).
After you make this change in the actual Vivado installation, you should just be able to right-click on the bsp folder in SDK and choose "Re-generate BSP Sources". The project should then be able to run and capture source frames from the host computer (or at least it is working for me on my setup).
Let me know if you have any questions.
Thanks,
JColvin
 

Hi @osman,
I don't think you will have to; I talked to one of my co-workers who remembered having a similar issue and they were able to help me find the bug in the Xilinx software driver that is causing the issue (this bug is fixed in later versions of SDK/Vitis).
Basically, there a bug in the xvtc_intr.c source file in the XVtc_IntrHandler function (in 2019.1) where it has a line that says
/* Spurious interrupt has happened */ if (PendingIntr | XVTC_IXR_SPURIOUS_INTR_MASK) { ErrorStatus = 0; XVtcPtr->ErrCallBack(XVtcPtr->ErrRef, ErrorStatus); return; } But that bitwise OR function always returns false no matter what the parameters are, so it needs to be changed to an AND, i.e.
/* Spurious interrupt has happened */ if (PendingIntr & XVTC_IXR_SPURIOUS_INTR_MASK) { ErrorStatus = 0; XVtcPtr->ErrCallBack(XVtcPtr->ErrRef, ErrorStatus); return; } You can permanently fix this in your 2019.1 installation by finding the file in your Vivado installation and making the change. For me, this file was in
You can verify which numbered version of the VTC is being used by checking the BSP folder in the libsrc folder (screenshot attached oh what you will be looking for).
After you make this change in the actual Vivado installation, you should just be able to right-click on the bsp folder in SDK and choose "Re-generate BSP Sources". The project should then be able to run and capture source frames from the host computer (or at least it is working for me on my setup).
Let me know if you have any questions.
Thanks,
JColvin
 

Hi @osman,
I don't think you will have to; I talked to one of my co-workers who remembered having a similar issue and they were able to help me find the bug in the Xilinx software driver that is causing the issue (this bug is fixed in later versions of SDK/Vitis).
Basically, there a bug in the xvtc_intr.c source file in the XVtc_IntrHandler function (in 2019.1) where it has a line that says
/* Spurious interrupt has happened */ if (PendingIntr | XVTC_IXR_SPURIOUS_INTR_MASK) { ErrorStatus = 0; XVtcPtr->ErrCallBack(XVtcPtr->ErrRef, ErrorStatus); return; } But that bitwise OR function always returns false no matter what the parameters are, so it needs to be changed to an AND, i.e.
/* Spurious interrupt has happened */ if (PendingIntr & XVTC_IXR_SPURIOUS_INTR_MASK) { ErrorStatus = 0; XVtcPtr->ErrCallBack(XVtcPtr->ErrRef, ErrorStatus); return; } You can permanently fix this in your 2019.1 installation by finding the file in your Vivado installation and making the change. For me, this file was in
You can verify which numbered version of the VTC is being used by checking the BSP folder in the libsrc folder (screenshot attached oh what you will be looking for).
After you make this change in the actual Vivado installation, you should just be able to right-click on the bsp folder in SDK and choose "Re-generate BSP Sources". The project should then be able to run and capture source frames from the host computer (or at least it is working for me on my setup).
Let me know if you have any questions.
Thanks,
JColvin
 

Hi @osman,
I don't think you will have to; I talked to one of my co-workers who remembered having a similar issue and they were able to help me find the bug in the Xilinx software driver that is causing the issue (this bug is fixed in later versions of SDK/Vitis).
Basically, there a bug in the xvtc_intr.c source file in the XVtc_IntrHandler function (in 2019.1) where it has a line that says
/* Spurious interrupt has happened */ if (PendingIntr | XVTC_IXR_SPURIOUS_INTR_MASK) { ErrorStatus = 0; XVtcPtr->ErrCallBack(XVtcPtr->ErrRef, ErrorStatus); return; } But that bitwise OR function always returns false no matter what the parameters are, so it needs to be changed to an AND, i.e.
/* Spurious interrupt has happened */ if (PendingIntr & XVTC_IXR_SPURIOUS_INTR_MASK) { ErrorStatus = 0; XVtcPtr->ErrCallBack(XVtcPtr->ErrRef, ErrorStatus); return; } You can permanently fix this in your 2019.1 installation by finding the file in your Vivado installation and making the change. For me, this file was in
You can verify which numbered version of the VTC is being used by checking the BSP folder in the libsrc folder (screenshot attached oh what you will be looking for).
After you make this change in the actual Vivado installation, you should just be able to right-click on the bsp folder in SDK and choose "Re-generate BSP Sources". The project should then be able to run and capture source frames from the host computer (or at least it is working for me on my setup).
Let me know if you have any questions.
Thanks,
JColvin
 

Hi @Rahmadi,
In principle, the Pmod ESP32 is compatible with any other hardware, provided it is electrically and physically compatible (the Pmod ESP32 is designed with a 3.3 V supply in mind), so in that regard it was not made only for Digilent products. The IP core that we made was developed with the Pmod interface in mind, though if you are using a Xilinx FPGA, you could ostensibly set the constraints to what you need.
As for what is going on with the ESP32 and the ST microcontroller, it's hard to say for certain what is happening, though it's almost certainly an issue with the implementation (if it was an issue with the ESP32 itself, it wouldn't respond to the Xilinx FPGA either). It could be that the ESP32 needs some additional configuration before it is ready to receive inputs, the tx or rx pin on the microcontroller not being set to the correct output/input state, data is being received but not being correctly processed, the pin 9 on the ESP32 being driven high so it's expecting to receive SPI communication rather than UART data, etc. I don't know what setup you are using with the Nucleo board nor am I familiar with the ESP32 implementation that is available for it, so I'm not certain how much help I will be in terms of debugging it.
Thanks,
JColvin

HI @dooeun,
Have you gotten to try a different cable (or less likely from a troubleshooting perspective, use an external power supply rather than having the power supplied through the USB cable) to help rule out that particular point of failure? Based on your picture, your general hardware setup looks correct.
When you say the connection is not actually connected, do you mean that you are not able to successfully see the device in the Windows Device Manager (presuming you are using a Windows OS?)
Thanks,
JColvin

HI @dooeun,
Have you gotten to try a different cable (or less likely from a troubleshooting perspective, use an external power supply rather than having the power supplied through the USB cable) to help rule out that particular point of failure? Based on your picture, your general hardware setup looks correct.
When you say the connection is not actually connected, do you mean that you are not able to successfully see the device in the Windows Device Manager (presuming you are using a Windows OS?)
Thanks,
JColvin

HI @dooeun,
Have you gotten to try a different cable (or less likely from a troubleshooting perspective, use an external power supply rather than having the power supplied through the USB cable) to help rule out that particular point of failure? Based on your picture, your general hardware setup looks correct.
When you say the connection is not actually connected, do you mean that you are not able to successfully see the device in the Windows Device Manager (presuming you are using a Windows OS?)
Thanks,
JColvin

Hi @DrDave,
Check out this Forum thread for more details on this:
Let me know if you have any questions.
Thanks,
JColvin

Hi @Yizakat,
I ran through the tutorial you referenced with the Nexys A7 100T in both Vivado 2020.1 and Vivado 2021.1 and did not get the error (or warning) you mentioned. It sounds like you followed the correct steps, but I have some clarification questions.
-What version of Vivado did you use? Since you said latest I'm guessing you are using 2021.2 which I did not specifically check, but it should operate the same. I'll be able to check 2021.2 tomorrow to see if something drastic changes for me and I'm not able to generate a bitstream.
-Are you using the Nexys 4, the Nexys 4 DDR, or the Nexys A7 100T?
-What version of the board file are you using? If you click in the "Board" tab where you can add items to the Block Design and click on the Nexys A7-100T header, it should said the version number in the Board Properties box just below that.
Thanks,
JColvin

Hi @dyne21,
I am looking to see if I can get this working, though I personally have always had issue getting the SREC SPI Bootloader ever working as advertised, whether I follow Digilent's or Xilinx's instructions on it.
I've instead successfully used this approach for storing SDK/Vitis projects in flash:
Thanks,
JColvin

Hi @mbr,
It's certainly possible to use Vitis HLS with Arty A7, though Digilent doesn't have any examples/demos of using Vitis HLS.
However, I don't think the Arty A7 is going to be the best platform for your application since it doesn't have any direct on-board way of receiving or sending video data (like an HDMI or VGA port).
Xilinx has a github repository dedicated to xfOpenCV here, https://github.com/Xilinx/xfopencv, though as noted in the readme, this has been superseded by the Vitis Vision Library, https://github.com/Xilinx/Vitis_Libraries/tree/master/vision.
Thanks,
JColvin

HI @kannan.sasikumar,
There are a couple of options you can do. 
One is to implement a UART module in HDL, such as this one, https://www.nandland.com/vhdl/modules/module-uart-serial-port-rs232.html; the .xdc in Vivado would need to have the UART data leaving the FPGA to the host computer assigned to D4 (UART_RXD_OUT) and UART data going into the FPGA from the host computer assigned to C4 (UART_TXD_IN), as per the schematic bank pins on page 7: https://digilent.com/reference/_media/programmable-logic/nexys-a7/nexys-a7-d3-sch.pdf.
The second option if you are wanting to use a Microblaze/SDK/Vitis flow with IP blocks, you can use the AXI UARTlite IP with Microblaze (Digilent has some instructions on how this might be done here: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi) and then using Xilinx's AXI UartLite examples (https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842359/AXI+UART+Lite+standalone+driver#AXIUARTLitestandalonedriver-LinkstoExamples) to receive data that you type on a serial terminal on your computer.
Thanks,
JColvin

Hi @NithinA,
I may be misunderstanding how much detail you are wanting to know about the triggered polling method, but the window position parameter defines where you want the trigger condition to be located in the buffer when the trigger occurs. This is helpful for when you need to know/see the state of the system prior to the trigger condition (such as when you looking for when a ceiling threshold is reached and you want to know if the system was oscillating or growing unstable prior to reaching that threshold or if it was just a spike).
The 'triggered polling method' just checks on a regular time interval to see if whatever threshold you specified as the trigger condition was reached or not.
Let me know if you have any questions.
Thanks,
JColvin

Hi @Ryan_98,
The issue is with the Pmod IPs themselves; the structure/implementation that they used no longer works as intended in newer versions of Vivado, as you experienced. We have not gotten to resolve this as of yet (something about lack of time and resources to restructure 50+ IPs) for the newer of versions of Vivado.
The Pmod IPs will work as intended in 2019.1 and earlier versions of Vivado though.
Please let me know if you have any questions.
Thanks,
JColvin

Hi @skinnypanda,
Which Zedboard board file are you using; the one from Digilent or the one from Avnet that is included by default with Vivado?
The fact that one of the error messages you are getting is calling out "zed.xsa" is a potential error as that is one of the built-in .xsa's with Vivado/Vitis and potentially not the one you created and exported in Vivado (the one you created would have a default name of design_1_wrapper.xsa) and would need to be specifically selected. As a test, I made a Zedboard project following the IPI guide and when I select my .xsa I exported, everything works as described in the tutorial, but when I select the pre-made zed.xsa file (i.e. selecting the wrong Xilinx platform file), I get the same errors to what you posted (though different messages in the Vitis log).
What I would probably recommend trying is to close out the Vitis workspace, delete the folder, and then relaunch Vitis from Vivado and ensure the correct .xsa is selected while creating the project.
Also, do you happen to recall which screenshots were different on the later version of Vivado that you had tried for the Getting Started with Vivado IP Integrator Guide? The design flow presented is fairly familiar to me so I usually end up going on "autopilot" and I haven't explicitly gone through it step by step to see what has changed drastically, though I'll make a note to do that later.
Let me know how it goes.
Thanks,
JColvin