How to transfer multiple bit data between phase shifted cloc

[kapatel]

Hi All,

I am designing a memory controller and I am using two clocks clk an
clk_90. Phase difference between clk and clk_90 is 90 degree. I want t
transfer multiple bit data between clk and clk_90. Should I us
asynchronous fifo or two registers (same as two flop synchronization).

Thanks in advance,

Regards,

Krupesh



---------------------------------------
Posted through http://www.FPGARelated.com

 

Different phases of the same clock are not asynchronous. There is a defined timing relationship between clk and clk_90 in your case, right? If the data can propagate between the two phases within that time (less setup), then you can just transfer the date directly between registers clocked by each phase with no problems.

If the time is not long enough, there are other choices:

You have four clock edges total. You can use more than just the initial and destination edges in your transition, and you don't have to do it all at once. Assuming clk_90's rising edge is a quarter period after clk's rising_edge:

You could transfer from rising_edge(clk) to falling_edge(clk_90) in 3/4 period), and then to rising_edge(clk_90) in 1/2 period.

Or you could transfer from rising_edge(clk) to falling_edge(clk) in 1/2 period, and then to rising_edge(clk_90) in 3/4 period. Either of these allows at least a half clock period to propagate the data in each step.

If you cannot make the transition in half a clock period (really fast clock!), you could transition in three steps: From rising_edge(clk) to falling_edge(clk_90), then to falling_edge(clk), and finally to rising_edge(clk_90). Each of these are 3/4 period transfers.

As long as the tool understands the timing relationship between the two related clocks, it will correctly analyze the timing on transfers between them, and report any problems.

Andy

 

[kapatel]

Hi Andy,

Thank you very much for your quick reply.

Frequency of both the clocks are 100Mhz. So data should be stable befor
2.5ns - set up time if data is transferred between clk clock to clk_9
clock directly. I am using Quartus II tool for CDC test which repor
warnings that multiple data bits are transferred asynchronously. I think i
can be ignored.
If its not working then I can try other alternatives as you suggested.

Thanking you,

Krupesh

Different phases of the same clock are not asynchronous. There is
defined=
timing relationship between clk and clk_90 in your case, right? If th
dat=
a can propagate between the two phases within that time (less setup), the
=
you can just transfer the date directly between registers clocked by eac
p=
hase with no problems.

If the time is not long enough, there are other choices:

You have four clock edges total. You can use more than just the initia
and=
destination edges in your transition, and you don't have to do it all a
o=
nce. Assuming clk_90's rising edge is a quarter period after clk'
rising_e=
dge:

You could transfer from rising_edge(clk) to falling_edge(clk_90) in 3/
per=
iod), and then to rising_edge(clk_90) in 1/2 period.=20

Or you could transfer from rising_edge(clk) to falling_edge(clk) in 1/
per=
iod, and then to rising_edge(clk_90) in 3/4 period. Either of these allow
=
at least a half clock period to propagate the data in each step.=20

If you cannot make the transition in half a clock period (really fas
clock=
!), you could transition in three steps: From rising_edge(clk) t
falling_e=
dge(clk_90), then to falling_edge(clk), and finally t
rising_edge(clk_90).=
Each of these are 3/4 period transfers.=20

As long as the tool understands the timing relationship between the tw
rel=
ated clocks, it will correctly analyze the timing on transfers betwee
them=
, and report any problems.

Andy

---------------------------------------
Posted through http://www.FPGARelated.com

 

[kapatel]

Hi Andy,

I can successfully transfer data between clk and clk_90 clock withou
getting any timing violation or CDC warnings.

Thanking you,

Krupesh.

Hi Andy,

Thank you very much for your quick reply.

Frequency of both the clocks are 100Mhz. So data should be stable before
2.5ns - set up time if data is transferred between clk clock to clk_90
clock directly. I am using Quartus II tool for CDC test which report
warnings that multiple data bits are transferred asynchronously. I thin
it
can be ignored.
If its not working then I can try other alternatives as you suggested.

Thanking you,

Krupesh


Different phases of the same clock are not asynchronous. There is a
defined=
timing relationship between clk and clk_90 in your case, right? If the
dat=
a can propagate between the two phases within that time (less setup)
then
=
you can just transfer the date directly between registers clocked b
each
p=
hase with no problems.

If the time is not long enough, there are other choices:

You have four clock edges total. You can use more than just the initial
and=
destination edges in your transition, and you don't have to do it al
at
o=
nce. Assuming clk_90's rising edge is a quarter period after clk's
rising_e=
dge:

You could transfer from rising_edge(clk) to falling_edge(clk_90) in 3/4
per=
iod), and then to rising_edge(clk_90) in 1/2 period.=20

Or you could transfer from rising_edge(clk) to falling_edge(clk) in 1/2
per=
iod, and then to rising_edge(clk_90) in 3/4 period. Either of thes
allows
=
at least a half clock period to propagate the data in each step.=20

If you cannot make the transition in half a clock period (really fast
clock=
!), you could transition in three steps: From rising_edge(clk) to
falling_e=
dge(clk_90), then to falling_edge(clk), and finally to
rising_edge(clk_90).=
Each of these are 3/4 period transfers.=20

As long as the tool understands the timing relationship between the two
rel=
ated clocks, it will correctly analyze the timing on transfers between
them=
, and report any problems.

Andy


---------------------------------------
Posted through http://www.FPGARelated.com

---------------------------------------
Posted through http://www.FPGARelated.com

 

[kapatel]

Hi Andy,

I can successfully transfer data between clk and clk_90 clock withou
getting any timing violation or CDC warnings.

Thanking you,

Krupesh.

Hi Andy,

Thank you very much for your quick reply.

Frequency of both the clocks are 100Mhz. So data should be stable before
2.5ns - set up time if data is transferred between clk clock to clk_90
clock directly. I am using Quartus II tool for CDC test which report
warnings that multiple data bits are transferred asynchronously. I thin
it
can be ignored.
If its not working then I can try other alternatives as you suggested.

Thanking you,

Krupesh


Different phases of the same clock are not asynchronous. There is a
defined=
timing relationship between clk and clk_90 in your case, right? If the
dat=
a can propagate between the two phases within that time (less setup)
then
=
you can just transfer the date directly between registers clocked b
each
p=
hase with no problems.

If the time is not long enough, there are other choices:

You have four clock edges total. You can use more than just the initial
and=
destination edges in your transition, and you don't have to do it al
at
o=
nce. Assuming clk_90's rising edge is a quarter period after clk's
rising_e=
dge:

You could transfer from rising_edge(clk) to falling_edge(clk_90) in 3/4
per=
iod), and then to rising_edge(clk_90) in 1/2 period.=20

Or you could transfer from rising_edge(clk) to falling_edge(clk) in 1/2
per=
iod, and then to rising_edge(clk_90) in 3/4 period. Either of thes
allows
=
at least a half clock period to propagate the data in each step.=20

If you cannot make the transition in half a clock period (really fast
clock=
!), you could transition in three steps: From rising_edge(clk) to
falling_e=
dge(clk_90), then to falling_edge(clk), and finally to
rising_edge(clk_90).=
Each of these are 3/4 period transfers.=20

As long as the tool understands the timing relationship between the two
rel=
ated clocks, it will correctly analyze the timing on transfers between
them=
, and report any problems.

Andy


---------------------------------------
Posted through http://www.FPGARelated.com

---------------------------------------
Posted through http://www.FPGARelated.com