Making a timer out of TFFs

I've tried making a 16 bit timer out of TFFs using this code:
snip ghastliness
but it works terribly.

On Jun 4, 6:53 am, laserbeak43 wrote:

I've tried making a 16 bit timer out of TFFs using this code:
snip ghastliness
but it works terribly.

Ye gods and little fishes, what on earth would you
want to do that for?  It's horrible!  All that
soldering.... all those wires.... yuck.  Nearly
twenty years ago I got away from all that junk by
learning Verilog and VHDL, and using synthesis.

Understood that you might want to work through some lab
exercises, but what is the point of anything so detached
from common-sense?

And what, precisely, does "works terribly" mean?  If you
get the ridiculous wiring-knitting just right, it should
work the same way as any other synchronous ripple counter.
Get it wrong and it'll be broken.

Oh, and your toggle FF model is garbage too.  T should
not be in its sensitivity list.  The clock test should
be an "elsif" on the end of the reset test, not a
separate "if".  The clock test should be
  elsif Clk'event and Clk='1'
or, better,
  elsif rising_edge(Clk)

If that code came out of a book, junk the book and get
a decent one.  If it didn't, get a book :-)

cheers
--
Jonathan Bromley

ftp://ftp.altera.com/up/pub/Altera_Material/QII_9.0/Digital_Logic/DE2/Laboratory_Exercises/VHDL/lab4_VHDL.pdf

On Fri, 4 Jun 2010 10:49:01 -0700 (PDT), laserbeak43 wrote:
ftp://ftp.altera.com/up/pub/Altera_Material/QII_9.0/Digital_Logic/DE2...

OK, maybe it's not so bad.  At least they invite you to *compare*
it with Q<=Q+1; which is the non-demented way to do it.

I don't know about "colourful" but I do have a hidden kindly streak,
so here's a TFF for you...

   process (Clk, nReset)
   begin
     if nReset = '0' then
       tff <= '0'; -- async reset
     elsif rising_edge(Clk) then
       if T = '1' then
         tff <= not tff;
       end if;
     end if;
   end process;

And here's a cutesy-poo way to describe a bunch of
TFFs organised as a ripple counter like the nice
lab description:

  signal Ctr: std_logic_vector(N-1 downto 0);
  ...
  process (Clk, nReset)
    variable ripple_enable: boolean;
  begin
    if nReset = '0' then
      Ctr <= (others => '0');
    elsif rising_edge(Clk) then
      ripple_enable := (count_enable = '1');
      for i in Ctr'reverse_range loop -- LSB first
        if ripple_enable then
          if Ctr(i) = '0' then
            ripple_enable := false;
          end if;
          Ctr(i) <= not Ctr(i);
        end if;
      end loop;
    end if;
  end process;

Less yucky than the wires?
--
Jonathan Bromley

BUT, that's the easy way to do it, and I think the point of the
exercise(i could be wrong) is to make you do it the hard way, forcing
you to use a instances of your TFF to string together a counter.

Hello, I've tried making a 16 bit timer out of TFFs using this code:
/////////////////////////////////////////////////////////////////////////////////////////////////////////////
entity myTFF is
        port( T, Clk, Reset     : in std_logic;
                        Q                       : out std_logic
        );
end myTFF;

architecture behavioral of myTFF is

        signal buf : std_logic;

begin

        process(T, Clk, Reset)
        begin

                if(reset = '1') then
                        buf <= '0';
                end if;

                if(Clk = '1') then
                        if(T = '1')then
                                buf <= (NOT buf);
                        end if;
                end if;

        end process;

        Q <= buf;

end behavioral;
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
entity TFFcounter16bit is

        port (  enable, clk, rst : in std_logic;
                        Qpin    : out unsigned(15 downto 0)
        );

end TFFcounter16bit;

architecture wowee of TFFcounter16bit is

        signal Qout : unsigned(15 downto 0);

begin

        myTFF0  : entity work.myTFF port map( enable, clk, rst, Qout(0));
        myTFF1  : entity work.myTFF port map( (enable AND Qout(0)), clk, rst,
Qout(1));
        myTFF2  : entity work.myTFF port map( ((enable AND Qout(0)) AND
Qout(1) ), clk, rst, Qout(2));
        etc... all the way town to myTFF15

        Qpin <= Qout;

end wowee;
///////////////////////////////////////////
but it works terribly. Could someone give me an example of how to do
this? Just in case you're wondering, this is not schoolwork It's from
the Altera Labs. DE2 Lab4 part1  to be exact.

thanks
Malik

[snip]

And here's a cutesy-poo way to describe a bunch of
TFFs organised as a ripple counter like the nice
lab description:

signal Ctr: std_logic_vector(N-1 downto 0);
...
process (Clk, nReset)
variable ripple_enable: boolean;
begin
if nReset = '0' then
Ctr<= (others => '0');
elsif rising_edge(Clk) then
ripple_enable := (count_enable = '1');
for i in Ctr'reverse_range loop -- LSB first
if ripple_enable then
if Ctr(i) = '0' then
ripple_enable := false;
end if;
Ctr(i)<= not Ctr(i);
end if;
end loop;
end if;
end process;

Less yucky than the wires?

On 6/4/2010 12:52 PM, Jonathan Bromley wrote:
 
 > [snip]





