[moved] Time-code decoder - SMPTE - BiPhase Mark - clock recovery - full design

[orso135]

Hello!
I am a just-graduated engineer and right now I am doing an internship in Japan. My task is to develop a SMPTE time code decoder on a FPGA ALTERA DE0 TERASIC and display the time-code on the 7-segment displays.
I have attended two courses at the university about digital design, but up to now I have no practical experience and unfortunately my supervisor knows nothing about VHDL.

Quick summary of the theory behind the timecode:
• SMPTE timecode is a set of cooperating standards to label individual frames of video or film with a time code. Timecodes are added to film, video or audio material, and have also been adapted to synchronize music.
(Wikipedia: http://en.wikipedia.org/wiki/SMPTE_timecode )
• Timecode is encoded using LTC
(Wikipedia: http://en.wikipedia.org/wiki/Linear_timecode )
• The bits are encoded using the biphase mark code (also known as FM): a 0 bit has a single transition at the start of the bit period. A 1 bit has two transitions, at the beginning and middle of the period. This encoding is self-clocking.(http://www.philrees.co.uk/articles/timecode.htm )


This is the basic design I came up with and I would like to have your opinion about it




The first step is to decode the time-code (encoded in Bi-Phase Mark). In the figure below there is the data-path of the Bi-Phase decoder.


First, clock recovery has to be performed using a PLL. Then the following FSM that changes states after every clock edge (twice in a clock period) can be employed.



In states in_s0 and in_s1 (respectively first and second half periods) the input is saved in RegX and RegY (both 1 bit registers). The stored values are then compared, if:
• they are equal then the decoded value is a ‘0’
• they are different then the decoded value is a ‘1’
At the following clock edge the current state is restored to state in_s0. The value of the two registers is compared and with an offset of half period the result is saved in a register (RegZ) that holds it for a whole clock period.


Below there is the Algorithm State Machine and Finite State Machine of the main design.

Once the clock has been recovered and the time code decoded then the shift register A (regA) is filled.
The last 16 bits are constantly compared with the SYNC WORD. This is accomplished in the state s0 (new FSM see attachment 5).

Once the SYNC WORD has been found then the FSM jumps to state s1 where a counter that was initially set to 0 is now enabled. When the counter reaches 79 (that is 80 clock ticks starting from 0) then the state becomes s2 (that is the whole timecode frame of 80bit has been saved).

In state s2 the timecode frame (80bits) is copied into the register B (regB) and the counter is now reset.

The combinatorial decoders (for frames, seconds and minutes) make sure that the correct bits inside the timecode frame are correctly displayed using the 7-segment displays of the DE0 board.


My questions are the following:

• How would you accomplish clock recovery on an FPGA? I previously found this https://www.edaboard.com/threads/11258/, but I did not really understood it. Do you have any suggestions?
• Does the Bi-Phase decoding algorithm make sense to you or you would employ another (maybe easier) solution?
• Do you think this design is feasible? Do you see any flaws or possible improvements that can be made?

Any comment is highly appreciated! Thank you very much for your support!

 

[ads-ee]

FPGAs do not support clocking on both edges as you seem to want your FSM to run at 2x the clock rate.

Oversampling the signal is the usually done to do what you are asking. There aren't any PLLs in an FPGA that will lock on a non clock data stream to perform clock recovery. Sampling is usually done at 5x the data with a FSM to used to calibrate the delay and find the optimal sample point.

 

[orso135]

Thank you very much for your help! :smile: and sorry for posting in the wrong section.
I have no practical experience in reconstructing a signal after performing sampling, do you have suggestion in terms of resources (e.g. books, websites)?
Would it be reasonable to implement the FSM in the following way?

Let’s suppose to oversample the signal 6 times. Since the input signal is digital it may have only HIGH or LOW values. Since the signal is encoded using Bi-phase mark:

• if a sequence of ‘0’ is sent, then the input is a square wave and a constant value is sampled 6 times
• if a sequence of ‘1’ is sent, then the input is a square wave and a constant value is sampled 3 times, then an opposite value is sampled 3 times (there is a variation at the falling edge of the signal clock).

This implies that by counting constant consecutive samples we can determine if a constant value is LONG (6 samples) or SHORT (3 samples). This can be done using a shift register of 1 bit (FF). For initialization purposes, we have to wait for the first transition. Then we increase a counter until the value changes. Compare the counter value with ‘3’ or ‘6’ and determine if the sequence is LONG or SHORT. If LONG output ‘0’, if SHORT output ‘1’.


Is this reasoning correct? Do you have any suggestion?

 

[std_match]

This implies that by counting constant consecutive samples we can determine if a constant value is LONG (6 samples) or SHORT (3 samples). This can be done using a shift register of 1 bit (FF). For initialization purposes, we have to wait for the first transition. Then we increase a counter until the value changes. Compare the counter value with ‘3’ or ‘6’ and determine if the sequence is LONG or SHORT. If LONG output ‘0’, if SHORT output ‘1’.

You should not look for 3 or 6. There will be some jitter, so 4 or lower is SHORT and 5 or higher is LONG.
Your state machine should be robust, so it always can resynchronize if there is a disturbance.

 

[orso135]

Thank std_match for your suggestion!
This is a quick sketch of the ASM and datapath of the new decoder made using your help.
Everything that is done before incrementing the counter CNT serves as initialization (the FSM waits for the first data transition).

The sampling clock is obtained by scaling the original 50MHz clock 3472 times (the highest frequency of the time code is 2400Hz -> 50MHz/(2400*6)=3472 )

The only decoding error is detected when a SHORT is not followed by another SHORT (if a '1' is sent then there are always 2 transition in one period -> 2 SHORTs). In that case an LED is turned on and the registers are reset.

The output is saved in a register and every time its value is changed a signal out_state_change flips from '0' to '1' or viceversa (XOR).

Do you think this implementation can work? Is it robust enough? do you see any improvement?

 

[std_match]

You should probably have range checks on the CNT value. Maybe SHORT = 2-4 and LONG = 5-7.
Restart the decoder if you get a value outside of these ranges.

Do the development and debugging with a simulator and a test bench (the Altera version of Modelsim). It is a waste of time to do all of the debugging on the real hardware.
When you go to the hardware you should be confident that the design is correct.
This means that you must generate an SMPTE signal in your test bench, but that is easy with VHDL.
It is also easy to generate the errors that the design should handle. That is normally much more difficult with the real hardware,

 

[Dan Mills]

Do note that the speed of the smpte timecode can vary widely, particularly if the source is a tape transport doing a locate operation, this is an actual valid use case for LTC.

You cannot assume that 25 frame LTC will be running at 25 frames per second, an order of magnitude or so faster is possible....

Regards, Dan.

 

[std_match]

Do note that the speed of the smpte timecode can vary widely, particularly if the source is a tape transport doing a locate operation, this is an actual valid use case for LTC.

You cannot assume that 25 frame LTC will be running at 25 frames per second, an order of magnitude or so faster is possible.....

This means that the sample rate must be higher and that the state machine must adapt to the current speed. A low-speed SHORT can be longer than a high-speed LONG. If it is considered from the beginning, it should not be a big problem.

 

[Dan Mills]

Yea, not that hard to deal with, measure the count on a high speed clock and average it over the last few hundred edges, but I was worried that the OP might be thinking that the input rate was known....

Regards, Dan.

 

[orso135]

Thank you very much for all your suggestions. I really appreciate your help!
So far I’m employing as source a dedicated time code generator, so I hope I should not be concerned too much about variation in speed of the smpte code. My first goal is to develop something that ‘just work’. Once I create the first prototype I’ll try to improve it, adding for example dynamic sync for speed variation.

Attached to this post there is a newer ASM, FSM and datapath



for the timecode decoder. Considering that the internal clock of the FPGA is 50MHz, I figured out that keeping a bigger frequency distance from the Nyquist limit may be recommended and I decided to sample at 48kHz. This implies that the scaling factor is now 1041.
If there are (5-15) constant samples then is SHORT, if there are (15-25) constant samples then it is LONG (only if previously there was no single SHORT (SHORTs always come in pairs); this is taken into account by the signal prev_SHORT). Any other situation is considered an error that turns on a LED and reset the decoder.

Comments are always greatly appreciated!:smile: