zygot

This comment represents experience in experimentation for a typical approach to an HDL UART implemented in logic. Really, it can be worked out by math, as it comes down to how many samples, in an asynchronous over-sampled approach to determining the center of a baud period, can one get at a particular Fs for a particular baud period. Again, we're talking about a UART, not an USRT. In this case the empirical testing is probably a bit more realistic than a back-of-the-envelope calculation as all of the factors in a physical implementation have been taken into account; factors such as IO buffer slew and delay, relative clock accuracy errors, etc. For the experiments I'm referring to an HDL UART on one board communicating with an HDL UART on another board. An HDL UART connected to a USB UART bridge device is another matter. FTDI USB bridge devices use a low accuracy 60 or 120 MHz oscillator for timing. The relative Fs for sampling Tx/Rx transitions is important. For anyone interested here is a proect and a tutorial that I've published on the Digilent Forums: https://forum.digilent.com/topic/20479-inter-board-data-transfer-project/ [edit] I corrected the link above that was pointing to the wrong project. Apologies to anyone who was confused. https://forum.digilent.com/topic/24531-debugging-with-the-ftxxxx-mini-modules/ Both of these are based on the general idea of asynchronous logic design for serial communications where clocking on both ends of the interface are independent ( that is an wide baud period error with respect to the Tx and Rx ends can be tolerated); that's the whole concept of a UART. Both projects have HDL source code and can be built on an arbitrary FPGA platform(s). Both designs can be fully simulated using VIvado ISIM. In the FTDI tutorial, we do the maximum 12 Mbaud that the FTDI 'H' devices are capable of. As for using a 1 GbE PHY as a modem to connect FPGA boards together, or even an FPGA board and a PC together for data transport, this is an almost ideal approach ( at least from a hardware perspective ), as long as you eschew FPGA tool vendor IP and use the all HDL approach. I've been using both UARTs and Ethernet extensively for such purposed for years.

I don't understand what that sentence means. Are you sure that you understand or have enough information to understand what you are designing to? At high baud rates there is usually hardware flow control as elastic storage isn't generally very deep. Something on the order of 12-13 Mbaud for a UART implemented in logic for the Artiix is about the upper limit, if you logic is clocked at 100 Mhz. For the typical 10-bit/baud period UART a 10 Mbaud rate translates to about 1 MiB/s tops.

After years of reading posts to the Digilent Forums, I'm not all that convinced that most buyers of Digilent's FPGA products are all that savvy. Even people who can do their homework might be snookered by misleading marketing claims, especially for devices as complex as DDR memory, and not take the time to do their homework. While MTs/s has an aura of technical profundity to it, it's actually pretty useless as a far as telling potential customers about what kinds of applications the board is suitable for. The Nexys Video DDR on a board designed for Video applications does 800 MT/s and the NetFGPA-1G-CML, a board design as a quad Ethernet NIC does 1600 MT/s... so, quick... which is the more capable board? Well, the Nexys Video has a 16-bit DDR DQ bus, so it has a 1600 MiB/s peak data rate between the DDR and the FPGA. The NetFPGA-1G-CML has an 8-bit DQ bus so it has a peak data rate of 1600 MiB/s. Both of these boards are capable of simultaneously being data sources and sinks. In the case of the Nexys Video this is HDMI or Display IN and OUT ports operating at fairly high data rates. In the case of the NetFPGA board, this is 4 full-duplex Ethernet 1 GbE PHYs plus a PCIe connectors. In both boards, the DDR is, by design, a bottleneck for high performance designs, doing what their names suggest they are supposed to excel at. For experimentation or as an educational platform they are both fine, if expensive. Does anyone really believe that someone without experience in either video or Ethernet applications is really going to work all of this out while trying to decide on a purchase that needs to be made *real soon now* ? Slimy, misleading marketing hype is, I'm afraid is always going to be thrust into the potential customer's eyeballs, whether intentional or not. The storage media companies have been doing this for decades. They just decide to redefine MB as 1,000,000 bytes and put a teensy disclaimer buried deep in a place where no one is going to read it ( on advice of their lawyers ). The difference may not seem that significant, until you start talking about terabyes of data. It would certainly be swell if Digilent cleaned up its DDR performance misinformation but I've spent 7 years trying to get them to stop peddling "high speed differential" PMOD interface connectors to no avail. People are still trying to implement LVDS_18 interfaces on boards with no possibility of success. But surprise me Digilent, show us that you can be above the sleaziness level of product promotion. BTW, the Nexys Video doesn't need to be sold based on misrepresentation or confusing marketing. It's far from the fastest Artix device, but it is the biggest in terms of resources. It lets users experiment with transceivers using the mDP IN/OUT connectors. It has a LPC FMC connector. It's not over priced for the educational opportunities that it affords its users, even if the DDR is anemic as a supporting function for it's fine video capabilities. The NetFPGA has limited usefulness, unless you want PCIe connectivity and 4 1 GbE Ethernet PHYs for very limited NIC designs. Don't buy it unless you are prepared to develop everything from scratch, as if it were a custom prototype and you are the guy who has to see if everything works based on nothing more than the schematics ( and this board has the distinction of having the only schematics with errors that I know of ). The company that contracted for Digilent to design it disavows any knowledge of the board, and Digilent provides no useful support. Having said that, I do use the board for some applications

