Multi-Clock Designs.

K

Kiran

Guest
Hi All,

I would like to start a discussion on multi-clock designs.
When a design has multiple unrelated clocks (unrelated in the sense
that the frequencies do not have an integer relationship), the clocks
are considered to be asynchronous. The design is partitioned into
separate clock domains and signals crossing these clock domains are
passed through synchronizers. The synchronizers are used to reduce
the chance of metastability. All these are standard design practices.

Lets take the case where there are two clocks. One is derived from the
other using a clock divider. Therefore the derived clock has half the
frequency of the master clock. Are these clocks still considered to
be asynchronous? Do we still have to use synchronizers on signals
crossing the clock domains even though we know the timing relationship
between these two clocks?

I encountered two sets of opinion.

1. They can be considered to be synchronous. There will be no problem
during clock tree synthesis. Its ok to use clock divider.

2. They still are asynchronous clocks. Design practices for
multi-clock designs still have to applied. Otherwise, clock tree
synthesis will be a problem. Timing closure will be a problem because
gate level timing simulation may not be sufficient, instead SPICE
simulations may have to be done. It is not ok to use clock divider.
Always use PLL to generate the clocks in the design.

Whats your opinion?

Regards,
Kiran.
 
If you design as though it's an asynchronous case, you avoid having to push the tools very hard to achieve timing closure. But you sacrifice efficiency in the
design, since you may be wasting cycles with some sort of synchronization scheme.
I've usually taken the approach of a synchronous design, since for integer division relationships the STA tools can handle this well. It may mean a more
iterative optimization cycle, but I think it's cleaner in terms of timing analysis. Of course, this depends a lot on the size of the trees. I'd favour pushing
the tools first, back off on the design only if you find it's too hard to meet.

Kiran wrote:
Hi All,

I would like to start a discussion on multi-clock designs.
When a design has multiple unrelated clocks (unrelated in the sense
that the frequencies do not have an integer relationship), the clocks
are considered to be asynchronous. The design is partitioned into
separate clock domains and signals crossing these clock domains are
passed through synchronizers. The synchronizers are used to reduce
the chance of metastability. All these are standard design practices.

Lets take the case where there are two clocks. One is derived from the
other using a clock divider. Therefore the derived clock has half the
frequency of the master clock. Are these clocks still considered to
be asynchronous? Do we still have to use synchronizers on signals
crossing the clock domains even though we know the timing relationship
between these two clocks?

I encountered two sets of opinion.

1. They can be considered to be synchronous. There will be no problem
during clock tree synthesis. Its ok to use clock divider.

2. They still are asynchronous clocks. Design practices for
multi-clock designs still have to applied. Otherwise, clock tree
synthesis will be a problem. Timing closure will be a problem because
gate level timing simulation may not be sufficient, instead SPICE
simulations may have to be done. It is not ok to use clock divider.
Always use PLL to generate the clocks in the design.

Whats your opinion?

Regards,
Kiran.
 
On 7 Jan 2004 11:20:01 -0800, kirandev@msn.com (Kiran) wrote:

Lets take the case where there are two clocks. One is derived from the
other using a clock divider. Therefore the derived clock has half the
frequency of the master clock. Are these clocks still considered to
be asynchronous? Do we still have to use synchronizers on signals
crossing the clock domains even though we know the timing relationship
between these two clocks?

I encountered two sets of opinion.

1. They can be considered to be synchronous. There will be no problem
during clock tree synthesis. Its ok to use clock divider.
IMO, this is correct. You can let the CTS balance the two clock trees
by adding buffers to align the edge of the fast clock to the edge of
the slow clock to compensate for the clk->q of the divider. Any good
STA will be able to time all edges for setup/hold constraints between
the two clocks. There is no problem doing this. No spice simulation is
needed.
Of course this doesn't mean a PLL can not be used, it is just not
necessary.

Muzaffer Kal

http://www.dspia.com
ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations
 
In article <9043844f.0401071120.277100ac@posting.google.com>,
Kiran <kirandev@msn.com> wrote:

[ Re: Divided clocks design style: sync or async? ]

If clock A is derived from a faster clock B using a simple divider,
then you can still treat the design as synchronous. Static timing
analysis will be complicated. Consider using faster clock B everywhere,
with appropriate (synchronous) clock enables.

BUT, if the clocks are not related, then they are asynchronous. e.g.
if clock A comes from a 50 MHz crystal and clock B comes from a 100 MHz
crystal, then you need to treat them as completely unrelated. Don't
assume a 2:1 frequency ratio; the crystals will drift over time and
any relationship will be lost.
 
On Wed, 07 Jan 2004 11:20:01 -0800, Kiran wrote:

Hi All,

I would like to start a discussion on multi-clock designs.
When a design has multiple unrelated clocks (unrelated in the sense
that the frequencies do not have an integer relationship), the clocks
are considered to be asynchronous. The design is partitioned into
separate clock domains and signals crossing these clock domains are
passed through synchronizers. The synchronizers are used to reduce
the chance of metastability. All these are standard design practices.

Lets take the case where there are two clocks. One is derived from the
other using a clock divider. Therefore the derived clock has half the
frequency of the master clock. Are these clocks still considered to
be asynchronous? Do we still have to use synchronizers on signals
crossing the clock domains even though we know the timing relationship
between these two clocks?

I encountered two sets of opinion.

1. They can be considered to be synchronous. There will be no problem
during clock tree synthesis. Its ok to use clock divider.

2. They still are asynchronous clocks. Design practices for
multi-clock designs still have to applied. Otherwise, clock tree
synthesis will be a problem. Timing closure will be a problem because
gate level timing simulation may not be sufficient, instead SPICE
simulations may have to be done. It is not ok to use clock divider.
Always use PLL to generate the clocks in the design.

Whats your opinion?

Regards,
Kiran.
The clocks are syncronous but depending on how the clocking system is
implemented there might be a phase shift issue. Assuming the phase shift
is relatively small, compensating for it is trivial, usually just using
the opposite edge of a clock. Truely asyncronous clocks are a different
story. Syncronizers reduce the probability of a metastable state
propagating through your logic but they can't reduce that probablity to 0.
 

Welcome to EDABoard.com

Sponsor

Back
Top