zygot

Don't spend money because you feel compelled to, spend money because you have a good reason to do so. With or without a physical FPGA platform you still need to hone your Verilog skills as well as your understanding of how to use the tools. You can do this with nothing other than Vivado... now, without consideration of what you anticipate that your future needs will be. I argue that this approach will make your anticipated future course work easier and more productive. 90% of FPGA development is spent in FPGA vendor tools, not using hardware; the exception is when your hardware becomes a tool for developing other FPGA designs. There are a lot of assumptions about how your future will transpire. If you are required to purchase an FPGA board for your coursework that's one thing. I understand wanting the comfort of being able to work on assignments outside of the lab. Are your expectations really a good reason to make a decision now, rather then later? Are you really expecting to buy everything that you need in a lab once the lab assignment work gets assigned? Is that a reasonable plan? I don't know, but neither can I or anyone else help you with that analysis. When I was in school there were a lot of courses where the textbook and lectures were insufficient to compete in tests. I was expected to use the school library, and hope that the material that was needed was available. I suppose that I could have just bought every textbook that I thought that I might need for future coursework in advance so that I could use them in the comfort of my domicile. I had enough trouble just buying the required textbooks. In general, I'd advise that hoping that the possibility of add-on boards is a cost-effective and useful plan for future undefined FPGA projects is a poor one. Especially, for PMODs which are low performance, older technology, and haven't had new product introductions for a while now. This ecosystem is pretty good for educational institutions but perhaps not as good for users. This is a general thought as individual needs are different. You say that: "PMODs are much more cost-effective compared to the FPGA boards themselves". I disagree, as a general statement. Have you priced PMOD boards compared to the cheaper FPGA boards? I want to make it clear that my opinion on this should not be something that constrains your decision. I make my own add-on boards. It isn't for the budget constrained. Making a PCB can be cheap. Populating it for 1 copy of a board that has limited use is usually a very expensive way to to do things. If it's the only way to do what you need to do to complete a particular project, then that's what you have to do. Gardening is a similar endeavor. For most people the food that they get from a garden is more expensive, once you account for ALL of the costs, than what they could get from the local grocery store. Price is, in general, a bad reason to have a garden. Marketing is about imagination... possibilities. Reality is about actual use of a product over years of use. Modern societies are dependent on economies and tend to encourage exchanging money for perceived possibilities. Just a thought....

Gee, how did I miss all of that fine print in the product advertising? Since these types of products include a customer's PC, doing who knows what, in addition to being part of the functionality of the product isn't testing something that should precede marketing claims? How does the word "should" ever get into a sentence by a vendor describing performance of a product?

Though I've pretty much lost interest in this thread, your persistence, and how the thread has involved intrigues me. Your goal started out as 'DSP using FPGA'. You can't afford one of the cheapest FPGA boards available from any vendor, yet you are obviously intent on buying something now, without a specific DSP project or goal. You aren't too keen on the free approach, which would just be to use the free tools. Why do you believe that spending money on something with lots of DSP slices is better for DSP using FPGA'? Why do you believe that spending money on an FPGA with 2-4 PMOD connectors as the only available IO pins for project use and then spending more money later for as-yet-to-be-determined additional PMOD add-on boards is more affordable than a cheap FPGA board with everything that you need to pursue your foreseeable ( yet undefined so far ) interest? I'm not sure what either the notion of DSP or FPGA actually means to you from what you've posted. A good tool for getting exposed to DSP concepts is OCTAVE. It's free. It covers a lot of possible area of interest. When I implement "DSP" type algorithms in logic, I always start off with OCTAVE to prototype my implementation. Implementing complex processing algorithms in logic is a lot harder to do than in software.. if you want to actually get down and dirty into the most basic level of logic and algorithm implementation. If you want to use canned libraries, or IP, that does all of the hard work for you, why bother with an FPGA board anyway? Do you think that not understanding what's happening on an FPGA board implementing "DSP" algorithms is better than not knowing what's going on with an RPi ( or your current PC ) implementing similar "DSP" algorithms in software? You don't have any money, why are you so set on spending it before you even have a good reason to do so? I'm only posting this reply because having you answer questions might be a more productive route to the best solution.