Ignoring the frequencies, parts of your proposed diagram, like a MicroBlaze subsystem certainly can be implemented using the IPI design flow. You don't mention what platform you intend to implement this project on, and that's an important consideration that qualifies any useful answer. Let's start at the end, where a 16 Mbaud UART is spitting out data. Where is this going to? There are devices that have UARTs capable of such rates, though once you get into the design you will likely find that the last 10% of the implementation requires a lot more than 10% of the effort. If the data sink is a PC, I don't know of any USB UART devices capable 16 Mbaud; 12 Mbaud is certainly achievable, with a bit of effort. A true UART at 16 Mbaud isn't trivial to design, though a USRT ( the asynchronous receiver/transmitter's synchronous cousin ) might be, depending on a what's receiving the data. You aren't going to find ready made free IP in the Vivado IP catalog for such a thing. I've posted couple of projects with HDL source code in various sections of the Digilent Forums if you want to understand how "simple" serial communications work. The nice thing about the IPI flow is that you can do a number of things "quickly" using the free IP provided by tools like VIvado. The not so nice thing about the IPI flow is that it's an impediment to developing project like the one that you propose when there isn't the free IP supporting it. A case in point is a UART, or Ethernet, or really any useful serial interface that isn't connected to a complicated bus like AXI (Vivado).

Doesn't seem that there a very many people interested in joining this conversation but I've thought of something to add. If you have any interest in partial configuration for AMD/Xilinx devices you will need to understand DFX, the latest version of their partial configuration schema. Partial configuration is pretty important for ZYNQ developers running an embedded version of Linux or even perhaps an RTOS as it would be nice if you you could change HW functionality on the fly depending on what you want to accomplish. It's also of interest to anyone trying to develop applications that involve connecting an FPGA to a PC host via PCIe. In this case the logic that implements the PCIe functionality can't be disturbed on the fly. So, why am I bothering to mention this? Well, DFX appears to be complicated enough that trying to do it without tcl scripts would be a daunting challenge. I am by no means competent in using DXF at this moment. If I have a point, it is that even those of us who are convinced that becoming comfortable with script writing as a normal development flow will have to make adjustments as the tools get more complex. As new products, like the Kria are introduced, you can be sure that the development flow is going to get more complicated. DFX is now at the top of my personal improvement list. Fortunately I have a KC705 which is one of the boards supported by the tutorial. I have a ZCU106 running Ubuntu 20 that sorely need it..

