another counter question

I am trying to use Altera 9000 part to run at 16.66MHz clock...

I had several counters..and I have something close to this

signal counter: integer range 0 to 4194303;

process (clk,reset)

if (CLK='1' and CLK'event) then
count <= count + 1;
end if;

if (count <= 120 ) then
PW <= '0' ;
else if (count <= 17 then
PW <= '1';
else if (count <= 183) then
PW <= '0';
end if;

if (count <= 48000 ) then
PW_2 <= '1' ;
else if (count <= 48825) then
PW_2 <= '0';
else if (count <= 4182300) then
PW_2 <= '1';
end if;

end if;

end process;



I have a counter defined as integer range. and my code complies and
simulates.

What I noticed is that the counter was violating the setup and hold
time (gettting timing error and counter won't reset to 0) in Max Plus 2
simulation as well on the board, since I have a high integer value. So
I divided the clock by 2 and use 8.33MHz clock but now I can't get the
1020ns resolution for PW. (1020/120 = 8.5) so I need to go back to
16.67MHz clock (one of the PW is 1020ns active low)

I looked at somet Max Plus 2 primitives for counter but not sure how to
use them or is there a better way to define counter in Max Plus 2?? Any
tips?? Also, I didn't have any luck using Hex Value or Std_logic_vector
(coundn't do arithmetics in Max Plus 2 with Std_logic_vector)..does any
one know about this as well?

Thanks,
Martin

martstev@gmail.com

wrote:
> I am trying to use Altera 9000 part to run at 16.66MHz clock...
>
> I had several counters..and I have something close to this
>
> signal counter: integer range 0 to 4194303;
>
> process (clk,reset)
>
> if (CLK='1' and CLK'event) then
> count <= count + 1;
> end if;
>
> if (count <= 120 ) then
> PW <= '0' ;
> else if (count <= 17 then
> PW <= '1';
> else if (count <= 183) then
> PW <= '0';
> end if;
>
> if (count <= 48000 ) then
> PW_2 <= '1' ;
> else if (count <= 48825) then
> PW_2 <= '0';
> else if (count <= 4182300) then
> PW_2 <= '1';
> end if;
>
> end if;
>
> end process;
>
>
>
> I have a counter defined as integer range. and my code complies and
> simulates.
>
> What I noticed is that the counter was violating the setup and hold
> time (gettting timing error and counter won't reset to 0) in Max Plus 2
> simulation as well on the board, since I have a high integer value. So
> I divided the clock by 2 and use 8.33MHz clock but now I can't get the
> 1020ns resolution for PW. (1020/120 = 8.5) so I need to go back to
> 16.67MHz clock (one of the PW is 1020ns active low)
>
> I looked at somet Max Plus 2 primitives for counter but not sure how to
> use them or is there a better way to define counter in Max Plus 2?? Any
> tips?? Also, I didn't have any luck using Hex Value or Std_logic_vector
> (coundn't do arithmetics in Max Plus 2 with Std_logic_vector)..does any
> one know about this as well?
>
> Thanks,
> Martin
>

Your definitions of PW and PW2 don't cover all cases so there
is an inferred latch, which is taboo. Note they're not clocked
in your implementation, so I didn't either in mine but I made
them concurrent statements.

I used unsigned instead of integer -- who knows what the
synthesizer is going to choose for integer. Probably it's 32
bits, so wouldn't wrap when you want it. The range checking
is only done during simulation I suspect, and I seem to recall
wrapping behaviour is not guaranteed. Use one of the bit
based types so you know what you're getting.

Hope this is useful.

-Dave


library ieee;
use ieee.std_logic_1164.all;
use numeric_std.all;

-- standard wrapping omitted
signal counter : unsigned (22 downto 0) := (others => '0'); -- 4194303
= X"3fffff"
begin
process(clk)
begin
if clk'event and clk = '1' then
counter <= counter + 1;
end if;
end process;

PW <= '0' when count < 120 else
'1' when count <= 178 else
'0';

PW2 <= '1' when count < 48000 else
'0' when count < 48825 else
'1';

end architecture;


--
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

skrev:

> signal counter: integer range 0 to 4194303;
>
> process (clk,reset)
>
> if (CLK='1' and CLK'event) then
> count <= count + 1;
> end if;
>
> if (count <= 120 ) then
> PW <= '0' ;
> else if (count <= 17 then
> PW <= '1';

Hi,

Why not compare inside the clocked region? You can set PW when you
reach 120 and clear it at 178. "Equal" comparators consumes less
resources than "less or equal" comparators. Putting them inside the
clocked region makes the signal start at the output of a flip-flop so
you dont start with a deep combinatorial net.

/Peter

PS The process is triggered by reset, but its not used to reset count...

skrev:

> signal counter: integer range 0 to 4194303;
>
> process (clk,reset)
>
> if (CLK='1' and CLK'event) then
> count <= count + 1;
> end if;
>
> if (count <= 120 ) then
> PW <= '0' ;
> else if (count <= 17 then
> PW <= '1';

Hi,

Why not compare inside the clocked region? You can set PW when you
reach 120 and clear it at 178. "Equal" comparators consumes less
resources than "less or equal" comparators. Putting them inside the
clocked region makes the signal start at the output of a flip-flop so
you dont start with a deep combinatorial net.

/Peter

PS The process is triggered by reset, but its not used to reset count...

I agree with the "equal" comparators issue suggested by Peter, but I
don't think is the point. I think the best way to implement a big
counter is divided in two and use the Carry out signal to start the
second counter.
The carry-out counter divides in pieces the combinational logic chain
and reduces the propagation delay in your logic.
Try this out.
Regards

Alessandro

Peter wrote:
> skrev:
>
>
>>signal counter: integer range 0 to 4194303;
>>
>>process (clk,reset)
>>
>>if (CLK='1' and CLK'event) then
>> count <= count + 1;
>>end if;
>>
>>if (count <= 120 ) then
>> PW <= '0' ;
>>else if (count <= 17 then
>> PW <= '1';
>
>
> Hi,
>
> Why not compare inside the clocked region? You can set PW when you
> reach 120 and clear it at 178. "Equal" comparators consumes less
> resources than "less or equal" comparators. Putting them inside the
> clocked region makes the signal start at the output of a flip-flop so
> you dont start with a deep combinatorial net.
>
> /Peter
>
> PS The process is triggered by reset, but its not used to reset count...
>

If you really want to make a fast counter, look no further than a LFSR.
As an example, you can design a 31-bit counter (with 2,147,483,647
valid states) with 31 flip-flops and one XOR (or XNOR) gate.

On another note, beware of the logic hazards on the PW and PW2 outputs-
only use them as inputs in the same clk domain, or register the outputs.

jens wrote:
> If you really want to make a fast counter, look no further than a LFSR.
> As an example, you can design a 31-bit counter (with 2,147,483,647
> valid states) with 31 flip-flops and one XOR (or XNOR) gate.
>
> On another note, beware of the logic hazards on the PW and PW2 outputs-
> only use them as inputs in the same clk domain, or register the outputs.
>

That's an interesting approach, all you'd need to do is know a good
starting state (such as '1') and figure out what the value would be
X states later and compare against that.

The code would be cryptic but comments would help.

You wouldn't be able to do comparisons on intermediate values and
have them make any sense, as the output isn't increasing monotically.
But I'm sure there are a lot of cases where this would be a perfect low
resource solution.

-Dave

--
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

alessandro basili skrev:

> I agree with the "equal" comparators issue suggested by Peter, but I
> don't think is the point. I think the best way to implement a big
> counter is divided in two and use the Carry out signal to start the
> second counter.
> The carry-out counter divides in pieces the combinational logic chain
> and reduces the propagation delay in your logic.
> Try this out.
> Regards
>

Thats a good idea. Using a pipelined carry chain I have run a 32-bit
counter at over 30 MHz in an old 5V process FPGA. A guess this
particular chip is rather old? But there shall be no problems to reach
16 MHz with a 22-bit counter.

/Peter

I think this is a very unfeasible counter to Martin's problem. As far as
I understood he really needs to have PW and PW_2 active in some values
range. I really don't see how would you implement such a signal,
checking the state that you can really do not foresee (unless you want
to layout a sequence of a 31-bit LFSR).
I think LFSR are good for RAM addressing as reported here:

http://www.opencores.org/forums/cores/2003/11/00044

Maybe I missed the point, but I really cannot see it usefull in this case.

Alessandro

David Ashley wrote:
> jens wrote:
>
>>If you really want to make a fast counter, look no further than a LFSR.
>> As an example, you can design a 31-bit counter (with 2,147,483,647
>>valid states) with 31 flip-flops and one XOR (or XNOR) gate.
>>
>>On another note, beware of the logic hazards on the PW and PW2 outputs-
>>only use them as inputs in the same clk domain, or register the outputs.
>>
>
>
> That's an interesting approach, all you'd need to do is know a good
> starting state (such as '1') and figure out what the value would be
> X states later and compare against that.
>
> The code would be cryptic but comments would help.
>
> You wouldn't be able to do comparisons on intermediate values and
> have them make any sense, as the output isn't increasing monotically.
> But I'm sure there are a lot of cases where this would be a perfect low
> resource solution.
>
> -Dave
>

"alessandro basili" <> wrote in message
news:eeo4sf$fsk$...
>I think this is a very unfeasible counter to Martin's problem. As far as I
>understood he really needs to have PW and PW_2 active in some values range.
>I really don't see how would you implement such a signal, checking the
>state that you can really do not foresee (unless you want to layout a
>sequence of a 31-bit LFSR).
> I think LFSR are good for RAM addressing as reported here:
>
> http://www.opencores.org/forums/cores/2003/11/00044
>
> Maybe I missed the point, but I really cannot see it usefull in this case.
>
> Alessandro

Actually using an LFSR to implement a counter where you set flags at hard
coded constants is quite feasible and useful and will result in just about
the smallest, fastest counter possible. The original post had a simple
counter that counts up and sets some outputs when that count was less than
or greater than a series of hard coded constants. This can easily be
transformed into one that sets/resets flip flops when particular counts get
reached and remain in their current state otherwise.

Here's another hint: All of the states of an LFSR can be precomputed
constants so comparing 'count=178' can be done just as easily with
'count=Lfsr_Count(17' where I've taken some liberties but the idea is
that the 178th step of an LFSR can be pre-computed in a VHDL function (in
this case 'Lfsr_Count') that can then be used to set a constant that will be
used to trigger the flags.

KJ