zygot

I see that this is your second attempt at getting an answer to your question. To my knowledge AMD/Xilinx does not sell device specific node-locked licenses nor is there a way to "extend" a license. The only way to get a license for your board is to buy another board with the same K325T device and use the unclaimed voucher that comes with it. You can try the AMD/Xilinx support to get their opinion if you create an account.

There's no reason not to start learning FPGA development with a Nexys Video board, if you have one lying around. It has the largest Artix device there is and a lot of useful external functionality; decent DDR3, Ethernet PHY, DPTI USB 2.0, an FMC connector, etc. This depends on what your expectations are for your self-taught FPGA journey will encompass. If you'd rather do C programming and ease into actual logic design later, a cheap ZYNQ might be what you want. This path is more comfortable for people with a strong software background. Of course there's a soft-processor approach like MicroBaze or RISC-V. An RPI4 has a lot more horsepower than even a UltraScale ZYNQ board that's affordable , and you can manipulate IO pins to control external hardware; so you'd have to ask why even bother with struggling with the complicated Vitis/Vivado tool flow. For ZYNQ, some functionality requires running a Linux disto on your hardware and that involves even more complicated tools that must be run on a Linux host. Hopefully, you really want to learn logic design and how to do it using an HDL like VHDL, Verilog or System Verilog. To get started with this, you don't even need hardware. Just learn your HDL and how to write testbench code and simulate your designs. Be aware that using an HDL for logic synthesis might be a difficult change of mindset for someone comfortable with C or Python development. On the surface VHDL or Verilog statements and constricts appear to be very similar to ADA or C. Logic design entails quite different conceptual underpinnings. But this is programmable logic design. There are a number of projects designed for the Nexys Video posted in Digilent forums that don't use a soft-processor or extensive Vivado IP and use most if not all of the Nexys Video interfaces.

I don't use AXI much, even for ZYNQ designs. The whole idea behind AXI is that it can accommodate fast and slow peripheral interfaces on one bus. That's why it's so complicated. I tend to think of things like a display controller implemented in logic as a functional block. Usually, there's some data exchange involved in functional blocks. I try to decouple data pipe timing and complexity from functional block timing. Usually this involves the simplest data pipe implementation at the fastest speed and some data buffering as the functional block either sources or drains data. If you want to use a third party IP, such as AXI QSPI, and not have to create your own design, then you are stuck with the limitations of that IP... unless you can figure out a work-around. If one end of a data pipe is connected to a processor or ZYNQ PS, then you will be using some sort of AXI IP as a data pipe. I tend to go with the streaming IP for a number of reasons. There are a lot of things to consider when designing a system. People in a hurry tend to go with what they are comfortable with. This isn't always the best option. Unfortunately, you may not know it until near the end of a project when everything needs to work. This has always been a problem for complex systems involving logic design and programming. Experience is the best guide. ZYNQ has lots of functionality and resources like timers. Unfortunately, the tools change from version to versions, or add bugs, and make using these resource difficult. I try to avoid the tool version dilemma to the extent that I can. One possible way to implement a fixed time delay in software without blocking processor execution is to use the PL wisely. One could write a delay value to a PL timer block via AXI and have the timer block set/clear a signal that is visible as a gpio pin to the PS once the timer reaches that count value. A pin state change could initiate an interrupt. Doing this the first time will probably be something of a chore. But once you perfect the technique you have something that a tool version change won't cause a major headache. The advantage of all that work is that you have something that you understand and can control for yourself. I have no problems with quick and dirty solutions, especially for prototyping ideas.. as long as they work and implementing them isn't beset by roadblocks. The quick and dirty offerings of FPGA vendor IP are too often not as advertised. Something to consider....

Digilent has the ADEPT runtime and SDK, but also provides AXI based DPTI IP that is separate from the ADEPT code examples. I haven't used the sources from Digilent's vivado-library-master repository. According to FTDI's documentation, it's not possible to use synchronous 245 FIFO mode unless the FTDI chips is configured from the EEPROM to work in 245 FIFO mode and the D2XX driver is selected. The FTDI clock output is only enabled when in 245 FIFO mode. That's what FTDI says. Digilent's documentation seems to contradict this by claiming that you can use either synchronous 245 FIFO mode or asynchronous 245 mode without changing the EEPROM contents. Either they know something that FTDI won't share with the rest of us or there's a mystery here. Anyone can view the default FTDI EEPROM contents for their Digient board. I don't recommend that anyone try and modify this unless they know what they are doing as you can cause big problems.

