Quartus 10.0 complains of nested clock gating scheme

I am not expert of ASIC to FPGA migration but I think it is not standardised.

You better plan to regenerate your clocks from PLLs and only mux them if absolutely necessary.

Have you considered using clock enable to replace some clocks?

Thank Kaz for the prompt response.

I have traced some discussions about the "clock gating" issues here and I heard a lot of suggestions like "using clock enable to replace some clocks".

I am sorry that I didn't look into the idea carefully.

Would you mind giving me a brief explanation(or a link) or better an example of that?

(It seems the concept is very basic so that people don't explain it anymore)

In fact, the nested clock gating scheme is from a soft IP and the clock path is a bit complicated. I don't really want to make any modifications on it even in FPGA mode.

All I can do is to replace the clock gating module.......

BTW, it seems Synplify tool can recognize the RTL coding style as in my previous post and nested clock gating scheme is not a problem at all.

I am wondering if I need to turn on some sort of settings/options in qsf file to get Quartus understand what I wanna do.

Thanks,

Acme

As I said I am no expert on ASIC to FPGA rules but I have gut feeling that replacing clock cells with altclkctrl may not be that straight forward.

You will need to identify the clocking plan of your ASIC design then emulate same plan from PLLs (this is easy) and if necessary use clock enable in any clock domain as needed.

The clock enable signal is generated from ordinary logic but using the clock of given domain. For example a counter can be used to generate pulses to enable a clocked register or freeze it. In theory from a single clock you can generate any rate below clock be it integer or fractional.

In RTL you just clock the process as usual then add if construct immediately after clock edge ...if clk_en then ....... end

so that every register is switched under your control in any given process. However, there are some logic pitfalls in interfaces between modules.

For fractional rate generation I commonly use accumulator that adds up n modulo m to generate n/m * clock rate. Though not regular but correct for processing digits

Each ALTCLKCTRL block sits at the top of a clock distribution tree, which can only be fed by dedicated clock input pins, PLLs or logic.

Thus, two of them can't be chained together directly. It should be possible to chain two of them by placing a LCELL primitive bewteen them. But this will lead to the clock skew issues one is trying to avoid.

One solution would be to rethink your clock trees and gating logic, so that you no longer need to cascade ALTCLKCTRL blocks.

These are Quartus style guideline for implementing clock gating with logic:

http://quartushelp.altera.com/10.1/mergedprojects/verify/da/comp_file_rules_clock.htm

Implementing will also lead to clock skew issues. However, Quartus has an option to try to convert gated clocks (following the above style) into clock enables.

Never tried it, though!

Implementing clock enables manually is simple, but it requires code changes. All you need to do is to follow the template:

always @ (posedge clk, posedge reset)

begin

if (reset) begin

// Active high reset stuff

end

else if (enable) begin

// logic goes here

end

end

Thank Kbugalho and Kaz for the explanation of clock enable concept.

It reminds me that the coding style of "clock enable" will be transfered into ICG cell in netlist (when synthesizing with some options as I know).

It is also a kind of power saving scheme.

However, this can not solve my problem.

It is impossible for me to modify the RTL code of the soft IP into clock enable style.

My biggest problem based on the pure quartus flow is that JTAG connection is failed. The CPU function seems to work well according to signal tap waveform. I have the following constraint related to EJ_CLK:

create_clock -name {PAD_EJ_TCK} -period 25.000 -waveform { 0.000 12.500 } [get_ports { PAD_EJ_TCK }] -add

Besides, below is related setting in qsf file:

set_instance_assignment -name FAST_INPUT_REGISTER ON -to PAD_EJ_TCK

set_instance_assignment -name CURRENT_STRENGTH_NEW "MAXIMUM CURRENT" -to PAD_EJ_TCK

set_global_assignment -name FMAX_REQUIREMENT "40 MHz" -section_id clk_ejtag

set_instance_assignment -name CLOCK_SETTINGS clk_ejtag -to PAD_EJ_TCK

And the timing report shows as below:

-Slow 900mV 85C Model Setup Summary PAD_EJ_TCK -3.609

-Slow 900mV 85C Model Hold Summary PAD_EJ_TCK -1.327

I think the bad timing is the problem that JTAG can't be connected well.

Do you have any idea of this?

What esle I can set to fix timing violations?

Is path constraint helpful? Would you give me an example?

Thanks,

Acme

As I said, Quartus has an option ("Auto Gated Clock Conversion") to automatically replace gated clocks with clock enables during synthesis.

Try it.

I assume that JTAG interface is a custom JTAG interface in your design, not the FPGA's JTAG interface.

You can try and fidle with some of the synthesis and fitting options.:

- Set synthesis optimization technique for speed.

- Set fitting to optimize all paths for hold timing.

Uh...i am not quite sure the JTAG interface is a custom JTAG interface or not.

I mean there is only one EJTEG interface on the fpga(820) mainboard and we get trace32 or similar device connected to it.

The EJTAG related PADs will directly connect to those on the interface of internal CPU.

After tracing some posts of "Auto Gated Clock Conversion", it seems it is not easy to get it work .....but, i will turn it on and give it a try.

BTW, I have ever tried "fitting to optimize all paths for hold timing" once and it takes more than 24 hours and can't get finished while original process without the option just takes about 5 hours.

So....okay I will try it again with both new options.

("synthesis optimization technique for speed" is my default setting)

Thanks,

Acme

By custom, I mean this.

The FPGA has a dedicated JTAG interface, which can be used to configure the FPGA, for SignalTap, etc, etc.

If I understand you correctly, you are using the FPGA to protype a CPU, which happens to have it's own JTAG interface as well.

Nothing wrong with that, I'm just trying to get situated here.

By the way, why "-add" on the create_clock constrain?

Oh...I am not sure why "-add" is there.

I reuse the sdc file from others and it looks like those clock constraints, e.g. create_clock, is imported into the tool successfully.

Should I remove "-add" from all create_clock statements?

Hi Rbugalho,

It seems "fitting to optimize all paths for hold timing" works!!

I can get EJTAG connected now.

However, it looks like a side-effect that I can't access to DRAM on the FPGA board any more. The dram clock is derived from fpga_pll (a megafunction, clock ratio is XTAIL*9/2 where XTAIL is a clock source from PAD) and I didn't set any constraint on it.

I think dram access problem is a timing issue so here comes a few questions about timing:

a. should I use create_clk command on the dram clock?

b. how to get timing report of clocks derived from fpga_pll?

c. do I have to set any constraint or options for dram clock at this situation? (I mean, with the option fix hold time for ALL PATH)

Thanks,

Acme