Send a pulse across clocks

Hello, I want to send a pulse from one clock domain to another, knowing tha=
t from the time event that this pulse is generated in the source clock doma=
in it arrives in the first rising edge of the destination clock domain and =
lasts exactly one clock period of the destination clock domain. Now, I know=
 this problem is not generic and is subject to timing constraints and clock=
 frequency/phase relationship. So the question would be, how to implement i=
t best in RTL with Xilinx technology and what time constraints to apply fro=
m source to destination FF. In particular the destination clock is a little=
 over half of the source clock frequency, the phase between them is unknown=
 and may change over time.

Currently my idea is to use the asynchronous preset/clear of the destinatio=
n FF, which would mean that on an specific part (Xilinx Spartan 6 or 7-seri=
es FPGAs) there must be some relation between the clocks that allows the mi=
nimum pulse width and propagation of the asynchronous signal.

Any help is appreaciated.

On Thu, 22 Jan 2015 06:05:23 -0800, Leo wrote:

> Hello, I want to send a pulse from one clock domain to another, knowing
> that from the time event that this pulse is generated in the source
> clock domain it arrives in the first rising edge of the destination
> clock domain and lasts exactly one clock period of the destination clock
> domain.

Huh?  That's not at all clear.

You're saying that the pulse always arrives on "the first rising edge of 
the destination clock domain" -- you mean the first rising edge after 
power up?  Always?  Or do you mean the first rising edge ever?

Then you say the pulse lasts exactly one period of the destination clock 
domain -- how can it do that, when it's being sourced in a different 
domain?

> Now, I know this problem is not generic and is subject to timing
> constraints and clock frequency/phase relationship. So the question
> would be, how to implement it best in RTL with Xilinx technology and
> what time constraints to apply from source to destination FF. In
> particular the destination clock is a little over half of the source
> clock frequency, the phase between them is unknown and may change over
> time.
> 
> Currently my idea is to use the asynchronous preset/clear of the
> destination FF, which would mean that on an specific part (Xilinx
> Spartan 6 or 7-series FPGAs) there must be some relation between the
> clocks that allows the minimum pulse width and propagation of the
> asynchronous signal.

If the pulse _from_ the faster clock domain always lasts two source 
clocks, then you should be able to reliably capture it with a plain old 
register.  However, we get back to your unclear opening paragraph.

Assuming that the pulse is of some shorter width, then yes you need to do 
something different.  I don't know that you necessarily have LUT-by-LUT 
access to the preset (I'd have to spelunk through data sheets, or ask 
here).  If you don't, you may have to build an RS FF, which should be 
possible with just a few lines of code.  If you do that then you'll have 
some hold time requirement which the tools may or may not be able to 
calculate.

> Any help is appreaciated.

If you want what I think you want, it would be helpful to allow a few 
clock cycles of delay in the destination, to allow for synchronization (or 
metastability killing -- whatever).  You haven't said how quickly you need 
to act on this pulse.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Thu, 22 Jan 2015 06:05:23 -0800 (PST)
Leo <capossio.leonardo@gmail.com> wrote:

> Hello, I want to send a pulse from one clock domain to another, knowing that from the time event that this pulse is generated in the source clock domain it arrives in the first rising edge of the destination clock domain and lasts exactly one clock period of the destination clock domain. Now, I know this problem is not generic and is subject to timing constraints and clock frequency/phase relationship. So the question would be, how to implement it best in RTL with Xilinx technology and what time constraints to apply from source to destination FF. In particular the destination clock is a little over half of the source clock frequency, the phase between them is unknown and may change over time.
> 
> Currently my idea is to use the asynchronous preset/clear of the destination FF, which would mean that on an specific part (Xilinx Spartan 6 or 7-series FPGAs) there must be some relation between the clocks that allows the minimum pulse width and propagation of the asynchronous signal.
> 
> Any help is appreaciated.

Pulse-toggle-pulse synchronizer.  My go-to answer for this problem;
there has to be a bizarre and compelling reason for me to do otherwise.

Sending domain has a T-flop; so the pulse causes the output to
transition.  We don't care which way.  The output of the T-flop goes
into one flop, then a second, then a third, on the receiving domain.
First gets rid of metastability.  XOR of the second and the third is
your reconstructed pulse.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

