Counter Bug

Altera_Forum · ‎03-12-2012

Hi all,

I am currently doing watchdog timer for my project. It consists of an 8 bit counter which reloads the user's value automatically when in timer mode, or stays at zero (in watchdog mode) when countdown is completed. It will also generate an underflow(Opposite of overflow I suppose?) signal when the counter has finished counting.

The problem that I have is about reloading the counter. When the counter counts down to zero, for a brief moment it goes up to FF, then loads the user's reload value. I want the counter to reload the user's value only, and not the FF. Furthermore, the underflow signal is only generated when the counter briefly loads the FF value, rather than zero.

Can anyone suggest the cause of this behaviour? I tried looking all over my code but I don't seem to find anything wrong. I've attached a screenshot of the problem. The counter value = 5 and the underflow is signal is represented by underrun_pulse_ff_in.

Altera_Forum · ‎03-12-2012

how about posting some code?

I get the feeling you havent taken into account the clock delays.

Altera_Forum · ‎03-12-2012

Thanks for replying. This is not the entire code (I am not allowed to put it out), but snippets of it:

counter_process:PROCESS(CLK,CLRn,load_cntr_gate_ff2,load_cntr_trigger_ff2)

BEGIN

IF(CLRn='0' )THEN

CounterValue<=(OTHERS=>'0');

ELSIF(rising_edge(CLK))THEN

IF(cntr_trigger_input='0' )THEN

CounterValue<=Reload_value;

ELSIF(cntr_gate_input='0')THEN

CounterValue<=CounterValue-1;

END IF;

END PROCESS;

CNTR_gate_input <= NOT((base_clk) AND (initialised_value) AND (start_stop_signal) AND (WD_gate OR TMR_gate_hi

OR TMR_gate_lo OR TMR_gate_internal));

CNTR_trigger_input <= NOT ((initialised_value)AND(SW_trigger OR SyncTrigger OR load_init_value_register_ff2 OR

TMR_mode_underrun_ff2 OR HW_trigger OR WD_trigger_signal));

Somehow I managed to solve the underflow signal problem, but the I still remove the temporary FF value during transition from zero to the user's value.

Altera_Forum · ‎03-12-2012

Well, given this is only a snippet, the best I can do is say that the CNTR_trigger_input only goes low when counter = FF. Remember the counter will go to FF after 00 (it doesnt actuaally, go up to FF, but down).

Without the full code, thats the best I can do.

Some tips -

dont call a signal a clock when its not a clock. From your diagram it looks more like an enable or trigger (I hope its not actually clocking anything).

Whats wrong with:


if counterValue = 0 then
  CounterValue <= Reload_value;
....

Stuff like this makes code much easier to read (rather than the long list of logic inputs).

Altera_Forum · ‎03-12-2012

Your simulation in post# 1 seems to show a different code (actually an even worse one!), because it obviously involves an asynchronous load, which isn't shown in the text in post# 3.

I completely agree with Tricky, that a straightforward behavioral description based on synchronous design methods is the answer.

Altera_Forum · ‎03-13-2012

So it's normal behaviour then for the counter to go FF after 00? Could you please elaborate more?

Well about the base_clk signal, it is indeed actually a sort of a "clock" signal, as the user can use 4 different clock frequencies to run his counter with. The signal is derived from a PLL signal whose input is from the main clock signal.

The counter has to have different options for starting countdown and reload, that's why its conditions take a train load of input signals. It's not really my choice to do it rather it's a project requirement.

Does adding a latch or two sync these inputs help in any way?

Altera_Forum · ‎03-13-2012

There are no limits on counters in hardware, or with certain types in VHDL. They will underflow or overflow quite naturally, and it becomes useful to do so in some circumstances.

So

FF + 1 = 0

0 - 1 = FF

I am very worried that you can have 4 "clocks" - that is very very bad design form. You need to use these 4 inputs as enables, and run the whole system off a single base clock.