I don't think that you quite grasp the meaning of "ignore". Instead of posting nonsensical vitriol I'd be impressed if you could put forth a cogent argument as to what, specifically, about anything that I've posted in response to your question here that you find to be "ignorant garbage". Please do take the opportunity to correct any misinformation that's been posted to this thread. This is your chance to make yourself a useful member of the Forum community. No one cares about how you feel. Readers might care about what you know, if it's technically supportable with facts. If all you want to do is vent shear nonsense I think that there's a place for that... perhaps Twitter? The Digilent Forums are not the plce to embarrass yourself with such outbursts. Again, anyone can post reasonable answer to questions, regardless of how vague, to public posts.

It makes a big difference if you are talking about the Arty A7-35T or the 100-T versions. Is there a reason why you'd want an external clock for a low speed Ethernet PHY? Fortunately, the Arty A7 seems to have a number of clock-capable pins connected to PMOD headers. BTW, it's not clear as to what you are referring to in your reference to "The 25MHz clock chip has an existing footprint on the board. ".

Here's the original ( from 2 years ago! ) toplevel entity. It likely isn't going to make any sense unless you've used Opal Kelly's FPGA boards before. The component ddr3_test is a modified version of supporting code to test external memory provided by Opal Kelly. I did it this way to shorten the spin-up of my first effort with the ZMOD/XEM7320. This is an all HDL plus Windows/Linux software project. Compare that to the mess that is the Eclypse-Z7 repository; it doesn't matter if you are using the Standalone or Linux software tools. I have no problems with the 2 track HW/SW development flow of ZYNQ; everything is just a lot simpler, easier, and faster when you understand all of the text source code and minimize time spent battling the tools and vendor IP and software libraries that you have no control over. I spent a LOT more time just running experiments with the Eclyspe-Z7 than it took to get this project working. There are plenty of things to complain about with the Opal Kelly boards and support. But what might make them a reasonable choice for real world FPGA project development is that you can, once you get past the learning curve, create a functional application with very fast and stable USB 3.0 connectivity to a PC software application. Since it all HDL, maintaining projects over years of development and tool versions is a reasonable endeavor. For anyone wanting to do ADC/DAC FPGA based projects using the AMD/Xilinx tools the XEM7320, even after 2 years, is the best platform that I know of. This doesn't make me happy, by the way. Someone has got to create a SYZYGY FMC mezzanine card that works with the Genesys2. Forget the SYZYGY transceiver port, hook up the MFC transceivers to a 4-lane iPass connector ( $12 in small quantities ). ADC_ZMOD1410.vhd

If you are going to use a complex device like an FPGA you might as well learn something about how it works and its capabilities. AMD/Xilinx tools come with the Documentation Navigator with plenty of user guides, application notes and other information to help with this. Use it. The 7 Series FPGAs SelectIO Resources User Guide has most of the information that you need to answer your questions. In addition, the schematic for your board is required, because IOSTANDARD availability is limited to the Vccio that powers the IO bank that the pins that you want to use is connected to in the board design. For PMOD IO this is 3.3V. There are no differential IO standards supported for these, except for TMDS_33. The User Guide shows you what termination is required to use that IOSTANDARD. It would be nice if FPGA board vendors were a bit more informative about the true capabilities of their boards, but most seem to adhere to the "buyer beware" model of advertising. In the case of Digilent's so called "high speed differential PMODs", the advertising is blatantly misleading, even for the boards that have user-selectable Vccio voltage supplies on certain IO banks. Cheap FPGA boards that allow the user to experiment with all of the IO options of their programmable devices tend to be on the expensive end. Sadly, you question is a common occurrence on the Digilent forums. The marketing folks at NI don't seem to care.

ISE was the name of the tools from Xilinx before Vivado came into existence. The last version of ISE was 14.7. ISE had limited support for Series7 devices, particularly package options.

Is it possible that DwfState enumerated as 6 is not unused, but perhaps undocumented or reserved?

