D@n

I don't understand your LTL because ... I've never used LTL. Did you look through the whole slide deck? There are only 13 slides. The first 7 are generic, the last 5 or so show how those generic slides apply to AXI-Lite. Frankly, if you understand the generic bus principles, then translating them to AXI Lite should be pretty easy. Dan

Okay, so ... I've looked at your specifications and ... understand nothing of LTL or the specification language you are using. Perhaps some pictures might help you understand the concepts, and you can then translate them to LTL? https://github.com/ZipCPU/wb2axip/blob/master/doc/busprops.pdf Dan

I write and maintain the ZipCPU blog. What questions do you have? Dan

Yeah, you have to provide timing exceptions to Vivado. They belong in your XDC file. For example, consider this line: set_max_delay -datapath_only -from [get_cells -hier -filter {NAME=~ thedesign/GEN_ETHERNET_DECODE*u_netpath/rx_afifo/rgray_r*}] -to [get_cells -hier -filter {NAME=~ thedesign/GEN_ETHERNET_DECODE*u_netpath/rx_afifo/rgray_cross*}] 3.0 This is used to tell Vivado that the FIFO's read gray code will be read in a second clock domain into the signal rgray_cross (i.e., read gray code, but crossed clock domains). Rather than doing proper timing analysis on this signal--which would fail because the two clocks are unrelated--the statement instead tells Vivado to call this clock domain crossing "passing" if from the time it takes to set the first signal to the time it takes to set the second can be done in less than 3ns. There are other ways to do this as well. They all end up being timing exceptions that you have to declare in your XDC file though. You can let Vivado be the one to tell you which signals need exceptions like this--subject to your review. Dan

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