• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by zygot

  1. I was stumped trying to run ISE on Win10 for a while but have had it working for a few months. Install the October 2013 final release of ISE 14.7, not the later December release ( the latter doesn't support Spartan 3A) Read AR# 62380 for post-install steps to disable SmartHeap and get it working. I've built and configured (using the Windows Adept Utility) a few Spartan 6 boards with ISE on Win10. I haven't exercised all of the ISE tools but haven't had to so far.
  2. All of my designs have a 32 or 48 bit free running counter for multiple uses. One is a sanity check to make sure that the clock is there. For a 100 MHz clock bit 24 toggles an LED at a nice rate.
  3. Ethernet on Zybo is connected to the PS. All you have to do is make sure that it is enabled in the ZYNQ 7 Subsystem. Use the Digilent board presets. I made a (few) designes from scratch just recently with an iperf udp server as experiments with a new OS installation.
  4. @D@n, as usual provides some valuable insight that most people would have missed. My first comment has to do with using the AVI-Lite bus. I agree with Dan that AXI busses, even the 'lite' ones are overly complicated for most PS-PL designs. If you are going to use a standard bus then you have to understand how it works.. before designing with it. Bussing signals doesn't have to be complicated. If you want to have IP ownership over a technology then you embed lots of functionality into your bus standard and it becomes complicated. In general I avoid Wishbone, AXI and other similar bus standards to the extent possible. It's horrifying that an FPGA vendor would promote and propagate bad design habits to their customers. One way to side-step using a bus with complications that you don't want to deal with or complexity that you don't need is to not expose the bus to IO pins in your board design schematic. The dual-port BRAM controller is one interface that I've used; exposing the signals on side to external pins in the board design. Once I've generated the board design I always have Vivado generate and HDL wrapper, that I, not Vivado, controls and use that wrapper as an instantiated design element in my own toplevel design file. I can then instantiate any number of additional components into my toplevel design as if it were an all HDL project. I have to take care of more details this way but I've found this to be a lot more manageable and a lot less frustrating way to do ZYNQ designs. My second comment has to do with Dan's discussion about the flaws in Vivado generated code. I'm all in favor of using a tool to identify bad code, when it's available. Everyone, regardless of experience, writes poor code at some point or another; if you have access to a "brain-fart" checker then why not use it? As long as it doesn't automatically change your source, the way that a spell checker does I don't see a downside. In the case of the if-the-else structure you have to make sure that all possible conditions and all possible states for those conditions are handled. This is not always easy to do. Even evaluating the output of such logic isn't always straight forward. Nested if-then-else structures can have multiple combinatorial logic levels and unpredictable delays and behavior. Understand the implications that come with using a particular coding structure when doing synthesis for logic design. There are two types of resets, synchronous and asynchronous. You can have both types in your process statements. Be aware that the concept of logic reset isn't nearly as simple as one would assume.
  5. 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.
  6. 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.
  7. 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.
  8. You knew that there was a reason for this MMCM or PLL output right?
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. zygot


    @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.
  14. @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..
  15. zygot


    @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.
  16. 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?
  17. zygot


    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,,,,
  18. 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.
  19. 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?
  20. It really all depends on what you what to do. What is that you intend for you DAC project?
  21. So my WIn10 box has Vivado 2018.2 which might be a WebPack install but I don't remember ( is there a way to know from running Vivado? ) I found the Genesys ZU3EG OOB on Digilent's GIT. There were no notes about what version was created in so I tried using the tcl command prompt to create a project. This failed of course because that's when I found out that the project needs Vivado 2019.1 to work. My WIN10 box has that version but also a license for the device and bitgen for that device. My other option was to try creating the project on my WIN7 box but the latest version there is 2018.2. I have a third option which is a Centos box but that has 3 Vivado installations that latest being Vivado 2016.3 (likely a WebPack install). Unsurprisingly, I did get a bitstream on the WIN10 box using Vivado 2019.1, but then I have a license for that. I don't have the hardware to see if I can configure a device and decided that I have more important things to do at the moment than run through the SDK. Note that all of my installations are the Design Edition not WebPack. Some people have broadband and the time to install every version of Vivado that comes out, just in case they need to replicate a particular demo project. I'm not one of those people.
  22. It just seems unlikely that the free tools would support devices that the 'full' version tools don't. The only way to know for sure is to do the HW/SW design, create a bitstream and bootable software package and run it. Seeing lines for a device and bitgen for that device flagged as past support in the License Manager isn't very encouraging. I have a few versions of the WebPack installed and used those for the Z020 based Zedboard. I don't think that I have any WebPack installations of 2017.4 or newer. What I suspect is that the free tool support for anything other than the Z010, Z020, or Z030 are limited.
  23. Thanks. Have you confirmed this? I have a ZU3EG and ZU7EV board, both came with node locked device certificate licenses which I redeemed. The license for the ZU7EV has already expired for Vivado 2019.2 ( according to Lincense Manager in that version). That version of Vivado uses Vitas instead of the SDK. My Vivado 2019.1 Design Edition installation shows all of the older ZYNQ devices as supported plus a license for the 3EG, 3EG-bitgen, 7EV, and 7EV-bitgen tools. It's really not clear to me what exactly is supported. Vitas documentation is really confusing as to what exactly is supported. I don't have a good 'golden' HW/SW project to try out for the 7EV based board to see if I can actually configure ad run a complete design. Prior to Vivado 2019.2 Petalinux development required a Linux host. Since Vitas replaces all former software tools one would imagine that you can now develop with Petalinux on Windows; but if I haven't been able to find any specific tutorials or documentation on the specifics yet.
  24. In my experience that statement is over optimistic. I'm always on the lookout for opportunities to use an off the shelf converter with one of my many FPGA boards equipped with an FMC connector. I've used the adapter that you refer to but successes are the exception. Even for simple single-ended interfaces the process of figuring out what the pin location assignments will be end up in failure due to some signal not making it to a pin on my FPGA board, Often, the issue is a 12V or other power supply issue. Every time I start the analysis it starts with creating a net connection diagram in text. For the AD9122 you have a parallel differential data interface so you might get lucky. I have a folder with every converter and converter EVM that I think is interesting and that device is there so I must have at least given it some thought... but no, I don't remember actually doing a signal connection diagram for it. That might be because the device is a bit old but don't really remember. Understand that an adapter will add delays to your timing budget and likely pair mismatches. While not necessarily a show stopper it might make a project quite complicated For LVDS with multiple lanes of high data rate multiplication relative to a clock references things get complicate fast. I've gone though the exercise of doing the pin location analysis for quite a few FMC equipped EVMs only to find that the reference clock or clock assignments were not correct. This has nothing to do with the FMC connector but the pin assignments by the FPGA board vendor. There are restrictions for clocking and data pin IO banks. I've discussed this in more detail elsewhere on Digilent Forums. One thing to be careful of with converters is that for actual implementations the analog conditioning is very application dependent. EVMs are generally designed to evaluate a device, not be suitable for any particular application. At the end of the day you are the one stuck with any choice that you make so do your homework even if someone says that a combination of FPGA boards and mezzanine cards works for them. Unfortunately, vendors of FPGA boards would like to think that the FMC standard carries some universal compatibility guarantee with it but they never offer a money back purchase guarantee or even bother to test a selection of mezzanine cards that their customers might want to use. So the burden is on the customer. I've bothered to post a few threads about my experiences in the interests of vendors and their customers alike. IO bank assignments matter. There is no universal interface. That's what I've found. Now the FMC can be a plug and play interface if the mezzanine card and carrier card vendors use that EEPROM but the FMC specification really doesn't cover all of the issues that are pertinent for FPGA carrier details. At least I haven't run into very many FMC mezzanine cards that use the EEPROM to set Vadj or identify feature or interface requirements. Things are looking up though as Digilent has decided to support the SYZYGY specification for some of its nwere boards. This is a plug and play interface with FPGA carriers in mind. It will take some time for device vendors to latch on and likely a few specification iterations before this becomes a real benefit to most FPGA developers but my hopes are high. That's saying a lot as my past experiences jave always kept driving me toward pessimism. Oh, and about the Kintex UltraScale, Be careful with the newer devices as the IO banks might only support Vadj up to 1.8V and are incompatible with older FMC mezanine cards that use 2.5V or 3.3V IOSTANDARDs.
  25. Well, I can only tell you to do what I do, as mentioned at the top of the thread. If the board vendor had demo code for a board that is designed to run on a platform that you have then you should be ok, though I'd probably still run through the schematics. Even then you have to build the demo to determine if there are any surprises, like proprietary IP sources, that you can't modify or need a license for, because it's unlikely that what you want to do is what the demo does. I've had mixed experiences from Analog Devices which has, on the face of it, excellent FPGA support. I've used the AD9739A-FMC-EZB with the KC705 with success. ( guess I forgot to mention that earlier ) Once you start thinking about adapters it's clear that you are on you own, without demo code. In this case make sure that you understand how to implement your own interfaces. Be careful of JESD converters as they are tricky and I am unaware of any free IP. Converters with parallel DDR interfaces are the most likely to work with an adapter. There are a lot of flavors of LVDS but your chances of success with an adapter is low, from my experience. There are other threads on this topic that I've written about on Digilent's Forums. In my experience using an adapter has worked out for low performance converters using singled-ended signalling. The best approach to evaluating new hardware is 'try before you buy'. If there's no demo code for your platform you need to figure out what the pin location assignments for your platform will be and design a test project to see if there are any gotchas you didn't think of. Why would anyone spend money first and then figure out if their purchase if usable? Never make assumptions. The devil is in the details and sometimes hiding on purpose.