I would like to implement a bitrate regulation on an fpga board.
Clock + data are incoming at bitrate with a +/- percentage. Then after a channel coder the bitrate is increased (Viterbi with tail bits or Reed Solomon)
Does anyone have an idea of implementation avoiding to design a digital PLL (second order) ?
I hope my issue is well explained.
Thanks a lot
Do you need a stable clock or pulse running at the coded rate or can you just get away with framing and buffering? Alternatively, if the coded rate is a nice multiple of the bitrate, then it may be as easy as generating a pulse at the new multiple of the old clock rate. e.g., a Rate = 1/2 Convolutional Encoder produces exactly twice as many bits as the incoming rate, so either running two streams in parallel or pulsing at double the rate of the incoming bits can often be done easily without a PLL.
If you need a coded bit rate clock (or pulse) that isn't an easy multiple of the input rate, then don't be intimidated by making a digital PLL. They're not that hard, and people have been doing them for many years.
In my case, I have to keep a 50% duty cycle on data and clock at output. Ratio of channel coding is not 1/2, it would be too easy :)
I guess digital PLL is the only solution. I have seen an interesting article somewhere here. I am mostly intimidated by others effects: false locks, and forgeting unpredicted tests...
I am not clear about your issue. Is your clock jittery or are you not sure how to control rate after channel coder.
Have you considered clock enable?
Here is a block diagram of what I try to implement:
Clock_in + Data_in | Channel | Clock_out + Data_out
at bitrate +----------->+ encoding +---> bitrate x k
| Rate 1/k |
Clock_in an data_in come from outside FPGA at bitrate +/- offset.
k is not an integer. The output clock_out and data_out is at (bitrate +/- offset) x k.
The input offset has to be estimated inside the channel encoder and added to the output speed.
Digital PLL does it well but is quite tricky to implement.
If the clock coming in is unambiguous then you should have to problem.
It's when the clock has to be recovered from the signal, or when there's lots of noise, or when the actual clock differs a great deal from your local reference that things get difficult.