Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Variable in Design Compiler for clock gating

Status
Not open for further replies.

aditya1579

Member level 2
Member level 2
Joined
Jan 2, 2013
Messages
47
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
1,624
HI,

Is there a variable in design compiler which I can set to tell it to use clock gating cells only from the rtl and not add its own ?

Request some details please, thanks.

Thanks,
Aditya
 

HI,

Is there a variable in design compiler which I can set to tell it to use clock gating cells only from the rtl and not add its own ?

Request some details please, thanks.

Thanks,
Aditya

RTL has no clock gating cell in it, it can't. RTL is a description of the circuit behavior, there are no cells present.
 

It is common practice to have instantiated clock_gating cells in RTL, which control clock propagating for the whole big module.

So, you need to use the following commans:
identify_clock_gating
set_preserve_clock_gate (and optional set_dont_touch)
compile_ultra (without -gate_clock option)
 

It is common practice to have instantiated clock_gating cells in RTL, which control clock propagating for the whole big module.

So, you need to use the following commans:
identify_clock_gating
set_preserve_clock_gate (and optional set_dont_touch)
compile_ultra (without -gate_clock option)

common where? this achieves nothing. tools do way of a better job than a human would.
 

It is common in soft-IPs. Such clock-gating just switch-off clock for the whole block or the big part of the block (by using dedicated control ports). While the tool adds additional CGs for some flops.
 

It is common in soft-IPs. Such clock-gating just switch-off clock for the whole block or the big part of the block (by using dedicated control ports). While the tool adds additional CGs for some flops.

This is really weird and I can think of at least one scenario where it gives sub-optimal results.
 

This is really weird and I can think of at least one scenario where it gives sub-optimal results.

Automatic clock gating can't always optimally determine when clock gating can be inserted. It's good if there is an obvious enable that can be converted, but not so good when you're gating multiple levels of logic.
 

Can you, please, elaborate in which situation it can be bad?

Think of a big SoC with multiple blocks. The clock source (e.g. PLL) is inevitably far from the block in question. CTS will put several buffers to drive the clock from source to block. The clock gating cell could be placed as closed to the source as possible to save power, but instead it is placed as close as possible to the block if you set any dont_touch properties on it. I am not sure the tool will make the right decision for the location or sizing of the cell in this case. Depends on how the CTS engine treats dont_touch attributes.

- - - Updated - - -

Automatic clock gating can't always optimally determine when clock gating can be inserted. It's good if there is an obvious enable that can be converted, but not so good when you're gating multiple levels of logic.

Sure. It seems we are discussing the use of a blanket clock gating enable signal for an entire block, which I could argue should be handled with a generated clock instead.
 
size_only is perhaps better than dont_touch if you want to preserve something. (You don't necessarily even need to use this will manually instanced clock gates).

Not sure what you mean by a generated clock in this context.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top