Beside device family user guides, there are quite a few user guides on Vivado. In particular read the one about Vivado synthesis as it has important information about its support for HDL languages. Only a subset of HDL keywords can be synthesized. Also read the Vivado Implementation guide. There's more of course for when you are ready. It's a lot to ingest but my approach is to speed-read through all of the most important and return to them as needed. You need to understand how the tools work in order to get your HDL implemented without timing problems. So, one thing that you've learned is that getting a design to work on hardware, even if behaviorally there are no major errors, isn't enough. More importantly, being able to build something that gets through synthesis, implementation and bitgen is one thing... having the skills and insight to debug your design is quite another thing.

There isn't one kind of simulation, even for ISIM in VIvado. What you are doing is behavioral simulation. This only simulates the behavior of your Verilog as the simulator understands it. There's no attempt to predict how it will be synthesized and placed into the logic elements. That means that it doesn't analyze signal delays inside your design. There's another kind of simulation that ISIM can do based on the actual netlist reflecting the implementation. This more accurately shows potential timing problems. Behavioral simulation helps debug bad logic and code. Timing simulation, usually done after the behavioral simulation appears to work, helps identify delay related issues. If your combinatorial logic and routing delay exceeds the clock period your design will either not work at all or have periodic failures. Timing issues for very complex designs, like Soft-processors, with almost no connections to IO can be difficult to debug. Even if you get your processor working, you might find that connecting to mode IO in order to add new external interfaces changes your placement and routing, and therefor timing, leading to a new round of timing closure effort. I'm not sure why you are using positive edge and negative edge clocking for your memory module. Dual clock memory structures have a purpose, but not in the way that you are using it. Using both edges of your clock in a design makes timing, and therefore place and route twice as hard. as a general rule, only use one clock edge throughout your design. Keep using your Document Navigator and keep reading. All FPGA vendors have information that help you write VHDL or Verilog so that synthesis produces common structures in a consistent manner. Alternatively, you can use the Block Ram memory Generator to produce FIFOs or RAM as a guide until you are more experienced. The fact that you had to slow down the clock that drives your logic suggests a larger problem. One thing that you can do is increase the clock period excessively as a test to see if internal timing is the issue. Another problem that you are facing is that you are troubleshooting HW and SW concurrently. Try to break up the complexity by working on smaller parts of your design and getting all of those working. Timing issues are inherently difficult as the same logic structure can exhibit widely different delays depending on the state of the input, and possibly the last state of the structure. This means that a timing simulation that only test a couple of all possible combinations of inputs and states might work fine but your hardware experiences a scenario different than what your simulation did and hardware fails; or that a better testbench succeeds in finding the failure for you.

You're showing me a counter, not how you use the counter. I'm guessing that you are trying to slow down the processor by somehow using the counter, correct? An embedded processor, not supported by your FPGA tools is not a good beginner's project. In modern programmable logic devices clock signals and logic signals are two separate and distinct parts to how the FPGA functions. Clocks have their own resources such as PLL and in Xilinx MMCM blocks for creating related clocks having a different frequency but related to one clock. Clocking infrastructure has its own routing fabric. The logic has its own resources and routing fabric. Logic doesn't need to be clocked but usually is. Creating a clock in logic is a very bad idea. Having said that you can pace clocked logic with a counter, implemented in logic, but you still have to clock all of your logic with a real clock. Before you even think about starting on your first logic design, whether you are designing the whole thing yourself or trying to implement someone else's design, you need to have a basic idea of how your FPGA device is organized and works. Open your Document Navigator that Vivado installed on you PC and read through UG474, UG472 and UG471 to understand how the logic elements, clocking elements, and IO work. A design with no timing constraints may not show timing problems and still not work because the tools need this kind of information to do the timing analysis. Once you get through implementation and open the implementation results, going to the timing section is just the beginning. You need to look inside all of the subsections, like clock summary, intra-clock paths timing, inter-clock path timing, etc. Even then you you aren't done. Earlier versions of Vivado generated a general timing report based on delays. Now you have to request a specific timing report. Vivado is pretty good at helping you along at creating constraints once you learn how to use the GUI. There's a couple of user guide for that as well. Would you jump into a helicopter and try to fly 200 miles a night with no instruction and no idea as to what the indicators indicated and what the controls were? Doing this with Vivado won't kill you but will certainly frustrate you more that it does experienced users.