It should be apparent that if you clock the ILA with ftdti_clk, then you can't use use it as an ILA data signal. Also, keep clocks and logic signals in their own lane, so to speak; don't use logic signals as clocks and don't use clocks as logic signals. Any design that uses the Genesys2 sysclk or a clock derived from sysclk, and uses ftdi_clk, has at least two clock domains in the design. Using signals from one clock domain in a different clock domain is a bad idea. There are ways to create copies of a signal in one clock domain that are usable in another clock domain. That's the proper way to go. When you create an ILA that is clocked by a 100 MHz clock that is derived from the Genesys2 200 MHz sysclk, and then sample signals in a different clock domain, you are forcing the tools to violate proper clock domain crossing techniques. At best this will cause timing closure problems. Most likely it will result in an unstable design. Here's a simple technique that I use to make sure that clocks that I think are there really are. Create a n-bit free-running counter that just wraps around from max count to zero. Send one of the higher count bits to an LED. If you choose correctly, you should be able to see the LED blink at roughly 1 Hz.

I have a project for the Genesys2 that uses the DPTI here: https://forum.digilent.com/topic/25315-using-ddr-as-a-video-frame-buffer/ Don't forget to install the ADEPT2 runtime and SDK. What are you clocking your ILA with? Doesn't seem that much is happening....

Generally speaking, harmonics are features of a synthesized signal that the designer gets for free.. and doesn't particularly want. I guess that the answer depends on how you intend to go about constructing your 50 Hz signal, as well as what the specifications for the signal ( other than harmonics ) are. There are a number of ways to synthesize signals. There are a number of ways to implement them in logic. Usually the prominent implementations are using a look-up table that contains pre-calculated samples, using a DDS type structure, or direct calculation using some algorithm. All of these will produce harmonics in the logic output samples. Then, once they are fed into a DAC and go through the analog circuitry that follows the DAC additional artifacts will be added to the signal. Then there's the transmission to whatever is receiving the signal... etc., etc... I suppose that you want some control over the prominent frequency components that aren't a 50 Hz pure tone. The way that one does any project like this is to simulate a prototype of their algorithm and implementation. This would be done first in MATLAB or OCTAVE using all of the high level features that these tools provide. Then, once you have a promising candidate, if using a algorithmic approach, redo the OCTAVE, but only using structures and simple keywords that can be implemented using an HDL such as VHDL or Verilog. Then you write your HDL implementation and simulate that using the Vivado simulator or your favorite alternative. Ideally, all of your simulation more or less agree ( accounting for differences in numerical dynamic range ). If you are using a look-up table implementation then your pre-calculated samples are what your output will be ( except of course for hardware dependent effects ) and the OCTAVE simulation is a lot easier. Only after you are happy with all of these simulations would you even attempt to create a bitstream and try it out on hardware. That's the basic idea. As for how one might synthesize a signal that meets some set of requirements.. this is a whole field of study. It really depends on on the specifications and what you are tryng to accomplish. If 50 Hz is just a reference to the signal cycle period, then there are a lot of possibilities that have been used. Instead of trying to manipulate a 50 Hz tone, you might combine multiple tones... similar to DTMF. Oh, and do you intend to construct a fixed signal or want to manipulate it on the fly in hardware? BTW. This is the kind of project that the Eclyspe-Z7 isn't bad for. You might find this project interesting: https://forum.digilent.com/topic/20299-fun-with-phasors/ You can read through the source code and documentation to get the idea of what's going on. There's even OCTAVE code. I wouldn't recommend buying an Eclypse-Z7 based on just one application, but you can see that for some applications, it's an acceptable platform.

For what it's worth, when partitioning functionality into logic or software for a system involving both logic and a processor, I try to keep both sides as simple as possible. For a Zynq or even an FPGA connected to a PC, let the logic resources do what they do best, and let the processor hw/sw do what your software environment does best. FPGA logic resources are great for controlling timing. Since your displays are connected to the PL, I'd make the PS code as simple as possible and use logic to handle timing. You can always use a signal from the logic as a status, and either poll it (blocking code) or connect it to the PS GIC. The problem with software is that implementing something with tricky timing might be simple when that's the only thing that your code is doing, but can get pretty hairy and complicated once all of the design functionality has been added, especially as you add more interrupt sources.

I've used the XM105 with the Genesys2 (HPC FMC) and the Nexys Video (LPC FMC). I don't know of a reason that the Zedboard couldn't use it as well; but you must do your own due diligence. Don't forget about Vadj when connecting FMC signals from a carrier board to anything.

