zygot

Members
  • Content Count

    1079
  • Joined

  • Last visited

  • Days Won

    50

zygot last won the day on December 26 2019

zygot had the most liked content!

7 Followers

About zygot

  • Rank
    Prolific Poster

Recent Profile Visitors

7211 profile views
  1. The best solution, though probably not one that you want to hear, is to make your ATLYS designs all HDL. Ditch the Microblaze and EDK.
  2. I have managed to install Webpack Vivado 2019.1 onto Ubuntu 19.1 and created my own ZCU106 HW/SW application. So the question of licenses for the ZU devices is mostly resolved, though I haven't run into any restrictions for the ZU7EV device yet if there are any.
  3. Well that brought a chuckle to my completely humorless day. Reality is so inconvenient... there must be a way to get along without it. Corporate officers do SOP. Accountants just make the books more complicated to avoid it. Simulating 100 us or so of nothing waiting for an MMCM to lock is annoying enough to sear the question of start-up into one's mental sensitivity list. I've never tried simulating configuration start-up though... still simulating has pointed out more than a few 'oversights' in my preparation on many an occasion.
  4. You knew that there was a reason for this MMCM or PLL output right?
  5. Writing blocking code to service hardware is easy to do but, as you have found out, is not usually preferred. Waiting for characters from a UART or keyboard are two examples where this might be done as a simple approach. For your project the Xilinx standalone OS SDK provides examples for two methods of handling intermittent UART events without tying up your processor in a non-productive loop;; these are polled and interrupt driven approaches. Providing example code for hardware servicing is one area where the Xilinx SDK shines and is an excellent way to learn basic concepts.
  6. If you don't explicitly use a primitive to assign input and output buffers the tools will infer that for you. Usually you can be lazy but in general you should get in the habit of adding the lines to your HDL. I confess to being lazy for many projects where I can get away with that. All IO pins need input or output buffers. This is an excellent, older book, and certainly an easier read for someone already familiar with the basic concepts. The analysis for both digital and PCB design has undergone some conceptual evolution since it was written; but is still valuable. Yeah, this was a pretty optimistic (naive) objective. Even if you are an expert in digital design and PCB design and have good (expensive) tools to help with designing a good FPGA based board the task is complicated... lot's of details that need to be taken care of. I suppose that there are PCB design shops that could allow me to spin my own FPGA board but it would entail a larger investment than I'd want to risk. No one makes the FPGA boards that I want.... but I think about it... Sometimes not being naive stops people from accomplishing objectives.
  7. I agree with this concept though I'd state it a bit differently. Combinatorial logic can produce runt pulses and unwanted transitions due to delays in the various signal paths; even in LUT based logic. A logic simulator like ModelSim or Vivado Simulator will show these. You can 'clean up' these artifacts by using clocked registers, either in the LUTs or IOB. It's hard to tell from a scope picture if that is in play. Nevertheless, using registered logic is a good standard practice; and I join @xc6lx45in recommending it. In fact, successful digital design is based on the concept of inserting registers between combinatorial elements whenever delays approach the clock period. The idea is that the register feeds some combinatorial cloud of logic that is guaranteed to reach a steady state in a period of time that is less than the clock period clocking the registers. The length of time for this to happen depends on a number of factors and can vary with synthesis and place and route behavior.
  8. I wouldn't jump to conclusions.... no really, I wouldn't do that. Yeah, I see the spikes that appear to be about 500 ns apart. I also see missing spikes that one would think should be there if your clock is always running. I'm more inclined to to think that I would investigate along the lines of simultaneous switching, or some other driver related issue assuming that your probing is pristine. Frankly, I'm not sure that your one picture is sufficient to figure this out. There are no rules ( ok, so few rules ) in debugging. You can turn off some, or all of the output drivers to test a hypothesis. Who cares if a test makes the entire circuit not work? Divide and conquer is the debugger's mantra. Along with SLOW slew rate I assume that you've set your outputs to the lowest current drive. As @hamsterhas pointed out identifying and correcting oversights and mistakes will certainly resolve those issues. Some things you don't have control over but you might be able to lessen the magnitude of some issues with insightful design fixes. For some projects the CMODs are fine; I have two in use most of the time. A few simple tweaks on a re-spin could make them excellent for the use cases that they are aimed at: Providing better ability to power the CMODs from an external power supply without losing USB connectivity Allowing users to optionally power IO banks with a lower Vccio Providing a few matched IO suitable for LVDS. I get the point about connector signal integrity but really, this class of device doesn't require the ultimate performance ( not saying that users aren't going to want that ). 2mm pin spacing or even 2.54mm spacing would be just fine. providing more GND and power pins. The list above is by no means complete. Everything is a trade-off. One suggestion might be to have whoever specs and designs the next spin have a lot of experience under their belt incorporating the current design into embedded projects. They'll figure out what needs to be done and the resulting balancing of all of those trade-offs will result in a terrific product.
  9. zygot

    Vitis

    @JColvin, I really appreciate your help. I suspect that I could have had more success by choosing the 'Hello' Application but why bother? I will pursue a Zedboard Vitis project and if it's interesting will post it. It'll be a tertiary level enterprise though. At this point I've concluded that Vitis and therefore Vivado 2019.2 or later are 'not ready for prime time'. Actually Vivado 2016.2 on WIn7 is my main HDL Xilinx toolset 'main squeeze' and except for a few idiosyncrasies gets the job done. At least I'm familiar with it's quirks. I still can't figure out why implementing a memory viewer in Vivado Simulator is so hard... Quartus has had a hardware memory tool for decades.... ISE ISIM can do it. A lot of my angst has to do with the knowledge that the Win7 box will die someday and I really haven't found a suitable successor yet. IF only Centos 6 were based on a slightly later Kernel it would be one OS to last (almost) forever.
  10. @elodg Hey, thanks. Your changes are certainly helpful and explicit. I think that I'm going to table development with Vivado 2019.2 for a while until Xilinx can support it's new software development regimen better. [edit] though I will play with Vitis and the Zedboard... I'm looking forward to the availability of pricing, delivery, and documentation on the ZU5EV..
  11. zygot

    Vitis

    @JColvin, Hey, thanks. For right now I just want a fixed point of reality to hang on to. Where things go after Vivado 2019.1 for ZYNQ can wait. Get on with your life there's no hurry.
  12. zygot

    LVDS input output behaviour

    I'm not sure what you mean by Tracking ADC. LVDS has pretty restricted ranges for valid 'analog' levels. Perhaps more verbage would help. If you are using HR bank IO you need to provide external termination. If you are using HP bank IO you can use internal termination. Either way your receiver must be terminated properly to work. Have you tried driving your input LVDS with an output pair on the same IO bank?
  13. zygot

    Vitis

    Today I've set a personal high for the number of experimental projects that have ended in failure. Vivado 2019.2 and Vitis. Need I say more? Well, not all of the misery was trying to combine the two tools. Vitis currently supports only a handful of platforms. It doesn't support my ZCU106 ( but does support the ZCU104 ). In theory, Vitis supports the Zedboard. Digilent sells the Zedboard. Has anyone had success with Vitis and the Zedboard? I started with the provided zed XSA file in an attempt at simplifying things. I tried creating a platform with it for both the standalone and RTOS environments. In both cases while trying to create an application the build failed because I didn't have the necessary libraries. In both cases any attempt to add the necessary libraries by changing the BSP settings resulted in build errors. Anyone building a working design using Vitas? I really need a win before the day ends,,,,
  14. zygot

    LVDS input output behaviour

    @Arshi, One of us is terribly confused. Do I understand that you are trying to drive the LVDS_25 input pairs on your Kintex board with a signal generator? There's no 'analog voltage' and 'reference voltage'. LVDS isn't an analog comparator. LVDS is a differential digital signalling standard where the driver asserts the _n and _p pins to opposite digital levels. The receiver end has to have the proper parallel termination. If I'm the one who's confused perhaps a better explaination of what it is that you are trying to accomplish might help.
  15. Hey, thanks for taking the time to reply. I have spent hours trying to 'prove' one way or another that Design Edition installation of Vivado 2019.2 will allow me to use the Genesys ZU-5EV board, when that becomes a real product. As I pointed out I did at least create a bitstream for the Genesys ZU-3EG using Vivado 2019.1.. as that's the version the OOB was created with. As I have a node-locked license for the XCU3EG device this wasn't surprising. I did manage to find a demo project for an XCZU5EV board from Trenz that should work with Vivado 2018.2, which happens to be installed on my WIN10 box. Again, the license Manager specifically indicates that I have a license for the 3EG and 7EV devices and bit_gen for this versio of Vivado. Unfortunately, the tcl script failed to create a project so I was unable to get to a resolution. I should mention that I did manage to see a message while all of this is running indicating that VIvado did get a license for the ZU7EV device but since I never got to a bitstream I'm not sure what to make of that. But Vivado 2019.2 License Manager duly reports that both the zu7ev and zu7ev_bitgen licensees are past support. As my WIN10 Vitis + Vivado 2019.2 installation indicates that my ZU7EV license has expired and there is a Vivado 2019.2 trd project for my ZCU106 board I decided to try one more time to see if the License Manager is or isn't relevant. After over an hour of processing Vivado abruptly exited due to a fatal Java runtime error (??!!??) before completing all of the myriad synthesis builds; and this was just for the Ethernet 10G demo oart if the trd. The Xilinx trd pdf document is lacking in useful build information but does mention that the Pentalinux build environment is required... and that has to run on a Linux Host. So there are a few issues for me here before I can consider buying one of your new boards. First is the Vivado version. Clearly, reasons that aren't obvious, Digilent has chosen not to use the latest version of Vivado tools. Generally, when licenses are required versions matter. The only thing that I have managed to conclude about Vivado 2019.2 is that it is a horribly broken toolset. Even though Vitis happlly installed itself on my WIN10 box even the official Xilinx board releases suggest that I can't use it for a complete HW/SW project on WIN10. The documentation is horrible, which in past experiences is a really bad sign. Vivado 2019.2 doen't have a 'launch the SDK' button because there is no SDK, just Vitas. Vitas will launch the hardware tools, but only for new platforms or a few existing older platforms. YIKES!!! No one seems to be able to tell me what my XCZU3EG and XCZU7EV licenses are good for, if the WebPack tools support development for these devices. This is a problem, not only for potential customers like me, but for Xilinx partners like Digilent. So, I'll just have to wait until Digilent releases an OOB for the Genesys ZU-5EV that I can build with Vivado 2019.1 on mys system (I suppose that I'll have to install Vivado 2019.1 onto a Linux box to do the software development). One resolution that I have made is to follow my own advice and verify that the tools will allow me to use a platform before making a purchase. The burden of proof shouldn't be on the user. It took me a week of failed attempts to download Vitis 2019.2 onto my WIN10 box so that I could install it. And that's the problem. What other licenses do I need to use the Genesys ZU-5EV features and what version of Vivado do I need to actually do development with it?