Sounds about right. For USB, which is not DMA oriented on the upstream host end but highly software coupled, software latencies can wreck havoc with attempts at streaming. There are a lot of moving pieces in any particular USB implementation. The hardware involved can be a factor, but host OS considerations might be an even bigger factor. There's a lot of gamesmanship in high end data streaming instruments; shouldn't be too hard so see why there would be more for low-end instruments. No one wants to tell potential customers to look elsewhere to accomplish their goals. Most customers buy stuff with one application in mind and then are disappointed when it stumbles on the next application.

How did you use your clock divider? What was your intended effect for doing this? How did you implement this? How do you know this? By looking at the LED? If the Signal driving the LED is on for 10 ms and goes off for 100 ns, and repeats this cycle would you expect to detect this by looking at the LED? You say that it works in simulation. Perhaps. Does you simulation last long enough? Is it complete? You ran a timing report of course and carefully looked over the results. Since the project is pretty self-contained you might want to try a simulation of your placed and routed implementation netlist and see how that works.

Usually, students are put in a lab, with an experiment to perform, and given test equipment to use. I'm betting that rarely, if ever, do students get instructions on how to use test instruments. Oscilloscopes can be useful things. The problem is that an oscilloscope is an unrepentant and enthusiastic liar if the user doesn't know how to configure them for the purpose at hand, and is unaware about how the pictures that the user is looking at were created, and how to interpret them. The default rendering mode for most digital scopes is the sinx/x presentation, AKA "Lie to me" mode. It can be especially confusing when the user is expecting a sine wave to appear. Scope users who are uninformed about what's going on behind the rendered display can make a lot of very bad assumptions and draw very wrong inferences with regard to these pictures. You got sucker punched... by a box with an on/off switch, and insufficient instructional preparation. This is a whole topic for discussion.... for another time. The first thing that a lot of people do, if they are trying to do something that they have no experience in, is to jump right into an exciting problem with a quick plan and start doing things.. Typically, lab sessions encourage this due to time constraints. It's a good idea to begin every endeavor with a bit of mental rumination about what's involved. The next step is a "sanity check" that often involves a bit of simple math and thought to see if the plan is realistic. Often, with a project involving analog <--> digital conversion some time spent with MATLAB or OCTAVE helps set some boundaries and helps define expectations. And that could bring us back to the oscilloscope which is basically a DSP device that does this: analog --> digital --> x/y plot of an "analog" signal that should represent what the scope probe is measuring, but often misleads the user, sometimes badly. Someone could make a whole course on signals and systems just using an oscilloscope as a point of inquiry. Things like the DDS compile and similar IP has uses, but learning how to use shortcuts that do most or all of the hard stuff for you can be an impediment to learning. Yes, they can be invaluable tools that let you focus on higher level problems. But if you have no idea what the tools do, then they can be impediments understanding what, exactly you are doing. Basically, the DDS just creates data that used in a lookup table and massaged a bit. Anyone with a modicum of HDL experience can do pretty much the same thing. It may seem like a waste of time building you own DDS compiler using HDL or Verilog and OCTAVE, but everyone thinking of using such IP should, at least once, do it for themselves. The secondary benefits can be more valuable than using such tools to solve complex problems.

OCTAVE or MATLAB if you have a student license ( actually recently I learned that they now provide a reasonable pricing plan for individual personal use ) is the place where you should start this kind of project. Prototype your system in OCTAVE and then start building FPGA HW.

