Synchronize incoming singal to clock

[TheThunder]

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

 

[ast]

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 ?

 

[Dave Pollum]

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

 

[TheThunder]

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!

 

[Mike Treseler]

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]

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 :

 

[David R Brooks]

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.

 

[ast]

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.

 

[Eli Bendersky]

"TheThunder" <[email protected]> a écrit dans le message de (e-mail address removed)...











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.

 

[Laurent Pinchart]

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...geID=1&multPartNum=1&sTechX_ID=kc_smart_reset

Best regards,

Laurent Pinchart

 

[Mike Treseler]

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.

The powerup reset value of a synchronizer is irrelevant.
No useful synchronization can occur until reset
is over and the input value is shifted in.

However, if a global buffer for reset is already in use,
I would hook up the synchronizer flops to simplify simulation.
For an fpga this doesn't cost anything as the flop
asynch reset input already exists.

-- Mike Treseler

 

[Eli Bendersky]

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.

On the contrary, I fail to see any clear disadvantage to this method.
Delaying the synchronized signal by further two clocks after a reset
which is typically very long (usually these resets come either from a
uC or a voltage supervisor chip, and in both cases are long) doesn't
really matter much.

However, I see two advantages:

1) Reset can be a sign that there is trouble, especially with the
voltage supply. A good voltage supervisor chip will drive the reset_n
low if it detects a brownout. If my synchronized signal drives some
critical output, I want to know it's in a safe ground state when there
is a reset.

2) Reset into every FF makes simulation easier without any 'X'es

And correct me if I'm wrong, but in FPGAs these resets are free, all
FFs have 'clear' inputs with routing of global fast signals. And based
on the link you have provided (below), I understand that FPGAs are
your intereset as well.

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 athttp://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&mult...

This is an interesting article but it addresses a completely different
matter, one that springed up in this group a few times. It is
generally agreed that it's a good practice to make the reset_n release
synchronous.

Kind regards
Eli

 

[yves.770905]

On the contrary, I fail to see any clear disadvantage to this method.
Delaying the synchronized signal by further two clocks after a reset
which is typically very long (usually these resets come either from a
uC or a voltage supervisor chip, and in both cases are long) doesn't
really matter much.

However, I see two advantages:

1) Reset can be a sign that there is trouble, especially with the
voltage supply. A good voltage supervisor chip will drive the reset_n
low if it detects a brownout. If my synchronized signal drives some
critical output, I want to know it's in a safe ground state when there
is a reset.

2) Reset into every FF makes simulation easier without any 'X'es

And correct me if I'm wrong, but in FPGAs these resets are free, all
FFs have 'clear' inputs with routing of global fast signals. And based
on the link you have provided (below), I understand that FPGAs are
your intereset as well.


This is an interesting article but it addresses a completely different
matter, one that springed up in this group a few times. It is
generally agreed that it's a good practice to make the reset_n release
synchronous.

Kind regards
Eli

I am very much in favor of resetting every flipflop in my design.
Thing is that you do not always get it for free inside an FPGA.
For Xilinx FPGAs e.g. a series of flipflops van be implemented in a
shift register primitive (SRL16) of the FPGA if these flipflops are
not reset at all. If you want to reset these flipflops you end up not
having an SRL16 instantiated but as many flipflops as you put in the
chain, which is allocating a lot more slices for the same thing. And
probably results in a reduction of maximum frequency as well.

Kind regards,

Yves

 

[Laurent Pinchart]

On the contrary, I fail to see any clear disadvantage to this method.
Delaying the synchronized signal by further two clocks after a reset
which is typically very long (usually these resets come either from a
uC or a voltage supervisor chip, and in both cases are long) doesn't
really matter much.

However, I see two advantages:

1) Reset can be a sign that there is trouble, especially with the
voltage supply. A good voltage supervisor chip will drive the reset_n
low if it detects a brownout. If my synchronized signal drives some
critical output, I want to know it's in a safe ground state when there
is a reset.

2) Reset into every FF makes simulation easier without any 'X'es

And correct me if I'm wrong, but in FPGAs these resets are free, all
FFs have 'clear' inputs with routing of global fast signals. And based
on the link you have provided (below), I understand that FPGAs are
your intereset as well.


This is an interesting article but it addresses a completely different
matter, one that springed up in this group a few times. It is
generally agreed that it's a good practice to make the reset_n release
synchronous.

Adding asynchronous resets to all flip-flops should not be done lightly, and
a global reset strategy should be carefully thought out.

My main point was that reset signals are not needed everywhere. Asynchronous
resets are prone to race conditions during reset release, and making sure
reset nets are released synchronously cost resources. I just wanted to
point this out to the original poster.

Best regards,

Laurent Pinchart