Let me start by saying that 7 cm is not a long distance to go for 40 MHz signals. I've ran double that frequently and didn't even break a sweat. Below is a list of issues that you need to consider when doing this:
Trace length: As I just said, 7 cm is not far. But look at your timing budget. If your budget is tight you might have to do something called "matched trace lengths", where every signal of your bus has the same length. Odds are that at 40 MHz you don't need this, but it is worth looking into.
Parallel traces: Try to keep some space between signals on this bus. This is super important for clock and control signals, and less important for data. A normal PCB might have 0.008 inches (0.2 mm) between traces, and you might consider doubling or tippling that. It is OK for them to be close for short distances, but the longer the traces the farther apart they should be.
Power/Ground Planes: Yes, have them. This is important. Run your traces on a layer that is adjacent to the power or ground plane. I am skipping over a LOT of details here that pertain to high-speed digital design. This is an area for you to learn more of in the future. If you can't have a power/gnd plane then your problem has gotten 10 times harder. Run a ground trace next to each signal trace and hope for the best!
Termination: Yes, use them! If the signals are going from one chip to another (and not connecting to more chips) then using source termination is the easiest. Normally that would be a 33 to 50 ohm resistor in series and located at the driver of the signal.
Decoupling caps: Make sure that all chips are properly decoupled. Then add decoupling caps near places where signals move through a via (no more than 1 cap every 3 square cm). Again, I am skipping details but at 40 MHz you don't need to worry that much.
This has to be a protocol error between FPGA and MCU. Your low-level AC signal (audio) from the FPGA is being mis-read (somehow) by the MCU. The noise looks like incorrect value of the sign bit appearing as large impulses on the decoded signal.
As Dave Tweed says, you don't want the MCU to be reading the signal while the FPGA is updating it. Are you reading all the GPIO pins with a single instruction? I'm guessing not.
You might want to bombproof this transfer with a handshake from FPGA to MCU. Update the audio sample then assert a Req signal. Wait for the MCU to assert an Ack signal, retract Req, then wait until MCU retracts Ack (and the next sample is ready) before updating the signal again.
In the MCU, only access the audio data when Ack is 1.
Best Answer
Some things I'd try:
You have to think about how the current is flowing - both "out" and "back" - any time the current of one signal mixes with another (say using a single ground return wire), you will have potential for problems.
Another suggestion - in order to understand what's going on so you can predict these problems next time, read (and inwardly digest :) a book on signal integrity