Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21611 Discussions

synchronization problem

Altera_Forum
Honored Contributor II
1,375 Views

Hi ,  

i have a digital card with FPGA and the FPGA transmit serial data from the pin from this card to other external loopback card(connected together) 

and then the data back to the the FPGA to different pin. 

 

The problem is that the data have variant delay at the digital line and it cause meta stable issue to the signal and as a result the received signal is different from the transmitted signal . 

i can't transmit the clk with the data because of technical issue and can't measure the delay line and insert the delay into SDC file because of system request . 

 

which vhdl code can solve this problem ? 

 

Thanks for helping.
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
551 Views

Sounds like a homework problem.. :) Depending on the the data rate a standard RS232 protocol works. Read up on it, and understand what the Start and Stop bits are used for. 

 

Metastability is still a problem, but this can be minimized by having a mulitple register stages at the input so by the time you "read" the data, you know it should be stable. 

 

As long as your data rate is much slower than your internal clock rate, you can then detect the edge of the start bit, and find the approximate center of the bits, then use a this to sample each bit at it's ideal center. 

 

Pete
0 Kudos
Altera_Forum
Honored Contributor II
551 Views

Hi ,  

it's my final project for BS.c and i cant transmit start bit and stop bit because it insert overhead to the data traffic . 

how can i sample the center of the bits ? do i need to sample at higher clock and shift the pulse 45 degrees ? 

thanks for support .
0 Kudos
Altera_Forum
Honored Contributor II
551 Views

What is the data rate you are sending at?  

 

There are several different methods that can be used, but each have their own issues: Like you said the start/stop bit of RS232 adds overhead, but it allows you to align each byte. This works well in modern FPGAs with data rates up to 1 Mbps. If you know the transmit data rate, you just simply detect the first start edge, then count your high speed clocks until you are in the center of the bit, to sample, and then sample at the low speed data rate until you receive a byte (or n Bytes) (You don't have a clock to adjust the phase, because you are assuming your clock is a high speed internal clock.) 

 

Manchester Encoding allows you to recover the sending clock. But usually you need a preamble of some known pattern to define the "Start" of a packet. (So you can determine if it's a 1 or a 0) 

 

There are other methods as well, but these are the simplest. 

 

Pete
0 Kudos
Altera_Forum
Honored Contributor II
551 Views

Hi ,  

The data rate i'm sending is at 25Mhz - it is PRBS data (serial data) . 

As I understood your explanation , I need to detect the first start edge (because i generate it , i know when it start ...) and thens ample at High speed clock -  

lets say 100MHz until the higher clock is in the center of the data to be able to sample at the healthy and stable signal, and then sample at 25MHz again  

to reproduce the original data at 25MHz . 

am i correct ? will it work stable ?
0 Kudos
Altera_Forum
Honored Contributor II
551 Views

This is typically how I do it for slower date rates. But it has a couple of requirements: 

 

1: your sampling clock must be >> that your data rate. 

2: You know the data rate, and the accuracy in the data rate vs your sampling data rate is close enough that it will insure proper sampling throughout the packet. 

3: You have a reliable means of detecting the start of the packet. (Either through start/stop bits, preambles, etc). 

 

With a data rate of 25 MHz, I would want a sampling clock in the 200 MHz range, so that I can insure I'm in the center of the bit. You can use each transition to re-time your sampler to make sure you stay within the center of the bit, but if you have long sequences of 1's or 0's you could end up with problems if your effictive sampling data rate and transmitting data rate have any significant skew. 

 

Pete
0 Kudos
Reply