No version of Vivado supports any Spartan 6 or Spartan 3 device... or any device that predates Series 7. You need to use ISE. Even locating a version of ISE from the AMD/Xilinx archives that supports Spartan 3 devices is an adventure. If you are lucky you might find a really old PC with ISE installed on it lying around. That would be your best bet for making these boards usable.

It should be noted that AXI DPRAM size used with the AXI BRAM controller is very limited (8KB). Yes, you can instantiate lots of controller/BRAM instances but the cost is high. A further problem to solve with many of these solutions is knowing what the scope of the data in the shared memory is at any point in time. You could implement a mailbox connecting your ARM cores to the Pl logic. My point here is that all of these solutions have some non-trivial issues to resolve in your design approach. Tip: AXI addressing is byte oriented.

I don't think that you will find any Artix7 or Z7020 based boards with HP IO Banks.

Don't hold me to this, but I've used PC power supplies in the past in lieu of a good lab bench power supply. As I (seem) to recall there has to be a minimal draw on, I want to say the 5V supply, but it could be the 12V supply, or it will shut down. this might be an avenue for inquiry as to what's going on with your board.

Troubleshooting a complex, multi-voltage power supply on a board with a sequence controller isn't easy. The older Xilinx boards used a lot of power supply modules that had serial interfaces for setup and debugging. Most boards are simpler. I had a KC705 that decided to prevent FPGA configuration. The vendor that made the board wanted about the same amount of money just to check out the board as a new one would cost. You might have some luck with a bench supply that has voltage and current controls and meters, but unless you are a power supply expert, and I'm assuming that you are not, then the odds are not in your favor.

The Genesys2 borrows heavily from the KC705 board design which uses the same FPGA device/package. For the XC7K325T FFG900 package all of the HP IO are on banks 32,33 and 34. The Genesy2 has a pretty capable DDR3 design which requires HP IO banks. For the 32-bit DQ design on the Genesys2 this doesn't leave many HP IO free, certainly not enough to populate a HPC FMC connector. So, what do you want... fast DDR performance or MIPI interfaces? Of course you want both. FMC is not plug and play for FPGA boards. There are just too many devices and package options to design an FMC mezzanine board with high performance IO capability that will work with any FPGA carrier board having any device package. Always check the schematics for your FPGA board and any FMC mezzanine card that you are considering purchasing for compatibility. This means working through schematics for both boards and finding problems. This can be a chore. I've been preaching this for years on Digilent's Forums. Still, because of the way that Digilent markets it's products there are posts of unhappy customers. Heed the 'reverend' Zygot's warnings brothers and sisters. An FMC camera interface mezzanine card with an appropriate CSI/MIPI PHY might be a solution for the Genesys2 ( or KC705 ). The Genesys2 has an HDMI sink so this might be an alternate way to acquire camera data. I've done this with an SDI HD camera and an SDI to HDMI converter. The nice thing about this arrangement is that you can have the camera oriented in any direction regardless of how the Genesys2 is positioned. A few FPGA boards have SDI PHY interfaces (3G all the way up to 12G ) but these are not common.

Well, my first question is "What kind of external Power Supply are you using"? If it's a bench supply is the current output being limited? I know is sounds silly but I've got to ask. (been there done that...)

Yes, your current method is highly inefficient. You can DMA data between the PS external memory and your PL logic two basic ways. One way that I've done this is similar to yours. Implement DPRAM so that your logic has access on one port, and the IPI AXI IP in your block diagram has access to the same memory. You can even use the PS DMA controller to move data to external memory. Another possibility is to use AXI IP to DMA data between PS memory and the PL where the DMA is in the PL logic. There are a few different approaches to select from here. The best way to do this is to write your own AXI IP to DMA data between PS resources and PL logic. This is not a trivial undertaking. All of these methods retuire some kmnowledge of how PS/AXI works and the limitations involved. Nothing that's high perfromance is free or simple.

