D@n

I've actually seen complaints of this often. I'm not sure I've seen the "right" solution yet, although I think I recall individuals having success by forcing Vivado to repackage their IP from scratch.

You can convert PDM to PCM before the FFT or after. That's an engineering choice. Both will work. Often the PCM gives you lower logic, and more headroom for the FFT--but that may require more engineering than what you are up to at present. Try this: Simulate and verify every component individually. Dump the outputs of the component to a text file that you can read and verify with Matlab. Make sure you get what you want along the way. Just as a heads up, frequency estimation is often more difficult than just taking an FFT of an incoming waveform. I've done it. The FFT approach was the first one I tried. Depending on the details of the sample rate and the FFT size, you may have too many bins or not enough. You are also very likely going to be distracted by harmonics. If you've never "seen" the output of an FFT given real life signals, you should do that first. It's very instructive. The "best" way to do that is often via a scrolling raster, but ... video requires memory, often external memory, and ... that's likely to be a bit beyond a beginner's first project. For now, perhaps you should consider capturing data and running it through the algorithm you'd like on your PC (matlab? Octave?) to see what real-life data looks like. Perhaps you might even wish to read audio from your computer's sound card, to get an understanding for how rich real data sets can be. Unfortunately, that 7Segment display isn't going to give you enough feedback to know how to debug an algorithm like this, applied to so rich a data set as the real world. You will need software help along the way. Dan

@House, Have you considered how much logic a multiple requires? How about a divide? There are no shortcuts to division, and the low-level hardware guys haven't provided many short cuts for multiplication. Both are very computationally intensive components. They'll both use a lot of LUTs, and likely keep you from meeting timing. The solution to the expensive multiplies is to use a DSP element. Those, however, have requirements to them. You have to use them "right", or ... they'll get turned into LUTs and you won't meet timing (or area) again. My general rule of thumb when building multiplies using DSP elements is to take no more than one clock per multiply. always @(posedge clk) if (CE) product <= A * B; If you use any more logic than that in an always block, you're likely to break Vivado's algorithm that packs multiplication logic into DSPs. When not using DSP elements, I take (roughly) one clock per bit. You can read about my algorithm here. While the tricks I used to make the multiply use less logic work for divides, I know of no other tricks to make divides work. You're roughly stuck with one clock per bit, and no hardware acceleration. Other things can be made cheaper, but those don't appear to be your problem at present. Dan

Yes, I remember that day well. I remember taking a computer architecture course in graduate school and much of what we studied was the power PC. My how things change.

You are not going to get Vivado on an RPi. There's no money in it. You are more likely to get some other design tool, such as an open source Yosys+NetPNR or some such, to run on an RPi. I know folks who have run the two on RPi to date, just not for Xilinx chips (yet). I know because ... I've had to debug some of it. (Welcome to open source, you get what you work for.) While I doubt it yet works for Xilinx, you are more than welcome to roll up your sleeves and get to work at it. Dan

+1 😁

I've seen crazier things before--like the AF sergeant who instructed me to install a piece of PC/Windows software on a Sparc machine. Much like I expected, it didn't work. In this case, I'll wait for the forum request for help to arrive from the individual trying to install Vivado on an RPi before making such a declaration. 😄 Dan

