ArKay99

Members
  • Content Count

    22
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by ArKay99

  1. Not trying to get in the way of jpeyron's help, as I"m a rank newb here and not trying to step on any toes, I've seen this error before, and I would wait until this can be confirmed as the source and/or a possible solution put forward. Are you running this on Ubuntu? It seems make is trying to find a 32 bit tool and/or libs that haven't been installed according to what I've seen. This is from an old thread... https://www.microlab.ti.bfh.ch/wiki/huce:microlab:tools:linux-client:xilinx-vivado arm-xilinx-eabi-gcc The SDK is shipped with a 32bit compiler so you may need to install 32bit support. Unfortunately, the error in such a case is not very helpful in diagnosing the problem: /opt/Xilinx/SDK/2015.3/gnu/arm/lin??/bin/arm-xilinx-eabi-gcc: No such file or directory On older systems, the solution would be: apt-get install ia32-libs On newer systems, ia32-libs has been made obsolete. You should instead install: apt-get install lib32z1 lib32ncurses5
  2. I looked at the project referenced, but couldn't get into it at this time. However, there were a few things that were misleading, at least to me. Specifically, it appears that in step 11, the author has the reader generate a new BSP for standalone, however, all the subsequent references are for FreeRTOS. The illustrations show standalone and no FreeRTOS is shown. This would have lead me to try and make the BSP using standalone parameters even though it was named RTOSDemo_bsp. It also seems that is what happened to you as the SDK is complaining about something not being available for make to include (I can't see the rest of the path). Have you tried making the new BSP with FreeRTOS selected? Sorry if you've already done this, or I misunderstood what is being attempted.
  3. Thanks for the update. Since I've been working with the rgb2dvi component I was intrigued. I vote for door number 3.
  4. ArKay99

    DDR issues on Zybo-Z7-20

    Hi BogdanVanca, Thanks for the info as I assumed that what those values were for. I was looking for a 'sanity check' because warnings are warnings and I at least like to understand why. Also, the DDR on my board being intermittent and not knowing why was becoming frustrating to say the least. Here is what I did to arrive at my new set of values which seem to have fixed my issue. All this assumes that the preset.xml file is from a Zybo Z7 Rev B board. I have no way of determining the trace lengths without gerbers, and even then I don't have the tools to get a measurement that precise. I would assume those values would have to come from the pcb designer... Since I had the manual for the Zentel chips at hand, under DDR Controller Configuration I left Memory Type at DDR 3 (Low Voltage) Memory Part set to Custom No other changes here. Under Memory Part Configuration: Changed Speed Bin to DDR3 1600K CAS Write Latency (cycles) to 6.000000 tRC to 48.75 tRAS to 35.0 tFAW to 40.0 Those were the 'small changes' I made. I then set the DSQ0-DSQ3 values to 0.0 and the DQ[0] to DQ[3] at 0.25 and things started working again. However, I was puzzled as to how the values that were so far off got into the DQS and DQ fields. So I did a few searches and came upon this thread: https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Package-pin-delay-considerations-for-Zynq-PS-DDR3-PCB-routing/td-p/495444 . I thought I was on to something and then upon generating the pin delay values and the package die pin values, as referenced in that thread, I started calculating the values. When I did the averages of those values, to my surprise I got the exact same values as were in the preset.xml file. Afterwards I also found those values in the I/O Planning Layout spreadsheet. So, after reading through that thread and the other linked thread, and putting it all together, it looks like that warning is suspect. The calculator gives as the CLK0-CLKS3 lengths is 18.8mm and the lengths of the DQS0-DQS3 values vary from 22.9 to 29.7. When the clock path delay is subtracted from the Data Strobe delay if the clock path is shorter than the data strobe path, you will get negative numbers. This seems like an entirely possible scenario, and one that works when the negative values are used. One last point and one that sort of answers my question of how those numbers got entered that stalled my DDR. Yesterday as I said, I entered the delay values into the appropriate fields based on the reports and averaged the delays to end up with the numbers in the preset.xml file. Then I closed the DDR configuration window and went about the other work on SDK side of things. This morning I opened up the DDR Configuration window to find the values had changed. When I opened up the calculated windows to reveal the delay calculator all the path delays were what I had entered, the same as preset.xml and the lengths I had entered were 0. When the values were then 'calculated', the resultant DQS to CLK Delay was different. I even had a positive vale for the DQS1 DQS to CLK Delay. I checked the preset.xml file and those values were untouched. So there is one possible reason for the delay values becoming 'out of bounds'...a bug? So, all of the above has given me a bit of enlightenment on the workings of the DDR controller, it's parameters, the version of memory I have, and a lot of the surrounding factors.
  5. Good news. I am curious as to how you resolved the issue.
  6. ArKay99

    DDR issues on Zybo-Z7-20

    A follow up on this. I queried on this at Xilinx forums and got many hits relating to this as far back as 2016.1. After reading quite a few threads and responses, it appears that the negative values seem to be a default value that gets installed in the presets.xml file. A few remedies suggested were to leave them alone they will be ok, even though they may trigger warnings, to editing the values in the presets.xml to positive values. A Xilinx employee suggested to edit the file to have 0.001 in all the fields and make sure Write leveling, Read gate, and Read data eye are checked. There are other things that I did according to the preset.xml file and would be glad to share them if anyone is interested.
  7. ArKay99

    DDR issues on Zybo-Z7-20

    I've been working with my Zybo-Z7-20 board for about 6 weeks now and have been having a hard time with anything having to do with the DDR. If I built and run the OOB demo using Vivado 2016.4 It ran, sort of. I would sometimes get could not write to memory 0x0010000 errors when trying to load a new change into the memory. When I tried to run the demo in Vivado 2018.2, it would give the same message, but none of my breakpoints would get hit and the program in flash would only run. If I set the linker file to run from OCM it would run, but not that well. I built the Hello World example and it ran fine. I then set the Hello World example to run from OCM and did some read write tests to DDR and they worked. Then I built and ran the memory test example and tested the DDR and it ran fine. Then I put the memory test code into the OOB demo main program, set it to run from OCM and it failed to read or write to memory. Then I started looking at physical memory. On my board (I have a B2 version) there are mounted 2 Zentel A3T4GF40ABF chips. I downloaded the manual and found a few things about them. They are DDR3L @ 1600K. The schematic shows a MT41K256M16HA-125 which is a DDR3L @1066F. The other parameters are fairly close and in the Zentel part manual it states the part can be used as a 1066 speed bin part. I thought I had found the answer to my stalled DDR, but entering a few of the parameters that were slightly different in the Zynq IP setup page didn't help. Today I gave up on trying to make the 2016.4 demo work in 2018.2 and decided to work with and build the Audio DMA example. After I got it dl'd and installed I opened up Vivado and got eight critical warnings about entering negative values into the DQS clock delay could make the DDR fail. Upon loading up the block diagram I opened the Zynq customizing dialog and found these values in the DQS to clock delay fields: DQS0: -0.050, DQS1: -0.044, DQS2: -0.035, DQS4: -0.100 , and in the board delay fields I found these values, DQ[7:0]: 0.221, DQ[15:8] 0.222, DQ[23:16] 0.217, DQ[31: 24] 0.244 Then I opened my OOB project that doesn't work and looked at the same DQS clock delay values and found: DQS0: 0.217, DQS1: 0.133, DQS2: 0.089, DQS3: 0.248 and the board delay values were DQ[7:0]: 0.537, DQ[15:8] 0.442, DQ[23:16] 0.464, DQ[31: 24] 0.521 Then I opened my Hello World project that does work and found these values: DQS0: 0.0, DQS1: 0.0, DQS2: 0.0, DQS4: 0.0 , and in the board delay fields I found these values, DQ[7:0]: 0.25, DQ[15:8] 0.25, DQ[23:16] 0.25, DQ[31: 24] 0.25 I then installed these values into the OOB project and it worked...i.e. the SDK hit my breakpoints, variable values were shown and registers were getting filled, etc. and I could step through the code. Also any changes I made were shown. The values for the Audio DMA project were in the …\board_files\zybo-z7-20\A.0\preset.xml file. They are also the values that show when I select Calculated in the dropdown. I don't know where the other project's values came from. All the preset.xml files I searched and obtained had the same values as the Audio DMA project. So having learned all about the above, I have these questions. Since the DDR chip I have on my board is different than the B.2 schematic, and different than in the DDR config page, could I be provided the 'correct' values? I did find the procedure on training DRAM in theZynq-7000-TRM.pdf, and the DRAM Training/Board Details are checked. So I could give that a try. If you've gotten this far, thanks for your interest, and any help and guidance is greatly appreciated.
  8. I looked at your constraints file and one thing puzzles me. You've constrained the clock to be a higher frequency than the 'standard' clock frequency in the file. In the dvi2rgb documentation there is this info on the TMDS clock constraint: The TMDS clock input Clk_p/n is constrained in the IP to the maximum DVI clock frequency, 165 MHz. On some architectures this might result in timing impossible to meet. Depending on the application, if a lower pixel clock frequency is acceptable, the clock can be constrained on top-level, which will override the IP-internal constraints. For example, to constrain the design for 720p resolution (74.25 MHz), calculate the clock period (13.468 ns), and add the following to a project XDC file to constrain the clock on the top-level input port: I've just been experimenting with the Vivado TPG and found that if I didn't use that frequency in concert with the rgb2dvi component things didn't work.
  9. Thanks so much. That was painless. 😉
  10. Thanks for the info. CPU from the overview is: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz 4.00 GHz 16 gig 1866 ram System type: 64-bit Operating System, x64-based processor. OS is Windows 10 Pro 64 bit. I'm thinking that even though I'm running a 64 bit processor and 64 bit Windows I should dl the 32-bit PC (i386) desktop image, specifically the: ubuntu-16.04.3-desktop-i386.iso? Thanks for the start procedure for the vm, no need to outline the steps.
  11. I'm a newb with Linux or Ubuntu, but want to install the version I need to get Linux working on my Zybo Z7 with the project. Been to the Ubuntu forum, signed up and asked the question and got several answers that didn't seem quite right about the version of both the OS, the LTS vs GA and the kernel, where they exist, etc. I've got a clean Win 10 machine and going to put VMWare on it and run Ubuntu on it, but it's clear as mud how I go about getting and installing 16.04.3. OR do I need that as the minimum and can install the most current version.. 18.xx something? What have the developers here done to get the platform needed to build the demo?
  12. As I said, I haven't done this project yet and it's possible that the SDK isn't used as the Zynq can be programmed and run with just the PL. However, when I looked at the project description I saw this... This says to me that the hardware has already been built in Vivado and the next step is to work with the SDK, by either importing the hardware handoff or generate the bitstream in Vivado, export the hardware, and include the bitstream in the export, which will create the hardware handoff, then launch the SDK from the menu in Vivado. So, if you've already done the Vivado update part as outlined by jpeyron, then I would incorporate what he's suggested to update the SDK portion of the project. I'm still new to the Xilinx tools, but I would do it the latter way, genetate a bitstream in Vivado before launching the SDK, export the hardware (including the bitstream), then launching the SDK from within Vivado. Once I get the project up and running that's when I go back and start changing, adding or subtracting things and see what my changes do while learning the system. The SDK is sensitive to changes in the hardware and will add or subtract and recompile what it needs to keep the software up to date with the hardware.
  13. According to the response by jpeyron: I haven't done this project, but went through upgrading the Out Of The Box demo from my Zybo Z7 020 board from 2016.4 to 2018.2, which has a playback version of the DMA for audio. I have completed that and have it working and learned a lot. But I installed and worked with the 2016.4 version of the tools so I could build and run the project, then peruse the code. I am about to get into this project myself, so I'm interested in your results. Did you do what was suggested? 1: The version IS important. if you are using a new version of the tools (2018.2 vs 2016.4) you have to tell the tcl what version you are running, I believe it's because the IP's are versioned. So, I would make the edit as outlined, then load the project, upgrade the ip cores. Then I would do the next steps, create wrapper and generate the bitstream. 2: There is a software component that has to be tied to the hardware component and that has to be done through the SDK. I believe the software component has to be upgraded through a new hw_handoff component (generated by exporting hardware with bitstream), then importing the correct projects in the SDK, and then creating a new board support package which will create a new fsbl project (IIRC). Then you can program the Zync, once you've set up the SDK project properly. Lastly, if you don't want to go through all of that, I didn't for the demo project as it was too much for a newb just starting out with the tools, I went to Xilinx and downloaded Vivado 2016.4 and checked the SDK, so I didn't have to do a separate dl for that too. You can have multiple versions of the tools on the machine at once. This way you won't have to go through the extra layer of determining what is different between the two versions and determine the cause and subsequent resolution just to get to a working project.
  14. Well, I applied for the ticket and was 'approved' at the Xilinx Service Portal, but upon entering it, I have no way to enter a ticket and am left with the only choices of the Forums, the FAQ's, or the Knowledge Base, of which I spent almost 2 days perusing and searching and have come up empty. I suppose because I don't have a corporate email account, and a third party product, they're not interested. At this point, I'm not sure what to do. I'm also glad that I didn't pay the $595 for a node locked SDoC license! I have also exhausted the threads relating to Eclipse and their memory problems, and it appears this has been and is a known issue for Eclipse. Here is what I've done so far... According to some of the threads relating to this, the java vm sets up memory allocation limits using the eclipse.ini file, and suggests upping those limits. I have done so to no avail. At this point I'm going to have to roll back to SDoC 2018.1 and perhaps skip over 2018.2. However, unless the 2018.1 xfopenCV issue has been fixed. I'm left with a broken product at this point. IMHO, for a product (SDoC) that claimed as it's #1 selling point is usability, Xilinx has failed miserably. It's hard enough to learn a new platform, complex software and hardware, but when the tools don't work it makes it impossible. I still have Vivado and the SDK and will move forward with those tools. Not ranting, just frustrated and disappointed...
  15. Thanks for the input Jon. In addition to starting the ticket with Xilinx I started a search on eclipse not responding and got lots of hits. I'm sorting through that now. And a awaiting a reply from Xilinx support. I will apprise as to the outcome. From the eclipse threads it might be as simple as having the correct version of java installed.
  16. I think you mean the .pfm file referenced in the custom platform generation tutorial video? The ones from Xilinx are at Xilinx\SDx\2018.2\platforms. However, I too would like to know where the Digilent ones are that are referred to in the video at 1:11 here https://www.xilinx.com/video/soc/sdsoc-custom-platform-generation.html I also, have not been able to find them...they may not exist which would mean they have to be created from scratch as a custom platform.
  17. First of all, I'm not sure if this is the right forum for this, as this is a question about tool installation and usage. If it is in the wrong place perhaps a mod can move this or provide a suggestion as to the right place to ask this. I had SDoC 2018.1 installed along with Vivado and Vivado HLS and subsequently installed 2016.4 Vivado, SDK, and Vivado HLS to work with the OOB project for my Digilent board. I got that working and was able to go through much of the project all the way to debug and program and verify with the SDK and the contained C code. A few days later I wanted to start utilizing some of the example projects and the xfopencv libs, but was unable to download them. I saw that SDoC 2081.2 was released, so I downloaded and installed that and upon starting SDoC I started having the problem. It appears that when changing focus between the different container objects in the gui that the ui becomes unresponsive for about 20 seconds with the spinning blue circle. Then it will get focus and I can nav around in the container, but after I close it and try to select a menu item or a tab in another container, the ui can't get focus for another 20 seconds. This is really frustrating as it makes even setting up the environment futile. I then fully uninstalled SDoC 2018.2 and re-installed it with a fresh download but got the same issue. Keep in mind that 2018.1 worked just fine. I then did a full uninstall of 2018.1 and 2018.2, then another fresh download and install of 2018.2 with no 2018.1 on the computer. I still observe the same behavior. I should mention that Vivado 2018.2 and the SDK being launched from the Vivado menu seems to work just fine. After a few days of looking around for an answer to this, I've come up short so I'm asking for advice and or help here. I applied for a ticket at the Xilinx Service Portal, but it may take a few days to get through the noise there with no guarantee I will get help due to my non-corporate email address, although I do have an SDoC license. I'm also thinking that if it's a problem with the SDoC ui interacting poorly with eclipse that may be another issue. I have inspected my environment variables, license location, and viability and SDoC does report the license is available in the console when I start it...although sometimes it takes a while to establish that. My internet connection is solid and fast with 100 mbps up and down.
  18. Thank you for verifying the project creation script. Yes, I had done what you did. I also ran it without the "./" prepended and got the same results. However, what I did notice was your path to the .tcl file and mine were different in that none of your directories had a space in the name. I had my projects in a folder named Xilinx Projects. I could cd to it using the old DOS trick of putting quotes around the path. Apparently tcl has problems internally when operating on folders with a space in the name. I admitted I am a newb. I made a new directory without a space, extracted the zip to that folder, opened Vivado 2016.4, cd'ed to the project directory and ran the script with the ./ . Now I have a working project to explore. I can't thank you enough. Yes, I have the ZYBO Z7-20. I will look into those threads.
  19. Thank you JColvin. I wasn't expecting a response on father's day, so double thanks. An FYI, I hooked up an HDMI monitor and there is a test pattern being tx. I haven't checked the rx. I'll wait for your response tomorrow. In the meantime I'm going to see how to download the bitstream from the Zybo to a file on my computer, just so I at least have that.
  20. I just purchased a ZYNQ-7020 Development board for my development and learning purposes. Just out of the box, it's pretty amazing and I'm anxious to dive in and start kicking the tires...so here's my question and resulting dilemma. I found what appears to be the code at the bottom of the product page. I downloaded and installed it and upon reading the readme discovered that it will only work with Vivado 2016.4. So, I downloaded and installed 2016.4 from the archives, after I discovered that Vivado can have multiple versions coexist on the same machine (thank you Xilinx). After the install I launched Vivado 2016.4 and took the actions stated in the readme and invoked the create_project.tcl script. It ran for a while and near the end it failed with a few critical errors stating there were a few components that could not be found. I did install the ip and if folders in the vivado-library folder in the common-repo folder (they were in the local folder adjacent to the vivado-library folder which was empty). Upon opening the project I am presented with an incomplete design, with just some connectors and a button and the audio (I guess the I2S) components with no routing. I spent the better part of yesterday attempting to fill in the missing pieces but was unsuccessful, mostly due to the fact that I'm a newb with Vivado, the ZYNQ FPGA and the 7020 dev board. In the readme it states that it is provided 'as is' and no further development to newer version of the board will be maintained. This is disappointing for a few reasons, the main one being I have no starting point to peruse the functionality of the board in general with associated working code. By playing around with the board I found in addition to the leds putting on a light show, there is audio out of the headphone jack and the buttons and switches have other functionality. From the OOB code I can see references to the HDMI and DVI, although I haven't hooked up a monitor to it to see if there is anything actually happening there. Another reason is in case I brick the board, which I'm bound to do at least at first, I will have a known working set of modules to reload to get back to 'square one'. Lastly, having working code and playing around with it is the best way, for me, to learn about a system. Does anyone know of any other course to obtain the OOB code?
  21. I answered my own question. I went to the link and downloaded the installer for SDx and installed that, which gave me Vivado, Vivado HLS, and DocNav, all in the 2018.1 format. Then it was a simple matter to license the installation and I was up and running in a few minutes...after a lengthy download. My next challenge was to find the code for the OOB demo that the ZYNQ -7020 ships with. I found that at the bottom of the ZYBO Z7 product page. I downloaded that and opened the readme to find out it would only work with 2016.4. i created a new thread to address that.
  22. Hello all. I have been programming in C/C++ for almost 30 years and before that in assembler and BASIC on an Apple 2...yes, a long time ago! I've also had several years experience doing embedded design with Atmel products and PCB design. I have been learning Verilog and VHDL for the last couple of years and about 6 months ago bought a Lattice MachXo2 Breakout board and a few different Codec boards aimed at audio encoding/decoding. I've also done a bunch of work with the Mico8 and it's environment and integration. My short term goal is to learn about digital filtering as applied to accelerated functions in FPGA fabric and coefficient generation. I just purchased a ZYBO Z7 with a 7020 with the I2S PMod and the SDSoC-Zynq Development voucher. As such I'm also looking forward to learning about machine vision and other video related technologies. I went to the link at Xilinx to dl the tools and At the top of the release notes for SDSoC 2018.1 There was this information: SDSoC™ and SDAccel™ are now fully integrated with Vivado® Design Suite, no longer requiring a separate Vivado Design Suite image. Then, further down the notes is this: Note: There is no separate Vivado® version of the installation, only "stand alone" and SDx installationsĺ Any difference in the installation happens if you use a different xsetup installer, that is the one from SDx™ or the one from Vivado. Running the SDx xsetup installer would get you the same Vivado as the 2017.4 Vivado xsetup installer, and offers the same options as the Vivado System Edition installation. The SDx xsetup installer is a super-set of the Vivado SE version. So, I'm inferring from all the release note information is that I should not download and install Vivado 2018.1 webpack edition, but the SDSoc 2018.1 version and that will have everything I need to get up and running? Sorry for the 'long winded' question... I just don't want to do this incorrectly, and have to do it over again due to the length of the install process. One last question...Is there a difference between the 'standard' SDSoC Environment and reVision? Is it just a different set of libraries? Thank you in advance for any help in getting me up and running th right way on this platform.