El jueves, 22 de enero de 2015, 14:46:17 (UTC-3), Tim Wescott escribi=F3:
> On Thu, 22 Jan 2015 06:05:23 -0800, Leo wrote:
>=20
> > Hello, I want to send a pulse from one clock domain to another, knowing
> > that from the time event that this pulse is generated in the source
> > clock domain it arrives in the first rising edge of the destination
> > clock domain and lasts exactly one clock period of the destination cloc=
k
> > domain.
>=20
> Huh?  That's not at all clear.
>=20
> You're saying that the pulse always arrives on "the first rising edge of=
=20
> the destination clock domain" -- you mean the first rising edge after=20
> power up?  Always?  Or do you mean the first rising edge ever?
>=20
> Then you say the pulse lasts exactly one period of the destination clock=
=20
> domain -- how can it do that, when it's being sourced in a different=20
> domain?
>=20
> > Now, I know this problem is not generic and is subject to timing
> > constraints and clock frequency/phase relationship. So the question
> > would be, how to implement it best in RTL with Xilinx technology and
> > what time constraints to apply from source to destination FF. In
> > particular the destination clock is a little over half of the source
> > clock frequency, the phase between them is unknown and may change over
> > time.
> >=20
> > Currently my idea is to use the asynchronous preset/clear of the
> > destination FF, which would mean that on an specific part (Xilinx
> > Spartan 6 or 7-series FPGAs) there must be some relation between the
> > clocks that allows the minimum pulse width and propagation of the
> > asynchronous signal.
>=20
> If the pulse _from_ the faster clock domain always lasts two source=20
> clocks, then you should be able to reliably capture it with a plain old=
=20
> register.  However, we get back to your unclear opening paragraph.
>=20
> Assuming that the pulse is of some shorter width, then yes you need to do=
=20
> something different.  I don't know that you necessarily have LUT-by-LUT=
=20
> access to the preset (I'd have to spelunk through data sheets, or ask=20
> here).  If you don't, you may have to build an RS FF, which should be=20
> possible with just a few lines of code.  If you do that then you'll have=
=20
> some hold time requirement which the tools may or may not be able to=20
> calculate.
>=20
> > Any help is appreaciated.
>=20
> If you want what I think you want, it would be helpful to allow a few=20
> clock cycles of delay in the destination, to allow for synchronization (o=
r=20
> metastability killing -- whatever).  You haven't said how quickly you nee=
d=20
> to act on this pulse.
>=20
> --=20
>=20
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com

You are right, after re-reading, it isn't clear. I want the pulse generated=
 on the rising edge of the source clk to be transported to the destination =
clk domain in the first rising edge of the destination clk after the pulse =
was generated. In other words I want the destination clock to catch the pul=
se as fast as possible, and I also need the pulse to last a single clock cy=
cle of the destination clk (I plan to shift it down a shift reg to delay it=
).

I can leave with latency as long as this latency is always the same in dest=
ination clk cycles.

I need it because from the time that this pulse is generated in the source =
clk, I need to count exactly 14 clk cycles of the destination clk to catch =
correct data going down a pipeline on the destination clk.

El jueves, 22 de enero de 2015, 14:50:13 (UTC-3), Rob Gaddi escribi=F3:
> On Thu, 22 Jan 2015 06:05:23 -0800 (PST)
> Leo wrote:
>=20
> > Hello, I want to send a pulse from one clock domain to another, knowing=
 that from the time event that this pulse is generated in the source clock =
domain it arrives in the first rising edge of the destination clock domain =
and lasts exactly one clock period of the destination clock domain. Now, I =
know this problem is not generic and is subject to timing constraints and c=
lock frequency/phase relationship. So the question would be, how to impleme=
nt it best in RTL with Xilinx technology and what time constraints to apply=
 from source to destination FF. In particular the destination clock is a li=
ttle over half of the source clock frequency, the phase between them is unk=
nown and may change over time.
> >=20
> > Currently my idea is to use the asynchronous preset/clear of the destin=
ation FF, which would mean that on an specific part (Xilinx Spartan 6 or 7-=
series FPGAs) there must be some relation between the clocks that allows th=
e minimum pulse width and propagation of the asynchronous signal.
> >=20
> > Any help is appreaciated.
>=20
> Pulse-toggle-pulse synchronizer.  My go-to answer for this problem;
> there has to be a bizarre and compelling reason for me to do otherwise.
>=20
> Sending domain has a T-flop; so the pulse causes the output to
> transition.  We don't care which way.  The output of the T-flop goes
> into one flop, then a second, then a third, on the receiving domain.
> First gets rid of metastability.  XOR of the second and the third is
> your reconstructed pulse.
>=20
> --=20
> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> Email address domain is currently out of order.  See above to fix.

That is a good answer thank you. The only question I have is: does the XOR =
output always have the same delay in destionation clk cycles (3 cycles), or=
 there might be a case where it takes more or less ?

