an alternative method to do divided clocks

[Metin Yerlikaya]

Hi,

the other day a colleague came over and suggested the following:

"To reduce design complexity and risk it is necessary to
remove all divided clock systems. There is an alternative method to do
divided
clocks. (Generate clock enable signals) The risk and the efforts for
this change are small. (Important structural change, no functional
change)"

what are the pros and contras of this method? I hear something like
this for the first time. He said also that more than one clock domain
is not good for scan. From my experience: I inserted last year scan
for a chip with
more than 10 clock domains. It was no problem. I'm also sure that with
this
enable signal we will have additional timing trouble, it has to be
buffered
like a clock signal etc.

I just wanted to ask people here if anyone had an experience with this
alternative method and if its worth to change the clocking scheme
(just for scan) ?

Many Thanks

Metin

 

[Charles Bailey]

A divided clock scheme will use less power than a gated clock scheme.

Whether a divided clock scheme makes scan more difficult depends on your
test methodology. (For IBM's LSSD methodology, multiple clock domains
are no problem at all.)

Charles Bailey

 

[m]

On 15 Feb 2005 00:53:38 -0800, metinnn@gmx.de (Metin Yerlikaya) wrote:

Hi,

the other day a colleague came over and suggested the following:

"To reduce design complexity and risk it is necessary to
remove all divided clock systems. There is an alternative method to do
divided
clocks. (Generate clock enable signals) The risk and the efforts for
this change are small. (Important structural change, no functional
change)"

what are the pros and contras of this method? I hear something like
this for the first time. He said also that more than one clock domain
is not good for scan. From my experience: I inserted last year scan
for a chip with
more than 10 clock domains. It was no problem. I'm also sure that with
this
enable signal we will have additional timing trouble, it has to be
buffered
like a clock signal etc.

I just wanted to ask people here if anyone had an experience with this
alternative method and if its worth to change the clocking scheme
(just for scan) ?

Many Thanks

Metin

I can think of several differences with clock enables from divided
clocks:
You need to add "if (enabled)" to all your divided clock logic.
You need to change your timing scripts to add multi-cycle constraints
for the target of the enabled logic.
CTS is a little bit easier as there is no need for extra effort to
compensate for the clk-Q of the dividing flop.
Power of course will be higher as CT is going to consume more and your
"enabled" logic may have slower transitions but this can be
compensated if you use a power optimizing step in your synthesis.
For scan you need to add muxes at the output of the dividing clock but
that's not really a big deal.

Good luck.

 

[J o h n _ E a t o n (at)]

Metin Yerlikaya wrote:

what are the pros and contras of this method? I hear something like
this for the first time. He said also that more than one clock domain
is not good for scan. From my experience: I inserted last year scan
for a chip with
more than 10 clock domains. It was no problem.

DFT will insert test muxing and use one clock domain for scan test.
That not a big problem

I'm also sure that with this
enable signal we will have additional timing trouble, it has to be
buffered like a clock signal etc.

Nope. You clock needs a balanced tree and your scheme will make that

harder.( more leaf cells) Your enables are easy to distribute. If you
think you need three levels of buffers to distribute your enable signal
then put in three levels of resyncing flipflops and feed the top with a
enable that is three clocks before the one that you really want.

I just wanted to ask people here if anyone had an experience with this
alternative method and if its worth to change the clocking scheme
(just for scan) ?

It's not a good solution for future chips. Chips are getting bigger and
faster. The future is in more clock domains with gating for lower power.
Rather than one huge clock domain you want many and you handle all signals
between major blocks with clock crossing resyncing techniques. That is needed
even if both blocks are leafs on the same clock tree. Cross chip skews are
getting to be that bad.

If all your flops in the chip switch on one clock edge then you have power and
emi issues that can get nasty. If you need a lot of different clock freqs then
you wind up needing a very high frequency master clock to divide easily down
for all yor enables.


The better solution is to increase the number of clock domains. Suppose your chip
has a system bus that runs at 100 mhz but some of the modules connected to that buss
could work fine at 10 mhz (timers, gpio's motion control etc).

You create a 10 mhz that is balanced to the 100 mhz so that the rising edge of 10
is coincident with a rising edge of 100. You then create a clock enable that is true
for the one 100 mhz cycle before the rising edge of 10 mhz. You can now run your slower
blocks on 10 mhz as long as you only change the signals entering those blocks when
the clock_enable is high. If you use two way handshaking protocols then you don't even
need the clock_enable.


John Eaton

 

[John_H]

"Metin Yerlikaya" <metinnn@gmx.de> wrote in message
news:12ad7f3c.0502150053.226811c@posting.google.com...

Hi,

the other day a colleague came over and suggested the following:

"To reduce design complexity and risk it is necessary to
remove all divided clock systems. There is an alternative method to do
divided
clocks. (Generate clock enable signals) The risk and the efforts for
this change are small. (Important structural change, no functional
change)"

<snip>

One of the troubles with using divided clock domains is skew. There's a
fixed clk-to-out time for the derivitive clock which makes it more difficult
to transfer data from the higher speed domain to the divided clock domain.
The differences in the clock net loading also makes it tougher to balance
the propagation delays between the two domains.

If you use divided clock domains that don't interface with the other clock
domains, don't sweat it. If you need data transferred from higher to lower
speed domains or between lower speed domains, the chances of the data for a
clock cycle changing at the same time as the divided clock for *that new
cycle* becomes great. Since multi-cycle path constraints are easy to define
in the EDA tools, cycle timing should be the same for the divided clock
versus the enabled clock schemes.

If micro-power is a concern, divided clocks can be better but extreme care
has to be taken in transferring data between domains.