zygot

I believe that you have some confusion about reset verses reconfiguration; it might just be a linguistic thing. Do read the reference manual provided by Digilent. Most of their boards provide some sort of access to the configuration mode input pins on the FPGA. In the case of your board JP1, when jumpered, configures the FPGA from a valid bitstream in the FLASH memory. So, after writing the FLASH memory you can just put a jumper on JP1 and after cycling power your board configuration data will come from the FLASH device instead of the USB JTAG interface. I'm not sure what you have in mind with respect to using the UART/JTAG interface but the board was not designed in a way to control the mode bits on the fly. In theory, one could design board to do this. The NetFPGA-1G-CML has a PIC processor that looks for a bitstream in an externally connected thumb drive and configures the FPGA from that, if present. In my experience this doesn't work out properly if that board is sitting in a PC connected to a PCIe slot.

If I wasn't clear about FPGA applications for internet security, I'm referring to an entire design implemented in HDL logic with no processor involved.

I'm afraid that I've got nothing to offer other than what I posted earlier.

I'm curious. You can get fine resolution delay for inputs using IDELAY. How do you propose doing compensation for your outputs? In general, trying to simulate balanced (differential ) signalling with single-ended output buffers is a bad idea. All of your IO aren't even on the same IO bank. Do you have a good sense of how much delay variance internal routing can be for 32 pins? Have you worked out a rough timing budget for this? This discussion assumes that you don't care about pair-pair skew for your application. Differential signalling is great when implemented properly and sent through high quality transmission lines. My sense is that you are being a bit overly optimistic. The problem with differential signalling is that there is a whole new way to achieve illegal logic states with 2 complementary signals. You can't fix bad data. Personally, I'd find a platform more suited to such an application. If 16 true differential pin pairs with differential PCB routing and a suitable connector weren't available I'd consider using external single-ended to LVDS drivers. Maxim, I believe that they are now part of ADI, has some nice driver/receiver ICs for conversion between single-ended and differential signalling. The Mimas-A7 has the kind of length matched IO that you want. The IO banks are all 3.3V Vccio, but you can change that to 2.5V or 1.8V by changing one resistor in the power supply design. I'm not recommending anything, but just trying to point out that looking around for hardware that suits the needs of a particular project is worth the effort. You can do a lot of work and end up with a less than desirable working platform. How much is your time worth? Digilent sells a limited set of (really old) PMODs and FPGA boards that are designed to sell those products. Not all vendors in this market use that business model. I really can't imagine what your application is, but transformer coupled logic is a whole other kettle of fish to chase around... But don't let me interfere. I'm just trying to flesh out ideas that I believe you need to consider.

I managed to install ISE 14.7 on my WIn10 box. IMPACT doesn't work on that OS either. The problem is 32-bit compatibility most likely. I still use Spartan 3 and Spartan 6 and ISE on a modern OS can create a bitstream. For configuration on Win10 the Adept Utility for Windows works just fine ( for supported devices ). For devices that aren't supported it's possible to add a line to a text file in most cases. Those old PCs running Win98 might be just fine for Centos 7 or other ancient Linux distribution with Kernel predating 2.7. One way or another if you won't or can't find a tool that's compatible with the OS that you want to use you have your work cut out for you. But Tumbleweed? Don't expect to find that on the list of any compatible FPGA vendor tool supported OSes. Some people like a challenge more than productivity.

@asmi, Yes, I just finished another post about SYZYGY and somehow managed to forget about the SYZYGY equipped carrier boards that Digilent sells; 1 A-100T, 1 Z7020 and two UltraScale+ ZYNQ boards. The eminently forgettable Eclypse-Z7 has 2 SYZYGY ports and a rather bizarre PMOD design, all of the others have only 1 ( but in at least 1 case an FMC connector ). Opal Kelly's tiny Z7012S based Brain-1 Crowd Supply board has 3 standard SYZYGY and 1 transceiver ports. Opal Kelly supplies KiCAD footprints for a basic pod design, though it seems that every time KiCad releases an update all of the older component footprints become incompatible. Nevertheless, SYZYGY might be a reasonable option if you are going to design a custom board that you want to connect to an FPGA carrier board. I suggest looking at the boards that Opal Kelly has in stock at the moment ( though I don't know if that guarantees immediate shipment ). The Mimas-A7 has a lot of well matched IO with an A7-75T FPGA. You can change one resistor to make them 1.8V or 2.5V logic compatible for true differential IO. Unfortunately Artix Series 7 devices have no HP IO banks and thus no internal differential termination, which is the ideal place to put them for receivers. You can view the Mimas IO length report without having to request it and before you decide on a purchase. But thanks for the correction.

