So, I have to create a generic N-bit adder with carry in and carry out.
I have made two fully working architectures so far, one using the generate function and one using the rtl description as follows:
entity:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity adder_n is
generic (N: integer:=8);
port (
a,b: in std_logic_vector(0 to N-1);
cin: in std_logic;
s: out std_logic_vector(0 to N-1);
cout: out std_logic);
end adder_n;
architectures 1 and 2:
--STRUCT
architecture struct of adder_n is
component f_adder
port (
a,b,cin: in std_logic;
s,cout: out std_logic);
end component;
signal c: std_logic_vector(0 to N);
begin
c(0)<=cin;
cout<=c(N);
adders: for k in 0 to N-1 generate
A1: f_adder port map(a(k),b(k),c(k),s(k),c(k+1));
end generate adders;
end struct;
--END STRUCT
architecture rtl of adder_n is
signal c: std_logic_vector(1 to N);
begin
s<=(a xor b) xor (cin&c(1 to N-1));
c<=((a or b) and (cin&c(1 to N-1))) or (a and b);
cout<=c(N);
end rtl;
Now, my problem is in the third architecture where I'm trying to infer the adder. Even though the following architecture I created compiles just fine, when I try to simulate it, I get a simulation error (on Modelsim), which I have attached at the end of this post.
I'm guessing there's something wrong with the numeric_std definitions. I am trying to avoid the arith library and I'm still trying to get used to the IEEE standard.
Any ideas are welcomed!! Thank you!
Inference arch:
--INFERENCE
architecture inference of adder_n is
signal tmp: std_logic_vector(0 to N);
signal atmp, btmp, ctmp, add_all : integer :=0;
signal cin_usgn: std_logic_vector(0 downto 0);
signal U: unsigned(0 to N);
begin
atmp <= to_integer(unsigned(a));
btmp <= to_integer(unsigned(b));
cin_usgn(0) <= cin;
ctmp <= to_integer(unsigned(cin_usgn));
add_all <= (atmp + btmp + ctmp);
U <= to_unsigned(add_all,N);
tmp <= std_logic_vector(U);
s <= tmp(0 to N-1);
cout <= tmp(N);
end inference;
-- END
Simulation error:
# Cannot continue because of fatal error.
# HDL call sequence:
# Stopped at C:/altera/14.1/modelsim_ase/test1_simon/adder_inference.vhd 58 Architecture inference
The length of U is N+1 (0 to N)
Changing
U <= to_unsigned(add_all,N);
To
U <= to_unsigned(add_all,N+1);
Will prevent a length mismatch between the left hand side and right hand side of the signal assignment in architecture inference of adder_n.
The passed parameter to to_unsigned specifies the length.
Related
I'm trying to write VHDL code for a 3 input simple adder. When I type the following code, S gets the correct output value but S1 gets zero, and hence add_out also gets the wrong value.
library ieee;
use ieee.std_logic_1164.all;
entity adder is
port( A,B : in std_logic_vector(3 downto 0);
C : in std_logic;
carry_out : out std_logic;
S : out std_logic_vector(3 downto 0);
addOut : out std_logic_vector(4 downto 0));
end adder;
architecture behavioral of adder is
signal S1 : std_logic_vector(3 downto 0);
begin
proc : process(A,B,C) is
variable carry : std_logic;
begin
carry := C;
for i in 0 to 3 loop
S(i) <= A(i) xor B(i) xor carry;
S1(i) <= A(i) xor B(i) xor carry;
carry := (A(i) and B(i)) or (B(i) and carry) or (A(i) and carry);
end loop;
carry_out <= carry;
addOut <= carry & S1;
end process proc;
end behavioral;
Why is the signal S1 not getting the same value as S?
S1 probably (almost certainly) DOES get the same value as S.
However you wouldn't expect to see that value of S1 on addOut, thanks to the mistake in the process sensitivity list. Study the semantics of signal assignment, (aka "postponed assignment") and delta cycles, and all will become clear. (My usual explanation on this topic, if you'll excuse some self publicity)
Specifically, you have a new value on S1, but no means to wake up the process again to propagate it to any other signal.
The best fix is probably to move the addOut and carryOut assignments outside the process, where they will immediately reflect any changes on their own inputs, and reduce the likelihood of sim/synth mismatches.
I am trying to be multiply the values in the line:
Q<= unsigned(reg_output) or (unsigned(multiplicand) and unsigned(shifted_lsb)*"0010");
note: I know multiplicand is a std_logic_vector, I did this for comparison via the if's.
Everytime I compile I get the error:
Illegal type conversion from ieee.std_logic_1164.STD_LOGIC to ieee.NUMERIC_STD.UNSIGNED (non-numeric to array).
here is my code below:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity shiftaddr is
port(
clk, clear : in std_logic;
multiplicand: in std_logic_vector(3 downto 0);
reg_output: in unsigned(7 downto 0);
shifted_lsb: in std_logic;
Q: out unsigned(7 downto 0) );
end shiftaddr;
architecture arch of shiftaddr is
signal temp: std_logic_vector(3 downto 0);
begin
shift: process(clk,clear,multiplicand, shifted_lsb,reg_output) --Define a process and state the inputs
begin
if (clk = '0') then
Q <= reg_output;
end if;
if (clk = '1') then
if (multiplicand(0) = '1') then Q <= (reg_output);
end if;
if (multiplicand(1) = '1') then
Q<= unsigned(reg_output) or (unsigned(multiplicand) and unsigned(shifted_lsb)*"0010");
end if;
end if;
end process;
end arch;
How do I go about fixing this? Thanks
The problem comes from:
unsigned(shifted_lsb)*"0010"
shifted_lsb is not a vector, you cannot convert it to unsigned which is a vector type. As suggested by Khanh N. Dang you could just test its value instead.
But your code is probably bogus: your sensitivity list is not that of a synchronous process while one of your signals is named clk. Moreover, if you want your process to be a synchronous one you will have a problem because you are using both states of the clock. You should probably:
indent your code so that we can read it without too much effort,
think hardware first: if you have a clear idea of the hardware you want (registers, adders, multiplexers...), coding usually becomes very easy,
read again the part of your text book about synchronous processes.
I'm learning VHDL from the root, and everything is OK except this. I found this from Internet. This is the code for a left shift register.
library ieee;
use ieee.std_logic_1164.all;
entity lsr_4 is
port(CLK, RESET, SI : in std_logic;
Q : out std_logic_vector(3 downto 0);
SO : out std_logic);
end lsr_4;
architecture sequential of lsr_4 is
signal shift : std_logic_vector(3 downto 0);
begin
process (RESET, CLK)
begin
if (RESET = '1') then
shift <= "0000";
elsif (CLK'event and (CLK = '1')) then
shift <= shift(2 downto 0) & SI;
end if;
end process;
Q <= shift;
SO <= shift(3);
end sequential;
My problem is the third line from bottom. My question is, why we need to pass the internal signal value to the output? Or in other words, what would be the problem if I write Q <= shift (2 downto 0) & SI?
In the case of the shown code, the Q output of the lsr_4 entity comes from a register (shift representing a register stage and being connected to Q). If you write the code as you proposed, the SI input is connected directly (i.e. combinationally) to the Q output. This can also work (assuming you leave the rest of the code in place), it will perform the same operation logically expect eliminate one clock cycle latency. However, it's (generally) considered good design practice to have an entity's output being registered in order to not introduce long "hidden" combinational paths which are not visible when not looking inside an entity. It usually makes designing easier and avoids running into timing problems.
First, this is just a shift register, so no combinational blocks should be inferred (except for input and output buffers, which are I/O related, not related to the circuit proper).
Second, the signal called "shift" can be eliminated altogether by specifying Q as "buffer" instead of "out" (this is needed because Q would appear on both sides of the expression; "buffer" has no side effects on the inferred circuit). A suggestion for your code follows.
Note: After compiling your code, check in the Netlist Viewers / Technology Map Viewer tool what was actually implemented.
library ieee;
use ieee.std_logic_1164.all;
entity generic_shift_register is
generic (
N: integer := 4);
port(
CLK, RESET, SI: in std_logic;
Q: buffer std_logic_vector(N-1 downto 0);
SO: out std_logic);
end entity;
architecture sequential of generic_shift_register is
begin
process (RESET, CLK)
begin
if (RESET = '1') then
Q <= (others => '0');
elsif rising_edge(CLK) then
Q <= Q(N-2 downto 0) & SI;
end if;
end process;
SO <= Q(N-1);
end architecture;
This is a VHDL code to count in sequence 1-2-3-4-6-7 but seems to count form 1-7
The code seems to have a logical error somewhere . Please help
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity newtest is
port(C, CLR : in std_logic;
Q : out std_logic_vector(2 downto 0));
end newtest;
architecture archi of newtest is
signal tmp: std_logic_vector(2 downto 0);
begin
process (C, CLR)
begin
if (CLR='1') then
tmp <= "000";
elsif (C'event and C='1') then
if (tmp="100") then
tmp <= tmp + 1;
end if;
tmp <= tmp + 1;
end if;
end process;
Q <= tmp;
end archi;
In a process with two sequential signal assignments to tmp not separated by time the later assignment will occur. A signal has a current value and a future value. Signal assignments are not updated until after the current simulation cycle. You've updated the future value before it could be assigned to the current value in the next simulation cycle with a clock C'event and C = '1'.
The following uses the numeric_std package instead of the Synopsys std_logic_unsigned package without changing the type of tmp, hence the type conversions to and from unsigned. I simply didn't want to divert my ieee library to contain something non-standard compliant. You can use std_logic_unsigned and remove the type conversions.
You could likewise declare signal tmp as unsigned (2 downto 0) and type convert it when assigning to Q (Q <= std_logic_vector(tmp);) or if possible make both Q and tmp unsigned.
library ieee;
use ieee.std_logic_1164.all;
--use ieee.std_logic_unsigned.all;
use ieee.numeric_std.all;
entity newtest is
port(C, CLR : in std_logic;
Q : out std_logic_vector(2 downto 0));
end newtest;
architecture archi of newtest is
signal tmp: std_logic_vector(2 downto 0);
begin
process (C, CLR)
begin
if (CLR='1') then
tmp <= "000";
elsif (C'event and C='1') then
if (tmp="100") then
tmp <= std_logic_vector (unsigned (tmp) + 2);
else
tmp <= std_logic_vector (unsigned (tmp) + 1);
end if;
end if;
end process;
Q <= tmp;
end archi;
Now there is only ever one assignment to tmp and it should go from "100" to "110". Someone is bound to point out tmp could be an unsigned instead of a std_logic_vector, or tmp could be an integer instead of either.
As far as synthesized hardware adding increment by 2 requires an additional term input for the two rightmost bits of tmp input
I'm trying to design a 32bit binary serial adder in VHDL, using a structural description. The adder should make use of a full adder and a d-latch. The way I see it is:
Full adder:
architecture Behavioral of FullAdder is
begin
s <= (x xor y) xor cin;
cout <= (x and y) or (y and cin) or (x and cin);
end Behavioral;
D-Latch:
architecture Behavioral of dLatch is
begin
state: process(clk)
begin
if(clk'event and clk = '1') then
q <= d;
end if;
end process;
end Behavioral;
Serial adder:
add: process ( clk )
variable count : integer range 0 to 31;
variable aux : STD_LOGIC;
variable aux2 : STD_LOGIC;
begin
if(clk'event and clk = '1') then
fa: FullAdder port map(x(count), y(count), aux, s(count), aux2);
dl: dLatch port map(clock, aux2, aux);
count := count + 1;
end if;
end process;
However, it doesn't seem to work.
Also, what would be the simplest way to pipeline the serial adder?
"It doesn't seem to work" is pretty general, but one problem I see is that you are trying to instantiate the component fa: FullAdder within a process. Think about what component instantiation means in hardware, and you will realize that it makes no sense to instantiate the module on the rising_edge of clk...
Move the instantiation out of the process, and it should at least remove the syntax error you should be seeing ("Illegal sequential statement." in ModelSim).
For pipelining the serial adder, the best way is to connect the adders and d flip-flops one after the other. So, you would have the cout of the first adder be the input of a flip-flop. The output of that flip-flop will be the cin of the next adder and so on. Be careful though, because you will also have to pipeline the s of each adder, as well as each bit of the input, by essentially putting several d flip-flops in a row to copy them through the various pipeline stages.