zygot

Members
  • Content Count

    1006
  • Joined

  • Last visited

  • Days Won

    49

zygot last won the day on November 17

zygot had the most liked content!

5 Followers

About zygot

  • Rank
    Prolific Poster

Recent Profile Visitors

6826 profile views
  1. I'm not sure that I understand this statement. You can't implement a UART in the PL and connect it's RxD and TxD signals to the PS MIO pins that are connected to a USB UART device on your board. I will caution you to consider how you are going to configure your FPGA device. Development boards made by Digilent or Terasic include the hardware for configuring the device as well as using debugging IP from the tools. Before making a selection understand how the configuration works and if it works with the FPGA vendor's tools. Ideally, an FPGA development board will have a standard JTAG header as an alternative means for these functions. I would suggest that beginners avoid boards that restrict configuration to a custom and or closed format. Some of the low end so called FPGA development boards are too cheap and or too difficult to use. As a beginner you want all the help and options for development that you can get so choose wisely. Some choices require more effort in figuring out what you are going to get.
  2. It is possible to mux PL pins to ZYNQ PS peripherals. You can, for instance use one PS UART connected to the MIO pins as normal and connect a second PS UART to PL IO pins. For a two pin UART interface this pretty easy to do. For an Ethernet interface not so easy. It sounds to me as if what you want to do is leverage your ZYNQ platform into something that let's you experiment with Verilog designs. You can certainly start with the board design flow to experiment with exchanging data between the PS and PL Verilog code. Simply adding GPIO ports that connect to PMODs would be a place to start. Later you can experiment with using BRAM or you own IP. Personally, I find that having Vivado create a toplevel HDL source that I control works best; but I'm pretty comfortable with HDL design. In my case I create my own HDL toplevel design source and instantiate the board design HDL code. This make connecting HDL code to open ports and pins straight-forward. If you can afford it I strongly urge you to consider buying a cheap non-ARM based FPGA development board to learn Verilog development. It's just a lot less complicated. There are a number of options for nice <$100 FPGA boards, though the best one's for the money might not be Xilinx based. Once you figure out how to implement something in HDL that you can interact with using , say a UART, then try an integrate your HDL into the ZYNQ platform. There is HDL code projects on other areas of the Digilent forums to play with to help get started. A UART is the easiest interface for debugging or connecting an HDL design to PC applications. For <$10 a good 3.3V TTL USB UART breakout module or cable is indespensibe. It is also possible to tie off the PS and just use your board as an FPGA platform; this is not something that I'd recommend. In the end you should choose the best strategy for you. Just don't be afraid to ditch a processor based design because it seems daunting. Before you are ready to implement a 6502 soft processor with peripherals in logic you should be comfortable implementing, simulating, and debugging "peripherals" in the HDL of your choice. At least that's the view from where I sit.
  3. The SDK has always been free. As of Vivado 2019.2 the SDK, SDSoC, and SDAccel tools have been replaced with Vitas. Digilent needs to remove the SDSoC voucher from its product list. It's not clear from what I've read where all of this is heading in the future and Xilinx isn't making a very good effort at making this clear.
  4. Try browsing the Project Vault area. You can find numerous VHDL or Verilog code samples among the projects submitted. I generally provide simulation testbench code as well. I believe that you'll find the authors will be helpful if you have questions.
  5. zygot

    Advanced topics

    I certainly won't argue against reading the available literature form Xilinx or Intel; tutorials, reference manuals, etc. A problem with diving into "advanced topics" is that it's hard to wrap your mind around everything by trying to absorb complicated information in a vacuum. It certainly doesn't hurt to be familiar with material on timing closure and constraints. Don't just stick with one vendor. I highly advise that you understand how Intel's or maybe even Actel's timing analysis tools work. Getting into trouble, as it were, is pretty easy. Dealing with it is probably easier with a structured approach. So, one idea for a structured approach is to browse the many Application Notes that are available from the vendors. Often they come with design files demonstrating concepts. This might be an easier way to dip your toes into deeper waters without your eyes glazing over. The reality is that simple designs often don't require much attention to timing and placement constraints but complex high clock rate designs often do. Quite a few application demo delve into advanced concepts. The nice things with this path is that you usually get some sort of analysis and explanation of the theory behind ways of dealing with complexity. One easy path to complication is, as has been pointed out above, understanding pipelining to achieve substantially higher data rates for a given design. This will introduce you to timing closure concepts, latency, valid data scope, and other issues quickly, but with specific issues to resolve. First you need to understand the AC switching specifications for your particular device so as to make the project feasible. For real FPGA design situations what takes place beyond the IO pins is critical; but this is no longer FPGA development but digital design. Ideally, one would start with understanding digital design before trying to do FPGA development; but the is no right or wrong path to enlightenment. If you aren't competent at doing high level simulation and writing useful behavioral and RTL testbenches the you aren't ready for the other advanced topics. Well, for now that's my 2 cent contribution. Bon Voyage!
  6. The only two FPGA development boards that I am aware of with two HDMI outputs are Digilent's ATLYS and Numato Labs's Opsis. One of the ATLYS HDMI outputs is unbuffered and shares pins with a PMOD so probably doesn't have the quality of the other buffered one. I don't know if the Opsis is available anymore. Both are Spartan 6 boards. If your project can have a DP output and an HDMI output The Genesys2 and Nexys Video might be good choices. The Opsis is the only FPGA board that I am aware of designed for video distribution.
  7. I'd say that the problem is that any version of Vivado 18.x doesn't work on the first try. This shouldn't and doesn't have to be so hard.
  8. @sapperlott It's too bad that your board has been sitting around gathering dust for so long; I have one that is rarely not in use. I assume that you are running the demo_BIST project? I abandoned all of those Digilent Microblaze demos long ago; too complicated and too much of a hassle. I wouldn't read too much into what "Test Short" means unless you are willing to slog though all of the source code to find out what ia being tested. [edit] Obviously, I'm not prepared to do that. It sounds as if the board is working just fine. Create you own HDL project to do something useful, involving the UART, a couple of PMOD signals, the LED and switches, and test that. If there's a spare LED available almost all of my code includes a 'heartbeat' counter to indicate that the design is being clocked. Just create a free-running counter and select the appropriate bit to toggle the LED. I'm almost positive that you are ready to get that board being useful. [edit] Those SMT USB micro connectors will not be able to withstand years of use and will shear off unless you take measures to secure them to the board. Fortunately, the Atlas has a standard JTAG header as a alternative.
  9. zygot

    ZYNQ based board

    I assume that you mean at least (???) two Superspeed USB ports. If you want two downstream endpoints on a ZYNQ FPGA board connected to the PL then the only options that I know of would be a board with two FMC connectors. Cypress and FTDI make USB 3.0 FMC mezzanine development boards capable of Superspeed data rates. Be careful of maximum Vadj voltages. The newer devices might only support 1.8V maximum. Perhaps the best option would be to consider replacing all of your criteria with a different approach. Have you proven that your host application can support two 300+ MB/s USB streams simultaneously and timing requirements?
  10. zygot

    SdSOC tools

    @asmi Again, thanks for the help. It seems that Xilinx has an issue with Firefox, even with no add-ons enabled. Even trying to get the unified installer for the 2019.2 tools I never got connected to the login page using Firefox... just lost in space somswhere. I had to use Edge to even download the installer. Horrors! I'm just curious. Are you on Linux or Windows. It's not clear if the new Vitas software development tools can do everything on Win10 and if it does how complicated that is. I'm assuming that for the SDK side there will be no significant change. This seems less likely for the other tools.
  11. zygot

    SdSOC tools

    Perhaps, but I was unable to get the 2019.1 version of the SdSOC tool; just dumped into an empty non-functional page from any link on the main website. But it's time to update anyway to the most recent tools. For those of use without broadband this is becoming almost impossible. It took me a week to get the 2019.1 Vivado+SDK tools...
  12. zygot

    SdSOC tools

    @asmi Thanks. Looks like I have a license for something that doesn't exist for my current installations. According to the release notes there is a limited number of platforms supported by Vitas so it's unclear what the future holds for most hardware platforms currently requiring the SDK. Xilinx certainly isn't making it easy to figure out.
  13. zygot

    SdSOC tools

    It's embarrassing that I have to ask this here but I have a license for the SdSOC development environment but am unable to download it. I wasted 20 minutes going round and round on the Xilinx website without making any progress. Does anyone know where the download page for this tool has gone? Xilinx has a new Veritas tool but I don't have a license for that..
  14. Programmable logic devices are absolutely terrific for some things. For your project I wouldn't have a processor, soft or hard in the design. Of course I'm a bit more confident in my HDL skills. Still, if you have experience with an HDL you should consider an all HDL design. There are fewer to things to worry about. SPI is a nice interface to design for; just don't tell Vivado that the SCLK is a clock. With even low end Series 7 devices you should be able to implement a simple 40 MHz SPI master interface without timing issues. I'd start with the SPI master and verity timing using simulation. You can feed it with data from a BRAM to send out data formatted to support whatever it is that you want to connect to and capture it with an ILA. No software to worry about. Very little resource usage. Generally, devices with an SPI interface are pretty tolerant of less than great SCLK inputs. My personal opinion is that implementing a soft-core processor in an FPGA is for an advanced developer. Yeah, I know that this goes against what most beginners hope is the case and what most FPGA vendors think will make using their devices easier and suitable for a broader audience. Really, a low percentage of FPGA designs need or should have s programmable core. If you don't have the HDL chops there are controllers that do 40 Mbps SPI like the Delfino and development kits are cheap. A TMS320F28379D launchpad would do everything you need. The only problem with that is the hardware is crazy complex to program with tons of unexpected limitations and modes to worry about. But Ti does offer pretty good tools for free. In fact that platform would be a good test platform for verifying an HDL Artix design implemented on hardware.... [edit] So after writing this I just noticed the report that you show above. I wouldn't worry too much about the TNS number as the WNS is positive. You have generate a detailed timing report to see how it came up with those numbers. Look for nets that are unconstrained. Your design might work fine as long as the IO pin locations and IOSTANDARD constraints are correct. So don't give up on what you've done too soon.
  15. When doing a new design it's always a good idea to check the pin report to at least make sure that the toplevel signal assignments are correct. If the locations don't match the schematic or constraints file then something is wrong. Always run through the synthesis and implementation messages to look for any warnings about constraints being ignored. Often location constraint issues will result in BITGEN DRC errors that prevent bitstream generation; but not always. Be aware that the tools will assign default IOSTANDARD and other IO constraints unless you provide your own. When you use vendor IP wizards in your design Vivado creates timing and sometimes location constraints that are not obvious in the heirarchal view so you have to go find them. Use problems like this to get familiar with Vivado. Open the implemented design and view all of the reports and informational views. From what you've said timing seems to be what concerns you. After generating a bitstream the main summary report shows the maximum negative slack numbers. I guess that this is what you are looking at. Usually, if a simple design doesn't meet timing it's because the tools were never given basic external clock rates to work with. Understand that if your design has a wizard generated MMCM or PLL in it the constraints file for that IP will be in your design though it will be buried within the heirarchy. If you provde your own clock constraints that relate to the same inputs as the IP constraint you will get a warning in the synthesis and implementation reports. Open the implementation and looks around. Vivado reports all signals not constrained by a known clock rates. If also reports all known clocks. Often this information will point to a silly error. Vivado is complicated and finding the right view to get pertinent information is often contextual. I still sometimes fumble around trying to get to where I want to be every once in a while.. I'm not a fan of GUIs that limit access to a particular screen contextually. You just have to spend some time getting to know the tools' quirks and behavior. FPGA development tools generate a lot of warnings. Even the IP wizard generated code generates warnings. For new projects it's worth the time to rund though these looking for obvious errors in your own code or just plain syntax mistakes or omissions that have confused the tools.