Ciprian

Digilent Staff
  • Content Count

    73
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by Ciprian


  1. 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


  2. 17 hours ago, zygot said:

    [...]You can certainly implement the simple concept as outlined in your diagram using only HDL. 

    Let's hold off on the final goal for now. It's not only OK, but a really good idea to run through a number of smaller design projects that can then be used to implement a grand idea. [...]

    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: http://web-pcm.cnfm.fr/zybo-video-workshop-materials/

    If you don't have 2017.4 I have attached the the Zybo-Z7-10-base-linux to this message. 

    -Ciprian

    Zybo-Z7-10-base-linux.zip


  3. 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


  4. 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. 

    4 hours ago, Victor said:

    Excuse me for the extra questions.
    I searched the step by step instruction how to use HW in Petalinux.
    Now I have lot of difficulties in this way because I have not enought skills in the embedded SW.

    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:

    https://kernel.googlesource.com/pub/scm/libs/libgpiod/libgpiod/+/v0.2.x/README.md

    Good luck,

    -Ciprian


  5. 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:

    https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842398/Linux+GPIO+Driver

    -Ciprian


  6. 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


  7. 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


  8. 12 minutes ago, zygot said:

    Well, that and the fact that you provide no means to re-created the SW bitstream and associated export files that go with the SW demo code.

    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 README.md inside will provide all the information you need.

    -Ciprian


  9. On 2/13/2020 at 3:53 PM, zygot said:

    @Ciprian,

    Yes, I do like the product and think that it represents a positive expansion of your offerings that covers the needs of a larger audience.

    At the moment my frustration is not being able to use your zmod IP to create my own custom hardware bitstream. Your latest vivado-library provides the controller IP for both but no connection to zmod ports. If there's full support for the normal board design flow I'm not finding it. 

    @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.

     

    20 hours ago, zygot said:

    This statement might be true but I haven't been able to accomplish it. You might not realize that the SDK behaves differently on Windows than it does in Linux.

    For WIN10 SDK I have not been able to get the SDK to link to the SYSROOT file system, which I believe is the reason why I couldn't create a Linux project build for either ZMOD demo. It took some doing but I did managed to do this running the SDK in Linux. The documentation on setting up zmod library builds is not quite correct in a number of places for either OS host.

    I was able to connect the SDK to the Eclypse Z7 Ethernet port for debugging on both OSes.

    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


  10. 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


  11. 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


  12. 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:1234554836_Screenshotfrom2019-11-2916-07-34.thumb.png.38aedf6cb88701d167cc79291602ba1b.png

    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


  13. Hi @V94,

    I'm unsure how you have manged to get a bit stream with the MIPI_CSI_2 IP core force upgrade. The core needs to be updated to the 2019.1 by us first; there are some primitives which have changed. This means that it should fail at synthesis in 2019.1.

    Unfortunately I cannot give you an estimate when we will be able to update it to the latest version.

    -Ciprian


  14. As far as I can tell from your code, you are continuously reinitialize and reconfigure the XSysMon (the XADC driver). During this process, which is redundant, you are loosing a lot of samples.

    Try this instead:

    #include <stdio.h>
    #include "xparameters.h"
    #include "platform.h"
    #include "xsysmon.h"
    #include "xil_printf.h"
    #include "xstatus.h"
    #include "xuartlite.h"
    
    
    #define UARTLITE_DEVICE_ID    XPAR_UARTLITE_0_DEVICE_ID
    #define SYSMON_DEVICE_ID     XPAR_SYSMON_0_DEVICE_ID
    #define UART_BUFFER_SIZE 16
    
    #define NUMBER_OF_SAMPLES 4500
    
    int main()
    {
        static XSysMon SysMonInst;      /* System Monitor driver instance */
        unsigned int ReceivedCount = 0;
        unsigned char RecvBuffer[UART_BUFFER_SIZE];
        XUartLite UartLite;
    
        unsigned int channel = 3;
    
        int Status;
        XSysMon_Config *ConfigPtr;
        XSysMon *SysMonInstPtr = &SysMonInst;
        int *sample;
    
        //External memory address to store samples
        sample=(int *)0x60000000;
    
        init_platform();
    
        Status = XUartLite_Initialize(&UartLite, UARTLITE_DEVICE_ID);
    
        ReceivedCount = 0;
        while(ReceivedCount==0){
            ReceivedCount = XUartLite_Recv(&UartLite, (unsigned char *) RecvBuffer, 1);
        }
    
        ConfigPtr = XSysMon_LookupConfig(SYSMON_DEVICE_ID);
        if (ConfigPtr == NULL) {
            return XST_FAILURE;
        }
    
        XSysMon_CfgInitialize(SysMonInstPtr, ConfigPtr, ConfigPtr->BaseAddress);
    
        XSysMon_SetAvg(SysMonInstPtr, XSM_AVG_0_SAMPLES);
    
    
        XSysMon_SetAdcClkDivisor(SysMonInstPtr, 39);
    
        XSysMon_SetSequencerMode(SysMonInstPtr, XSM_SEQ_MODE_SINGCHAN);
    
        XSysMon_SetCalibEnables(SysMonInstPtr,
                    XSM_CFR1_CAL_PS_GAIN_OFFSET_MASK |
                    XSM_CFR1_CAL_ADC_GAIN_OFFSET_MASK);
    
        Status=  XSysMon_SetSingleChParams(SysMonInstPtr, XSM_CH_AUX_MIN+channel,
                                FALSE, FALSE, TRUE);
    
        if(Status != XST_SUCCESS) {
            return XST_FAILURE;
        }
    
        /*
         * Disable all the alarms in the Configuration Register 1.
         */
        XSysMon_SetAlarmEnables(SysMonInstPtr, 0x0);
    
        while(1){
    
    
            /*
             * Wait till the End of conversion
             */
            //print("Capturing\n\r");
            for(int i=0;i<NUMBER_OF_SAMPLES;i++){
                XSysMon_GetStatus(SysMonInstPtr); /* Clear the old status */
                while ((XSysMon_GetStatus(SysMonInstPtr) & XSM_SR_EOC_MASK) !=
                    XSM_SR_EOC_MASK);
    
                //Four last bits are noise
                *(sample+i) = XSysMon_GetAdcData(SysMonInstPtr, XSM_CH_AUX_MIN+channel);
    
            }
            //print("Finish capture\n\r");
    
            //xil_printf("samples=np.array([");
            for(int i=0;i<NUMBER_OF_SAMPLES-1;i++){
                xil_printf("%d,",*(sample+i));
            }
            xil_printf("%d\r\n",*(sample+NUMBER_OF_SAMPLES-1));
    
            xil_printf("end\n");
    
        }
    
        cleanup_platform();
        return 0;
    }

     


  15. @HeroGian

    Your question is somewhat tricky. It is doable on an ARM but as far as I can gather it's not dynamic, you either start without caches and then everything moves slower or you continue using caches. The dynamical approach is somewhat tricky  because you risk freezing your OS. I you want to try that you can find more info here:

    https://forums.xilinx.com/t5/Embedded-Linux/how-disable-cache-in-Linux/td-p/740556

    There might be a better way to do it. What you actually want is just a hardware accelerated memcpy in the DDR, you could try to handle this like an DMA transfer in to DDR from the PL and use a coherency function for it. These are kernel space specific functions so I guess you will have to wirte a kernel driver for it. I strongly suggest reading about continuous memory (CMA) and coherent data transfers + the ACP port of the Zynq before proceeding. Here is a link which might give you an insight in to what and why I suggest this.

    https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Cache-Flushing/td-p/635653

    https://forums.xilinx.com/t5/Embedded-Processor-System-Design/XC7Z010-can-I-automatically-invalidate-cache-with-my-PL-to-DDR/td-p/715220

    Although you are using a Zynq, there might be some useful information in the ZynqMP wiki by xilinx about what you need.

    https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842098/Zynq+UltraScale+MPSoC+Cache+Coherency

    Sorry for not being able to give you a more coherent and straight forward answer, what you are attempting is tricky.

    Good Luck,

    -Ciprian


  16. Hi @Sduru,

    These are BSP errors you will have to regenerate the bsp. Just right click on it in the project explorer (on the left of the main SDK windows) and hit Re-generate BSP sources. These are common xilinx SDK errors, not specific to this project.

    -Ciprian


  17. Hi @daeroro,

    #define SPI_DEV    "/dev/spidev32766.0" 

    Judging by the .dtsi this should be something else... probably something like spidev1.0. You will need to change to the right device name. To determine which is the right name please run

    ls /dev/ | grep spi

    on the running petalinux target.

    -Ciprian


  18. Hi @Sduru,

    In order to see data transfers on the AXI-Stream interface which is connected to the PCAM you will need to configure the PCAM and enable the DMA transfers to do so. This is accomplished using the SDK, therefor you will need to program and monitor the ILA as well as run the SDK program to see any changes on the ILA. I'm guessing that you have a problem with running the code which would explain why you don't see the menu on the console  or any traffic on the ILA.

    I'm guessing that your terminal is set up properly (although using COM1 is unusual), because you mentioned that you ran a hello world project and it displayed the message on the terminal, which leaves us with the possibility that you either have an error running the code  in SDK or that there is a bug which does not allow you to get to the menu part of the PCAM code.

    To test this please put a xil_printf("hello world\n"); at the beginning of the main function and check if it is displayed.

    -Ciprian


  19. Hi @ahmedengr.bilal,

    Like I mentioned in the previous post there is no HDMI output from the Linux side, neither the embedded rootFS provided by petalinux nor the kernel configuration we give out is set to accommodate this feature.

    Regarding the missing media-ctl and v4l2-ctl, you have not activated the v4l-utils in the rootfs configuration of the petalinux. to do this you need to navigate to your petalinux project folder and run:

    petalinux-config -c rootfs

    Once the menu appears you need to go to Filesystem Packages->misc->v4l-utils and activate: v4l-utils, libv4l, media-ctl. Rebuild the whole project and it should be working now.

    -Ciprian