parity generator? in VHDL
Steven B.
4-bit generator? or some other even-bit generator?
Any help would be great.
Thanks,
-Steven
** you can send replies to this newgroup or to sbutts @ mailexcite.com
Q. Yang
Q. Yang
VhdlCohen
>
>4-bit generator? or some other even-bit generator?
>
package std_logic_misc:
function XOR_REDUCE(ARG: STD_LOGIC_VECTOR) return UX01;
----------------------------------------------------------
-- Ben Cohen, Raytheon Systems, (310) 334-7389 Vhdl...@aol.com
-- ** "VHDL Coding Styles and Methodologies, 2nd Edition", Ben Cohen,
-- ISBN 0-7923-8474-1 Kluwer Academic Publishers, 1999
-- ** "VHDL Answers to Frequently Asked Questions, 2nd Edition",
-- Ben Cohen, ISBN 0-7923-8115-7 Kluwer Academic Publishers, 1998
-- Web page: http://members.aol.com/vhdlcohen/vhdl
Em
> Anybody know how to code a parity generator in VHDL? Let's say for example a
> 4-bit generator? or some other even-bit generator?
>
> Any help would be great.
>
> Thanks,
>
> -Steven
>
> ** you can send replies to this newgroup or to sbutts @ mailexcite.com
Two alternative descriptions:
- one uses the well known parity chain. An alternative to this description
is a process that contains a FOR LOOP with the XOR operation.
- the second has a more behavioural view, it count the numbers
of ones.
Both result in the same logic (witjh my synthesis tool)
Regards,
Egbert Molenkamp
mole...@cs.utwente.nl
ENTITY parity1 IS
GENERIC (nbits : positive := 3);
PORT (d : IN bit_vector(nbits-1 DOWNTO 0);
odd : OUT bit;
even : OUT bit);
END parity1;
ARCHITECTURE xor_chain OF parity1 IS
SIGNAL chain : bit_vector (nbits DOWNTO 0);
BEGIN
chain(nbits) <= '0';
lbl:FOR i IN d'RANGE GENERATE
chain(i) <= chain(i+1) XOR d(i);
END GENERATE;
odd <= NOT chain(0);
even <= chain(0);
END xor_chain;
--OR--
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_arith.ALL;
ENTITY parity2 IS
GENERIC (nbits : positive := 3);
PORT (d : IN std_logic_vector(nbits-1 DOWNTO 0);
odd : OUT std_logic;
even : OUT std_logic);
END parity2;
ARCHITECTURE behaviour OF parity2 IS
BEGIN
PROCESS(d)
FUNCTION number_of_ones(inp : IN std_logic_vector) RETURN natural IS
VARIABLE nmb : natural; -- RANGE 0 TO inp'LENGTH;
BEGIN
nmb := 0;
FOR i IN inp'RANGE LOOP
IF inp(i)='1' THEN nmb:=nmb+1; END IF;
END LOOP;
RETURN nmb;
END number_of_ones;
BEGIN
IF (number_of_ones(d) REM 2)=0 THEN
odd <= '1';
even <= '0';
ELSE
odd <= '0';
even <= '1';
END IF;
END PROCESS;
END behaviour;
phil_j...@my-dejanews.com
synthesize. It may not matter as what you get may be fast enough. I tend to
build my own parity function using parenthases to specify how I want the XOR
gates structured. This way, I am more likely to get a balanced tree rather
than a long chain:
Good:
ODD_PARITY <= ( (A xor B) xor (C xor D) ) xor ( (E xor F) xor (G xor H) );
Not so good:
ODD_PARITY <= A xor B xor C xor D xor E xor F xor G xor H;
BTW, to get even parity, just add one, better yet, ODD_PARITY = EVEN_PARITY_N
(not). One more thing, if you have more info on the library of the part you
are targeting, you can better optimize the tree. For example, if your ASIC
library contained a 3 input XOR gate (some do) then build your tree based on
that: Eg. ODD_PARITY <= (A xor B xor C) xor (D xor E xor F);
Good Luck!
PJ
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Lasse Langwadt Christensen
>
> Be careful of using a loop or function call. You do not know how it will
> synthesize. It may not matter as what you get may be fast enough. I tend to
> build my own parity function using parenthases to specify how I want the XOR
> gates structured. This way, I am more likely to get a balanced tree rather
> than a long chain:
>
> Good:
> ODD_PARITY <= ( (A xor B) xor (C xor D) ) xor ( (E xor F) xor (G xor H) );
>
> Not so good:
> ODD_PARITY <= A xor B xor C xor D xor E xor F xor G xor H;
>
> BTW, to get even parity, just add one, better yet, ODD_PARITY = EVEN_PARITY_N
> (not). One more thing, if you have more info on the library of the part you
> are targeting, you can better optimize the tree. For example, if your ASIC
> library contained a 3 input XOR gate (some do) then build your tree based on
> that: Eg. ODD_PARITY <= (A xor B xor C) xor (D xor E xor F);
>
> Good Luck!
> PJ
Is it naive to think that the syntheziser will also figure this out?
I mean why should it make a chain if it can make a three, and I think
it should atleast be smart enough to know how to make large logic
functions
in 'chucks' that fit the technology
--L2C
--___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
Lasse Langwadt Christensen, MSEE (to be in 1999)
Aalborg University, Department of communication tech.
Applied Signal Processing and Implementation (ASPI)
http://www.kom.auc.dk/~fuz , mailto:lang...@ieee.org
phil_j...@my-dejanews.com
synthesize. It scores each solution and uses the "best" one. There is a
trade-off between area and speed. It typically uses the design that provides
the needed speed with the smallest area. However, for a parity function, a
tree and a chain both contain the same number of gates and nets, so which is
better. The tree is faster but if the chain meets your speed requirement, it
MAY be used instead of the tree.
What will the tool do in a given situation I can't say for sure. Not sure
anyone can. I can say that I have done parity checkers and generators and
Synopsys DID implement them as chains or poorly structured trees until I
added the parenthesis to tell it exactly what I wanted. Would what it
generated have worked? Yes, because it met the speed requirement (and all
other constraints). Is it what I wanted? No. So, I changed it.
Not trying to be difficult here, just trying to point out one of the
subtleties of synthesis.
PJ
In article <36DE3A99...@kom.auc.dk>,
-----------== Posted via Deja News, The Discussion Network ==----------
Em
phil_j...@my-dejanews.com wrote:
> Be careful of using a loop or function call. You do not know how it will
> synthesize. It may not matter as what you get may be fast enough. I tend to
> build my own parity function using parenthases to specify how I want the XOR
> gates structured. This way, I am more likely to get a balanced tree rather
> than a long chain:
>
> Good:
> ODD_PARITY <= ( (A xor B) xor (C xor D) ) xor ( (E xor F) xor (G xor H) );
>
> Not so good:
> ODD_PARITY <= A xor B xor C xor D xor E xor F xor G xor H;
>
-- If you like a balanced tree like structure AND the number if inputs should
still
-- be generic! you could use the following VHDL description.
-- It is synthesisable (at least with my synthesis tool).
--
-- The solution is NOT mine! (I don't remember the original author)
--
-- I only changed it a little to make it synthesiable. E.g. my synthesis tool
-- did not support an 'unconstrained' array in the port declaration, therefore
-- I added a GENERIC.
-- Original it was:
-- entity ParityTree is
-- port (Inputs: in Bit_Vector;
-- Output: out Bit);
-- end ParityTree;
-- I replaced it with:
-- entity ParityTree is
-- generic (nmb : integer);
-- port (Inputs: in Bit_Vector(1 TO nmb);
-- Output: out Bit);
-- end ParityTree;
--
-- Have FUN.
--
-- Egbert Molenkamp
-- mole...@cs.utwente.nl
--
--
--This example is the VHDL implementation of:
--
-- "To make an n-bit parity generator, take two n/2-bit parity generators
-- and connect their outputs with an xor gate. A one-bit parity generator
-- is a piece of wire."
entity ParityTree is
generic (nmb : integer);
port (Inputs: in Bit_Vector(1 TO nmb);
Output: out Bit);
end ParityTree;
architecture Recursive of ParityTree is
component ParityTree
generic (nmb : integer);
port (Inputs: in Bit_Vector (1 TO nmb);
Output: out Bit);
end component;
alias MyInput: Bit_Vector (1 TO Inputs'Length) IS Inputs;
signal LowerHalfParity: Bit;
signal UpperHalfParity: Bit;
signal lower : bit_vector(1 TO MyInput'Length/2);
signal upper : bit_vector(MyInput'Length/2 + 1 TO MyInput'Length);
begin
GeneralCase:
if MyInput'Length > 1 generate
lower <= MyInput(1 TO MyInput'Length/2);
upper <= MyInput(MyInput'Length/2 + 1 TO MyInput'Length);
LowerSubTree:
ParityTree
generic map (MyInput'Length/2)
port map (lower,
LowerHalfParity);
UpperSubTree:
ParityTree
generic map (MyInput'Length-MyInput'Length/2)
port map (upper,
UpperHalfParity);
PullItAllTogether:
Output <= LowerHalfParity xor UpperHalfParity;
end generate;
BaseCase:
if MyInput'Length = 1 generate
PassThrough:
Output <= MyInput(1);
end generate;
end Recursive;
ENTITY parity IS
PORT (inp : bit_vector(1 TO 9);
outp : OUT bit);
END parity;
ARCHITECTURE demo OF parity IS
component ParityTree
generic (nmb : integer);
port (Inputs: in Bit_Vector(1 TO nmb);
Output: out Bit);
end component;
BEGIN
r : ParityTree GENERIC MAP (inp'LENGTH) PORT MAP(inp,outp);
END demo;
Jamie Lokier
> What will the tool do in a given situation I can't say for sure. Not sure
> anyone can. I can say that I have done parity checkers and generators and
> Synopsys DID implement them as chains or poorly structured trees until I
> added the parenthesis to tell it exactly what I wanted. Would what it
> generated have worked? Yes, because it met the speed requirement (and all
> other constraints). Is it what I wanted? No. So, I changed it.
I'm curious. Why did you want precise control over the tree structure,
if Synopsys synthesised a working structure already?
Is it that you did not/could not enter the real constraints for your
application?
Curious,
-- Jamie
Jamie Lokier
> I'm curious. Why did you want precise control over the tree structure,
> if Synopsys synthesised a working structure already?
> Is it that you did not/could not enter the real constraints for your
> application?
I ask because I am interested in techniques for synthesis, and what
real-life designs require from it.
In my mind, adding parantheses wuold not guarantee control over the
synthesised tree structure: just as the tool may convert "a XOR b XOR c
XOR d" into any shape it likes, it has the freedom to implement anything
that is equivalent to "(a XOR b) XOR (c XOR d)". That is, it may
synthesise a chain from the latter equation, although it may be less
likely to find that as its _first_ solution.
-- Jamie
Richard Guerin
can it be generated serially ? The later approach can (if feasible)
can reduce the number of required XOR gates to one(1) .... attractive
for sythesizable applications (i.e. like a UART)