D@n

asmi: "I meant what was you doing with it that caused USB port to be ripped out? That's gotta require some serious force. This devboard is designed to be used in a lab, as it doesn't even have mounting holes if my memory serves me."

I can't tell you how many development boards I have in which those surface mount USB connectors have ripped off. For some, it's definitely stress from insertion/removal of a USB cable over time. You can't leave the cable plugged in them because that'll put stress on the flimsy top layer copper pads. Even putting a duplicate pad on the opposite side of the pcb and inserting lots of vias would help somewhat... though would negate the cost of the proper connector. You can't perform lots of insertion cycles for the same reason. I don't buy boards with USB connectors, unless they have through-hole tabs anymore.

Using smt connectors that don't have through-hole tabs saves almost nothing in production costs and greatly hinders the product lifetime.

A different opinion.

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

Wanted to follow up and say thank you, inserting OBUFDS fixed the issue. Bitgen complete! Now on to further challenges...

Most of the time when I read content on a site like the Digilent Forums, my browser has most scripting blocked. Most people are aware of the cat and mouse game involved in monetizing the internet as we know it.
Unfortunately, some websites are not completely friendly places to visit. For the this one, unfortunately, posts are presented either in an order that reflects how conversations evolve over time or something else that is loosely referred to as "by vote" I don't know what by vote means, particularly when a thread has no "votes". What I do know is that it's possible to influence how people understand what it is that they are reading by changing the context. It might be innocent.. it might not be.
I always choose to read threads having a lot of posts, especially where there is some back and forth, in chronological order as I believe that it pushes comprehension toward being more informative. Unfortunately, for Digilent's Forums posts are not presented by default in chronological order; in fact in some browsers with scripting blocked you can only see posts is the other format... whatever that is supposed to be doing.

Off topic to the purpose of this thread, but regrettably, I have never been able to find a setting to force the Forum to present the replies on an individual thread in chronological order by default. I've also asked Invision Community (who makes the software this Forum is hosted on) about adding/changing this a couple of different times over the years, but to no avail.

The feedback is really appreciated.
We found a plugin for the wiki system the documentation site runs on that will allow for PDF download, which has since been installed. There are some incompatibilities with other plugins and some other issues on the site which cause problems in the exported files, but we should be able to fix things up over time. The photo galleries at the top of many manuals are a particular offender, along with mathematical formulas, and some other missing figures here and there.
What this means is that it's currently possible to download any page as a PDF by appending "?do=export_pdf" to the URL. As mentioned above, results will be mixed, but the baseline capability is currently there, and we're looking to keep improving on it. - Edit, and we should be able to add download buttons to individual pages once we're confident that the results for those pages are good.
Thanks!
Arthur

@artvvb,
I would also ask Digilent to post and maintain PDF copies of all of their manuals.
It is common for hardware to outlive its support, or for newer versions of hardware to have newer documents that then get confused with the manuals for older products.  My solution to this has always been to download the PDF manual of the user guides or other spec sheets at the time of purchase, to guarantee that 1) I won't get confused by an update to a product I don't have later, and 2) I'll still be able to keep and maintain the manual long after the company that built the product has stopped supporting it.
Thanks!
Dan

