64 Bit Counter

Need a large counter ? This was done in a single chip, done with simple Verilog code. Could
have been done with schematic capture but that would have been tedious.. Notice most of
chip resources un-used, available for other functions. See right hand window. Lots of other
analog and digital resources in the SOC for use.

PSOC 5LP family, Cypress/Infineon. This was a no code design, but ARM core still available
for other stuff. Did a similar design for a SIPO 64 bit shift register. Or quad DDS driving quad
WaveDAC ...Lots of fun.


Tools, PSOC Creator, and compiler free. Typical board for most projects $ 10,



Note, its no C code if you do not use the counter state, just use it by adding internal HW to do a compare
register function. But if you need the cntr value at any point then by definition you are doing a coded design.
Or an ISR on cntr overflow.

Regards, Dana.

I Wish I had 1/10 of your FPGA knowledge.

danadak said:

Need a large counter

Click to expand...

How are you doing carry from one 8-bit counter to the next?

Schmitt Trigger this is not standard FPGA design, its much simpler.

Actually one does not have to jump into FPGA level of design where timing
is a large component of design. This tool basically masks most of that, the way
its characterized the timing is checked in the build cycle, and warnings if a problem
manifests itself. But in ~ 8 years of use only once did I have to get involved with timing.

So in short I am not qualified to touch a FPGA in a professional sense and maximize
performance. Here you drag and drop the components (in PSOC lingo a component
is an onchip resource like a counter or timer or DSP or OpAmp...), wire them up with tool.
Dbl click it to set parameters, and then hit the build button. Each component comes with
its own API library, you just open its datasheet to look for f() call naming, and use that
in your code if you need to change settings under program control. Multiple wizards, like
a state machine wizard if you need it, a DMA wizard that generates setup code, filter wizard
for the DSP.......

I love the parts because its like a breadboard on a chip. I was never a fan of all the time it
took to go from idea to proto to eval, the proto aspect, because of mixed sig and digital
content, makes proto go rapidly. In fact I use chips capability many times to test itself, the
design I am doing.

The simple but capable boards feature two high end 5LP parts for the 5LP family, one used
to handle programming and debug, the other the target. $10. If you need full I/O count then
looking more like $ 25 type boards. When done with design you snap off programmer/debugger
portion. You can then use that in another design although its severely limited in I/O.

The mixed sig even has a precision Vref for the A/D (20 bit DelSig and 12 bit SAR), its .1%.

Ability to create custom components for your library. A whole community out there that has
done some, like 24 and 32 bit DDS, 74HC logic equivalents.... Creation can be schematic capture
and/or Verilog. I am a newbee to Verilog but the FPGA guys have huge IP libraries where you can
port to PSOC if HW is capable. Eg. it cannot to Ghz anything, like a lot of FPGA activity these days.
But stuff like extra capable shift registers, counters, state machines at "embedded" types of speed
relatively easy.

I have been doing embedded since 1972, and am not going back to those tools or parts, EVER !

A lot of fun. IDE and Compiler free.


Regards, Dana.

ronsimpson, it was done in Verilog, so not sure how it was synthesized. There
is a utility out there I would have to find again that converts V code back to
schematic elements such one can see how the carry was done. But this is not
a cascade of 8 bit counters, its straight V code.

PSOC has in its standard library 8/16/24/32 bit counters as well.


Regards, Dana.

ronsimpson said:

How are you doing carry from one 8-bit counter to the next?

Click to expand...

It looks like a single 64-bit counter (the Cntr64 block); the 8-bit blocks represent copying part of the count to RAM locations each clock cycle.

If the HDL uses the increment one-liner (i.e. reg <= reg + 1), then the carry will have to be counted and calculated in parallel (i.e. this will be a synchronous counter). Using cascaded asynchronous counters should use fewer resources (and allow a faster clock rate), but then you have to worry about when you read the rippling count.

Thats correct on status registers, the workaround to get the current cntr value
in byte form.

The verilog code looks like -



Regards, Dana.