How to detect the edge of video synchronization signal (vsync and hsync)?
Allen
I am trying to detect the positive edge of video synchronzation
signals by writing "sythesizable" Verilog code.
Here is the problem:
I try to enable a counter to record the length of vsync
signal at the positive edge of vsync and stop recording at the next
positive edge reached.
I have no idea how to implement this one, does anyone
have experiences about this? I tried to write Verilog code, but after
synthesis it doesn't work well
__
__
vsync __| |___________________________________________| |______
^<======== Length of vsync signal ====== >
^
Start to calculate the length of
vsync Stop calculating
Thanks ,
Regards.
Jonathan Bromley
Allen <lph...@gmail.com> wrote:
> I am trying to detect the positive edge of video synchronzation
>signals by writing "sythesizable" Verilog code.
If you include ASCII-art in posts, please make sure you edit
the post in a fixed-width font so that everyone can see the
pictures instead of having to guess!
> Here is the problem:
> I try to enable a counter to record the length of vsync
>signal at the positive edge of vsync and stop recording at the next
>positive edge reached.
That's not the length of vsync, it's the length of a whole video line.
Anyways, here goes. It's the standard synchronous edge detector.
If the vsync signal is already strictly synchronous with your
system clock, then there's no need for the resynchronising flop.
I'll write it as several separate processes to make it easier to
follow - but you really ought to write it as one big process,
I think.
stage 1:
~~~~~~~~
Resynchronise the vsync signal to your system clock.
Creates just one flip-flop. Not needed if vsync is
already synchronous with the clock.
always @(posedge sysclk)
synch_vsync <= vsync;
stage 2:
~~~~~~~~
Locate the positive edge of vsync by finding when vsync
is 1 but a delayed copy of it is 0. Use this to create
a fully-synchronous enable signal.
always @(posedge sysclk) begin
vsync_delayed <= synch_vsync;
vsync_rise <= synch_vsync & ~vsync_delayed;
end
stage 3:
~~~~~~~~
Run a counter, but every vsync rise you reset the
counter having first captured its value into the line_length
register. Note that "line_counter" and "line_length"
must be appropriate multi-bit registers, wide enough to
hold the number of clock cycles in a video line. Note
too the missing synch detection, which notices if the
counter overflows. Signal "synch_lost" goes to 1 as soon
as the counter overflows, and goes back to 0 after the
next complete line is measured. Register "line_length"
contains a nice stable copy of the number of pixels on a
line (positive edge to positive edge of vsync).
Of course, in a real video application you could also
decode the line_counter value to extract blanking, burst,
and suchlike information.
always @(posedge sysclk) begin
if (vsync_rise) begin
synch_lost <= missing_sync;
missing_sync <= 0;
line_counter <= 1;
line_length <= line_counter;
end else begin
line_counter <= line_counter + 1;
if (line_counter == 0) begin
missing_sync <= 1;
synch_lost <= 1;
end
end
end
There. I've done it for you. Only the declarations needed.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan...@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
gabor
wrote:
> On Mon, 22 Oct 2007 00:27:27 -0700,
>
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
Another point since you said your synthesized code "did not work
well".
A vsync signal is often supplied from a slow (with respect to rise/
fall
times) signal source. This can create glitches during transitions
that
your system clock may be fast enough to catch. I would generally
recommend cleaning it up with a debounce circuit. I usually use a
5-stage S/R and set the internal synchronous signal only when all
stages are high, and clear the internal signal when all stages are
low.
This works well for frequencies around 100 MHz. You can reduce the
number of stages if your clock is slower.
Martin Thompson
Nit picking follows - sorry!
Jonathan Bromley <jonathan...@MYCOMPANY.com> writes:
> On Mon, 22 Oct 2007 00:27:27 -0700,
> Allen <lph...@gmail.com> wrote:
<snip>
>
>> Here is the problem:
>> I try to enable a counter to record the length of vsync
>>signal at the positive edge of vsync and stop recording at the next
>>positive edge reached.
>
> That's not the length of vsync, it's the length of a whole video line.
>
I'm sure Jonathan means the length of a whole video *frame* :-)
However.... this won't tell you how many pixels are in your frame
though as there is some time during which hsync will be low but vsync
will be high. And often vsync leads the rising edge of the first
line's hsync and lags the falling edge of the last line's hsync.
<more snippage>
Cheers,
Martin
--
martin.j...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
Jonathan Bromley
Thompson <martin.j...@trw.com> wrote:
>Nit picking follows - sorry!
As indulged-in by all the best pedants - we're a
dying breed :-)
>> That's not the length of vsync, it's the length of a whole video line.
>
>I'm sure Jonathan means the length of a whole video *frame* :-)
Urrm, no he didn't, he meant "line" because he suffered a
brain-fart and just read "vsync" as "hsync" throughout.
I could blame the drink, but (depressingly) there wasn't
any at the time, so it must be either old age or stupidity.
The effects are broadly similar.
Of course your nitpicks are valid and important.
I provided a pretty nifty line-length measurement, though!