zygot

The assertion that a newer version of Vivado has a different idea of which pins for a particular device are appropriate for clock inputs than earlier ones is a makes for a valid question. @BYTEMANare you sure that you have selected the correct device, including package, in the Vivado device settings for both versions of the tools correctly when generating a bitstream from the sources? I haven't tied to replicate your observation but suspect that something other than a tool bug is going on. [edit] While sometimes vendors lay out PCBs with inappropriate routing of external clock inputs, this is not the case with the CMOD-A7. As you can see in the master constraints file: "#IO_L12P_T1_MRCC_14 Sch=gclk" gclk is on an MRCC pin which is perfectly valid. Always refer to the schematic for location constraints. I just looked at a project from last year for the CMOD-A735T built with Vivado 2019.1 and didn't run into this error message. [edit2] When confronted with unexpected error messages from synthesis, implementation or bitgen you can often find clues to the root of the problem in the vast list of warnings. Start with the synthesis warnings first. Sometimes, constraints are ignored; sometimes due to changes in syntax incorporated in newer versions of the tools. Again, reading the warnings will help.

I'd caution against trivializing anything that looks like "just plug in and go" in the FPGA development board world. There's a lot of details between the promise and reality. The SYZYGY specification seems to be the best effort toward 'plug and play' that I've seen to date, but there hasn't been much in the way of new SYZYGY pods or carrier boards in the past year with that. There are just too many details to tie up for true 'plug and play' for the FPGA arena. I've done custom mezzanine boards for FMC and HSMC and it isn't at all trivial or cheap. In fact making one of anything involving a custom design and PCB isn't cheap unless the design is trivial, you mount the parts yourself, and you can panelize small circuits.. and will be using multiple finished boards. That's just my experience. Anyway, is appears the @Mario875is well on his way to figuring all this out. You can find an FPGA platform to do almost anything that you want, if you are willing to pay for it. If you have a constrained budget then don't feel bad about having to constrain your design goals. The best plan, if you want to execute a project with specific goals and requirements is to find a platform that already supports it. If you need HDMI 2.1 functionality then there are likely platforms available. Just be aware that just because a particular part appears on a board doesn't mean that you can actually use that part to its full capabilities. External memory like DDR is a typical example of this. Always, asking questions and a bit of spelunking are necessary to avoid buyer's regret.

One thing about video, at least for hobby projects, is that a few lost bits here and there, might not result in terrible video performance. You may not notice a few off-color pixels or effects from timing issues. In general video can be pretty forgiving of implementation problems. All of this changes when you have to do commercial or broadcast level video testing and have a product with guaranteed specifications. This isn't the case for most FPGA applications. A few lost bits every couple of microseconds is likely to be untenable. That's why I generally am willing to make a higher investment in hardware when I know that it will have to support a wide range of projects. I use both the Nexys Video and the Genesys2 for a wide range of applications. They aren't in the same class; but they certainly don't cost the same either. But I've gotten good use out of both of those boards so I'm a happy camper. You mileage, as they say, can vary. Or as the broadband carriers who've been spending federal grant money to prevent widespread broadband infrastructure say in the weekly mailings that I get: Gigabit Internet only $xx/mo! That's the large print. In the teeny tiny fine print hidden in a dark background is: "XXX makes no representation related to download or upload speeds." To an extent that's the kind of environment that FPGA development boards operate in. At least with FPGA boards you can find relevant information to give you a chance on making a good purchase decision. The Xilinx tools have always supported the Kintex 160T for free... and curiously finding boards that use this device are rare as hen's teeth. In fact do search for any Kintex FPGA board out there and see what you get, and at what price. That's a shame as Kintex and UltraScale Kintex is a great semi-affordable family. But I digress... Personally, I think that the Genesys2 is pretty remarkable for the price.

