Data Transfer between two Spartan 3E

Question

I'm trying to do ADC-DAC with two separate Spartan 3E kits. First kit will get analog signal and convert it to digital. Second kit will get this converted digital data and convert it to analog again. I successfully implemented ADC and DAC separately, but how can I send 14bit digital data from first kit to another kit? (Do I need a clock synchronization?)

Answer 1

You need to get three signals from one FPGA to the other

1. the data itself as a stream of bits
2. A clock signal to indicate each new bit of data
3. A framing signal to divide the stream of bits into separate data words (e.g. indicate that the next data bit is the first bit of a new word.

But you only want to use one wire (and a ground connection!)

There are standard ways of doing this; combining the three distinct pieces of information into a single signal.

One common technique for combining clock and data together is called "Manchester encoding" (you can search for more information on this). It starts with a clock running at twice the bit rate. On every even numbered clock edge you change the state of the signal. Then on the odd clock edges, you change the state if that data bit is '1', otherwise you leave the state unchanged.

The receiver has to distinguish between clock and data edges to synchronise itself. It does so by measuring the time between transitions : as soon as it detects a missing transition it knows there was a data bit so the next transition must be a clock; once it has synchronised, it can start to decode data.

So we have now combined clock and data together; we just need to add framing.

Clock ^   ^   ^   ^   ^   ^   ^   ^   ^ ...
Data    0   0   1   0   1   1   0   0   ...
Sig   0 0 1 1 0 1 0 0 1 0 1 0 1 1 0 0 1 ...

One way to do this is to delete a clock edge so that there are at least 2 missing transitions followed by an actual clock edge. This sequence breaks the normal rules of Manchester coding and is called a preamble, or a framing pattern.

The receiver can detect the preamble, and know that the next bit is the start of a data word. (The preamble can contain other information too, to distinguish between left and right channels in a stereo signal for example).

Clock ^   ^   ^   ^   ^   ^   ^   ^   ^ ...
Data    0   x   x   0   1   1   0   0   ...
Sig   0 0 1 0 0 0 1 1 0 1 0 1 0 0 1 1 0 ...
Pre       1 0 0 0 (note missing clock)
Count               1   2   3   4   5   ...

Note that if the signal was 1 before the preamble, you would invert the preamble and it would then be 0 1 1 1.

For a fully worked example using this technique, look at the AES/EBU audio interfacing standard or SP/DIF its consumer grade derivative.

Answer 2

Two options, depending on the data rates you are dealing with:

For relatively low data rates (on order of 10's - 100 kbps), frame and serialize your data and send it out over the RS-232 port. On the other side, receive the serial data, deserialize, and look for the data framing to pick out your data. As long as data does not need to be processed every clock cycle, you don't need to worry about synchronizing clocks in this case. If the data rate is such that samples are processed every cycle, then you will need to synchronize the clocks since small variations in the clock rate between the two boards will over time cause you to drop samples.

For higher data rates, look into using the FX2 connector with differential outputs (LVDS). Send your 14 bits (28 wires) across to the other board, along with the clock used by the ADC board. On the DAC board, receive the clock and use it to generate your local system clock. You can then use the generated system clock to sample the incoming data. This is called a source synchronous design. You may need to play around with clock phasing to sample the incoming data at the proper time in order to not violate setup/hold requirements at the IOB. Also note that the signal skew between data bits could become critically important to control at high clock rates. If you aren't careful, you could have one or two bits that lag a sample behind, essentially corrupting your data.