Leaderboard


Popular Content

Showing content with the highest reputation on 02/07/19 in all areas

  1. 2 points
    You are not wrong - but for that device ID the tooling will not let you use all the LUTs present on the silicon die. It is a somewhat artificial restriction, and might have some implications for the power and thermal properties of the package (e.g. a smaller package may not be able to dissipate the heat).
  2. 1 point
    Hi @bklopp, Here is a completed Nexys Video UART interrupt project in Vivado 2018.2 that uses interrupts in microblaze. thank you, Jon
  3. 1 point
    Hi @bklopp, Here is a forum thread that has a completed project that uses interrupts in microblaze. thank you, Jon
  4. 1 point
    For anyone else having a similar problem I found a workaround, though it's a little strange. Install the glibc 2.14 library in parallel in an alternate location. I put mine in a folder in the root directory. The libdwf.x.x.x binary does not look for the glibc-2.12 library directly. It looks for a symbolic link file named libc.so.6 in directory /lib64. That file redirects libdwf.x.x.x to the glibc library. Now if you modify libc.so.6 to point to the new glibc library, you will have major problems because many systems in the computer rely on the current installed version 2.12 (I got a kernel panic and had to use a recovery disk to revert my changes...). Instead of modifying glibc.so.6, make a new symbolic link file in the same location that points to the new library. I named mine "glibc.so.7". But libdwf.x.x.x will still look for libc.so.6 instead of the new file so you have to open it in a hex editor and modify it. All I had to do was Ctrl-f for "libc.so.6" and change the 6 to a 7. After all that it works! I think you could also modify a binary in the same way to get the waveform GUI application to work. Try running if from terminal and look at the errors to find whatever file is looking for the glibc library and modify it to look for libc.so.7 instead of libc.so.6. I havn't gotten around to it though since I just need to run python scripts.
  5. 1 point
    Hi @srce, I have attached the bin file for the Genesys 2 OOB Demo. thank you, Jon genesys_2_demo.bin
  6. 1 point
    zygot

    Implementation Strategies

    @xc6lx45 Here's why I really like your last post on this subject. Between the lines I read: "Asking someone to resolve your issue is risky because every design is different and the issues created for a particular implementation is different and the best solution is different". This concept is even more true when the advice comes from someone who can't possibly understand all of the particulars of your project. Sure, there might be responses with general guidelines and testimonials of past experiences but the burden of understanding, and responsibility, is still yours. The gold in your advice is this: Have you learned about....? I understand the desire to save time but.. use that Xilinx Documentation Navigator and get to know something about your tools. Try out the timing explorer, or whatever your tool calls it, and see what the tool comes up with as Synthesis and Place & Route strategies for improving your timing closure. Be teachable.. even by Vivado. I can say with confidence that whatever you do to get today's project ills resolved will be unlikely to solve tomorrow's project ills. Till someone can put experience into a pill this is the best advice you will get ( assuming that you aren't just solving an unwanted problem and have no interest in doing future FPGA development. ) As an aside this thread opens a point of frustration that never seems to be addressed adequately. Some constraints and tool guide commands can be inserted into HDL source as pragmas and some have to use alternate means like constraints files, TCL, or GUI project settings... Vendors, is it really too much to expect that one day your tools could be more user friendly?