Impedance matching and PMOD are not compatible terms. Once you've gone through one right-angle 0.1" xn header and it male mate any impedance matching for the PCB traces between the driver and the receiver is pretty much destroyed. I've never seen any information from Digilent about their standard PMOD PCB trace characteristics. What they publish for the other PMOD headers without the series current limiting resistors varies but don't expect 50 ( I think that I've read 70-80 ohms one on of their board reference manuals, but I don't believe that this is consistent from product to product). They do provide trace lengths for FMC connector traces if requested. These are the only connectors requiring impedance matching that they use. I do hope that someone from Digilent does provide the information that you are asking for though.

What you don't mention is the FPGA platform that you intend to use. I imagine that you are using the USB104 with one SYZYGY port. The 3 PMOD headers are low data rate interfaces ( < 10 MHz ). connecting a PMOD DAC that works at 100 MHZ Fs isn't going to happen. If your DAC sampling bandwidth is below the 500 KHz or lower range then you might have a fighting chance. I guess that it all depends on what you are trying to capture with an ADC and what you want to see out of your DAC.

Let me make a clarification of sorts. I use the Ethernet PHY as a data pipe only for point to point communications. That is, I don't try, or even want to, support all of the features such as fragmentation, collision detection and recovery, internet connectivity etc. But a more constrained approach is very useful, and not at all a security risk. ( In fact I believe that an FPGA based internet appliance has great potential as an internet security product... any takers out there? ). You can even connect multiple nodes through a switch by implementing the discovery and broadcast modes of the ARP packet. A node can be another FPGA or software running on a PC. Data packets can be anything that you want or need to define them as. It's all very doable in a slow grade Artix or Spartan 6 grade device. When I say ideal, I'm mostly referring to the physical connectivity which is full duplex, magnetically isolated, and has cheap cabling available at the local hardware store. The older generation of 1 GbE PHYs are remarkably robust for packets with payloads < 16 KB over 2-3 meter CAT5 cables, even without error checking. It's almost too good to be true. Kudos to Digilent for designing their boards with a 1 GbE Ethernet PHY that comes up ready to rock. Another aspect of Ethernet verses other serial interfaces like USB is that packet size is variable, packet definition is a blank slate ( past the synchronizing preamble ) and software doesn't affect its performance. USB performance is very dependent on OS kernel performance and driver/application design; and latencies are unpredictable and generally very long. You can have synchronization timing in the 10s of ns range over Ethernet. If you have a PCIe FPGA board with a 1 GbE PHY in your PC you don't even have to think about packets ( in the software application ); you can just DMA streams of data. Ideal for someone like me who hates writing software applications. The catch there is the OS driver. It does take a bit of work to figure out. UltraScale devices make the PHY interface more complicated and the Vivado IP is total nonsense. It's well worth the effort and hours spent learning. A lot of the learning for me was spent creating experiments. Playing for fun and education is even more useful for competent FPGA developers than it is for those just trying to learn it.

Can you provide a bit more information to help understand what you are trying to accomplish? How are you intending to compensate for PCB trace length mismatch for outputs? I can't say for sure, but I suspect that all of the standard PMOD signals end up being auto-routed after all of the other nets have been placed; so there is likely a very wide variance in trace length. Also you need to address the series current limiting resistors in the standard PMOD IO traces. Digilent has provided limited trace length reports for FMC and the -nonstandard PMODs. A platform more suited to your project requirements might be the best way forward, but it's not possible to provide any useful guidance with the information provided. "Timing critical application" suggests to me a way of connecting external things to your FPGA through well designed transmission lines, which would include the a consideration of the connectors as well as termination.

I completely agree with that argument. There's a price to pay of course; some of your logic needs to be clocked at at 4x - 8x the maximum toggle rate of the signals that you are sampling. This isn't usually a big deal, especially if you can leverage something like ISERDES. How much over sampling you need depends on a number of factors. Some FPGA devices, notably the Cyclone devices from Intel have artificially limited clock network frequencies to push customers toward more expensive devices and annual tool subscription expenses. If the transmission line between the source and receiver is of poor quality a simplistic implementation of oversampling might not work out well. This shouldn't be the case with components on a fabricated PCB. If your source goes through a PMOD, then that's another story. Overshoot/undershoot does bad things to digital logic. For compensation of line length mismatch there's always IDELAY. It's a shame that Series 7 devices don't have output delay compensation. Earlier devices had both. All of this discussion might be a bit much for someone thinking about operating an entire design from an Ethernet reference clock, if that was your intent. But at least you have some ideas to work with. We've come a far ways from answering your original question, but I suspect that it's all the better to get answers that are off-topic but more germane to getting your project implemented correctly.

