Digilent Staff
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Ciprian

  1. It is close, the version which I have is: <board name="Nexys_Video" display_name="Nexys Video" family="artix7" part="xc7a200tsbg484-1" device="xc7a200t" package="sbg484" speedgrade="-1" vendor="" /> Although I don't know if we have an official version for this board in HLS, the one I provided should work. If it does not you can also just chose the correct part in the parts list, for HLS there are no board specific settings besides the FPGA part.
  2. Well generally you have a C code which you want to optimize of which only a part can be optimized, so you are right so far. This is due to different limitations in the way HLS transforms your C code in to HDL; basically once you start writing code for HLS you need to understand how that code will be synthesised by HLS in order to obtain the best performance. You can find more details about the directives in UG902. I have unfortunately not worked with CPU-GPU accelerations so I don't exactly know how it works, but I assume that you have the GPU and the CPU in the same PC/Laptop. If this is the case then you can offload some functions to the GPU without actually knowing the interface between the CPU and GPU, you just give it the task and when it's finished its finished. Now if there are a lot o small actions which the GPU has to do there will be a back and forward between the GPU and The CPU for reading and writing data in which case the bandwidth between the processors becomes and issue. At least this is how I understand the issue, please correct me if I'm wrong or the info is incomplete. When it comes to FPGA's most of the time you don't have an FPGA in a PC/Laptop (I have not heard of one so far but there might be one somewhere) so you have to chose how to interface with your FPGA (USB, PCI, Ethernet, etc) depending on the required speed and bandwidth you can chose what you like. Being on the Digilent forum I assume you have one of our boards or are considering buying one so you either have to make due with what high-speed interface you have on your dev. board or you can buy a board which suites your needs. The idea is that not knowing what HLS is going to be used for and how, the authors of the UG871 will not focus on the bandwidth between the FPGA and something else, because they assume you will chose an interface which can handle the desired data at the desired speed. There is also the point that you might have a soft-core processor implemented in the FPGA and do not desire to send data to a different processor which is not in the FPGA, in which case you will have to focus on the throughput of the soft-core CPU and the HLS core. Or you could use a Zynq which has a ARM processor next to a FPGA, but I digress.... Now from the HLS perspective they do take in to account the throughput of the data which will be flowing in to the HLS core and they do warn you about the limitations of the core using the initiation interval (aka 1/throughput) which you will get in the synthesis report, but that is the maximum throughput which your HLS core can support and that can be optimised using the HLS directives. If you need a high speed data transmission for bulk data then you will need to interface your HLS core using an AXI-Stream interface. For example if you want to accelerate your C code from a PC using PCI it would look something like this: CPU <=> PCI <=PC side============FPGA side=> PCI <=> PCI-to-Axi-Stream core <=> HLS core Hope this has clarified some of your questions... Ciprian
  3. Ciprian

    Ask for help about Pmod I/O

    @D@n, @Notarobot In a way you both are right. Generally speaking if you have an interrupt and based on that interrupt you want to do something "simple" as GPIO control or interface control (SPI, UART, I2C, etc.) and the timing is extremely important then it is strongly advised to program it in to the PL; this is also this case if you are dealing with a complex project and you PS code is starting to mess with your overall performance of the project. I am a strong advocate of using as much of the PL as possible because that is the advantage of an FPGA and especially of the ZYNQ. But if you need something sequential like a certain order to the execution of a project then it is easier to use the processor, yes you loose execution time but you gain transparency and simplicity which for a project with a "higher complexity", such as using multiple interfaces in a certain order or implementing stacks, is important. So rather than creating a enormous state machine just to accommodate a certain sequence it's easier to just use the PS and coded it in C. The bottom line is: 1. We do not know what the user wants to do, might be something easy might be something which is more than just some GPIO and an interrupt signal 2. We do not know the extent of his knowledge, he might be more proficient in C than in HDL which means it would be easier for him to just use the PS 3. We do not know if high performance is a requirement for what he wants to do, he might not need high speed execution time, it would be nice to have it but it is not a necessity 4. We do not know if he has a deadline (self imposed or otherwise), and this is the most important for him because based on this information he must choose if he will venture in leaving his comfort zone and learning something new or he needs it ASAP and then just tries to make it work somehow (this is bad practice by the way) based on what he knows and as little as possible effort. We are speculating here and until we get more information you both are, in a sens, right. Cipi
  4. Hi JCer, To tell you the truth we have also tried but with no success, sadly it is not a priority project so I don't think we have a good answer for you. There where some previous kernel versions on which we had a HDMI working on the ZedBoard but that board has a dedicated HDMI controller on it. If you are determined to have it working and you manage to build one could you please post it? As far as pointers go: 1. consult the older versions of ZedBoard linux projects. 2. focus on the DRM driver from xilinx which is the main output driver (as far as I know) 3. be patient, this is not an easy project Good luck, Ciprian
  5. It is unclear to me what you mean by: "I want to change the flash program address of Linux and ramdisk image." Do you want to load the ramdisk and the kernel to a specific location in the QSPI or do you want to change where the ramdisk is loaded in the DDR memory on booting, because as far as I know when the kernel boots it loads the content of the QSPI (kernel and ramdisk) in to a specific location in the DDR.
  6. Ciprian

    Ask for help about Pmod I/O

    It's unclear to me what you mean by: "when I send a high voltage to the pmod pin, the program started to work". Do you want to reset the software part (C code) or do you want it to be like an enable signal for the hardware part or do you want the project to initialize and then wait for the interrupt signal?
  7. Ciprian

    Ask for help about Pmod I/O

    Hi ZYLL, AXI GPIO core is fairly slow, although I could not find a specific switching rate, other users have found that it works around 2-3 MHz. If you are doing bit-banging using AXI GPIO this is the best you can hope for. I recommend either writing your own GPIO core, although I don't know how much of an improvement it will be, or moving the whole part of the project which uses the AXI GPIO core in to the PL and making a custom core for it. Regarding the trigger signal, use AXI interrupt controller core which you can configure either on edge or on level and you should receive an interrupt when the signal changes. Regards, Cipi
  8. Hi yohboy, So.... are you booting from the QSPI (I assume yes) or from the SD? If you are trying to boot the Linux from the QSPI which is delivered with the board and the QSPI memory has been overwritten you could try this: Regards, Cipi
  9. I don't know if it will work with a petalinux uImage, uboot has to be configured to work with a certain Linux kernal and linux kernel format (uImage, zImage,etc.). The one that we provided to you is a custom Linux kernel and userspace build primarily for testing certain functionalities of the zybo and programming the QSPi with the demo Linux image. In conclusion the SD Linux image was never meant to be accessible with a username or a login. Regarding on how we did the programming of the QSPI, all of the code you are looking for is in the uramdisk, although I have not tried it yet myself I imagine that you can unpack the uramdisk and read the code using this methode: If you want to start working with Linux on the zybo and want to build your own userspace and kernel you should follow this tutorial: Although it's not up to date it's a good starting point for doing it yourself I hope this helps, Cipi
  10. Ciprian

    FPGA USB Audio

    Well the idea is that in the FPGA there is no USB controller so you should either have a USB controller IP or build one yourself. As far as I know a colleague of mine has published a USB controller core on our git, but I don't know what it can do. Also, you are right the Nexys Video is not a viable solution because it dose not have a USB Phy... my bad, so that leaves only the Genesys2, if you insist of using the FPGA for USB, which is expensive. So.... I guess the easiest and cheapest solution would be a Zybo.
  11. Ciprian

    FPGA USB Audio

    I would recommend something Zynq based because you already have the USB controller in the ARM of the Zynq (Zybo or Zed). If you want to build your own USB controller or use a custom on in the FPGA than you have to find something with only FPGA (Nexys Video or Genesys 2). All four of these boards have an audio codec on them which supports the I2S protocol. Stay away from: Pynq, Arty Z7, Nexys 4 DDR and Nexys 4; these have an analog circuit which receives the audio samples via PWM or PDM, so no audio interface. Cipi
  12. While booting from QSPI you don't have to program the board, you just set the jumper to QSPI and switch the board on. Also there should be Linux booting messages sent trough the UART, if you are not getting those then the QSPI content has been probably overwritten. If you get the booting messages and there still is no HDMI output, then the HDMI is probably faulty. You might not be fast enough to start the COM port on you terminal before the booting messages are finished displaying, so what I recommend is to: 1. Set QSPI jumper 2. Connect the pc to the UART connector on the board and then turn on the board 3. Open COM port in preferred terminal 4. Press PS-SRST Now, if your QSPI has been overwritten you can load the file attached to this massage on a SD card (after you unzip it) and boot from the SD card (same procedure as the QSPI booting) you should get some color bars on the HDMI. If noting works then, probably, the HDMI is dead. Cheers, Ciprian
  13. Hi anfractuosity, I looked over the (assuming that you did where referring to this project in your earlier post) and I have some followup questions regarding how exactly you build the project. So first up I would like to know how you managed to build the project using Vivado 2016.4? When I try to run the create_project.tcl file in a different version then Vivado 2015.4 I get an error and it dose not create the block design. My second question is: have you overwritten the project which was stored in the QSPI Flash? if not, try booting from the QSPI using the boot selection jumper and connect the HDMI to the TV you should be getting a test pattern. You could also try not building the project and directly opening the SDK project from the sdk folder and programing the .bit from there and then running the displaydemo project. cheers, Ciprian
  14. Hi Saurabh, Sadly the documentation you are referring to is outdated, the newer versions of linux kernel do not have the same config files as the one presented in that document. Also as far as I know Digilent dose not have an updated version of this document or a tutorial which will help you guide your way through the maze which is embedded Linux and Linaro (as far as I know). Now depending on what you might want you have a couple of options: If you are looking only to use Linux on the board, for the sake of using Linux without actually adding or creating costume IP in the FPGA part of the Zynq. I recommend using an "plug and play" kind of a solution, called Xilinux by Xillybus. It is sort of an black box approach, from a hardware perspective, with a hard to modify Linux Kernel. You basically just have to build the hardware copy the kernel and the image on a SD card and you are good to go. It is also more stable than Linaro, from what I tested. If you are more into building your costume hardware and costume kernel, I recommend using the Analog Devices tutorial for the ZedBoard. Although it is harder to follow and you have more steps than with the Xilinux, it will allow you to change things in it with little ease. This approach will also teach you more about embedded linux than the other one, because it will force you to self study on this subject. Also if you are more inclined towards this solution I strongly suggest you look over the Zybo Linux example from Digilent. Granted it is not constructed for the ZedBoard but the configuring and building of the kernel and hardware is very similar, you might get a better perspective on the whole embedded Linux world if you look at the Zybo example also. There is no easy beginner friendly solution for what you want. Nothing like the raspberry pi where you just plug in a SD card and turn a switch. But ultimately it will teach you more than the pi and with a little persistence it will also be a lot more "powerful" then the pi. Cheers, Ciprian
  15. Ok, so to recap... you tried to use 2 SPI controllers on 2 Pmod connectors and it did not work when you used them both in slave mode? As far as I understand you tried to use both the QSPI IP core and the PS SPI and that did not work either. You tried using only one controller and then changed the Pmod connector from the .xdc and it worked for all Pmod connectors, this means that the connectors are working and there is no problem with them. Please correct me where I'm wrong
  16. 1. It should work , I currently have ISE 14.7, VIvado 2014.3, VIvado 2014.4, VIvado 2015.1 and VIvado 2015.4 installed so Xilinx products will probably not cause any issues among themselves. The only issues which I have experienced so far from having so many versions of Vivado installed is a drastic lose of hard-disk space, every version is approx 20 GB and a problem with the environment variable, which is mostly used to determine the "default"(for a lack of a better word) version of Vivado you are currently using. 2. If you follow the tutorial from the zynqbook you aren't doing anything wrong. Most likely there is something wrong with your vivado installation, or the board package. This is also verified by the fact that the project from kypropex generates errors. 3. TCC0_WAVEx_OUT, SDIO_0, USBIND are ports of the zynq processor which maybe connected to the FPGA part of the zynq. They are set and configured inside the processing_system, because you are a novice at this I strongly recommend you ignore them for the time being, or else you might get into complications and loose sight of your current project. Try a clean reinstall, and then redo the project from zero. Best regards, Ciprian
  17. Hello Ag, I downloaded the "reference design" which was uploaded by kypropex. I took the board support files from the Digilent website ( and copied the zybo file in to D:\Xilinx\Vivado\2015.4\data\boards\board_files, this is because I installed Vivado on drive D:\. The validation of his design was success full and so was the bit generation. I retried this with the board files which you uploaded and I didn't get an error when validating project and generating the bit. Make sure that the board files are in the correct folder D:\Xilinx\Vivado\2015.4\data\boards\board_files\zybo\B.3. The good news is that as far as I can tell you are right, there is something wrong with the identification of the board files. Just to make sure that the board is functioning correctly; the SDK project from kypropex, has a valid bit file(which was probably exported by him), try to program that file along with the elf file in to the FPGA from SDK 2015.4. This is covered on page 32 of the zynqbook. Ciprian