Only 20-30 MHz? At 100 Msps how many samples does your DAC get per cycle? You can do the math for yourselves. How sine-like does your stimulus waveform have to be? You're telling me that you've already done this with the DDS compiler. You've simulated this of course... right? Vivado simulator will render data in analog format is you tell it to. There are techniques for synthesizing 20-30 MHz high quality sine waves but usually they don't involve a multi-GHz DAC. Have you confirmed that the analog bandwidth for your ZMOD 1411 DAC supports a 20-30 MHz signal? I suppose that if you look at your DAC output with an oscilloscope having an analog bandwidth of 5 MHZ what you might see, besides having a very small amplitude, might resemble a sine wave. Does that make it a ( good enough ) sine wave? Perhaps, but not very likely. Have you worked out the requirements for your ADC path? I don't want to rain on your parade.... just asking a few questions that I'd have asked myself at the beginning of such a project. (Don't take this as criticism or a personal insult... someone who's done certain kinds of work for a few decades should be a bit more organized ) Some mistakes made a the beginning of a project can't be fixed late in the development stages....

I mentioned it because this is a board that is much smaller than the Eclypse-Z7, uses a much smaller ZYNQ device, and yet is more capable. Opal Kelly hasn't updated any of the support material since it was released. I'm not recommending that you consider it as an alternative platform or comprehending that you avoid it. Opal Kelly also makes the XEM7320, which I've used and might be a more suitable platform for your project. I ported the project in the above link to that board and there's a project posted nearby,

Have you looked at this project? https://forum.digilent.com/topic/20299-fun-with-phasors/ You don't need the DDS IP or compiler to create sine-waves or even more complex wave-forms. It can all be done with some HDL code and BRAM. Of course I don't know what kind of waveform you need to create. Read the documentation for the project above and see if it's relevant to what you want to do.

People who write their own source code don't care about such things.

That's just a silly thing to assert. Vendor IP is composed of script generated HDL code plus, perhaps, PERL and TCL scripts. Sometimes the HDL sources are available in readable form and sometimes come with encrypted form. I don't what kind of logic design you do, but it's pretty rare that anything that I do can be done with canned IP that is very limited in terms of how it can be used and modified. Often the sources are almost unreadable and involve dozens of files that are hard to unwind. IPI IP HDL aren't anything like what I'd write or want to maintain. Also, my sources don't get broken or disappear when the vendor releases a new tool version or decides that it doesn't want to provide the IP anymore. Typically I have to worry about a lot of other considerations like very limited resource usage constraints, which vendor IP happily slurps up hoping that you'll think that you need a more expensive device to fit your design into. I could go on and on... Obviously, playing with legos works out fine for some projects. Some people actually have to produce unique things that require more work but is maintainable in a commercial application and meets real-world requirements. There's no one right way to do design. If IPI works for you, then that's great. It doesn't work for me or any company that I've worked with. I never choose an FPGA platform based on the vendor, it's tools, and certainly not its "free IP", which I rarely use anyway, unless the tools force me to. If I buy a general purpose FPGA platform, it's based on cost and suitability to execute a design concept.

Well, I overlooked this bit when I wrote the reply just preceding this. I'm not sure how to interpret this based on what you've revealed so far.

The sampling rate is one aspect of your requirements. How many ADC and DAC channels you need to support is another. How many samples are used for the stimulus and how many are used for the response is yet another. The stimulus/response system is pretty typical. If you can fit all of your ADC and DAC samples in BRAM, then your project can be pretty straight-forward and easy, with all of the hard stuff in the PL. If you need 2 million samples for both converters, then things will be tougher. It all depends on how you design your hardware architecture. The Eclypse-Z7 can be fine for such a project where all storage can fit into PL resources. Since the PL has no external storage other than the PS DDR. Larger storage requirements will involve 2 bidirectional DMA between the PL and the PS external memory controller. I was never suggesting that a UART could stream ADC and DAC samples in real time. But certainly this is an option if all you need to do is write to 1 32 KW BRAM storage element before you send the stimulus and read from another 32 KW storage element after the response sample time has ended. You can also do this using the PS UART, but at a considerably lower baud rate. All of this depends on your non-specified requirements. You don't need to provide those, but the more information that you can provide, the better the replies will be. In theory, one 1 GbE can simultaneously stream 1 channel of ADC and DAC 16-bit 50 Msps samples with an arbitrary sample depth. Doing this through the PS GEM is problematic because the GEM is DMA driven, the samples are DMA driven, the PS cores use the DDR and the DDR is where the samples are stored. It's an unfortunate "feature" of the Eclypse-Z7 design. The platform isn't designed stream data from 1 ADC ZMOD and 1 DAC ZMOD to an external device. Really this comes down to whether or not the Eclypse-Z7 can meet all of your project requirements ( and you can come up with a suitable design architecture using its features ) or not. Opal Kelly had a crowd funded BRAIN-1 project to fund it's SYZYGY development. This board has 3 standard ports and 1 transceiver port. Unfortunately, it's also ZYNQ based with no external storage available directly to the PL. I also uses the Z7012S which is a device with very limited PL resources. But it could support 1 DAC pod, 1 ADC pod and 1 Ethernet PHY pod, meaning that it could use an Ethernet PHY as a streaming interface as long as the total data rate each direction is < ~120 MB/s. One last thought. If you can create your stimulus waveform in the PL logic, then this dramatically simplifies your overall design problems.

