Browse Prior Art Database

SRAM-Based Counters

IP.com Disclosure Number: IPCOM000108314D
Original Publication Date: 1992-May-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 7 page(s) / 239K

Publishing Venue

IBM

Related People

Fleek, AE: AUTHOR [+2]

Abstract

In a LAN environment, bridges and routers require many counters to track protocol timing and monitor statistics for all the attached ports. The implementation of register-based counters is inefficient space-wise. Another disadvantage manifests when the counts must be expanded due to conditions unforeseeable at the time of system implementation. This article describes a counter which minimizes the aforementioned problems.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 46% of the total text.

SRAM-Based Counters

       In a LAN environment, bridges and routers require many
counters to track protocol timing and monitor statistics for all the
attached ports.  The implementation of register-based counters is
inefficient space-wise.  Another disadvantage manifests when the
counts must be expanded due to conditions unforeseeable at the time
of system implementation.  This article describes a counter which
minimizes the aforementioned problems.

      The disclosed SRAM-based Counter utilizes the SRAM to store all
of the counts.  A bank of edge trigger flip-flops (CR-FF) is used to
latch the event count requests.  When enabled, the ONE AND ONLY LOGIC
(OAOL) and the SRAM COUNTER PROCESS UNIT (SCPU) arbitrate the count
requests and systematically process the counts one at a time until
all the tallies are completed.  The LOAD/COUNT UNIT (LCU) increments
the SRAM value and stores the new count in the original SRAM
location.  The SCPU resets the CR-FF as soon as its counting is
completed.  It takes two clock cycles to complete one count request
when multiple count requests are pending for services.  An Enable
Register is also implemented for selecting the counter size, enabling
the device and reporting the counter overflow status.  The SRAM is
memory mapped allowing quicker access.  The uP can access the SRAM
contents through memory-read and memory-write.  The Device Enable
will not affect the uP operations.  Fig. 1 is the SRAM-based counter
system block diagram.

      The following steps are examples of advance for the counter
number K.
1.   CNT #K request sets the Kth CR-FF.
2.   The Kth CR-FF output feeds the "ONE AND ONLY LOGIC" (OAOL) for
SRAM service arbitration.
3.   The OAOL grants the SRAM service to counter "K" request.
      1.   The "CNTsum" becomes active to feed the "SRAM COUNTER
PROCESS UNIT" (SCPU).
      2.   The counter address encoder releases the address pointer
to SRAM 3-STATE driver bus.
      3.   The "CNT's grant" becomes active to enable the SRAM
address 3-STATE driver.
4.   The SRAM 3-STATE driver activates the SRAM address bus (address
bits 0, 1 are from SCPU).
5.   The SCPU sends the "SCLK" to the OAOL to sample the count
requests.  If "CNTsum" is not active, repeat step 5.  If "CNTsum"
becomes active, go to step 6.
6.   The SCPU reads the SRAM data.
      1.   The SCPU generates the "SRAM OE" to provide the SRAM Kth
count value to the LCU.
      2.   The SCPU generates the "COUNT" to the LCU.
      3.   The SCPU generates the "SCPC" to reset the Kth CR-FF.
7.   The LCU increments the SRAM data and latches into the output
register.
8.   The SCPU writes the LCU output data into the SRAM during the
next clock cycle.
      1.   The SCPU issues "L/C OE" to the LCU, the LCU puts the data
onto the SRAM data bus.
      2.   The SCPU generates the SRAM WR, the incremented count is
restored to its original SRAM location.
9...