On Thu, 22 Jan 2015 10:21:34 -0800 (PST)
Leo <capossio.leonardo@gmail.com> wrote:

> El jueves, 22 de enero de 2015, 14:50:13 (UTC-3), Rob Gaddi escribi=C3=B3:
> > On Thu, 22 Jan 2015 06:05:23 -0800 (PST)
> > Leo wrote:
> >=20
> > > Hello, I want to send a pulse from one clock domain to another, knowi=
ng that from the time event that this pulse is generated in the source cloc=
k domain it arrives in the first rising edge of the destination clock domai=
n and lasts exactly one clock period of the destination clock domain. Now, =
I know this problem is not generic and is subject to timing constraints and=
 clock frequency/phase relationship. So the question would be, how to imple=
ment it best in RTL with Xilinx technology and what time constraints to app=
ly from source to destination FF. In particular the destination clock is a =
little over half of the source clock frequency, the phase between them is u=
nknown and may change over time.
> > >=20
> > > Currently my idea is to use the asynchronous preset/clear of the dest=
ination FF, which would mean that on an specific part (Xilinx Spartan 6 or =
7-series FPGAs) there must be some relation between the clocks that allows =
the minimum pulse width and propagation of the asynchronous signal.
> > >=20
> > > Any help is appreaciated.
> >=20
> > Pulse-toggle-pulse synchronizer.  My go-to answer for this problem;
> > there has to be a bizarre and compelling reason for me to do otherwise.
> >=20
> > Sending domain has a T-flop; so the pulse causes the output to
> > transition.  We don't care which way.  The output of the T-flop goes
> > into one flop, then a second, then a third, on the receiving domain.
> > First gets rid of metastability.  XOR of the second and the third is
> > your reconstructed pulse.
> >=20
> > --=20
> > Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> > Email address domain is currently out of order.  See above to fix.
>=20
> That is a good answer thank you. The only question I have is: does the XO=
R output always have the same delay in destionation clk cycles (3 cycles), =
or there might be a case where it takes more or less ?

In rereading, it's not quite what you asked for, with a minimum latency
solution, nor what you later asked for with a deterministic latency
solution.

The problem is, with truly asynchronous clocks, shortening latency
increases risk, and deterministic latency is impossible.  Think about
a scope, triggering on your source clock edge.  The relative location
of your destination clock edge is uniformly distributed everywhere on
the screen, up to and including mere picoseconds either way from the
source edge.