So, you do have a sense of humor. If nothing else I've got you to support, in your own words, my argument that MT/s isn't particularly informative when choosing an FPGA platform, nor is talking about details that are informative "off-topic".

Asynchronous design is often a fine approach up to a point. For 10 Mbps SDR serial data this might even be preferred as suggested by the quote above. If you can control timing by design, rather than by constraints it's usually a good way to go, though you may run into portability issues using a wide range of programmable devices. For RGMII interfaces the asynchronous approach is going to become problematic, especially for 100/1000 Mbps. In general, I'd want to stick with the synchronous design approach for Ethernet interfaces. It's one way to conceptually maintain a common design approach to an interface that has a lot of variation in the PHY logic interface. For something like SPI, with a limited variation of the PHY level interface I take it on a case by case basis depending on the SCLK frequency. If you are clever you can take whatever design approach you want; as long as you don't violate or ignore fundamental digital design concepts, especially when dealing clock domain crossing logic, or fail to understand how the external hardware that you want to connect to your design works.

And what does that statement have to do with QDDR memory? Nothing. I can think of a lot of video applications that require very low latency high density external memory storage. Quick, name all of the cheap FPGA boards with QDDR memory that Digilent or a similar vendor sells. I can't think of a good reason to respond to your other comments, but it is refreshing to have you actually try and have an intelligent conversation rather than the usual stuff.

Absolutely. Ethernet interfaces have 2 separate clock domains. I'm not sure that this is what you are attempting to simplify, but if it is, you can't. Even for a 10/100 Mb/s Ethernet PHY interface you need to provide proper timing constraints if you want a reliable interface. Actually, it's good practice to supply proper constraints for all IO, even if it doesn't seem necessary. For trivial learning endeavors you can pretend that this isn't a necessary step in the design process, but as your designs get more complex and use a high percentage of the FPGA resources the illusion that what's running on hardware is representative of simulations disappears. More importantly, you cannot treat the Ethernet PHY Rx and Tx clock domains as related clocks.

I don't use AXI busses for non-ZYNQ designs. I've never seen a company use IPI or AXI busses for commercial designs for a variety of reasons. The IPI flow isn't all that it appears to be. Making timing with poor constraints does not result in a robust design. Adding registers or pipelining is a limited technique that doesn't necessarily resolve system timing closure; this depends on a lot of factors. Great! Publish your example project using QDRII on a Nexys Video board. QDRR is mostly found on FPGA based NIC cards and is a low density ( 1 MB or so ) very high power dissipation design solution. For sure, the basic idea that a design should use resources that are best suited to an application is unassailable. In fact, that's been at the heart of everything that's I've posted to this thread. With a board like the Arty A7-100T or the Nexys Video, you have to work with the resources that are available. My professional experience is designing application specific hardware not general purpose boards for educational experience. I'm not suggesting that Digilent's FPGA boards are lousy, just the marketing that promotes misleading ideas about what they are good for.

I think that you are making what's generally referred to as a "straw man" argument; fabricating a specious scenario that seems to debunk an unrelated statement. 166 MHz SDRAM is a fairly slow grade for what's available. SDRAM devices aren't limited to 16-bit data widths. And how doe you calculate your assertion that 333 MIB/s is too slow for 1080p video; assuming that you are using a narrow, slow SDR memory interface? So, by your calculations a 32-bit SDRAM interface that only runs at 166 MHz can do 666 MiB/s which is fast enough to support 2 channels of 100 Msps 16-bit ADC or DAC data. My reference was for educational FPGA platforms. Most such project s don't require anything better. If you don't need vendor IP for external memory, then so much the better for an "educational" FPGA board.

You may be correct about this.. not sure why I was thinking otherwise. For now, I'll stipulate that you are correct. I disagree with that premise based on experience. I'm not talking about the MIG controller per se., I'm talking about the logic that controls the MIG and has to work with a number of other interfaces using unrelated clock domains and IO that can appear on any IO bank. For some designs you might be correct, not so for other designs. I disagree. Latency is a system issue. Some systems require low latency DDR read operation. Making a broad statement about the MIG controller isn't much value for every particular use of the MIG or external memory.