You don't mention what this is. Looking at published project code isn't the same thing as running the tools on the sources and creating a bitstream. That step will tell you if you need any licenses, and what tool version headaches you might run into. You will also have a lot more information to work with examining the post route reports. Also, 3rd party IP may not do for your project what you want. Using it, and modifying the demonstration sometimes is informative. Likely, the hardware interfaces are a minor part of any fun video project but the high speed ones using advanced IO features can certainly make the task of timing closure on a fully functional project a lot more difficult. I understand your reluctance on spending twice as much for the Genesus2. All I can say is that the Kintex part on the Genesis2 is not the slowest part available and is much more capable than the A200T on the Nexys Video. But no one wants to waste money. You might think about future projects. Sometimes, but certainly not as a rule, higher initial investment can be a better ROI proposition. This is you call and yours only of course. It certainly depends on how much use you plan on getting out of the board. In general both the Nexys Video and Genesys2 are pretty good platforms for a wide range of interesting non-trivial projects. Get to building those projects on your Vivado installation and see where that leads. For commercial designs ignoring specifications isn't OK, unless you know how to do it correctly. For self-edifying home projects run on the bench at room temperatures exceeding specifications might work out fine for your needs. If you are pushing the limits of your device I recommend that you use the XADC feature of Series7 devices to monitor temperature and possibly voltages. These are very capable devices that can demand more from the supporting hardware than a board design might provide. The ZynQ-7020 PL is roughly equivalent to an A75T in terms of performance and resources. The UltraScale ZYNQ PL performance doesn't tend to scale with the ARM core performance. More homework as the ARM equipped FPGA devices are supported by Xilinx differently in terms of documentation. I tend to think of ZYNQ as an ARM with embedded programmable logic.