I'll bite.. First can you provide a more specific description of what you mean by "adjustable harmonics" ?

The Zedboard has an LPC FMC connector. You should review the schematics for the Zedboard and the XM105 to check for compatibility. The FMC standard is designed so that LPC and HPC sockets are compatible; LPC just has fewer contact pins installed. Be aware that most of the XM105 signals are single-ended only, even if they are differential on the carrier board. You do get a nice programmable external clock source with the XM105.

Really... I wasn't going to read this thread again, and then you replied to my post. I haven't tried the 2023.1 version of Vitis/Vivado. It does seem that there were major changes. This is what Xilinx has always done; the new release breaks projects developed using older versions of the tools. For commercial users, this might encourage yearly license expenditures. For small companies and educational/recreational users who don't have $3500+ per seat to spend every year it's a major pain in the arse. 2019.2 saw the elimination of most of the old SDK and the introduction of Vitis. Huge impact for ZYNQ development flow. One version of Vivado, it might have been 2019.1 changed the IP database structure. More work for people using old HDL code containing Vivado IP ( like FIFOs ). It never ends. The Z7020 is ancient. You don't get any benefit from using a recent version of the tools. In some ways you lose; like having IP depreciated. I've been doing programmable logic development for longer than Xilinx or Altera has been making FPGAs. I've learned to incorporate some self-defense measures in order to keep my sanity ( or what's left of it ). One of these is not to keep up with the never ending "improvements" that break my IP and previous work. I use Vivado 2019.1 and 2020.2 almost exclusively. Both have their own bugs, and a few shared ones; but I know what most of them are by now. Yes, I do stumble into undiscovered bug once in a while ( this just happened a week ago with regard to IDELAY, using code that previously worked with a different clocking structure). A general rule of thumb is to use the version of the tools that came out with the device that you are using. This might mean using an older PC and OS. But the Vivado 2018.3 installer could fit on a DVD. I would suggest using the same version of the tools that your FPGA board vendor uses for it's product demos and support. While Digilent is not going to make public its Waveforms support for the Eclypse-Z7, it does supply something for that board, and it's a lot more than they do for most of their other FPGA boards. There are a lot of facets to FPGA develoment, especially ZYNQ development. Unfortunately, some of these involves figuring out how to be productive in spite of the best attempts by the tool vendors to throw boulders in you path. It's not just about the technical details for devices. Be kind to yourself and make the experience as happy as possible.

Stop with the commentary that you find to be not at all helpful. So noted... I apologize if my comments seems snide; they aren't at all, I just hate to see someone struggle unnecessarily. I agree that Vivado is buggy and difficult to get along with. But it still understands VHDL, Verilog and System Verilog. My theory is that the more control that a developer has, the easier the overall effort in the long run. That opinion is based on experience using tools from all of the FPGA vendors. With ZYNQ you need to use AXI bus structures, and you need to accommodate all of the ARM peculiarities. That's more complications. An you can't simulate a whole design. You like the Eclipse-Z7 hardware. Good for you. Keep on keeping on, as they say. In the future I'll force myself not to read this thread. No more comments. The project that I linked to above was also done in my spare time as an exercise of curiosity. No frustration at all.

And I'd imagine able to work to very high temperatures. Given the lack of detail I put this post in the general category of "put an SOS message in a bottle and toss it into the ocean". I could be wrong of course, but I think that what you want is not going to come from a distributor's shelf. You, or someone that you pay is going to design and build it. Oil drillers do some pretty crazy things these days and that includes electronics near the business end of a drill.