Recently, it's become impossible to post comments to the Digital Forums without having full on Java Script enable in the user's browser. This isn't even possible from some corporate PCs. For other users, it's an unnecessary security risk. Stop going down this path.

What's confusing you is that Vivado is happy to set your toplevel entity for synthesis as the toplevel entity for simulation and attempt to run a simulation if you tell it to. So, ask yourself: If I use the code in my toplevel project entity or module for simulation, what exactly am I simulating? Let's assume that you have a hardware design that has no input signals. Most programmable devices don't have in internal oscillator or clock source, so such a scenario isn't possible. A few programmable logic devices do have internal clock sources, but for this discussion they aren't relevant. But if you could have a logic design with no input signals, and we ignore external clock inputs, then I suppose that doing a simulation without a testbench entity might be useful. This would be a pretty rare case though, wouldn't you agree? Vivado does provide example design projects for some of it's IP, like the MIG. In this case, the example project will have a testbench so that you can run a useful simulation. Generally, trying to understand what's going on in these simulations is very difficult, but this is one possible way to learn about how to write a testbench. An easier way would be to see examples of testbench code written to help understand what a design is suppose to do. If you look around you can find these somewhere in the Project Vault or Tutorial sections. You won't become a simulation expert this way, but it is a good way to get started on the learning journey. Happy hunting!

There are some good projects published in various sections of the Digilent Forums with example testbenches for Verilog or VHDL HDL design flow.

All files that are in the Vivado project hierarchy have attribute settings. Among those settings are ones that tell the tools if the file is for synthesis, simulation, or both. Not all HDL constructs can be synthesized. A good testbench usually has a lot of statements that are not supported for synthesis. That brings us to the point that in order to so a proper behavioral simulation, the toplevel entity must be a testbench file, and this must be marked as being used for simulation only. If you look in the project heirarchy view and right-click on any element listed there you can view all of the file properties. Vivado ISIM is pretty good in most respects but not really easy to use as a general purpose logic simulator for proper a design flow. Proper design flow means creating a testbench for every entity in the hierarchy so that you can simulate all of it's parts independently from the bottom up. It is possible to add as many testbench files as you want into a VIvado project, but managing all of the simulation session possibilities is very unwieldy, unlike with a simulator like ModelSim. Lastly, logic simulators like ISIM or ModeSim only support simulation of logic; so for a ZYNQ device this generally means that the tools are insufficient for simulating the whole PS/PL design.

Any pin can be an output of a Series 7 internal clock. Only clock capable pins can be used as an input to the Series 7 clocking infrastructure. An advantage of using a logic derived signal as a clock for an interface like SPI is that you can control timing in your HDL design explicitly. As the interface clock period starts approaching internal routing delays and IO buffer delays this approach start becoming unmanageable. The advantage of using an internal clock derived from an MMCM or PLL is that you can ( must ) provide timing constraints to help control timing. Output slew rate and current drive settings are all part of the design. For either approach it's a good idea to verify signal timing relationships at the receiver end with a suitable scope. It's easy to under-estimate how much delay can be incurred due to place and route; and IO pins for an existing board are fixed. The transmission line bandwidth requirements for sending a signal from source to destination is dependent on the signal slew rate, not toggling frequency. Transmission line bandwidth is one concern; managing overshoot and undershoot conditions at the receiver end by controlling impedance variation is another concern. I don't actually have an S7 CMOD, so I was looking at an A7 CMOD. Every year those SMD resistors seem to be getting smaller when I look at them...

It would be convenient if any discussion about any of the tutorials or projects that I've posted were on the same thread as the project. This would make it a lot easier for anyone having issues to follow the discussions. The Digilent Forums are great, but not well curated or organized and even with their search tool it's hard to track down topics of interest. If all posts are in the same place this makes it a lot simpler for everyone. Thanks. And thanks for anyone providing solutions to issues.