Digilent mostly supports the external memory and interfaces with a MicroBlaze based IPI design flow. Their support for things like DDR, Ethernet isn't too helpful if you use the HDL design flow. Vivado IPI flow isn't going to be any use to you if you decide that an Intel Cyclone V board, one one from another FPGA vendor is the ideal platform for a project. Asmi believes that the IPI design flow is great for beginners. I believe that the HDL design flow is what beginners should develop competency in. Eventually, even with the IPI flow you will need to understand the HDL design flow to get some projects completed. This is a whole discussion topic that I won't pursue here. I do programmable logic design involving devices and tools from all of the vendors. Terasic is the Intel version of Digilent's educational promotion efforts, but for Intel FPGA devices. They generally don't have Ethernet or a USB interface similar to DPTI and their main FPGA boards. They do have a lot of project demos involving Qsys ( Intel's version of IPI ) but they also have some good HDL support with source code for things like DDR and their ADC/DAC adaptor boards. It's worth looking into. I'm really hoping that you get more than two people responding to your questions as the more perspectives the better. Whether all of that information will guide you to a decision that you will be happy with in the years to come is anyone's guess. One thing that asmi and I can agree on is that Digilent offers a unique forum for anyone wanting to ask for advice regardless of their experience.

Why do you believe that? Clearly moving 100 MB of data over a 12 Mbaud UART channel is time consuming. Moving 16 KB over a 12 Mbaud UART might not be a burden. It depends on what you need to do with that data. I've proposed some ideas in a previous thread that you started on this topic and you pretty much ignored it; so I'm guessing that you dismissed it out of hand. If you don't respond, then you are indicating that you don't want additional information about what's are concerns are.. The best solution is to figure out how the GEM on the Z7020 works, either in Linux or the stand-alone XIlinx supporting libraries. Evidently you've decided that this is too hard. That doesn't leave you with many options as there's no alternative hardware interfaces other that the 2 PMOD headers. There's also the Ethernet using the SYZYGY option but perhaps that's too hard as well. You might be able to prompt better replies to your questions if you were more open to discussion and revealing information about your project requirements. I've put in a lot of work trying to make the Eclypse-Z7 a useful platform so I am not uninformed on the subject. I'm not in any way offended if you don't want my advice, by the way.

Forgetting to disable caching is one common mistake.

Thanks for inadvertently expanding on my comments above. As usual, asmi thinks that reading a couple of very dated user guides for gen 4 or gen 5 FPGA devices makes you an expert on using DSP features on Series 7 devices using IPI or even primitives with current Vivado tools. It's a typical mistake made by someone who's never actually had to implement specific functionally in a custom design with a particular purpose in mind. I was using DSP slices back before Vivado, when the information that asmi references worked on ISE for FPGA families that predate Series 7 like Spartan 3 or Spartan 6 or Virtex4 or Virtex 5. I also currently use DSP resources with modern FPGA families like Series 7 and UltraScale on current tools. In practice, promotional or introductory reading material only get you so far long the path of design and implementation when you have hard specifications to meet. DSP slice functionality is only part of the story. Nevertheless, those are good resources to start with. There are also some good old applications notes and user guides. Be aware that it's tough sledding for someone just beginning in FPGA development. You should also consult Intel DSP literature as their DSP blocks are different than those in Xilinx families. Once you've understood what's the DSP block can do you still have to read the IPI IP user's guide to see what those implementations allow you to do... if like asmi you want to use the IPI flow. It's all a lot more complicated to get what you want than simply reading a few resources. But I'd be happy to see some actual Verilog or VHDL code where asmi struts his vast experience that produces comments like the one that I just quoted. People who know nothing are complete experts in everything... until they have to build something that works and isn't just pasting together tinker toys from a third party. It's all something to keep in the back of your mind; doing complex unique things in logic is rarely easy or straight-forward.