That means that when you hit the first flop on the destination domain
(and that needs to be ONE flop, never ever ever two with an expectation
they'll behave the same) you have a guarantee that sometimes you'll
violate the setup timing of that flop.  When you do that, it goes
metastable -- the internal nodes hit a linear state that is neither 1
or zero, and stay there until the positive feedback pushes them to one
rail or the other, an amount of time that is probabilistic rather than
deterministic.  Whether it'll settle to the old or new value is
anyone's guess.

But the moral of the story is: accept that there's 1 clock of
variability in that latency and design your system to live with it.  If
you can't, then you can't have an async clock crossing there.

--=20
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

On Thu, 22 Jan 2015 10:21:34 -0800, Leo wrote:

> El jueves, 22 de enero de 2015, 14:50:13 (UTC-3), Rob Gaddi escribió:
>> On Thu, 22 Jan 2015 06:05:23 -0800 (PST)
>> Leo wrote:
>> 
>> > Hello, I want to send a pulse from one clock domain to another,
>> > knowing that from the time event that this pulse is generated in the
>> > source clock domain it arrives in the first rising edge of the
>> > destination clock domain and lasts exactly one clock period of the
>> > destination clock domain. Now, I know this problem is not generic and
>> > is subject to timing constraints and clock frequency/phase
>> > relationship. So the question would be, how to implement it best in
>> > RTL with Xilinx technology and what time constraints to apply from
>> > source to destination FF. In particular the destination clock is a
>> > little over half of the source clock frequency, the phase between
>> > them is unknown and may change over time.
>> > 
>> > Currently my idea is to use the asynchronous preset/clear of the
>> > destination FF, which would mean that on an specific part (Xilinx
>> > Spartan 6 or 7-series FPGAs) there must be some relation between the
>> > clocks that allows the minimum pulse width and propagation of the
>> > asynchronous signal.
>> > 
>> > Any help is appreaciated.
>> 
>> Pulse-toggle-pulse synchronizer.  My go-to answer for this problem;
>> there has to be a bizarre and compelling reason for me to do otherwise.
>> 
>> Sending domain has a T-flop; so the pulse causes the output to
>> transition.  We don't care which way.  The output of the T-flop goes
>> into one flop, then a second, then a third, on the receiving domain.
>> First gets rid of metastability.  XOR of the second and the third is
>> your reconstructed pulse.
> 
> That is a good answer thank you. The only question I have is: does the
> XOR output always have the same delay in destionation clk cycles (3
> cycles), or there might be a case where it takes more or less ?

When the source and destination clock edges are close to happening at the 
same time there will be an uncertainty of which destination clock catches 
the transition on the T-flop -- but that uncertainty will be with you 
always anyway.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Rob Gaddi wrote:

[snip]

> 
> That means that when you hit the first flop on the destination domain
> (and that needs to be ONE flop, never ever ever two with an expectation
> they'll behave the same) you have a guarantee that sometimes you'll
> violate the setup timing of that flop.  When you do that, it goes
> metastable -- the internal nodes hit a linear state that is neither 1
> or zero, and stay there until the positive feedback pushes them to one
> rail or the other, an amount of time that is probabilistic rather than
> deterministic.  Whether it'll settle to the old or new value is
> anyone's guess.
> 

This is a bit over-pessimistic.  The setup and hold time of a flop are
spec'd over PVT.  The metastability window is much much smaller than
the window specified by the setup and hold times.  What you do get
between the setup and hold time is a window when you can't know
for sure over all temperature, voltage, and process whether the
change in the input will propagate to the output on that clock
cycle, or whether it will not go through until the next cycle.

> But the moral of the story is: accept that there's 1 clock of
> variability in that latency and design your system to live with it.  If
> you can't, then you can't have an async clock crossing there.
> 

Again if you want to be pessimistic, you could add the setup/hold
time violation window to the destination clock period and call
that the variation in latency you will see.  However this ignores
the fact that the device will be operating at the same PVT
point on one cycle that it is on the next cycle.

Anyway the toggle business is a very good idea since it means you
don't need to deal with asynchronous set/reset in the destination
clock domain to stretch a short pulse.

-- 
Gabor

On Thu, 22 Jan 2015 14:05:05 -0500
GaborSzakacs <gabor@alacron.com> wrote:

> Rob Gaddi wrote:
> 
> [snip]
> 
> > 
> > That means that when you hit the first flop on the destination domain
> > (and that needs to be ONE flop, never ever ever two with an expectation
> > they'll behave the same) you have a guarantee that sometimes you'll
> > violate the setup timing of that flop.  When you do that, it goes
> > metastable -- the internal nodes hit a linear state that is neither 1
> > or zero, and stay there until the positive feedback pushes them to one
> > rail or the other, an amount of time that is probabilistic rather than
> > deterministic.  Whether it'll settle to the old or new value is
> > anyone's guess.
> > 
> 
> This is a bit over-pessimistic.  The setup and hold time of a flop are
> spec'd over PVT.  The metastability window is much much smaller than
> the window specified by the setup and hold times.  What you do get
> between the setup and hold time is a window when you can't know
> for sure over all temperature, voltage, and process whether the
> change in the input will propagate to the output on that clock
> cycle, or whether it will not go through until the next cycle.
> 

Right, but with an async clock crossing you are GUARANTEED to
occasionally end up inside of that admittedly small window.
Likewise, when you do, the probability function of how long resolution
will take has (if I recall correctly) an exponential PDF.  On modern
FPGAs, the resolution function becomes more likely to be resolved than
not in something absurd like 100 ps, making the chances that it's not
done resolving in the span of a reasonable clock period something on the
order of being hit by a bus that is being hit by lightning. 

But you still don't know whether you're going to get a 0 or a 1.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

On Thursday, January 22, 2015 at 1:21:37 PM UTC-5, Leo wrote:

> That is a good answer thank you. The only question I have is: does the XO=
R output always have the same delay in destionation clk cycles (3 cycles), =
or there might be a case where it takes more or less ?

Since the clock phases are unknown and (presumably) different and shifting =
relative to each other, then it could be longer.  The most likely answer is=
 that it would occasionally take one extra clock.  If you consider metastab=
ility, then there could be likely yet another extra clock or an exponential=
ly decreasing probability of even more.  There is no way to guarantee that =
the very next destination clock edge will be the one that grabs the pulse s=
ince you haven't designed in a way to guarantee that you won't violate setu=
p/hold time requirements.

So the delay in clock cycles will look something like this:
3 : Happens when setup/hold time is not violated
4 : May happen when setup/hold time is violated but no metastability
5 or more : Will happen when setup/hold time is violated and metastability =
occurs

Kevin Jennings