Altera_Forum · ‎03-13-2012

--- Quote Start ---

There are no limits on counters in hardware, or with certain types in VHDL. They will underflow or overflow quite naturally, and it becomes useful to do so in some circumstances.

So

FF + 1 = 0

0 - 1 = FF

I am very worried that you can have 4 "clocks" - that is very very bad design form. You need to use these 4 inputs as enables, and run the whole system off a single base clock.

--- Quote End ---

No, no, I think you might have misunderstood.

These 4 signals are not actually fed into the counter clock input, but to the counter enable so that the counter decrements only when one of these pulses goes HIGH. The counter's clock gets its signal from the main clock signal. Sorry if I wasn't clear on this.

Sorry to repeat the question, does this mean that the FF value is normal?

On a different note, I have 2 latches that are supposed to delay the signal by 2 clock edges, but I got only 1:confused: I am starting to wonder whether SignalTap is playing with me or maybe Cyclone II is going kaputt?

Altera_Forum · ‎03-13-2012

--- Quote Start ---

No, no, I think you might have misunderstood.

These 4 signals are not actually fed into the counter clock input, but to the counter enable so that the counter decrements only when one of these pulses goes HIGH. The counter's clock gets its signal from the main clock signal. Sorry if I wasn't clear on this.

--- Quote End ---

Thats good - but it would make more sense to call the signals something other than _clk. How about _en, because they are not clocks.

--- Quote Start ---

Sorry to repeat the question, does this mean that the FF value is normal?

--- Quote End ---

Yes. The behaviour is perfectly normal. Whether you actually want this behaviour is down to your spec and design.

--- Quote Start ---

On a different note, I have 2 latches that are supposed to delay the signal by 2 clock edges, but I got only 1:confused: I am starting to wonder whether SignalTap is playing with me or maybe Cyclone II is going kaputt?

--- Quote End ---

It will be neither. It will problems with the design and your coding. The way you say latch - is it really a latch (like a transparent latch) or are they registers.

If you could post the code, we could help much more. The code doesnt look like its anything special really.

Altera_Forum · ‎03-13-2012

--- Quote Start ---

It will be neither. It will problems with the design and your coding. The way you say latch - is it really a latch (like a transparent latch) or are they registers.

If you could post the code, we could help much more. The code doesnt look like its anything special really.

--- Quote End ---

Well it's a D latch. Here's the code:


IF(CLRn='0')THEN
  underflow_pulse_out_1<='0';
ELSIF(rising_edge(CLK))THEN
  undeflow_pulse_out_1<=underflow_pulse_in;
END IF; 
 
IF(CLRn='0')THEN
  underflow_pulse_out_2<='0';
ELSIF(rising_edge(CLK))THEN
  undeflow_pulse_out_2<=underflow_pulse_out_1;
END IF; 
 
CounterUnderflow<='1' When (CounterValue=0)ELSE '0';
underflow_pulse_in<=CounterUnderflow AND CounterEnable;

I don't think there's anything wrong with it. Then again I don't have a lot of XP with VHDL.

Altera_Forum · ‎03-13-2012

why separate them? why not combine it like this?


IF(CLRn='0')THEN                           
  underflow_pulse_out_1<='0';             
  underflow_pulse_out_2<='0'; 
ELSIF(rising_edge(CLK))THEN                
  undeflow_pulse_out_1<=underflow_pulse_in;
  undeflow_pulse_out_2<=underflow_pulse_out_1;
END IF;

Now, this is again only a code snippet (can you please post the whole file, then we can simulate/look at it (feel free to PM it). I assume the other two lines are outside a process?

If you were to reset the counter on just the underflow signal, then you will avoid the FF line of the counter. But we need the whole code to see where the problem actually is.

Altera_Forum · ‎03-13-2012

Do you have an email address perhaps? I can't send a PM since my posts count is under 10......