cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mrflibble
Observer
Observer
9,038 Views
Registered: ‎03-17-2011

Clock domain crossing from clock to divided clock

Jump to solution

I have some data within a 390 MHz clock domain, that I need to get to a slower 195 MHz clock domain.

 

The 390 MHz and 195 MHz clock are both derived from the same 100 MHz source.The 100 Mhz goes to a PLL in the spartan-6. The VCO output frequency is 780MHz, and is then divided by 2 and 4 respectively to give 390 and 195 MHz clocks. Both are set to 0 degrees phase, and related to source clock.

 

The data is a continous stream, so to prevent congestion the lower speed datapath has to be doubled in width. So I do something like this:

 

reg [3:0] taps      = 0;     // data source fipflops, continuous stream @ 390 MHz
reg [3:0] taps_even = 0;     // ce_even
reg [3:0] taps_odd  = 0;     // ce_odd
reg [3:0] taps_390_even = 0; // ce_even
reg [3:0] taps_390_odd  = 0; // ce_even


// continuous data stream at fast clock
always @(posedge clk_390_0) begin
    taps <= some_data;
end


// Even CE
always @(posedge clk_390_0) begin
    if (ce_even) begin
        taps_even     <= taps;
        taps_390_even <= taps_even;
        taps_390_odd  <= taps_odd;
         end
end

// Odd CE
always @(posedge clk_390_0) begin
    if (ce_odd) begin
        taps_odd <= taps;
    end
end

 

 

Now taps_390_even and taps_390_odd are multi-cycle path registers. They change every 2nd cycle of the 390 Mhz clock, and this just happens to coincide with the posedge of the slower 195 MHz clock. Now the idea was to do the clockdomain crossing as simple as this:

 

// cross from clk_390 to clk_195 domain
always @(posedge clk_195_0) begin
    taps_195_even <= taps_390_even;
    taps_195_odd  <= taps_390_odd;
end

 


So ... is this the correct way of doing this, or is there a better way? Note that according to the fifo generator datasheet, the max frequency for any flavor fifo (fabric FFs, BRAM) in a spartan-6 is lower than 390 Mhz...

 

And if this method is correct, I am not 100% sure about what to put in the constraints file. I use a PLL from core generator, and specified the INPUT clock. So if I understand correctly that way I automatically get the correct constraints for the clk_390 and clk_195 signals. Which means I will just have to provide the multi-cycle path related stuff... I'd guess it will be something clever with FROM, TO and the flipflops and/or the clock enables, but not sure how exactly.

 

Would appreciate any help. Thanks!

0 Kudos
1 Solution

Accepted Solutions
ywu
Xilinx Employee
Xilinx Employee
11,038 Views
Registered: ‎11-28-2007

Yes, if you don't add multi-cycle path constraints, the paths from 390MHz to 195MHz will be timed at 390MHz. Based on your code snippet, yes, multi-cycle constraints can be added for registers using ce_even and ce_odd as clock enables.


@mrflibble wrote:

Thanks for your reply Jim.

 

Good to know that it's valid. Don't I need some extra constraints? After all the actual values of ce_even and ce_odd will determine how many cycles these multi-cycle paths will be.

 

Or maybe when I do not specify them, the tools will just assume the default which I'd guess would be a 390 MHz clock period for ALL flipflops concerned. Which probably would work as well, but that would place unnecessarily tight constraints on the last 2 FFs  in the chain. Unless I am missing something...

 

The ce_even and ce_odd are the clock enables for even and odd cycles. They are generated a different way, but essentially they look like this:

 

 

// rough equivalent, purely for example
reg ce_even = 1;
reg ce_odd = 0;

always @(posedge clk_390_0) begin
    reg ce_even <= ~reg ce_even;
    reg ce_odd <= ~reg ce_odd;
end

 

 

 

 




Cheers,
Jim

View solution in original post

8 Replies
eteam00
Professor
Professor
9,037 Views
Registered: ‎07-21-2009

Have you considered

  • generating only the 195MHz clock
  • use IDDR2 clocked at 195MHz to de-mux some_data input stream
  • run everything at 2x data-width @ 195MHz

 

This might be considerably simpler than the dual scheme you describe, and 390MHz (fabric clock) is quite aggressive for Spartan-6 designs.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
mrflibble
Observer
Observer
9,029 Views
Registered: ‎03-17-2011

