Synchronize incoming singal to clock

Hello @ all,

i have a small problem with synchronizing an incoming singal to the
Clock of my VIRTEX4.
At the moment i use this code to synchronize the incoming asynchronous
signal Pulse:

Sync_Pulse : process ( Internal_Clock )
begin

temp_pulse <= Pulse;
sync_pulse <= temp_pulse;

end process;

My question is if there is a more elegant or easier way to synchronize
an incoming signal.
thank you
Marc

TheThunder

"TheThunder" <> a écrit dans le message de news: m...
> Hello @ all,
>
> i have a small problem with synchronizing an incoming singal to the
> Clock of my VIRTEX4.
> At the moment i use this code to synchronize the incoming asynchronous
> signal Pulse:
>
> Sync_Pulse : process ( Internal_Clock )
> begin
>
> temp_pulse <= Pulse;
> sync_pulse <= temp_pulse;
>
> end process;
>
> My question is if there is a more elegant or easier way to synchronize
> an incoming signal.
> thank you
> Marc
>

Yes, use 2 Flip Flop, thats is correct.

but

do you really want these Flip Flop be trigerred by both edge of the clocks ?

ast

TheThunder wrote:
> Hello @ all,
>
> i have a small problem with synchronizing an incoming singal to the
> Clock of my VIRTEX4.
> At the moment i use this code to synchronize the incoming asynchronous
> signal Pulse:
>
> Sync_Pulse : process ( Internal_Clock )
> begin
>
> temp_pulse <= Pulse;
> sync_pulse <= temp_pulse;
>
> end process;
>
> My question is if there is a more elegant or easier way to synchronize
> an incoming signal.
> thank you
> Marc

Except for leaving out the clock in your process, that's a standard 2-
stage synchronizer.
In other words:
process ( Internal_Clock )
begin
if rising_edge( Internal_Clock ) then
temp_pulse <= Pulse;
sync_pulse <= temp_pulse;
end if;
end;

-Dave Pollum

Dave Pollum

oh sorry i forgot to post the

"if rising_edge()"

thank you very much so i don't have to search anymore for a better
way!
1000 thanks!

TheThunder

TheThunder wrote:

> At the moment i use this code to synchronize the incoming asynchronous
> signal Pulse:
>
> Sync_Pulse : process ( Internal_Clock )
> begin
>
> temp_pulse <= Pulse;
> sync_pulse <= temp_pulse;
>
> end process;
>
> My question is if there is a more elegant or easier way to synchronize
> an incoming signal.

I use a procedure call from a synchronous process like this:

retime(
arg_in => Pulse, -- entity port value
update => retime_v -- UPDATE the variable retime_v
);


See the "Rising Level Counter" example here
http://home.comcast.net/~mike_treseler/
for details.

-- Mike Treseler

Mike Treseler

There is a lot which you can see on the web regarding metastability.
In general if it is one signal, which comes across another clock
domain, than it is fine. If there are bigger buses involved, you may
need another solution.
Also there are many asynchronous serial communications standards
today. I have started to document a USB full speed project on
http://bknpk.no-ip.biz. In this case host and slave uses asynchronous
clocks.
Mike Treseler :
> TheThunder wrote:
>
> > At the moment i use this code to synchronize the incoming asynchronous
> > signal Pulse:
> >
> > Sync_Pulse : process ( Internal_Clock )
> > begin
> >
> > temp_pulse <= Pulse;
> > sync_pulse <= temp_pulse;
> >
> > end process;
> >
> > My question is if there is a more elegant or easier way to synchronize
> > an incoming signal.
>
> I use a procedure call from a synchronous process like this:
>
> retime(
> arg_in => Pulse, -- entity port value
> update => retime_v -- UPDATE the variable retime_v
> );
>
>
> See the "Rising Level Counter" example here
> http://home.comcast.net/~mike_treseler/
> for details.
>
> -- Mike Treseler

Pinhas

Pinhas wrote:
> There is a lot which you can see on the web regarding metastability.
> In general if it is one signal, which comes across another clock
> domain, than it is fine. If there are bigger buses involved, you may
> need another solution.
> Also there are many asynchronous serial communications standards
> today. I have started to document a USB full speed project on
> http://bknpk.no-ip.biz. In this case host and slave uses asynchronous
> clocks.
You shouldn't ever try to synchronise the signals of a multi-bit bus
(assuming you have no prior knowledge of exactly how they behave).
Given there is always some finite skew between the bits on the bus, it's
a cert that sometime you will synchronise the early & late values of
different bits, resulting in a broken value.
The proper way is to set the bus value, then assert a strobe.
Synchronise the strobe, then latch the bus (which is known to be stable)
into the new domain.

David R Brooks

