Fast Sampling of digital signals

Hi, I'm building a S/PDIF Receiver for implementation on spartan 3 fpga. I don't have an expensive DSO to analyze the spdif signals : ( So i decided to build a sampler and run it fast enough, say 10-20 times the spdif signal frequency and the display the signal on some audio editing software.(remember i'm sampling only digital signals so there's no ADC involved)

So here's my setup, I'm taking the input signal and passing it through a 2 flop synchroniser, then i'm packing 8 samples to a byte and writing it to a 16K block ram fifo on fpga. The sampled data is sent to the PC through FTDI's UM245R module. At reset the sampler samples

16K X 8 samples , writes to fifo and stops. the system is running at 50Mhz (also sampling input signal at 50msps), the sampling packing and writing to fifo is done on the fly. Then the usb module writes the data to the usb port in its own time.

The problem: When i sample signals from the same clock domain (i.e, a divided clock from 50Mhz sys clk) the are no problems. I see perfect clock signal with nearly 50% duty cycle and no glitches in sight. but once i feed an external signal signal such as the spdif or a clock from a different oscillator, the signal seems to closely match the frequency of the input but I see a lot of glitches. Most of the glitches are one sample wide and very close to the rising/falling edges of the input signal. but there are also quite a few glitches in stable 1's /0's regions of the input signal.

So what could be the possible cause of these glitches? I can understand glitches near the edges which could be due to metastability but in the middle of stable 1's and 0's there could be no issue of metastability. I have used 2 flop synchroniser like the ones used in asynchronous fifo's. What else can i do the eliminate the glitches?

Reply to
aravind
Loading thread data ...

Reply to
Peter Alfke

When working with SPDIF I wouldn't rule out analog effects, especially transmission line effects. And not just on your end, some of the sources are pretty ugly.

Did some digital audio work and found a couple systems where playing with the terminating resistor would make all the difference between reliable operation, iffy operation, and completely inoperative. Some of that turned out to be a suboptimal manufacturer configuration of the clock recovery device making it hypersensitive to duty cycle, but the analog quality of the signal could make it work or fail.

Reply to
cs_posting

Ok, I agree i did use a fairly long cable to bring the spdif signal from the PC, but i have the same problem when i feed a ~1Mhz clock straight off an oscillator.

Reply to
aravind

You can simplify your system: Eliminate the FIFO controller, and write bit-serial data into one BRAM port, and read byte-wide data from the other port. You just need two counters, one longer one for write, and a shorter one for read.

To trace mysterious errors, I always reduce complexity to "bare b> >

Reply to
Peter Alfke

. .

Try a schmitt trigger on input?, and possible some small capacitance?

Reply to
pbFJKD

formatting link

Reply to
vasile

I am also about to produce some audio equipment to interconnect studio devices. The fundamental issue is the variant capability of jitter compensation of different devices - most make the signal even worse. To get along with a number of jittering channels, I found that the FPGA freq cannot be high enough! 50 Mhz is only factor 1000 above the lowest signal of 48kHz, what I am typically using over SPDIF.

A big aspect is also the analog behavior of the interface you are using. I found much better results in using optical TOSLINK than coaxial SPDIF. When beeing electrically wirered I try to only use the AES/ EBU imterfaces of my devices, which ist symmetrical bus.

Reply to
fpgauser

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.