Hi Bob, thanks for your reply! :)

 

Unfortunately the very nature of the design is such that the data gets generated at a high clock rate, and no way to get rid of that characteristic. Well, there is ... not doing the design, but you get the idea.

 

The data does not pass an IDDR2 so no luck there. Besides, it's a little more that the 4 bits in the above example. It is 192 bits in the real design, and then several of those units in parallel. So IDDR2 resources are no option.

 

So your questions are valid, only in this particular case I am really stuck with the data being generated at a high clock. Consider that a given, and then I'd like to get it to a lower speed as soon as feasible.

 

The idea is to get it to the 195 MHz clock domain, and from there on I can use a regular BRAM based fifo for the rest of business.

0 Kudos
eteam00
Professor
Professor
9,026 Views
Registered: ‎07-21-2009

I don't understand.  How can you sample your data with a 390MHz SDR clock, but not with both edges of a 195MHz DDR clock in an IDDR block?

 

The data does not pass an IDDR2 so no luck there. ... It is 192 bits in the real design, and then several of those units in parallel. So IDDR2 resources are no option.

 

Please explain.  I'm wondering what the problem might be.

 

Even with -3 speed grade, max fabric clock distribution frequency is 400MHz.  390MHz is much closer to 400MHz than 195MHz (duh!).

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
mrflibble
Observer
Observer
9,022 Views
Registered: ‎03-17-2011

It's a TDC in fpga fabric, as in a tapped delay line. So external signal comes in, goes straight up a long carry chain, and all the taps along this carry chain are sampled at a 390 MHz clock frequency.

 

So if I were to use a clock frequency of 195 MHz to sample carry chain taps, then a pulse has more time to travel dwn the carry chain between 2 sampling clock posedges. Which means you will need a longer carry chain to be able to fit the twice as long clock period. I currently use TDC's that are 192-bits long (so that is 48 CARRY4 elements). To fit the period of the 390 MHz clock about 176 bits are used at room temperature.

 

Due to the property of the carry logic cells, the longer the chain, the higher the measurement uncertainty at the far end of the TDC. Not only in theory, but I also did a boatload of measurements that support this. Hence: shorter TDC is better. Hence: higher sampling frequency is better. A 350 MHz ballpark sampling frequency might still be acceptable as a lower bound, however 195 Mhz is not.

 

And then you might get clever and just export the carry chain output to outside the slice as well, and sample it both at the posedge AND and the negedge of a 195 MHz clock. Well, yeah, but 1) see remark about shorter TDC == better. And 2) if this approach was without any problems I would already be doing it but then with the 390 MHz clock and then at both posedge and negedge.

 

This thing is already working in real hardware and giving good results (i.e, good timing resolution). But the processing as it is now is do a short burst capture into a whole lot of, and then sloooowly read those out. Works just fine for testing, but in the final design it should be able to keep capturing in fairly long bursts and therefore needs to be able to stream out the data to a deep fifo.

 

Hope that clarifies somewhat where the hell the data is coming from. ;)

 

0 Kudos
ywu
Xilinx Employee
Xilinx Employee
8,996 Views
Registered: ‎11-28-2007

Since the 390MHz and 195MHz clocks come from the same clock source, they are related clocks and the paths between the two clocks will be properly timed by the tools. What you have below will work fine as long as the maximum clock frequency on the global clock tree is bigger than 390MHz.

 


@mrflibble wrote:

I have some data within a 390 MHz clock domain, that I need to get to a slower 195 MHz clock domain.

 

The 390 MHz and 195 MHz clock are both derived from the same 100 MHz source.The 100 Mhz goes to a PLL in the spartan-6. The VCO output frequency is 780MHz, and is then divided by 2 and 4 respectively to give 390 and 195 MHz clocks. Both are set to 0 degrees phase, and related to source clock.

 

The data is a continous stream, so to prevent congestion the lower speed datapath has to be doubled in width. So I do something like this:

 

reg [3:0] taps      = 0;     // data source fipflops, continuous stream @ 390 MHz
reg [3:0] taps_even = 0;     // ce_even
reg [3:0] taps_odd  = 0;     // ce_odd
reg [3:0] taps_390_even = 0; // ce_even
reg [3:0] taps_390_odd  = 0; // ce_even