@skandigraun,
I'm not a physicist, so others might correct me here, but has I understand things audio waves are compression waves.  To "read" them, you need to create a diaphragm that will move as the compression wave moves, and then you can read the position of this diaphragm over time.  The PMic does this with a MEMS microphone.  Consider this to be the meaning of those twelve bits.
Be careful with that twelfth  bit: it is a sign bit.  You may need to extend it to the left some to understand it properly.  For example, { int v; v = (sample<<20)>>12; }.
It is possible to get volume by simply averaging the absolute values of the various samples.  While crude, the estimate should work.
Getting frequency is harder.  Doing that requires a Fourier transform.  However, sound is very often composed of many frequencies, as the attached picture shows.  In that picture, time goes from left to right, frequency from bottom to top, and energy comes out of the page.  It's taken from the opening of the Cathedral's recording of "Echoes from the Burning Bush."  The clip starts with laughter, but otherwise has speech within it.  I would particularly draw your attention to how speech has a fundamental frequency associated with it, followed by many harmonics of that same frequency--as shown in the picture.  The result is that it can be difficult to say which frequency is in use, as many are present at the same time.
One of the book's I have on my shelf is Cohen's "Time Frequency Analysis."  In it, Leon Cohen goes through and compares many algorithms for frequency evaluation.  At one time I had a paper written that proved that the Short Time Fourier Transform, among his list but widely criticized, was the *only* frequency estimation problem that preserved certain key properties of spectral energy estimation: 1) all energy values should be non-negative, 2) all frequency shifts should produce frequency shifts in the estimation, 3) time shifts should produce time shifts in the estimate, and 4) that the estimate have and achieve the "best" time-frequency resolution as measured by the uncertainty function.  Perhaps I'll find a venue for publishing it in the future.  For now, you might wish to study the discrete time Short Time Fourier Transform, which is appropriate for the data coming out of the PMic.
At one time, I tried to build a digital tuner from sampled data.  Such a tuner requires exactly what you are asking for: knowing the frequency of the incoming data.  Further, it requires the assumption that there is only one incoming frequency, even when multiple are present (as the diagram shows).  To get there, I evaluated the autocorrelation signal that I got by taking the Inverse Fourier Transform of the magnitude squared of the output of a Fourier transform, and looking for the biggest peak.  This operation, taking place in time, usually but not always found the fundamental frequency I was looking for.
One more thought: you can find forward and inverse Fourier transform code, in Verilog, here, just in case you need it. 
Hope that helps,
Dan

@HomaGOD,
Let's see ... when I built with the keypad, I used the COLumns as FPGA outputs, and the ROWs and FPGA inputs.  Here's how I went about reading it:
First, output zeros on all of the COLumns.  This is the normal state of the keypad.  You'll sit here until something happens. If any of the ROWs, treated as inputs, produce a value other than VCC, then a button has been pressed. You can then output VCC on two of the COLumns.  If the ROW inputs don't change, then these two columns were not responsible for the button--repeat with the other two outputs Once you've narrowed down which two of the COLumns is responsible for the button press, you can set VCC out on three of the columns--the two unused (i.e. unpressed) ones, and the one that has been pressed. Your goal is to find the one COLumn, which when set to zero, leaves the ROW at zero--because the key is pressed.  That column plus the row then gives you the key you need. Beware of bouncing!  Once the key is pressed, you will have to wait for it to settle before reading it.  Looking back over my notes, I waited for 100,000 ticks after registering the ROWs weren't all VCC before I went and tried to figure out which COLumn was responsible.
Also, this isn't the only way to handle the PMod keypad.  I remember doing this in college (decades ago ...) and reversing the directions of the pins in the process.  In this case, the pull ups can help you to know which way to go.  For example, the COLumns have no pull ups on them--so they work better as outputs than as inputs.
Dan

In an effort to learn how to move network data to/from an FPGA I have taken the https://www.fpga4fun.com/10BASE-T.html ethernet project, rewrote it in VHDL and ported it to a Basys3.  I also added a LOT of comments in the code to help explain the header information required for the packets, and I changed the way the IPV4 checksum was calculated in an attempt to make it more obvious with out it works.  I used clock wizard IP to gen the 20MHz clock required for the project.  This was all in Vivado 2019.1 but that only matters if you want to use the clock wizard IP that I attached.  If you just generate your own clock IP, the vivado version you use will not matter. I learned a large amount (yet just scratched the surface) about ethernet, IPV4, and UDP to allow me to rewrite this project.
fpga4fun.com is a fantastic site, even after it appears to have been abandoned years ago. Thank you so much Jean P. Nicolle for leaving your fantastic site online for us.
UDP_Tx.vhd Basys3_Master.xdc clk_wiz_0.xcix

Today I authored a brief post to introduce a simple FPGA design that I shared on GitHub. The design inputs a 24-bit color palette value from a keypad; and then that color value is mixed on a discrete RGB LED as well as text on a small display.
https://timothystotts.github.io/2020/08/31/colors-palette-tester-on-arty-a7.html
Regards,
Tim S.
 

@Luke Abela,
I recently had the opportunity to write a data processing application that used an FPGA as an "accelerator".  Sadly, it probably slowed down processing, but the infrastructure is something you are more than welcome to examine and work with if you would like.  Data was sent to the FPGA using UDP packets over ethernet, read on the FPGA, assembled into larger packets for an FFT engine, processed, and then returned.
Dan