Gee, I've been following this thread since it started.. two months ago. This one took me less than 2 week effort: https://forum.digilent.com/topic/20153-capture-4-channels-of-120-million-adc-samples/ Guess which platform I think of as "rapid development" and which one I think of as a sinkhole for time and effort ( not that one can't learn an awful lot about stuff that isn't necessary to implement very useful projects. You've probably heard of K.I.S.S.; how about ITPS ( It's The Platform Silly ) Projects for collecting large mounts of data and moving it to a PC are so much easier without Vitis, ZYNQ, Vivado IP.. just an HDL and one software application in C. But everyone hast the right to pick their own poison I suppose.

You're wise to be thinking about the potential for ESD damage to your FPGA boards. You don't need to freak out about it though. A good lab environment has controlled humidity and anti-static treatments for floors and work tables. They also use anti-static work pads with a high impedance connection to ground to drain off static charge as well as wrist straps that serve the same function. Sensitive equipment ( such as pcbs not enclosed in a metal grounded chassis ) would be placed on these pads and the user would use the wrist strap to avoid static charge buildup. I consider Digilent FPGA boards to be in the same class as a custom prototype board in an engineering lab. The fallout for destroying a precious prototype at work is likely greater than losing personal educational product; but both would be more painful than I;d want to endure. If you use your boards in a typical residential room with carpets and heating that produces dry air in the winter the chances of generating enough static charge that might damage your boards is pretty high. If might not be practical to turn a spare bedroom into a class-10 lab, but you can find a small anti-static pad and wrist band at a reasonable costs from most electronic distributors or supply houses. Only you can decide if this is a reasonable investment for you. BTW, you don't need to actually touch your board to damage it... ESD can arc though air over short distances.

If you are designing your own custom board, the right way to do this is to read the AMD/Xilinx documentation and understand all of the design criteria and recommendations... not to copy someone else's design and hope that it's correct.

For what it's worth, the same kinds of logic structures and techniques that were done long before FPGA, CPLD, GAL or PAL are still mainstays of good logic design today with the latest FPGA devices. These are strobes, counters, shift registers, state machines, etc. Rarely does one need an embedded ucontroller sucking up resources. FPGA devices with hard ARM or RISCV cores can be an impediment to effective design because it's hard ( at least for me ) to switch the hardware and software hats when doing that first crucial design step.. which is partitioning functionality between logic resources and software when creating the basic design architecture.

In the forum Guidelines section there is this recommendation: "If you have a completed project or tutorial you want to share, a subforums titled “Project Vault” and “Tutorials” are available in the General Discussion section.". As someone who's posted projects to both of those sub-forums over the years, I'm happy to see that stated. Unfortunately, both sub-forums are places where users continually post questions or other content. This reduces the chances of other users finding content that might be helpful or of interest. The quality of experience for readers and people posting projects would be much better served if Digilent made a better effort to curate those sub-forums, by moving irrelevant posts to a more appropriate sub-forum area. Occasionally, someone on the Digilent staff does this; but there is no obvious on-going effort to do so that might be call "curating". I've mentioned this before; nothing's changed, so I'll mention it again. Digilent is certainly good at promoting such work materials when if makes for good sales pitch... even when they aren't quite as advertised. I think that Digilent should be proud of its forums as a place for educational enlightenment, not just for selling stuff. A sign of pride might be better oversight and maintenance.

Let's make the question a bit more generalized. Instead of an AXI bus, let's assume any conduit that can write a register. A UART might be one conduit. Now, your question seems to resolve around a question of state. Do you want the contents of the state of your register to initiate a series of actions by some process or entity, or does the transition of state of the register initiate a series of actions? If you want the series of actions to occur just once, after the register changes state ( contents ), then it's a change of state that you want as a trigger. So, how does one do this? There are a number of possibilities. One possibility is that you have logic that holds the new state for just one clock cycle, so that the process that gets triggered by a new state only cares about the state of your register when if changes. So, the register might have a value of zero, indicating NOP. Something changes the register value to 0x5555. The process sees the new value and does something based on the register value, and the next clock cycle the register has been cleared back to 0x0000 because your register logic does that. Once the process is finished, the register doesn't contain a value that triggers the start of the process again. The process doesn't have to be monitoring the same register as the one that your bus writes to; it could be a copy that gets updated from the first one by bus activity and hold its value for only one clock period. [edit] Note that simply looking for a change of register contents might not be what you really want. For example, say that you decide not to clear a value written to the register, or you have two values.. 0x1 initiates process A and 0x02 initiates process B. If you want to do A then B you don't need to clear the register. If you want to do A then A then B, then you've got problems. A slight modification of the first approach would be to add logic to your design that creates a one clock wide strobe indicating that the register has changed state [ more accurately has been written to ]. If you have access to bus control logic, you might find a signal that already provides this. You could also create a process that just triggers a strobe when the register changes state. So, if you are following along, then you should be getting the idea. Another possibility is that instead of a simple process, you could write a simple state machine that incorporates all of this behavior. This is all pretty straightforward and part of digital logic design 101.

Anyone with questions about the SYZYGY standard or how it works should go to Opal Kelly's website and download the appropriate documents. I see that today, they require agreeing to terms of a license to do so. There's a SYZYGY document and a SYZYGY DNA document covering the hardware and carrier board/ pod negotiation sequence. Don't even think about creating your own SYZYGY pod without doing this first. Before trying to understand how Digilent implements their version of SYZYGY, it would help if you understood what it is. Then you might be in a position to ask good questions about Digilent's PMCU implementation. As far as I know, Digilent doesn't provide sourcec code for PCMU functionality.

The initial question is incomplete, because it's too general. For what it's worth here's my reaction to the question. In most complex logic algorithms implemented in logic there are always at least three competing goals to balance: 1) Resource usage 2) throughput speed 3) accuracy So, for this problem, we need to define a few things. - what is the number format? Integer, fixed point? floating point? block floating point? something else? - do you need to instantiate large numbers of the IP? - how accurate must the results be? - for something like a divide algorithm, is the quotient or the remainder ( or both ) what you need? - is there a maximum compute time? - are there resource budgetary restrictions? That list isn't meant to be complete, but you get the idea... you need some project specifications to decide what the best approach to your solution will be. Hard multipliers ( these are included in DSP resources these days ), offer potential high speed and reasonable dynamic range but can have serious timing issues depending on the connection topology when multiple DSP slices are required. An iterative algorithm might use few resources, but have insufficient data bandwidth for a particular application. Often BRAM used as a look-up table can help speed up the algorithm if used cleverly. Of course the fastest and lowest LUT usage way to do a divide ( by a constant ) is to create a constant. So n/10 is the same as n * 0.1. This approach can't be applied indiscriminately of course, but often a general complex calculation can be reduced into a simpler, but more constrained solution by knowing what's important and what's not for a particular application. There just isn't going to be one solution to implementing the calculation presented that works for all applications equally well. That's the nature of logic design.

OK, so this advice is too late. rule 1) never upgrade to a newer version of Vivado unless there is a compelling reason to do so. rule 2) never delete old versions of tools that you have developed projects with. rule 3) never use the latest version of Vivado for an older project. - you can save an old project as another project, or you can just create a new project and copy the old sources to a folder in the new project. If you are doing the HDL flow this is pretty easy to do. If you are using the board design IPI flow then you might use a tcl script to replicate the old sources. rule 4) If you HAVE to install a new version of the tools, then do a couple of short experimental projects with it ti discover what changes and bugs are going to hit you. Never use a new tool version to do a project with time constraints as an early exercise. Don't let the tools control your projects. Be smart and practice safe development. In my experience the AMD/Xilinx community forums are pretty bad as a place for getting answers to most problems.