// continuous data stream at fast clock
always @(posedge clk_390_0) begin
    taps <= some_data;
end


// Even CE
always @(posedge clk_390_0) begin
    if (ce_even) begin
        taps_even     <= taps;
        taps_390_even <= taps_even;
        taps_390_odd  <= taps_odd;
         end
end

// Odd CE
always @(posedge clk_390_0) begin
    if (ce_odd) begin
        taps_odd <= taps;
    end
end

 

 

Now taps_390_even and taps_390_odd are multi-cycle path registers. They change every 2nd cycle of the 390 Mhz clock, and this just happens to coincide with the posedge of the slower 195 MHz clock. Now the idea was to do the clockdomain crossing as simple as this:

 

// cross from clk_390 to clk_195 domain
always @(posedge clk_195_0) begin
    taps_195_even <= taps_390_even;
    taps_195_odd  <= taps_390_odd;
end

 


So ... is this the correct way of doing this, or is there a better way? Note that according to the fifo generator datasheet, the max frequency for any flavor fifo (fabric FFs, BRAM) in a spartan-6 is lower than 390 Mhz...

 

And if this method is correct, I am not 100% sure about what to put in the constraints file. I use a PLL from core generator, and specified the INPUT clock. So if I understand correctly that way I automatically get the correct constraints for the clk_390 and clk_195 signals. Which means I will just have to provide the multi-cycle path related stuff... I'd guess it will be something clever with FROM, TO and the flipflops and/or the clock enables, but not sure how exactly.

 

Would appreciate any help. Thanks!




Cheers,
Jim
0 Kudos
mrflibble
Observer
Observer
8,988 Views
Registered: ‎03-17-2011

Thanks for your reply Jim.

 

Good to know that it's valid. Don't I need some extra constraints? After all the actual values of ce_even and ce_odd will determine how many cycles these multi-cycle paths will be.

 

Or maybe when I do not specify them, the tools will just assume the default which I'd guess would be a 390 MHz clock period for ALL flipflops concerned. Which probably would work as well, but that would place unnecessarily tight constraints on the last 2 FFs  in the chain. Unless I am missing something...

 

The ce_even and ce_odd are the clock enables for even and odd cycles. They are generated a different way, but essentially they look like this:

 

 

// rough equivalent, purely for example
reg ce_even = 1;
reg ce_odd = 0;

always @(posedge clk_390_0) begin
    reg ce_even <= ~reg ce_even;
    reg ce_odd <= ~reg ce_odd;
end

 

 

 

 

0 Kudos
ywu
Xilinx Employee
Xilinx Employee
11,039 Views
Registered: ‎11-28-2007

Yes, if you don't add multi-cycle path constraints, the paths from 390MHz to 195MHz will be timed at 390MHz. Based on your code snippet, yes, multi-cycle constraints can be added for registers using ce_even and ce_odd as clock enables.


@mrflibble wrote:

Thanks for your reply Jim.

 

Good to know that it's valid. Don't I need some extra constraints? After all the actual values of ce_even and ce_odd will determine how many cycles these multi-cycle paths will be.

 

Or maybe when I do not specify them, the tools will just assume the default which I'd guess would be a 390 MHz clock period for ALL flipflops concerned. Which probably would work as well, but that would place unnecessarily tight constraints on the last 2 FFs  in the chain. Unless I am missing something...

 

The ce_even and ce_odd are the clock enables for even and odd cycles. They are generated a different way, but essentially they look like this:

 

 

// rough equivalent, purely for example
reg ce_even = 1;
reg ce_odd = 0;

always @(posedge clk_390_0) begin
    reg ce_even <= ~reg ce_even;
    reg ce_odd <= ~reg ce_odd;
end

 

 

 

 




Cheers,
Jim

View solution in original post

mrflibble
Observer
Observer
8,958 Views
Registered: ‎03-17-2011

Thanks for the confirmation. :)

 

In the meantime I got things working. And it's precisely as you say. All the paths from the 390 MHz to the 195 MHz domain are treated as 390 MHz so to speak.

 

This article cleared things up for me as well: http://www.eetimes.com/General/DisplayPrintViewContent?contentItemId=4018520

 

thanks!

 

 

0 Kudos