Digilent Staff
  • Content Count

  • Joined

  • Last visited

  • Days Won


Ciprian last won the day on May 1

Ciprian had the most liked content!

About Ciprian

  • Rank
    Frequent Visitor

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ciprian

    Zybo z7 evaluation

    This is more of a FPGA size question then a board specific question. We have other boards with the same FPGA, Arty Z7 for example. As for your problem, you might be able to generate the required array, depending on the -20 or -10 variant of the Zybo Z7 and depending on the way you write the HDL code. The best I can recommend is build your project in Vivado for the Zybo Z7 and look at the resource consumption and limitations. -Ciprian
  2. Disclaimer: I considered this Thread closed before writing this post, since Dannny has gotten his answer. Normally I would not comment on this thread anymore because it seams to have concluded, but its so rare to find a naturally developing "philosophical" dilemma in engineering circles that it's hard not to comment on it. I'd also would like to point out that this might help @Dannny in his current and future projects. The way I see it, the dilemma is similar to building a carriage. Zygot and [email protected] are strong advocates of the build it yourself philosophy, this means build your own wheel, build your own axie, seats, shafts and everything. I'm more of the design you carriage based on the components you have at hand, go to the wheeler and buy a "standard" wheel, find a widely used axie, seats and shaft and then customize it using those components. Their way of doing things is arguably better then what I do, it forces you to learn as much as you can about all aspects or you project and because you have written it you are less depended on others with it and what is more important it is yours. It, unfortunately, is also very time consuming and if you don't adhere to a standard you will not be able to find help as easily, also, and this is the worst part, you are in charge of maintaining all the pieces of your project (updates, drivers, incompatibilities). This is where zygots diver comes in to play: The way I like to do it, is more "hacky". You are in charge mostly of finding the right components for your design and make them work together. You save time on building everything yourself... if you lock yourself in using a certain bus, like AXI or Wishbone, you might find that there are components available for it, which people are actively maintain and regularly update if needed. The main issue is that there is no guarantee, it might work it might not, bugs are out of your control, maintenance might stop at one point and stuff becomes out dated or obsolete. You will learn about your project but you will not know every little detail, aspect or snippet of code in your design which makes it a black box in certain respects. An example for this the Test Pattern Generator by Xilinx. Up to Vivado 2016 (I think, can't remember the exact version) it was free to use, afterward they just moved it to payed lic. and if you want to use it then you need to pay for it. A very important aspect here is also the licensing of the IPs, if you build it yourself you own it and you can do with it as you please, if you take somebody else's code you will need to take a close look at the licensing agreements to figure out you limitations. Specially if you want to manufacture stuff with it. Ultimately it comes down to time, resources, and support. You will need to chose which is more suitable for your project and what your end goal is. In my opinion, because @Dannny wants to use his design with linux as a final goal, he should try to stick to a proven concept which has support for linux as well before he goes down a path of frustration and hard work. Because the linux community is helpful but you need a lot of knowledge in linux to know how and where to ask for help. There are not many who do embedded linux on FPGA... -Ciprian
  3. Ciprian

    Zybo z7 evaluation

    Hi Pier, I'm a bit confused, where do the signals come from? Do you have two external sources or do you generate them in the FPGA? Similarly, do you want to a analog output of the resulting signal or do you only need the samples? -Ciprian
  4. I respectfully disagree. Firstly, it is very different to go from a HDL design to a fully functional Linux system. Mostly because by doing it this way you lock yourself in a path where you must create everything yourself, ultimately rewarding but highly time consuming. Then there is the fact that, given the final requirements, you want a solution which has Linux driver because writing a DMA or even worse a VDMA driver is a very, very big challenge. The solution to @Dannny problem is a VDMA which has the functionality to use multiple frame buffers in the DDR or other memory devices. Further more it has Linux drivers and Bare-metal drivers. If your final goal is Linux then this is the safest way to go... What you need is a VDMA, VTC, AXI4S_to _video_out pipeline on the output path and Test pattern generator, VDMA pipe on the input... The whole thing doable and ultimately scalable to Linux with some effort, but much easier the creating in HDL and then writing drivers for it. Although I don't have a full example for you I'm sure that you can figure it out if you focus on the VDMA and on the xilinx video solutions... For the output solution you can take a look at this, Zybo-Z7-10-base-linux.... it is for a Zynq and with HDMI, true, but the principle is still valid and ca be adapted for non-Zynq solutions. There should be some examples on how to do this on the Xilinx forums or application notes, they might even have example projects... At Digilent we had some for Zynq, but I can't currently find them anywhere publicly posted. This might also help: If you don't have 2017.4 I have attached the the Zybo-Z7-10-base-linux to this message. -Ciprian
  5. Hi @danny, Before I can answer your question I need to know if you are planning on using it in an embedded linux or not. The solution might vary depending on this. -Ciprian
  6. HI @Ryu, Unfortunately we are not familiar with building Xillinux-2.0 and therefor I can't really help you to the full extend of what you need, you might be right regarding the frequency, but not the right one. The input frequency is used for generating the internal frequencies of the PS which in turn generates the frequencies of the PL, the HDMI is handled in the PL which means that there might be some issues there. Either way there is a external clock on the board which provides the input frequency for the PS (schematic page 10) which is 33.333 MHz. You should not change the settings in the PS files which describe the input frequency because those are used to set the PLLs in the PS which generate all the other frequencies, basically if you change that one all of them change. The way you should go about this (if you really want to change the input frequency, although that's not the were your problem is) is by using Vivado to change it, within the PS configuration, which should automatically reconfigure all the clock at build. Regarding your actual issue, each Linux project has a underlying Vivado project which describes the HW used by Linux, you need to create that project for the Zybo Z7-10 first and then base you Xillinux-2.0 build on it.... Like I said we don't have experience with this, you will need to contact Xillinux for it. For the UART make sure that the right settings are used baud, parity, etc. -Ciprian
  7. Hi @Victor, @zygot is right, you need to pick and choose what you need to do and what your options are. Besides this he is also right when he says that there are different ways of implementing control in user space for IPs. I have suggested UIO because this is the way we do it, and as far as I've seen Xilinx has some examples with it as well. You will most probably not find anything more detailed, in one document, which will explain everything you need to know. You need to take in to account that petalinux is a tool which simplifies an embedded linux build process (which has a lot of different components: FSBL, u-boot, bit streams, device-tree, kernel, user space, etc.) but you still need to understand how they interact and what they are in order to configure it. Once you do your research and stuff clears up you will notice that embedded linux is a powerful tool which can, on the long run, simplify many complex designs which have complicated software stacks. As for the "ioctl" control of a device (similar to what you have used with PCI), the driver must be written in a way that the user space API can grant you ioctl access. Either way, there are some user space libraries that can help with GPIO, like libgpiod which can be added in the petalinux rootfs from the menu. Here is a link to the features: Good luck, -Ciprian
  8. Hi @Victor, Your question is more of a general Linux programming question than a particular Petalinux one. Like zygot mentioned, it's better to use the drivers when there are drivers to be used. If you have a custom IP or one that dose not have a driver, UIO is your friend. GPIOs are simple enough for them to have one and generally have it loaded (petalinux does that automatically when it finds a GPIO in the imported .hdf). Here is a simple example of how to write a C code using the driver and how it interconnects: -Ciprian
  9. Hi @ zygot We have taken your remarks in to advice and are slowly implementing the requested changes. We'll be adding detailed commentary for changes that make sens (IP changes, SW code changes, etc.) for minor changes such as documentation updates, code commentary fixes, etc. we probably will not. This won't happen all at once but measures are being set up to ensure an easier overview from git commits over the implemented project updates. Regarding testbenches. Its a very good idea and we have started work on some of them, we have not yet reached a final conclusion on how, what and in which form we will release them. Looking forward we might release testbenches for future IPs..... I can't make any official promises though. -Ciprian
  10. Hi @xyz, @den_ya, It's an interesting issue you are having and unfortunately there might be a series of reason for which this is happening. Lets start by first knowing exactly what you have. 1. Do you have the resource materials as well as the Workbook or only the Workbook? 2. What version of Vivado are you using? 3. In your final version of the project (with the HLS IP) do you have the control interface active (ap_ctl)? If yes then make sure that the ap_start and the rst_n pins are connected to a const 1 signal. Once I know these answers I can provide more help -Ciprian
  11. Actually, there is a way of recreating the Vivado project from which the .hdf is obtained. You can do this by using the digilent-vivado-scripts inside the Eclypse-Z7-HW repo. This approach requires you to have the Eclypse Z7 board file, otherwise it will fail. You can use it with both python and from within Vivado... the inside will provide all the information you need. -Ciprian
  12. @zygot Than you for pointing out this issue, there seams to be something we missed either in the git repo or failed to mention in our documentation. In order for easier version control for Xilinx IPs and to simplify some of our more complex IP system, the Zmod IPs are an example for this, we have been using the vivado-hierarchies which work with our IP repo and the Vivado IPs. If you use it to import any Zmod into you block design in Vivado it will create the same hierarchical block as in the example project. For more details on how to use it please visit here. Unfortunately the nature of the Zmod connector does not allow us to create a board-flow for it; this means that you will have to connect the external ports to the xdc manually. We will try correcting this issue as soon as possible and probably have a new release tag for the Eclypse-Z7-HW repo. The fact that it did not work for you on Windows and that "the documentation on setting up zmod library builds is not quite correct in a number of places for either OS host" is troublesome. Could you please send me the changes that you have made so that we can look in to it and correct the potential issues? Thanks, -Ciprian
  13. Hi @zygot, Thank you for your mostly positive feedback, its nice to see that one of or most active forum members likes the product. While true that we have focused our documentation and subsequently our attention towards the Linux aspect of the project, we have not neglected the desire (or potential desire) of our customers to do just use bare-metal applications and use the 'normal ' Xilinx flow. We tried to keep it as backwards compatible as possible, regarding our usual way of providing demos, while adding a new infrastructure for an OS application. In this sens we had to create the more or less complex zmodlib, which provides access to our Zmods from both the on board Linux environment as well as the opportunity to use them in bare-metal. If you open the SDK workspace which we provide, either trough the Eclypse-Z7 repo or the direct link of the Eclypse-Z7-SW repo, you will notice that there are projects in the workspace which are meant for bare-metal use. These showcase the same functionality as their Linux project counterpart and are basically the classic approach to doing our demos. There were debates on how to provide the demos for this board in Linux, while some suggested just providing the .elf others suggested the source code with a make file in the rootfs. We settled on this approch using Xilinx SDK because it provides both the source code, the cross-compiler as well as a GUI for debugging the applications. Linux offers a big variety of ways in which applications can be debugged, compiled and run; our solution is not the most straight forward but it offers the benefit of having a familiar environment to develop a Linux application using the Eclypse Z7 and Zmods. It is possible to use Xilinx SDK on Windows to build and debug applications for the onboard Linux. As an alternative, if you just want to run the applications you can always build them on you PC and copy the .elf on to the onboard Linux and run it there. For petalinux development, which requires Linux use, I personally recommend using a Linux OS rather then a virtual machine as it will take longer to build on a virtual machine. Like I mentioned before, although a Linux OS /virtual machine with Vivado 2019.1 is easier to use for Linux application development with the Eclypse Z7 and Zmods, it is not mandatory. The Xilinx SDK should work for Linux application development on both Windows and on Linux. At the end of the day, this was a pretty exciting project for us to work on and we were focused on showcasing the new aspects of it while also providing our classic way of doing things... we just didn't explicitly document the former. Thank you again for the positive assessment, -Ciprian
  14. Hi @cwerner77, I tried to reproduce the problem but unfortunately I could not. You are right though in your assumption, it most likely is a DMA related problem, it expects to receive a certain amount of samples and if the stream is interrupted for some reasons it will stop. If you can record the first time and play back as well then it's most likely not an Audio codec issue. The most likely problem is that the DMA is either in an error state or the IP is no responding to the DMA request. There is a bug in the Demo that if you reprogram the FPGA without resting the board the DMA will hang. Either way I would recommend trying to reset the DMA controller before every playback or record. This would narrow down the search for why it does not work. This can be done with the XAxiDma_Reset() function. I'm also assuming at this point that you did not change anything in the Vivado project or the SDK sources. If you did please let me know, it is unlikely but it might effect the demo. - Ciprian
  15. Hi @youngpark, Well I don't know for sure why its not working for you but I would recommend a different approach. The most important thing for you is to make sure that the clock gets propagated throug the design using the clock path and this is done using an ODDR primitive. Therefore I suggest using this aproch: The clock forwarder can be found on our github in the vivado-library. You will also have to constrain it. For this please take a look in the ug903 provided by Xilinx specifically starting page 31. Good Luck -Ciprian