@digility, When I first started working with FPGAs, my first project was a serial port to Wishbone bus translator. I call it a "debugging bus". Using this abstraction, I could then create and send bus commands to the FPGA from a C++ program. The interface involved has been so robust, that I've now used it on (just about) every project I've worked on since. Were I to attempt to load an image onto an FPGA, this would be how I would do it. A couple of C++ programs would adjust the image as necessary from whatever format it came in on, to whatever format I'd need, and off I'd go. @zygot does present some good architectural questions to consider. I've (personally) stuck with 7-bit ASCII. Over time, I've started using the 8th bit (the MSB) to multiplex two streams together (a CPU console, getting mux'd with the debugging bus), so full 8-bit ASCII is quite possible. The maximum data rate achievable then depends upon the protocol. One protocol I built and demonstrated in my blog takes 11 hexadecimal characters (8 for a 32b word, 1 control character, a carriage return and a newline) to send 32bits of information. (29% efficiency.) I'm more commonly using 6 characters for this purpose (53%). More recently, I've been testing an approach that will send 32bits of information in only 5 characters (64% efficiency), while still maintaining the ability to use the serial port as a CPU console. On one project, I've even gone so far as to run this protocol over a network--so the FPGA can go underwater. In all cases, I've continued to maintain (nearly) the same C++ interface description as I started with. For the record, while the FTDI chip declares it can send data at 12Mbaud, I've only been successful at 4MBaud and only reliable at 1 MBaud across multiple circuit boards. I wouldn't set my expectations any higher than that. (The GbE interface, however, goes *REALLY* fast ... but that's another story, and takes a lot of work to get going--since you'd need to typically support ARP and ICMP protocols, before even touching the UDP/IP required for something like this. That's just a lot of work for a student project.) The issue I would worry about, however, is ... where are you going to store this image? The Basys3 device doesn't have a lot of memory, and you are likely to need that memory for other things as well. I suppose you might just feed the image directly into your algorithm. (I've done that too ...) But either way, you should think through what you want to do and any consequences associated with it. Is it possible that the serial interface will go too fast? Do you need handshaking? All things to consider. Dan

Yes, it is possible to store bitstreams on an RPi and then configure an FPGA from there via JTAG. My 10Gb Ethernet switch project does exactly that. We use the openFPGALoader tool to do the loading. openFPGALoader -c digilent --ftdi-channel 0 toplevel.bit There is no reason or need to install Vivado on a Raspberry PI. Dan

@reddish, Out of curiosity ... the CMod A7 has two QSPI SCK pins. I've enjoyed this feature in the past, because it allows me to run the flash at 2x the speed because one pin as a DDR capability, and the other is used for configuration only. My question therefore is, are you using both pins in your design at all? If not, are you using the STARTUPE2 primitive in your design? If so, are you overriding the DONE pin at all? Not sure if any of these might help, but they are at least worth looking into. Dan

Perhaps this might help: The conversation follows this post, and has some recommendations and resources attached as well. Dan

@zygot One of the things that made the MAXIM chip ideal for GNSS handling is that it was primarily an RF to baseband samples chip. It did everything. If you wanted to change how you did your DSP, that was all on you. Adding a new satellite? As long as it was in the same frequency range and used (roughly) the same bandwidth as GPS, the chip would work nicely. Yes, I can imagine this same chip working two decades later. Why? Because FCC frequency allocations only change slowly over time, and I doubt the DOD would want to do anything to cause the (currently working) GPS receiver base to suddenly fail with a new upgrade. Dan

@reddish, My first FPGA project was to build a GPS correlator given an FPGA and MAX2769. It's doable, even as a first project. As with anything, the trick is to break the project down into byte sized chunks, and to remember to plan on the need for debugging along the way. Dan

Welcome to hardware design. You now get to decide which memory to use. In general, there are four places you can store results: Off chip, block RAM, distributed RAM, and in Flip Flops (FFs). The first of these three are typically called "memory", whereas storage isn't really "random access", so the term "memory" is rarely used to describe it. Off chip memory comes in many varieties as well, such as SRAM, SDRAM, DDR SDRAM, DDR[2-5] SDRAM, etc. Of these options, FFs seem to be the most appropriate storage location for a counter. Such a counter might look very much like this one, used to measure one clock rate in terms of another. It's quite similar to what you wish to do. Dan

The counting part is the easy part. Beware of clock domain crossings and button bouncing. Moving the data to an external computer will take some work. How much work depends on how you wish to to it. Pushing a counter through a serial port isn't all that hard to do. Dan