"David R Brooks" <> a écrit dans le message de news:
4674495e$0$22421$...
> Pinhas wrote:
>> There is a lot which you can see on the web regarding metastability.
>> In general if it is one signal, which comes across another clock
>> domain, than it is fine. If there are bigger buses involved, you may
>> need another solution.
>> Also there are many asynchronous serial communications standards
>> today. I have started to document a USB full speed project on
>> http://bknpk.no-ip.biz. In this case host and slave uses asynchronous
>> clocks.

> You shouldn't ever try to synchronise the signals of a multi-bit bus (assuming you have no prior knowledge of exactly how they
> behave).
> Given there is always some finite skew between the bits on the bus, it's a cert that sometime you will synchronise the early &
> late values of different bits, resulting in a broken value.
> The proper way is to set the bus value, then assert a strobe. Synchronise the strobe, then latch the bus (which is known to be
> stable) into the new domain.

You can strobe asynchronously a bus only if one bit is changing at a time.

ie, generating a "half full" signal for an asynchronous FIFO by strobing
the write and read address pointer if there are gray encoded.

ast

On Jun 11, 7:56 pm, "ast" <a...@ast.com> wrote:
> "TheThunder" <marcal...@gmx.de> a écrit dans le message de news: 1181584299.313031.41...@w5g2000hsg.googlegroups.co m...
>
>
>
>
>
> > Hello @ all,
>
> > i have a small problem with synchronizing an incoming singal to the
> > Clock of my VIRTEX4.
> > At the moment i use this code to synchronize the incoming asynchronous
> > signal Pulse:
>
> > Sync_Pulse : process ( Internal_Clock )
> > begin
>
> > temp_pulse <= Pulse;
> > sync_pulse <= temp_pulse;
>
> > end process;
>
> > My question is if there is a more elegant or easier way to synchronize
> > an incoming signal.
> > thank you
> > Marc
>
> Yes, use 2 Flip Flop, thats is correct.
>
> but
>
> do you really want these Flip Flop be trigerred by both edge of the clocks ?- Hide quoted text -
>
> - Show quoted text -

The process the OP presented has another problem, IMHO. It doesn't
take reset into account. I don't think it's a portable way to code
such a process for synchronization. It is better to have some known
reset value:

process (clk, reset_n)
begin
if (reset_n = '0') then
sync_sig_1 <= '0'; -- or '1' if that is the reset value of sig
sync_sig_2 <= '0';
elsif (rising_edge(clk)) then
sync_sig_1 <= sig;
sync_sig_2 <= sync_sig_1;
end if;
end if;

sync_sig_2 is a synchronized (double FF) sig.

Eli Bendersky

Eli Bendersky wrote:

> On Jun 11, 7:56 pm, "ast" <a...@ast.com> wrote:
>> "TheThunder" <marcal...@gmx.de> a écrit dans le message de news:
>> 1181584299.313031.41...@w5g2000hsg.googlegroups.co m...
>>
>>
>>
>>
>>
>> > Hello @ all,
>>
>> > i have a small problem with synchronizing an incoming singal to the
>> > Clock of my VIRTEX4.
>> > At the moment i use this code to synchronize the incoming asynchronous
>> > signal Pulse:
>>
>> > Sync_Pulse : process ( Internal_Clock )
>> > begin
>>
>> > temp_pulse <= Pulse;
>> > sync_pulse <= temp_pulse;
>>
>> > end process;
>>
>> > My question is if there is a more elegant or easier way to synchronize
>> > an incoming signal.
>> > thank you
>> > Marc
>>
>> Yes, use 2 Flip Flop, thats is correct.
>>
>> but
>>
>> do you really want these Flip Flop be trigerred by both edge of the
>> clocks ?- Hide quoted text -
>>
>> - Show quoted text -
>
> The process the OP presented has another problem, IMHO. It doesn't
> take reset into account. I don't think it's a portable way to code
> such a process for synchronization. It is better to have some known
> reset value:
>
> process (clk, reset_n)
> begin
> if (reset_n = '0') then
> sync_sig_1 <= '0'; -- or '1' if that is the reset value of sig
> sync_sig_2 <= '0';
> elsif (rising_edge(clk)) then
> sync_sig_1 <= sig;
> sync_sig_2 <= sync_sig_1;
> end if;
> end if;
>
> sync_sig_2 is a synchronized (double FF) sig.

I would advice against a reset signal in input synchronization blocks. You
are trying to generate in internal signal (sync_sig_2) which follows an
external asynchronous signal (sig) and filters out most of the
metastability and other asynchronous race conditions. Adding a reset signal
will only delay the input synchronization time during reset without any
added advantage.

Beside adding complexity for no reason, an asynchronous reset will make
sync_sig_2 asynchronous. Ken Chapman published a very interesting article
about reset strategies in FPGA designs called "Get Smart About Reset (Think
Local, Not Global)". You can find it on Xilinx's website at
http://www.xilinx.com/xlnx/xweb/xil_...kc_smart_reset

Best regards,

Laurent Pinchart

Laurent Pinchart