asmi, If you want to defend bad design choices, that's your privilege; I choose to call them out. There's no point to continuing this little debate, so I 'll just stop with this thought, in the context of all of your arguments. The Raspberry Pi3 has a micro USB connector... with through-hole tabs. The RPi4 has 2 micro HDMI and a USB C connectors, all with through-hole tabs. These products are on very densely populated, very small PCBs, and retail for under $50 in single quantities. No one's complaining about connectors being ripped off of these products. That's just on example of well thought out product design, because the people making them care about their customers. I have lot's of cheap development boards with quality components that counter your arguments.

Asmi, Let's go with your premise that using USB connectors with through-hole tabs entails significant costs over smt connectors. All of Digilent's FPGA boards use through-hole connectors for the PMODs. So, either through-hole components can be done by automation equipment or not. I'm not buying the argument that good USB connectors with through-hole tabs have to be hand soldered anyway. So, what it comes down to is a vendor cutting a buck or two off of the assembly costs by using smt USB connectors should prominently advertise that fact that the products have very limited cable insertion cycle lifetimes under normal usage rather than do it correctly and charge a couple of bucks for a much better product. Of course no one is going to tell a customer that they have so little disregard for the customer, so they just go ahead and make products that have a good chance of premature failure due to one stupid decision. Reminds me of the cost saving measures of almost every auto maker using an airbag inflation initiator vendor whose products just happens to explode some of the time. Years later, after many unnecessary deaths, there's a giant recall... Of course no one is going to die from a broken-off USB cable connector. Neither is anyone going to force a recall for what may be considered a defective product if its an FPGA development board. My assertion is that no customer is going to choose to buy a board with an smt USB connector and likely to be ripped off by normal use after a year or so, over a reliable USB connector that costs a buck more. It's no way to treat a customer that you want to keep. This are especially true for a product designed, not for engineering lab use, but specifically for educational student use. I say shame on vendors who abuse their customers with bad design choices, and then hide it from prospective purchasers. Shame on vendors who just don't care.