I can download it using the link above and view it with no issues. There's no trick. Sometimes Linux/Windows text encoding is an issue but that's not the case here.

Yes, you can learn a lot without any hardware. You can even buy, sometimes very expensive, FPGA boards that don't connect to any external hardware other than a PC PCIe slot. But programmable logic has traditionally been used as a means for embedded processors to interact with external hardware in a way that they were not equipped to do. So, understanding how digital signals work in real-world circuits is a very important part of programmable logic design. Having a design operate on hardware is the best way to understand what happens to signals that are more complex than the ideal logic '1' or logic '0'. A hardware platform is the only way to refine your simulation "IQ". While most modern FPGA devices have internal ADC capabilities, none that I can think of offer a corresponding DAC resource. A lot of really interesting problems that can be solved in logic require conversion between the digital and analog realms. I am certainly not encouraging you to forgo using an FPGA development board, just pointing out that there are more than one way to look at FPGA development. You can learn about how FPGA devices work and implement very complex algorithms in logic without having to consider how to use the IO resources. I'm sure that there are people who do this. On the other hand, designing interfaces, that connect those internal algorithm implementations to external devices is a different skill set. You don't have to be an expert in both areas, but it certainly is nice if you are. Some people don't care about the low level details of how a problem gets solved, only about solving a higher level problem. Digilent's PMOD ecosystem definitely is a place where you can explore digital design and connect it to the real world in a relatively inexpensive, but limited way. But the PMODs do some of the most important interface design tasks for you, and limit your boundaries. Is this the best place for you? I do not know the answer to that question. If you want to design your own custom creation, put it on a PCB that you design, and connect it to an FPGA platform then the PMOD connectors found on Digilent's cheaper FPGA boards will likely not be so useful. Is using a generic FPGA board as a way to implement an unbounded project like that what you want to do? Again, I can't venture a guess about that. So, my point here is that if you don't have a specific project in mind that requires specific external hardware and interface resources don't worry about whether your first investment will be a wise one. Want to learn programmable logic design, or how the tools work, or how FPGA devices work? Just download the tools and get going. Do this first regardless. Want to implement complex data processing algorithms in logic? You can do that with just the tools. Want to learn digital design and how to implement high speed interfaces and create you own custom hardware? Then you can start with a cheap FPGA board with easy to use IO connectors. Want to understand how a particular light-to-digital IC works and do some real-world experimentation? Well, you will want physical hardware for that. You will still want your logic simulator. Want to do all of that? Great! Want to buy a cheap FPGA board today that will let you pursue some project 5 years in the future based on the knowledge and interest of your future self? It could happen.... but the odds aren't very high.

