MAX7000 power and Slew rate control

Altera_Forum · ‎01-03-2009

Hi All,

I have having problems with a simple 15 bit counter being un-reliable - various bits in the top byte appear to change as the bottom byte crosses the 0x00 / 0xFF boundary.

This sounds like a ground bounce (or similar) problem to me.

Hardware is new and unproven, I have tightened up the ground planes with some copper foil to no avail.

Dev environment is Quartus II 8.1 web edition and design is a mix of Verilog and schematic capture.

I am now trying to switch off all of the Turbo bits in the device. The design will tolerate being clocked at 10MHz, so nothing is moving very fast.

I have found the Turbo bit attribute in the assignment editor so I should be able to slow down I/O slew rate.

Current pin settings are "<bit name>, Turbo Bit, Off, Yes". as well as the assignment of location and pin number.

Nothing I have done so far seems to have affected overall power consumption (I am expecting about a 30% reduction when I move to power save / no Turbo mode).

The data sheet for the MAX7k implies that every macro cell has a Turbo bit - is there a global setting to set the whole device into low power mode by default ?

Any other places I should be poking about in Quartus to find more power saving features ?

Many thanks,

Mark

Altera_Forum · ‎01-03-2009

Without knowing the code - and clock speed -, it sounds rather like a problem of inappropriate synchronous data processing.

Altera_Forum · ‎01-03-2009

Hi FvM,

You are correct, there was a bug in my Verilog, I am still new to this languge. If you can point out what I am doing wrong in this example I will be grateful.

Clock was running at 24MHz. The intenet of the design is hopefully quite obvious.

Thanks,

Mark

=============

// Use I/Q shaft encoder input to

// control a 16 bit up/down counter

// use all available input edges

module IQ_interface(clk, I, Q, count);

output count;

input clk, I, Q;

reg last_I, last_Q;

reg [15:0]count;

always @(posedge clk)

begin

if(last_I != I) // detect change of I input

begin

last_I <= I;

if(I ^ Q) count <= count + 1; // incrementing appears to work OK

else count <= count - 1;

end

if(last_Q != Q) // detect change of Q input

begin

last_Q <= Q;

if(I ^ Q) count <= count - 1; // decrementing has the bug

else count <= count + 1;

end

endmodule

Altera_Forum · ‎01-03-2009

There is a general problem with the code, not obvious at first sight. It's from the fact, that I and Q are asynchronous inputs, unrelated to clk. They have to be synchronized to clk. A general rule recommends to use a two FF chain to handle possible metastable states, although a single FF as below usually solves the problem. The assignment of previous values can be performed in the unconditional code as well.

As far as I understand the I/Q logic is basically correct, so the below code should work.

module IQ_interface(clk, I, Q, count);
output count;
input clk, I, Q;
reg Is, Qs;
reg last_I, last_Q;
reg count;
always @(posedge clk)
begin 
Is <= I;
Qs <= Q;
last_I <= Is;
last_Q <= Qs;
if (last_I != Is)
  if (Is ^Qs) count <= count + 1;
  else count <= count - 1;
if (last_Q != Qs)
  if (Is ^Qs) count <= count - 1;
  else count <= count + 1;
end;

Altera_Forum · ‎01-03-2009

I like the elegance and simplicity of your solution. It also explains why all of the (synchronous) test harnesses that I wrote for the part in Verilog all worked fine, yet the real-world failed.

On an unrelated subject, do you know if there are any global switches for the MAX7k to put the whole part into low(er) power, slower slew rate mode ? I am currently configuring every pin as non-turbo which is a bit tedious.

Regards, Mark