The interface to an AC97 codec is a bit more complicated than straight digital audio. The serial data consists of 256-bit data frames; each frame contains several channels of 20-bit samples. The overall data rate is 12.288 MHz; dividing by 256 gives the sample rate of 48 kHz. Part of the 256-bit frame is dedicated to control messages, e.g. to set mixer registers. You may need to do this once after power up/reset to set the volume.
The AC97 spec is available from Intel. Writing your own master is not unreasonable but it will take some time. You may also be able to find one you can reuse. OpenCores has one. There's a very barebones AC97 controller and some general information about the protocol here.
I can't remember how many of the AC97 registers are standardized. The manual I found online for your board says it has an LM4550 codec. Assuming that's right, you may want to refer to the LM4550 datasheet for a complete list of configuration registers.
First thing you need to recognize is that designing with a 16-bit ADC is not trivial. Even at 1 sample/s, you need to pay extreme attention to every aspect of the design to achieve 16-bit precision, or even more difficultly, 16-bit accuracy. At 130 MSa/s, everything is even more difficult.
The parts you need to do this kind of design simply won't be inexpensive. First, because of the extreme precision and careful testing needed to achieve the required performance. Second, because this kind of thing isn't done in mass-market products, so the parts aren't built in the kind of extremely high volumes that can bring the price down for everyone.
As Dave says in another answer, be sure you really need 16 bits before you go down this road. But maybe you really need 12-bit precision, and you know that if you use even a 14-bit ADC you're going to have a hard time achieving that, so you're designing with 16-bit ADC and optimize everything else as much as you can.
Another key is likely to be understanding exactly what specs you need to make your system work, and don't over-specify your clock jitter. In an SDR application, you're going to be doing math on the samples to extract specific frequency bands, etc, which will have an averaging effect over many cycles. So you might not care too much that absolutely every sample is timed perfectly, only that over your calculation interval, there isn't too much deviation from ideal timing. How much is too much, of course, depends on what kind of math you're doing and how small a signal you need to extract from how much noise.
CTS Valpey, for example, has XO's with rms jitter specs as low as 200 fs. But this spec is defined when the phase noise is integrated over a specific frequency band, 12 kHz to 20 MHz (relative to the carrier). If the total cycle-to-cycle jitter is considered, the spec jumps to 3-6 ps, depending on the center frequency.
Let me also address one comment you made in your question:
OCXO are extremely stable over time ( years ) and are usually used for that.
The "ovenized" part of that product mainly reduces the drift due to temperature change in the surrounding environment, which can be significant over time scales of minutes or seconds, not just years. It will also reduce wear on the part due to thermal cycling and improve the stability on a time scale of years.
For the < 100 fs jitter range you're looking for, you might actually need an OCXO to prevent small temperature changes affecting the performance during the time it takes to measure the jitter accurately enough to know you've achieved your spec.
Best Answer
I haven't used Spartan6 specifically, but you should be able to instantiate a BUFPLL (page 52) primitive and feed the output of whatever is generated by the wizard into that.
Page 80 of Xilinx Spartan-6 Libraries Guide for HDL Designs will have the info you need on instantiation.