Re: Self clocking FPGA?

Altera_Forum · ‎03-04-2014

We have a need to power down large parts of our design - including the clock source for the device - but keep portions of the FPGA (Cyclone III, EP3C25) running. There are no other clock sources fed to the device (just the one we are trying to power down).

Initially we thought that we could use the internal configuration clock, but according to the documentation it is turned off after configuration completes.

Does anyone have any novel ideas as to how to create a clock using just FPGA resources?

Altera_Forum · ‎03-04-2014

--- Quote Start ---

Does anyone have any novel ideas as to how to create a clock using just FPGA resources?

--- Quote End ---

You could create an RC oscillator using logic, however, at that point you are leaving yourself open to PVT (process-voltage-temperature) variations.

I'd recommend deciding "how low power" you need to go, and then just design your system to achieve that level of power down. For example, if you really want low-power, turn your FPGA off, and use a microcontroller to decide when to turn back on :) Obviously suggestions like this are highly design-dependent. FPGAs have high static power. Before getting too fancy with your clocking logic, you need to determine whether you will actually save enough power.

Power saving ideas;

1. Have two external clocks; one for your always on logic and another for your logic that you want to stop clocking.

2. Use multiple resets; one for your always on logic, and another for the logic that you want to stop toggling.

3. Use a PLL.

You could have your always on logic clocked at a low frequency, or change to a low frequency when you want low-power mode. Your other logic could have its clock disabled.

(1) will have a slight power advantage because by disabling the clock external to the FPGA, you are stopping the clock tree from toggling. You can achieve the same thing using a clock multiplexer (if the Cyclone III supports it); one input would be the clock, the other would be a grounded clock pin.

All of these ideas should be easy to test using an evaluation board (most have current-sense for the core logic).

Personally, if I want low-power, an FPGA is not the first thing that comes to mind :)

Cheers,

Dave

Altera_Forum · ‎03-05-2014

The configuration clock isn't always disabled after configuration, you can use it through the ALTINT_OSC megafunction (in the I/O category). It's not documented though, AFAIK.

Altera_Forum · ‎03-05-2014

Thanks Dave - but this design is in production and we are not going to change the PCB for this "feature".

--- Quote Start ---

The configuration clock isn't always disabled after configuration, you can use it through the ALTINT_OSC megafunction (in the I/O category). It's not documented though, AFAIK.

--- Quote End ---

Now this looks promising!

Here is the code that pops out of the wizard:

module  internal_clk_altint_osc_947
	( 
	clkout,
	oscena) ;
	output   clkout;
	input   oscena;
	wire  wire_cycloneiii_oscillator1_clkout;
	cycloneiii_oscillator   cycloneiii_oscillator1
	( 
	.clkout(wire_cycloneiii_oscillator1_clkout),
	.oscena(oscena));
	assign
		clkout = wire_cycloneiii_oscillator1_clkout;
endmodule //internal_clk_altint_osc_947

It looks like the input is an enable - the only question is the level, but I'm going to guess logic high... I'll post my experimental results as I try it.

Altera_Forum · ‎03-05-2014

--- Quote Start ---

Thanks Dave - but this design is in production and we are not going to change the PCB for this "feature".

--- Quote End ---

The PLL, multiple resets, and clock multiplexer options most likely do not require a board change, so any of those options can be tested.

I'm interested in whether Daixiwen's suggestion works too. However, even with that option, you still need to figure out a low power clocking scheme. I believe the configuration clock is 33MHz (typical), so that clock may still be too fast for "low power". A PLL clock from your existing clock source, generating multiple outputs, including a low-frequency clock, with control logic that disables the clock to the higher powered logic will likely be your best bet, since this disables the clock tree to that logic (least power).

Cheers,

Dave

Altera_Forum · ‎03-05-2014

Dave - the majority of the power that we are trying to save is in the external ECL logic that provides the high precision vernier and buffering of clocks to the rest of the system - including the FPGA. Shutting this off is an easy way for us to save much more power than all of the power that the FPGA consumes, but then we have the problem of needing a secondary clock source since we have just taken away the primary FPGA clock.

The ALTINT_OSC megafunction (which appears to be just a call to cycloneiii_oscillator) WORKS great! Just tie the oscena to logic high, and you have a clock. I do not know the exact frequency, but it initially appears to be >= 50mhz.

My first experiment was to attach the altint_osc to a PLL, but that didn't work - some sort of fabric interconnect problem.

Altera_Forum · ‎03-05-2014

--- Quote Start ---

Dave - the majority of the power that we are trying to save is in the external ECL logic that provides the high precision vernier and buffering of clocks to the rest of the system - including the FPGA. Shutting this off is an easy way for us to save much more power than all of the power that the FPGA consumes, but then we have the problem of needing a secondary clock source since we have just taken away the primary FPGA clock.

--- Quote End ---

Ah, that makes sense. Thanks for clarifying.

Its good to hear ECL is not dead yet :)

--- Quote Start ---

The ALTINT_OSC megafunction (which appears to be just a call to cycloneiii_oscillator) WORKS great! Just tie the oscena to logic high, and you have a clock. I do not know the exact frequency, but it initially appears to be >= 50mhz.

--- Quote End ---

Its possible that the AS configuration clock (DCLK output) is half this. The DCLK typical frequency is 33MHz, so perhaps the oscillator is 66MHz.

--- Quote Start ---

My first experiment was to attach the altint_osc to a PLL, but that didn't work - some sort of fabric interconnect problem.

--- Quote End ---

Bummer. Try routing it to a clock mux and see if that works. The output of the clock mux can go to a PLL.

Cheers,

Dave

Altera_Forum · ‎03-05-2014

Another random idea ...

A PLL will output a clock regardless of whether is has an input clock or not. The VCO will sit at either the high-end or low-end of its tuning range. You could configure PLL from your external clock source, and look at the output frequency when its locked versus unlocked. Perhaps you could use the "locked" output to decide if the external clock is valid, and if its not, reset your logic, but keep a small amount of logic alive, being clocked from the unlocked PLL clock output. Worst-case if the "normal" output frequency is too high, you could use another PLL output with a larger divider and clock your low-power logic from that.

Cheers,

Dave

Altera_Forum · ‎03-05-2014

I experienced that the minimal VCO frequency can be much lower than the specified value, beyond a reasonable range.

Altera_Forum · ‎03-05-2014

Hi FvM,

--- Quote Start ---

I experienced that the minimal VCO frequency can be much lower than the specified value, beyond a reasonable range.

--- Quote End ---

Could you clarify this comment.

I interpret it to mean that you have observed the output frequency of an unlocked PLL to be much lower than the data sheet stated minimum end of the lock range of the PLL.

Did you happen to observe this on a Cyclone III?

Personally using an unlocked VCO is not something I would normally advocate, as it involves using the device in an unspecified manner, i.e., Murphy's Law all but guarantees that this scheme will work on the first 10 prototype boards, but then not work for the production run!

Cheers,

Dave