And here's a cutesy-poo way to describe a bunch of
TFFs organised as a ripple counter like the nice
lab description:

   signal Ctr: std_logic_vector(N-1 downto 0);
   ...
   process (Clk, nReset)
     variable ripple_enable: boolean;
   begin
     if nReset = '0' then
       Ctr<= (others =>  '0');
     elsif rising_edge(Clk) then
       ripple_enable := (count_enable = '1');
       for i in Ctr'reverse_range loop -- LSB first
         if ripple_enable then
           if Ctr(i) = '0' then
             ripple_enable := false;
           end if;
           Ctr(i)<= not Ctr(i);
         end if;
       end loop;
     end if;
   end process;

Less yucky than the wires?

Actually had to do something very similar to that a while back for an
application that really really really required that I convince the tools
to build a real ripple counter (each flop clocked from the falling edge
of the output of the previous).  Nothing short of directly instantiating
the flop out of UNISIM and wiring it up myself would coerce it into working.

--
Rob Gaddi, Highland Technology
Email address is currently out of order

Just out of curiosity: What kind of application demanded the use of
such an asynchronous counter.

On 7 Jun., 18:24, Rob Gaddi<rga...@technologyhighland.com> wrote:
On 6/4/2010 12:52 PM, Jonathan Bromley wrote:

[snip]





And here's a cutesy-poo way to describe a bunch of
TFFs organised as a ripple counter like the nice
lab description:

signal Ctr: std_logic_vector(N-1 downto 0);
...
process (Clk, nReset)
variable ripple_enable: boolean;
begin
if nReset = '0' then
Ctr<= (others => '0');
elsif rising_edge(Clk) then
ripple_enable := (count_enable = '1');
for i in Ctr'reverse_range loop -- LSB first
if ripple_enable then
if Ctr(i) = '0' then
ripple_enable := false;
end if;
Ctr(i)<= not Ctr(i);
end if;
end loop;
end if;
end process;

Less yucky than the wires?

Actually had to do something very similar to that a while back for an
application that really really really required that I convince the tools
to build a real ripple counter (each flop clocked from the falling edge
of the output of the previous). Nothing short of directly instantiating
the flop out of UNISIM and wiring it up myself would coerce it into working.

--
Rob Gaddi, Highland Technology
Email address is currently out of order

Hi Rob,
while I'm sure that it is possible to describe this in behavioral
VHDL,
instantiating (especially with a generate loop) is much simpler.

Just out of curiosity: What kind of application demanded the use of
such an asynchronous counter.
Maliks example is still about a synchronous one, even if it uses T-FFs
to simplify the combinatorical stuff.

Have a nice synthesis
Eilert

Asynchronous frequency counter.  A ripple counter only has a single
point of entry,

so you can gate the external input signal at that very
first flop.  Turn it off, wait long enough to be sure that the ripple's
worked its way through,

read it out,

raise then lower the asynch clear,
Async clear...sounds like seconc point of entry.

wait a bit more, and start it up again.  You can measure frequencies up
to the individual flop toggle speed of the FPGA.

On 6/8/10 3:04 AM, backhus wrote:

Just out of curiosity: What kind of application demanded the use of
such an asynchronous counter.

Consider a small CPLD with a 100 Mhz state machine. Now I want to add a
LED that blinks at a human observable rate. A giant synchronous counter
would waste a whole bunch of product terms and probably be the timing
critical path. A ripple counter is perfect for this situation.

On Jun 8, 11:33 am, Jeff Cunningham <j...@sover.net> wrote:

On 6/8/10 3:04 AM, backhus wrote:

Just out of curiosity: What kind of application demanded the use of
such an asynchronous counter.

Consider a small CPLD with a 100 Mhz state machine. Now I want to add a
LED that blinks at a human observable rate. A giant synchronous counter
would waste a whole bunch of product terms and probably be the timing
critical path. A ripple counter is perfect for this situation.

If the blink rate is a fixed (or a set of fixed) rates that are known
ahead of time, then an LFSR counter is likely the better choice.  The
product term usage would be darn near identical, clock routing and
timing is better.

If the blink rate needs to be externally programmable, then the LFSR
becomes a bit of a chore for whatever it is that programs it since
there needs to be an algorithm to translate from the desired blink
rate to the appropriate count value.

KJ

On Jun 8, 12:45 pm, Rob Gaddi<rga...@technologyhighland.com> wrote:

Asynchronous frequency counter. A ripple counter only has a single
point of entry,

Not usually...we'll come back to that

so you can gate the external input signal at that very
first flop. Turn it off, wait long enough to be sure that the ripple's
worked its way through,

Not sure that you can figure out out how long is 'long enough' by
measuring something in the system...which means you have to rely on
the timing reports

read it out,

raise then lower the asynch clear,
Async clear...sounds like seconc point of entry.


wait a bit more, and start it up again. You can measure frequencies up
to the individual flop toggle speed of the FPGA.


Unless you have a way to measure when the system has settled, then you
can only reliably measure up to the frequency that the timing reports
allow.

Depending on what you're doing with the frequency measurements, an
LFSR counter would work much faster than a ripple counter...you lose
the binary number interpretation of the bits of the counter though.

KJ