I do a lot of designs using Ethernet connectivity. Yes there are situations where the MMCM/PLL design runs into issues with competing clocking requirements. One such case is when you have a lot of clock domain requirements for external interfaces, such as video and MIG/DDR3 and USB in a design. Fortunately, the overall clocking resources in a device like the Artix A100T allow you to overcome such obstacles. For instance, you can use clock4 out of one MMCM as a source for a secondary MMCM. If you choose your MMCM setup carefully, you can pretty much work out a way to resolve these issues. Sometimes an interface requires an odd clock frequency that you can't achieve from a standard 100 Mhz external clock source; but generally the solution is a second external clock source. One thing lacking in Digilent's FPGA boards is a programmable external clock module. For some platforms is this an annoyance. For other platforms this is an unforgivable board design flaw. What you are doing is opting for a low quality oscillator as an external clock source instead of a higher quality external clock source. You are free to do that if you want to but it's not an optimal way to do things. As for constraints, I'd suggest getting proficient at adding these into your designs. As Vivado wants to control constraint management the tool is a impediment to this. If you are doing the HDL design flow, then you can control this vital part of the design process. The more control you have as opposed to letting the tool manage aspects of a design project the happier you will be for complicated project that need to survive years of life span. It's more work to assume responsibility but the alternative eventually just doesn't work.

All of the projects that I've published use a state machine that uses about 1/4 the maximum achievable bandwidth of FPGA vendor external memory controllers. The example design that the MIG provides runs a the full bandwidth, which works out to about 90% of the peak data DDR bus rate (on average for large blocks of data ), 1440 MiB/s for the Nexys Video board for instance. I've achieved these levels of bandwidths for testing board performance and simple MIG use cases, but for real world designs, like you are working on, achieving timing closure get to be very difficult. It's due to the way that the MIG UI interface works. The external memory controller for cheap Intel FPGA devices works differently than the AMD/Xilinx one does and exhibits a much lower read latency. It's also a lot harder to use effectively, due to poor documentation laden with errors. The MIG only supports BL8 mode for any of the devices that I've worked with using DDR3. Some DDR memories are limited to bursting of 8 cycles, but most can do double that or more. Higher burst cycles make for better efficiency and achieving the best performance while simplifying timing closure. I don't use soft-processor IP in my designs, but I'd think that you'd want to implement a fast BRAM cache with external memory as that's how the devices are designed to work. Caching instructions and data, has it's own issues of course. Again, some people are enamored with not very helpful stats like MT/s, but for anyone actually trying to use DDR in a real world design things get very complicated quickly. I believe that for the kinds of educationally oriented FPGA boards that Digilent makes, a couple of independent SDRAM interfaces would be preferable than one DDR3 memory interface. Yes, the data rates are lower but you can implement more than 1 external memory interface because the pin requirements are lower. Timing is way easier for SDR interfaces and users don't need to be tied to vendor IP. For a board with high data rate external interface sources and sinks this would make more sense. So for something like the Eclypse-Z7, instead of a Z7020 with one PS memory serving PS and PL needs, an Artix device with 2 SDRAM interface that allowed for simultaneous ADC and DAC external memory accesses, would have been a superior approach. I don't think that the Eclypse-Z7 was designed for users however. Terasic sells a number of relatively inexpensive boards with both DDR and SDR external memory.

@robfinch, What specifically are you confused about? Your analysis is correct; a 400 MHz 16-bit DDR bus is capable of a maximum of 800 MT/s or 1600 MiB/s ( 400 MHz * 2 transactions/clock * 2 Bytes/transaction ), where Mi refers to 1000000 and MB refers to 2^20 ( 1048576 ). When we are talking about DDR memory. the DDR bus isn't the limiting factor as data transfers are initiated with commands from a controller in the FPGA to a controller in the DDR memory. There's more to the story, and I've raised some of these details in a tutorial that I've posted on the Digilent forums. For DDR memory interfaces, that 1600 MiB/s figure is the absolute maximum data rate and can only be sustained during bursting read or write operations, and that doesn't include the command time or for read operations the latency from command to data. In addition, DDR requires refresh periods which inhibits data transfer for other purposes. But your post supports my notion that this isn't all that obvious to most users of Digilent's FPGA boards. It also supports my notion that a single performance claim, like MT/s is not all that useful. In real world usage DDR connected to FPGA devices has a lot of particular details that might have a negative impact on any particular use. This is especially important when there is just one external DDR interface and the user needs to support data going into and out of the same DDR interface. When data is coming from or going to video or Ethernet sinks or sources, this can be very problematic. This is what I described previously. Even though one person thinks that this is off-topic, it certainly isn't if you actually need to implement working projects on platforms that aren't designed by people who do such projects. I suspect that this is why board vendors prefer to market their products with one simplistic number rather than raise awareness of a fundamental weakness of their products that are sold as being suitable for certain applications. BTW, very few vendors of cheap FPGA boards even provide support for using a crucial component of what the customer is buying unless they are willing to waste a significant amount of the FPGA's resources with superfluous baggage like a soft processor. Digilent has never been one of the vendors who puts their customer's interest above that of the FPGA vendor's.