Are you kidding me? Projects with no goal other than to ask questions and see where the answers lead me are my favorite kind of projects. Well, understanding how an FPGA works is the proper place to begin. From questions posted to this site I'm guessing that most people just want to do something and never get around to that first step. There's plenty of information from AMD/Xilinx or Intel about how there programmable devices are made and how to use them. Understanding how they work is only part of the FPGA developer's journey. You need to understand how the FPGA vendor's tools work. You need to understand how to convey your logic design effectively to the tools in order to build logic that works. You need to understand how HDLs like Verilog and VHDL convey basic digital logic design concepts to the tools. You need to understand how to create functional logic that works the way that you intend it to. You need to understand how logic simulators work in order to debug your HDL description as well as your own short-comings in grasping all of the necessary details of what's involved. It's a lot of reading and practicing. But never get bogged down in the shear weight of all of that knowledge. You can start off slow and simple, mastering simple logic structures and progressing on to more complex things. And then, as incentive there's DSP and other uses for logic that can keep you motivated and pull you along. All of that reading and practice can be done without any hardware at all. You can use the logic simulators that come with vendor tools to build just about anything on any FPGA platform that you can think of. Most of us think that we need some physical feed-back on actual hardware as a reward for our hard labor. It isn't true, but still that feedback can be a psychological boost that will keep us going. So, after all of that, we come to making a purchase that we don't want to outgrow because it will have to last us for a long time. This is how I view buying a car. I need to last for 10 years or more. Fortunately, buying an FPGA board is a bit less complicated than buying a car. My advise to to buy the cheapest thing that you can find. For Digilent boards this would be something like the CMOD to ARTY. Either one can keep you busy for many years. Ten years ago I'd have made the argument that, if it takes you 5 years to exhaust the possibilities of the cheapest board, then that's about when the next generation of FPGA devices will arrive and make it obsolete. I think that the industry has changed recently to that argument isn't really a factor as new, low cost device families may not be on the horizon. Still, I would assert that in those 5 years you are likely to have grown in knowledge and competence and confidence to where you have develop some clear goals. Once you have goals, then budget and FPGA board features will steer you to the next level of FPGA platform, if there is a next level, and you have the money and time to pursue it. You don't need a $10000 bike to learn how to ride a bike. Once you learn how to ride a bike there are lots of divergent paths forward; do you want a road bike? A mountain bike? A unicycle? Who knows the future. Being fascinated and driven by ideas like DSP or communications applications of programmable logic is a good thing. But you need to develop some expertise on both DSP ( or Communications ) as well as FPGA development before you can do that. I'd avoid things like the PYNQ as it really isn't designed to be a general purpose FPGA platform. You are, without a lot of effort, restricted to one framework that has as its main objective abstracting away all of the tedious FPGA development flow so that the user can consecrate on a more software-like design approach. I'd advise against anything with a closed development framework. In the end most schemes to simplify programmable logic design just end up being restrictive and over complicated. Just to throw you a curve ball; the AD2 is FPGA based. It's a great, inexpensive platform for connecting the real world to your classroom textbooks ( do they even use those anymore? ). The down-side is that they aren't design to allow the user to change the FPGA application. They are more of an instrument. The up-side is that they are very well supported and allow you to explore a wide range of applications using real-world physical connections. Basically, what I'm saying is that I don't think that you can make a bad decision by spending the least amount possible. You can make a bad decision by spending more money than you can afford on something that has expensive features you might never use. As a general rule, spending money today on technology on the basis of what you know today and in anticipation of what will exist or what you will want to do in the future is a losing gamble.

DSP as an avocation is a topic with a pretty expansive range. It would seem that you are more interested in FPGA hard blocks that implement multiplies, adds, MAC, and other operations. It's unfortunate that programmable logic vendors refer to these as DSP blocks. When the first hardware multiplier appeared on a general purpose processor, that was enough to warrant the DSP label. It really doesn't matter what FPGA platform you choose, as I don't know of any that don't have enough 'DSP' blocks to keep you busy for a while. Unfortunately, for AMD/Xilinx tools at least, getting to use all of the features of the various versions of Series 7 or UltraScale DSP blocks in existence has gotten harder. The tools only allow you to implement a sub-set of possible DSP block features. You can implement them with macros or primitives, but those have been depreciated in recent Vivado releases. I suppose that a better answer to your depends on what you want to do with these 'DSP' blocks. As you might suspect, the more money you have to spend, the more DSP resources you can have. It isn't too hard to find out how many DSP slices ( 2 DSP blocks per slice ) any particular FPGA has. The actual DSP block is pretty complicated, but there are user guides for each variant. Whether or not you can use any of their features is, I suppose, something that can be investigated with the tools. You might want to read up on Cyclone V 'DSP' blocks as they are different than those from Xilinx. I mention that device because it's the best that you can get with the free version of the Quartus tools. Designing hardware that can do fundamental mathematical operations involved in DSP is the easy part. DSP involves a lot of math and complicated concepts... but that's where the fun is. The reason for talking about this last part is that DSP blocks in common FPGA devices only work really well for solving problems that can be organized a certain way. The limitation is in the DSP design and interconnecting fabric. That doesn't mean that hard MACs don't speed up processing, just that efficient use of them is complicated.