Good point. I'm not sure why I forgot about OSERDES2. Your post also illustrates my reluctance to recommend a particular platform for anyone's needs. It is non-specific enough to be misleading ( I'm sure that this isn't your intention... but that's my point ) but not specific enough to conclusive. The Artix clocking specifications are limited for the Nexys Video speed grade. @Mario875is adamant about non-interlaced 1080p with a 24-bit color depth. Is that what you implemented? There are always those vital little details that get missed on discussion platforms like this that cause confusion because they aren't addressed. It's easy to forget that general purpose low cost FPGA development boards like the kind that Digilent offers is just that: general purpose learning platforms. They are not necessarily appropriate for demanding professional quality applications.

I don't think that Digilent has any published information that warrants a particular video standard or color depth for the Nexys Video HDMI capabilities. I don't know of an FPGA board vendor who isn't happy to sell stuff to people who make poor assumptions... that's just the nature of the industry. Typically, in the FPGA development board space it is up to the customer to determine if a particular board meets the requirements of a project's needs. There is more to this than just hardware. Can you write own video IP or do you need to use free, or purchased, IP? Free IP tends to come and go with FPGA vendor tool versions. For certain applications where they think that then can monetize the IP assume that free IP that supports your specific needs isn't available. As you point out, the Kintex requires a license to create a bitstream. For the Genesys2, Digilent provides a voucher for a license that will be tied to one development host. This is a permanent license that lasts as long as your development PC host. The 1 year term refers to the tools versions updates that will honor that license. While not perfect, it's better than what other FPGA vendors will offer. BTW, my recent Kintex 325T license that came with the Genesys2 also is usable for the NetFPGA-1G-CML board using the same device but in a different package. And it works with ISE 14.7. I have a similar node-locked license for a different FPGA device that Xilinx let me transfer the license to a different PC; that was a couple of years ago. Unfortunately, the tools that I use on the new platform don't support this particular, Xilinx branded, board the ZCU106... which is quite disappointing considering the cost of this board.. and the fact that I bought it from Xilinx. Disappointing, but not surprising to anyone who'd been doing FPGA development for a while. Unfortunately, for video doing your due digilence isn't always easy to do. Sometimes video IC vendors have FPGA board project code available for a few boards. Usually, projects involve more than just pumping bits through a hardware interface, so you have to do a rough estimate of the timing capabilities for a particular FPGA device and speed grade for a complete project. One way to assure that a potential FPGA platform will be adequate for a particular project ( and that isn't a simple question to answer ) is to find code examples for that board that you can build with the tools that you have. In fact, you can try to do this with the demo projects for the Nexys Video; it's part of doing your due diligence before making a purchase. For high end video there are boards that support 6G and 12G SDI; but this doesn't fit your specific needs. Again, "buyer beware" is the customer mantra. The best answer that I have to your specific question about the Nexys Video capabilities is don't make assumptions and do you best to verify that whatever platform you choose will work for you. Fortunately, you can build any project that's published and get a chance to analyze the results without having to make a purchase. I forgot to mention that the Nexys Video has a LPC FMC connector and the Genesys2 as an HPC FMC connector. Both are well designed and support transceiver interfaces to mezzanine boards. That's a whole different topic as few board vendors guarantee that any particular mezzanine card will work with their board.... The add-on card capability does offer some hope of using a board for a particular project, though with even more expense and homework to perform.

Yup. HDMI uses the TMDS standard and the Nexus Video does a good job implementing it. The mDP ports however do use two GTP transceivers per port. The Genesys2 is even better with 4 GTX transceivers per mDP port. Both boards are good platforms for video projects. You are correct about the Artix clocking limitations. The Kintex on the Genesys2 does better. Even the Spartan6 on the ATLYS board does better.... though Series7 devices have superior clocking than Spartan 6. Be careful with the HMDI as TMDS uses 50 terminators and you can experience power supply issues with whatever is connected on the other end of the HDMI cable. You'll have to do you due diligence to determine what platform is best for your video needs. An alternative to the Nexys Video is the Numato Labs Mimas-A7 which is also an Artix board but with a smaller part than the Nexys Video A100T. I've used all of these for successful project development. The IO banks on the Nexys Video and Genesys2 boards for the HDMI ports use Vccio = 3.3V so, even if the board design allowed for LVDS ( they don't) the Diligent boards can't so LVDS. It's complicated.. so do your homework if you have certain video requirements to meet.

Can't help myself from making an observation or two about this post. Without the proper thermal conductivity analysis, and a bit of knowledge, it's quite possible to make things worse by slapping a "looks like" hunk of metal onto the top of your FPGA and declaring victory. Even if you know what the heck you are doing it isn't a guarantee that you can do development without worrying thermal considerations. This is especially true for boards that are not specifically designed.. and specified to support the full capabilities of the FPGA device. Modern FPGA devices have a means for monitoring internal substrate temperature. It's not there as puffery. If you are using one of these devices you'd be wise to take advantage of that facility, whether you think that your design is pushing the limits or not. I'm only posting this because the accepted 'solution' and entire thread doesn't mention anything relevant to the expected analysis.

Thanks @JColvin, BTW. After realizing that the ISE 14.7 installed on my Win10 box was willing to use my K325T license I was able to port the Xillybus PCIe demo for the KC705 to the NetFPGA-1G-CML target. At least I know that the hardware is functioning as I've been able to read/write to the FPGA using PCIe. Still, I'd like to have the option of using Vivado. Now that I know that I can use the Xilinx PCIe block with a modern Linux Kernel the NetFPGA-1G-CML might just become my favorite platform.

Yes, I think that you got me the information that I need. The reported lengths seem to be reasonable, from looking at the board. For most of Digilent's FPGA boards with a 1GbE PHY you don't need trickery to convert the PHY rgmii signals into gmii signals. For this particular board, I found that I had to implement IDELAY. No doubt one reason for that is that the PHY come out of reset with the 2 ns RxD delay enabled. The NetFPGA-1G-CML PHY interfaces are 1.8V, unlike the usual Digilent boards. I'm not sure if that's an issue or not. Since I'm going to do have the IDELAY expense in my designs I might as well do it correctly. I know that this is another topic but I've run into a curious issue with Vivado 2020.2 and the Xilinx PCIe 3.3 core. I was trying to port the Xilybus PCIe demo for the KC705 to the NetFPGA board. No bug issues except that Vivado just won't allow me to assign the GTX lanes to the proper bank or pins. Evidently, from what I can see from the reference projects earlier tools like ISE work. I know this because I've connected the board to a PC running Ubuntu an the board shows up as a PCIe device ( this is using the default application in BPI ). Anyone you know around Digilent familiar with Xilinx PCIe implementations who might have some idea how to beat Vivado into submission? With ISE, it seems that you can assign particular GTX transceivers with the ucf constraints. Vivado doesn't seem to be interested in the user's opinion about those assignments. Oh, one more question. Does anyone know of a Xilinx document where you can find the transceiver or PCIe block locations for a particular device and package that agrees with the tool constraints nomenclature? thanks,

Thanks. I need the routing lengths of the Ethernet PHY rgmii_rxd and rgmii_rx_ctl traces, as you've provided.

I've recently stared using this board. There is very limited support from CM Labs; their web site doesn't even mention hardware. I was able to get some, not particularly useful, information through an email contact. I have the Rev F board. The current schematics are for Rev E. What is the difference between the current schematics and my board? The Ethernet PHYs run a 1.8V and timing is a bit hairy, compared to the simpler Digilent board designs. What are the PHY receiver data and control PCB trace lengths? Since Digilent provides the schematic and user manual documentation you would see to be the only source for support.

If you populate a signed 16-bit std_logic_vector with a signed 14-bit ADC value the low two lsbs will be zero and unimportant. If you scale the ADC word to calibrate the span then those lsbs are no longer 'unimportant'. If you sample at 100 MHz but really are only interested in a 6.25 MHz bandwidth then you can decimate those 100 MHz 14-bit samples and get 16-bit samples at a 6.25 Mhz rate. The assumption that a 14-bit ADC is providing 14-bits of dynamic range is not a good one... so regardless of your system design those lsbs are something to understand, especially if you are processing the sample data. That, as they say, is an exercise for the student. There's a lot going on with analog to digital conversion. It's not a trivial subject for either practical implementation or theoretical musing. [edit] As to what, exactly the low n-lsbs of any particular ADC code output represents is a matter worthy of inquiry by all students ( i.e. users ) of such circuitry or components. Indeed, for some applications replacing a few of them with random data for improved performance has been a tried and true technique for a long long time.

There's a smart way to 'play around' with tools that modify FTDI bridge device EEPROM configuration data... and the other way.. which appears to be the one that you chose. A smarter way is to buy a FTxxx module and play around with that. If you are going to change settings on a board that uses the FTDI bridge device to configure the FPGA at least start off by reading the factory settings of the configuration EEPROM contents and saving it to a file for reference should you loose some valuable functionality from your experimentation. Fortunately, there's always someone at Digilent waiting for a chance to help those in you predicament again and again.... Even if you are intending to modify a cheap FTxxx module there's nothing in the utility that will prevent you from rendering other USB devices useless if you aren't careful and following a clear minded well informed and well thought out approach. All of the signalling for synchronous FIFO 245 mode appear to be connected so it's possible that the USB104-A7 can have a higher data transfer rate than the Digilent supported DPTI API provides but this is unlikely unless you are transferring large data sets from/to a DDR buffer. Also, the PC OS and other considerations will have a significant impact on results. Most people will be better off just using the modes that are supported and avoid the hassle that comes with one particular FT232H interface mode.

My intention was not to offend you, but to steer you in the right direction. The proper place to get an answer to your question(s) is from FPGA vendor documentation... not here. But feel free to take your chances if my advice doesn't appeal to you. No one should feel obligated to abide my comments, nor feel offended by them. You asked a question, I replied with my best answer, to the extent that I understood your question, which was pretty open-ended and non-specific. Nothing in my previous reply implies anything negative about you personally. I really don't understand why you are miffed at the response. What questions are you looking for? Perhaps reading the vendor material will generate more specific questions. What specific part of my previous reply do you think is in error? No other questions come to mind.

Tip: Don't solicit random responses to questions about PCB design questions if you are new at this, and hoping that someone answers questions that you haven't thought of. Also don't copy someone else's designs. Do read any literature that you can get a hold of regarding board design considerations from device vendors. There's plenty available and you should not restrict your search to one vendors. Do you homework before starting a PCB design not after trying to bring up new boards that are having problems. The first topic on your list would be power supplies.

Usually, the JTAG chain runs through the FMC connector. Usually there's a way to bypass the FMC connector JTAG circuit so that it doesn't interfere with FPGA configuration. You only need to use the JTAG chain on a daughter card if there's something on it that you want to configure through JTAG. One more thing to learn about when connecting add-on boards to your FPGA platform.

I assume that you mean a contiguous stream of ADC data samples. There's not a lot of processing that you are going to do on those samples with a Z7020 ZYNQ on the fly as data is being captured. If you look around on other areas of this site you can see how to capture 128 M samples of 4 ADC channels into DDR memory that can be processed on a PC later, using 2 ZMODs and a non-ZYNQ platform. The Digilent AXI IP isn't high performance or even good at demonstrating what a Z7020 and SYZYGY is capable of and I don't expect to see anything better. Is it possible to use AXI to DMA huge quantities of contiguous 100 MHz data into the PS external DDR if the PS is running code out of internal RAM? I don't know. I've done this for 143 MHz 64-bit data, about 1100 MB/s, for a total of 128 KB of sample data using Xilinx's Virtual FIFO IP on the Eclypse-Z7; but that's the limit of the IP. If you were to write you own AXI IP perhaps you can do better. If the Eclypse-Z7 were to have DDR memory connected to the PL that would be a much different matter and make the platform interesting. Using a ZYNQ PS to store data from the PL just isn't that useful for a wide range real-time DSP applications. It certainly can be for a few embedded applications. I'm not sure where you are headed with your post so I'll stop now.

I love happy resolutions to frustrating problems. Digilent could be more proactively helpful for basic customer issues. Perhaps a FAQ section or topical list of problem resolutions that customers could sift through on the web site? We all know that trying to update all documentation to keep up with problems caused by Xilinx tools version releases isn't feasible. But there has to be a better way, right?

Most of Digilent's FPGA boards use an FTDI USB bridge device that can have 2 or more endpoints, all using one cable. One is used for JTAG and one as a UART. Vivado Hardware Manager communicates through the JTAG endpoint, so COM4 isn't what you are looking for. If you look under Universal Serial Bus Controllers in Deevice Manager you should see a USB Serial Converter show up when you plug in a cable attached to your board. The CMOD-A7 uses the same cable for programming and UART communications so a COMxx device will also show up. So how do you know what device goes with your cable? Look at the OS tools that list USB devices before you plug in the cable and then after; you should be able to identify the device associated with the cable. Win10 likes to control device drivers and this isn't always in the users best interests. I do a lot of work with FPGA development and USB devices so I wrest control from Win10 for certain device drivers. usbview is a utility that (I think) you can get from FTDI and it is a lot more informative about USB devices enumerated by Windows.

Let's see if we can solve this. What OS is Vivado running on? Have you queried the OS tools to see if any USB devices get enumerated when you plug in the USB cables ( and for the Basys3 have the board powered on? ). For Windows this would be Device Manager ( usbview.exe is more helpful ) and for Linux it would be : dmesg | grep usb lsusb lsusb has command line options for more verbose replies. Vivado 2019.2 isn't the best version to use as it was the first time Xilinx abandoned the SDK tools and forced everyone to use Vitis. I still use Vivado 2019.1 for normal FPGA development. For FPGA boards using older devices there's no good reason to download 40+ GBs of buggy** tools. You might find Vivado 2018.x a better fit. Though lately both Intel and Xilinx have made finding the older versions of the tools hard to acquire. Basic Vivado Hardware Manager to FPGA board connection should work regardless of the Vivado version. ** I really want to embark on a rant thinking about how companies release software that they they've lost that ability to control due to its size... but I'll be good today...

I'm not exactly sure what you mean by 'program the port'. If you want to setup the internal DAC or ADC registers on one of the ZMOD pods you can use the low level controller(s) VHDL code that Digilent supplies in the vivado-library repo. These setup your ZMODs to function after power-on. You'll need some way to write registers in your HDL code if you want to change the default settings post configuration. You can use the USB DPTI for this, or you can add a UART interface to do this. If the preceding information isn't what you are looking for you'll have to be a bit more expansive in describing what you want. Syzygy ports and pods use a Micro on the pods to communicate with the carrier board on power-on to determine things like Vccio voltage and basic pod functionality. On the USB104-A7 and the Eclypse-Z7 carrier boards Digilent uses a micro with it's own code to implement the Syzygy DNA negotiation phase.

Why do you think that a soft processor ( or Vitis for that matter ) is necessary for your project? If you don't use MicroBlaze you don't need to use either the board design flow or any software development tools like Vitis. Your board is perfectly suited to an all HDL design flow. Just create a new project in Vivado and add all of your HDL source code, plus your constraints file(s). You can still use Vivado IP for clocking, internal storage etc. if that's convenient. FPGAs just aren't well suited for implementing replacements for general purpose computers systems. ( an exception might be for projects that are for experimentation of CPU architecture design concepts...) My hunch is that a major reason why MicroBlaze shows up in projects for boards like yours is that users are afraid to tackle the job of implementing a free-standing DDR interface. That's just the way that FPGA vendors like it; but that's not in the best interests of their customers. The USB104-A7 has DDR, a SYZYGY port, and a DPTI supported USB interface. You don't need a soft processor to use any of those resources I haven't taken the time ot figure out how Digilent supports the SYZYGY DNA for your board but if they sell the board they have to provide IP to use it.

Better yet, to get started, ditch the MicroBlaze and board design system altogether. Everything will be simpler. No mysterious signals added to your intended design. No hardware to export to the software development tools. No software co-design co-debugging. A good rule in engineering is to avoid doing things that make your work complicated and difficult. If you find yourself working for the tools, you're living in an unhappy universe. Make the tools work for you. The tools can't create designs, so don't allow them to dictate to you how you can do the design work.

I've not used the USB104A7 nor do I use soft processors. I do use wrappers when targeting a ZYNQ device and using the board design flow to develop a basic ZYNQ system. After verifying and generating the board design I have Vivado create a wrapper file in VHDL or Verilog for the system. I make sure to uncheck the default setting when doing this and tell Vivado that I, not Vivado, will be managing the wrapper HDL. My top level entity instantiates the system wrapper as a module/component along with all of the other modules/components in the design. For ZYNQ designs the toplevel entity is ignorant of PS signals like external memory DDR. For MicroBlaze, I assume that, all external signals and pins have to be handled in the toplevel entity. Either way we need to provide location constraints at a minimum for programmable logic external signals. You may not think that diff_clock_rtl_clk_n, diff_clock_rtl_clk_p, and reset_rtl exist as external pins in your design but Vivado synthesis certainly does. So, you have to figure out why this is the case. Do these signals appear on the HDL wrapper for your system design? Since you are wanting to write your own Verilog code you should consider abandoning the MicroBlaze and board design altogether. Take control of your project. If you just have to burden you design with a soft processor you don't need to start there. Just create you own toplevel module and add IO features as you progress. When using wrappers to instantiate board design flow systems you become responsible for managing constraints. Hint: Almost every design that I do has a free-running 32-bit counter connected to each clock with one bit connected to an LED as a heartbeat indicator. It's an easy way to see that the design is running. Connecting a small counter that is clocked by sys_clock and has its output connected directly to LEDs isn't going to be terribly informative. For a 100 MHz sys_clk bit 26 is a better signal to drive an LED indicator.