@RCB,
Why are you converting things to sign magnitude form, vs just leaving them in twos complement again?
I'm not certain what's going on.  Were this my own project, I'd use an FFT I'd be able to "see" inside of so that I might debug the problem.  Specifically, I'd look for overflow problems within the FFT--at least that's the only thing I can think of that might cause the bug you are referencing above.  It doesn't make sense, though, that you'd have overflow with one FFT and not with an identical FFT that only differed in output ordering.  You might wish to compare the .xml files of the two FFT's to see if they are truly the same as you believe.  You might also wish to try dropping the amplitude by a factor of 4x or perhaps even 64x to see if that makes a difference.  It might be that you have the scaling schedule messed up and that things are overflowing within.  It might also be that you aren't looking at all of the output bits with your bit-cut selection above--I can't tell by just looking at it from here.
Dan
P.S.  I don't work for Digilent, and do not get paid for answering forum posts.

@Ahmed Alfadhel
To understand what's going on, check out table 8 of the datasheet on page 15.  Basically, the DAC provides outputs between 0 and max, where 0 is mapped to zero and all ones is mapped to the max.  In other words, you should be plotting your data as unsigned.
To convert from your current twos complement representation to an unsigned representation where zero or idle is in the middle of the range, rather than on the far end, just toggle the MSB.
Dan

@skandigraun,
I'm not a physicist, so others might correct me here, but has I understand things audio waves are compression waves.  To "read" them, you need to create a diaphragm that will move as the compression wave moves, and then you can read the position of this diaphragm over time.  The PMic does this with a MEMS microphone.  Consider this to be the meaning of those twelve bits.
Be careful with that twelfth  bit: it is a sign bit.  You may need to extend it to the left some to understand it properly.  For example, { int v; v = (sample<<20)>>12; }.
It is possible to get volume by simply averaging the absolute values of the various samples.  While crude, the estimate should work.
Getting frequency is harder.  Doing that requires a Fourier transform.  However, sound is very often composed of many frequencies, as the attached picture shows.  In that picture, time goes from left to right, frequency from bottom to top, and energy comes out of the page.  It's taken from the opening of the Cathedral's recording of "Echoes from the Burning Bush."  The clip starts with laughter, but otherwise has speech within it.  I would particularly draw your attention to how speech has a fundamental frequency associated with it, followed by many harmonics of that same frequency--as shown in the picture.  The result is that it can be difficult to say which frequency is in use, as many are present at the same time.
One of the book's I have on my shelf is Cohen's "Time Frequency Analysis."  In it, Leon Cohen goes through and compares many algorithms for frequency evaluation.  At one time I had a paper written that proved that the Short Time Fourier Transform, among his list but widely criticized, was the *only* frequency estimation problem that preserved certain key properties of spectral energy estimation: 1) all energy values should be non-negative, 2) all frequency shifts should produce frequency shifts in the estimation, 3) time shifts should produce time shifts in the estimate, and 4) that the estimate have and achieve the "best" time-frequency resolution as measured by the uncertainty function.  Perhaps I'll find a venue for publishing it in the future.  For now, you might wish to study the discrete time Short Time Fourier Transform, which is appropriate for the data coming out of the PMic.
At one time, I tried to build a digital tuner from sampled data.  Such a tuner requires exactly what you are asking for: knowing the frequency of the incoming data.  Further, it requires the assumption that there is only one incoming frequency, even when multiple are present (as the diagram shows).  To get there, I evaluated the autocorrelation signal that I got by taking the Inverse Fourier Transform of the magnitude squared of the output of a Fourier transform, and looking for the biggest peak.  This operation, taking place in time, usually but not always found the fundamental frequency I was looking for.
One more thought: you can find forward and inverse Fourier transform code, in Verilog, here, just in case you need it. 
Hope that helps,
Dan

@MrKing,
Welcome to the forum.  Feel free to share your questions, as there tends to be a lot of learning going on here!
Dan

@hirayaku,
It looks like you may have changed or adjusted the parameters of the memory controller.  For example, the Zybo runs with a 525MHz clock according to the board support files, not a 200MHz clock or a 533 MHz clock.  Can you please check your memory controller configuration against the one in the board support files here, to check that it matches?
Thanks,
Dan