Of course you can use an Ethernet PHY to connect things without a processor. The PHY is essentially a standalone cable modem with an interface that can be as simple as a DDR interface or complicated as a transceiver interface. You don't need a MAC either, regardless of what the FPGA vendors want you to believe. For 1 GbE or greater data rates it sure is easier to have a PHY that's accessible by logic. In the case of the Eclypse-Z7 there's no Ethernet PHY on the board that the PL has access to. There is another option, if you can make do with using just one of the SYZYGY ports for ADC or DAC functionality; Opal Kelly sells a 1 GbE Ethernet PHY pod with a SYZYGY interface. This means that you can acquire ADC samples and transfer them off of the board without the PS even being aware of any of it. Essentially, you are turning the Z7020 into an A75 device. I've used this pod and can say that it works. The problem is that all of the FPGA vendors really, really don't want you to use an Ethernet PHY functionality without a processor so they make such hardware as hard to use as possible. An alternate way to transfer data between your Eclypse-Z7 and a PC would be to use the very odd PMOD design. It is possible to connect a FT4232H module to 2 PMODs and have 4 12 Mbaud UART channels connecting your 2 ADC or DAC devices to a PC directly. No this isn't close to the 120+ MiB/s of a 1 GbE Ethernet PHY, but it's a possibility and one that might be easier to implement. 3-5 MiB/s is better than 0 MiB/s. The ZYNQ GEM is difficult to work with, especially if you aren't running a version of Linux on your PS cores. Doing it in hardware is less convoluted, but requires a fair bit of knowledge about Ethernet packet structures and a solid digital design capability. The nice thing about doing it in hardware is that you can control all of your source code and not rely on any vendor IP. As to how the Opsero Ethernet cards are going to help you with you Eclypse-Z7 I'm baffled as, except for the Opa Kelly SYZYGY Ethernet pod, there's no way to connect to such a board. I've used one of Opsero's FMC Ethernet boards, and it's a well designed and supported product though I don't use any of their demo projects for reason that are beyond the scope of this post. My advice is to take the time to learn about Ethernet layers. For simple point to point communication, you only need a couple of packet types to connect with a PC. It did take me about 1 year to learn enough to be productive. Most people are smarter than I am. For the HDL implementation of Ethernet I'd suggest using a platform more suitable.. just about any FPGA board with a 1 GbE Ethernet PHY should do. You might want to start with a soft-processor implementation and then start working on a second project that doesn't include either a processor or MAC.

I believe that you meant to say off-topic. So, either you didn't bother to read what I posted and just wanted to criticize the length of the post or you'd prefer buying board A, capable of 1600 MT/s over board B capable of 800 MT/s even though board B has 2X the peak data rate because of the difference in DQ bus width? How is this part of the discussion 'off-topic"? There's a lot more to understanding FPGA-DDR performance than one over-simplified and misleading number. You may not care about that, but I do. DDR devices weren't designed to be connected to programmable devices. I don't now of any DDR3 devices that can't operate much faster than the FPGA that they are connected to on the kinds of boards that Digilent sells. I don't care at all about people criticizing my posts based on delivery. When someone can't think of any technical issue with the content and then wastes their valuable time to post criticism of the messenger that's a statement about them, not the messenger. I know that you like short posts, unless you're the one doing the posting, but you're the only one complaining about it. Don't smother the debate with personal grievances. If you've got a problem with an argument, write about that, not about the way that it's presented. What's important for a forum like this one is presenting useful information, not petty nonsense.

Anyone, who's owned a dog knows that while the lone wolf (dog) howl starts as a solo it ends up as a chorus as the sympathetic neighbors catch on. So, does breaking up a long string of text make it easier to digest my wordy attempts at communication for those with brains trained on social media?

AaaRooooooooo! I'm impressed, though it ignored my, belabored to some people, point about MT/s nonsense. Now about those "differential PMOD" references, and more importantly appearances....