Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Parallel/Sequential Parity Bit Generator for a Counter

IP.com Disclosure Number: IPCOM000043575D
Original Publication Date: 1984-Sep-01
Included in the Prior Art Database: 2005-Feb-05
Document File: 3 page(s) / 67K

Publishing Venue

IBM

Related People

D'Hervilly, G: AUTHOR [+2]

Abstract

The usual way to implement a parity bit generator, on a data bus, can be greatly improved in terms of area and/or delay, as the result can be predicted from the previous data bus value. In a very general manner, a truth table is built which defines whether the parity bit will change the next cycle time or not, depending on: - the present bus state, and - the forthcoming control bus state which will modify the present bus state. Hence, the parity bit computation can take place during the incrementation time itself. This method has been applied to an incrementing 8-bit counter: - The parity generator area-delay product is roughly divided by 2. - Last but not least, the parity generation does not impact the total cycle time.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 58% of the total text.

Page 1 of 3

Parallel/Sequential Parity Bit Generator for a Counter

The usual way to implement a parity bit generator, on a data bus, can be greatly improved in terms of area and/or delay, as the result can be predicted from the previous data bus value. In a very general manner, a truth table is built which defines whether the parity bit will change the next cycle time or not, depending on: - the present bus state, and - the forthcoming control bus state which will modify the

present bus state. Hence, the parity bit computation can take place during the incrementation time itself. This method has been applied to an incrementing 8-bit counter: - The parity generator area-delay product is roughly divided by 2.

- Last but not least, the parity generation does not

impact the total cycle time. In order to simplify the discussion, a realistic assumption is proposed, giving the following logic blocks a delay which is a multiple of the gate delay "D" (and an area which is a multiple of the 4-way AI area "A"): "D" "A" 0-4 WAY AI,OI 1 1

5-8 WAY AI,OI 1 2

XOR NOT 2 1

XOR 3 1 To illustrate the proposition, an 8-bit counter is proposed. The method herein described, in fact, matches any counter, with any number of bits. But, any piece of data is, usually, partitioned into 8-bit bytes, and a resulting parity bit is therefore added to each 8-bit byte. A counter is made of incrementing logic and registers where, to store the result with the hypothesis that cycle time is critical, a "carry-look-ahead" is required. This leads to an "incrementor with carry-look-ahead (ICL)" which dictates the counter cycle time for a given technology. The objective is to propose a parity bit generator which does not impact the counter cycle time, and which, therefore, makes the parity bit available at the same time when the incremented value is made available. Note that a typical delay time for the "ICL" is 3. "D".

Let's assume that it is computing (A', ..., H') from (A, ..., H) with: A' <- (-A = B.C.D.E.F.G.H B' <- (-B = C.D.E.F.G.H

C' <- (-C = D.E.F.G.H

D' <- (-D = E.F.G.H

E' <- (-E = F.G.H

F' <- (-F = G.H

G' <- (-G = H

H' <- (-H = 1 The usual way to implement a parity bit generator is to build a parity tree which generates the parity bit as soon as the data bus value is ready. For an 8-bit data bu...