I have an adder block and I need to feed the output (std_logic_vector) back to one of the adder's input ports to be added with another number (This is to be done in another entity where the adder is used.). I tried to do that thru a process with sensitivity list but it did not work. Is there a way to do so?
Note: no clocks are used.
Here is my code:
library IEEE;
use IEEE.std_logic_1164.all;
entity example is
port (
X: IN std_logic_vector(15 downto 0);
Y: IN std_logic_vector(15 downto 0);
Z: OUT std_logic_vector(15 downto 0)
);
end example;
architecture arch_example of example is
component adder is
port(a: in std_logic_vector(15 downto 0);
b: in std_logic_vector(15 downto 0);
cin: in std_logic;
s: out std_logic_vector(15 downto 0);
overflow: out std_logic);
end component;
signal s, ain, bin: std_logic_vector(15 downto 0);
signal cin, overflow, useless: std_logic;
begin
process(x, y) is
begin
ain <= x;
bin <= y;
cin <= '0';
end process;
process(s, overflow) is
begin
ain <= s;
bin <= "1111111110000001";
cin <= overflow;
end process;
U1: adder port map (ain, bin, cin, s, overflow);
z <= s;
end arch_example;
In your code, you have multiple drivers for the signals ain, bin, and cin because two processes are driving these signals at the same time. You can think of it as two gates driving the same wire.
To add another number to an intermediate result in a fully combinational design, you will need a second adder. The first adder cannot be re-used because you cannot easily tell, when to switch to the new inputs with multiplexers for example. (It will be possible with the concepts of asynchronous logic, but that is much more complex.)
A simple solution is to instantiate your adder component twice:
architecture arch_example of example is
component adder is
port(a: in std_logic_vector(15 downto 0);
b: in std_logic_vector(15 downto 0);
cin: in std_logic;
s: out std_logic_vector(15 downto 0);
overflow: out std_logic);
end component;
signal s : std_logic_vector(15 downto 0);
signal overflow : std_logic;
begin
U1: adder port map (x, y, '0', s, overflow);
U2: adder port map (s, "1111111110000001", overflow, z, open);
end arch_example;
The code snippet above uses positional assignment of component ports. This should be avoided because one can easily mixup the order of the ports. I recommend to use named assignments instead. Here one can explictly see which port (on the left of =>) is assigned to which signal (on the right):
architecture arch_example of example is
component adder is
port(a: in std_logic_vector(15 downto 0);
b: in std_logic_vector(15 downto 0);
cin: in std_logic;
s: out std_logic_vector(15 downto 0);
overflow: out std_logic);
end component;
signal s : std_logic_vector(15 downto 0);
signal overflow : std_logic;
begin
U1: adder port map (
a => x,
b => y,
cin => '0',
s => s,
overflow => overflow);
U2: adder port map (
a => s,
b => "1111111110000001",
cin => overflow,
s => z,
overflow => open);
end arch_example;
Related
I'm trying to do a circuit consisting of a 2 to 1 multiplexer (8-bit buses), an 8-bit register and an 8-bit adder. These components are all tested and work as expected.
The thing is: if I try to send the output of the Adder to one of the inputs of the
multiplexer (as seen in the image by the discontinued line), the simulation will stop rather suddenly. If I don't do that and just let ain do its thing, everything will run just as it should, but I do need the output of the adder to be the one inputted to the multiplexer.
The simulation is the following:
The code is:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity Sumitas is
port (m : in STD_LOGIC;
clk : in STD_LOGIC;
ain : in STD_LOGIC_VECTOR (7 downto 0);
Add : out STD_LOGIC_VECTOR (7 downto 0));
end Sumitas;
architecture rtl of Sumitas is
component Adder8bit
port (a, b : in STD_LOGIC_VECTOR (7 downto 0);
Cin : in STD_LOGIC;
S : out STD_LOGIC_VECTOR (7 downto 0);
Cout : out STD_LOGIC);
end component;
component GenericReg
generic (DataWidth : integer := 8);
port (en : in STD_LOGIC;
dataIn : in STD_LOGIC_VECTOR (DataWidth - 1 downto 0);
dataOut : out STD_LOGIC_VECTOR (DataWidth - 1 downto 0));
end component;
component GenericMux2_1
generic (DataWidth : integer := 8);
port (a, b : in STD_LOGIC_VECTOR (DataWidth - 1 downto 0);
Z : in STD_LOGIC;
S : out STD_LOGIC_VECTOR (DataWidth - 1 downto 0));
end component;
constant DW : integer := 8;
signal AddOut_s, MuxOut_s : STD_LOGIC_VECTOR (7 downto 0);
signal PCOut_s : STD_LOGIC_VECTOR (7 downto 0);
begin
m0 : GenericMux2_1
generic map (DataWidth => DW)
port map (a => "00000000",
b => AddOut_s,
Z => m,
S => MuxOut_s);
PC : GenericReg
generic map (DataWidth => DW)
port map (en => clk,
dataIn => MuxOut_s,
dataOut => PCOut_s);
Add0 : Adder8bit
port map (a => "00000001",
b => PCOut_s,
Cin => '0',
S => AddOut_s,
Cout => open);
Add <= AddOut_s;
end rtl;
and the testbench:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
entity bm_Sumitas is
end bm_Sumitas;
architecture benchmark of bm_Sumitas is
component Sumitas
port (m : in STD_LOGIC;
clk : in STD_LOGIC;
ain : in STD_LOGIC_VECTOR (7 downto 0);
Add : out STD_LOGIC_VECTOR (7 downto 0));
end component;
signal clk_s, m_s : STD_LOGIC;
signal Add_s, ain_s : STD_LOGIC_VECTOR (7 downto 0);
constant T : time := 2 ns;
begin
benchmark : Sumitas
port map (m => m_s,
clk => clk_s,
ain => ain_s,
Add => Add_s);
clk_proc: process
begin
clk_s <= '0';
wait for T/2;
clk_s <= '1';
wait for T/2;
end process;
bm_proc : process
begin
m_s <= '0';
wait for 10 ns;
m_s <= '1';
wait for 100 ns;
end process;
ains_proc : process
begin
ain_s <= "00001111";
for I in 0 to 250 loop
ain_s <= STD_LOGIC_VECTOR(TO_UNSIGNED(I, ain_s'length));
wait for T;
end loop;
end process;
end benchmark;
How can I do the thing I want? I'm ultimately trying to simulate a computer I designed. I have every component already designed and I'm coupling them together.
Constructing a Minimal, Complete, and Verifiable example requires filling in the missing components:
library ieee;
use ieee.std_logic_1164.all;
entity Adder8bit is
port (a, b : in STD_LOGIC_VECTOR (7 downto 0);
Cin : in STD_LOGIC;
S : out STD_LOGIC_VECTOR (7 downto 0);
Cout : out STD_LOGIC);
end entity;
architecture foo of adder8bit is
signal sum: std_logic_vector (9 downto 0);
use ieee.numeric_std.all;
begin
sum <= std_logic_vector ( unsigned ('0' & a & cin) +
unsigned ('0' & b & cin ));
s <= sum(8 downto 1);
cout <= sum(9);
end architecture;
library ieee;
use ieee.std_logic_1164.all;
entity GenericReg is
generic (DataWidth : integer := 8);
port (en : in STD_LOGIC;
dataIn : in STD_LOGIC_VECTOR (DataWidth - 1 downto 0);
dataOut : out STD_LOGIC_VECTOR (DataWidth - 1 downto 0));
end entity;
architecture fum of genericreg is
begin
dataout <= datain when en = '1';
end architecture;
with behavioral model substitutes.
(It's not that much work, copy the component declarations paste them, substitute entity for component and add the reserved word is, followed by simple behaviors in architectures.)
It reproduces the symptom you displayed in your simulation waveform:
You can see the essential point of failure occurs when the register enable (ms_s) goes high.
The simulator will report operation on it's STD_OUTPUT:
%: make wave
/usr/local/bin/ghdl -a bm_sumitas.vhdl
/usr/local/bin/ghdl -e bm_sumitas
/usr/local/bin/ghdl -r bm_sumitas --wave=bm_sumitas.ghw --stop-time=40ns
./bm_sumitas:info: simulation stopped #11ns by --stop-delta=5000
/usr/bin/open bm_sumitas.gtkw
%:
Note the simulation stopped at 11 ns because of a process executing repeatedly in delta cycles (simulation time doesn't advance).
This is caused by a gated relaxation oscillator formed by the enabled latch, delay (a delta cycle) and having at least one element of latch input inverting each delta cycle.
The particular simulator used has a delta cycle limitation, which will quit simulation when 5,000 delta cycles occur without simulation time advancing.
The genericreg kept generating events with no time delay in assignment, without an after clause in the waveform, after 0 fs (resolution limit) is assumed.
Essentially when the enable is true the signal will have at least one element change every simulation cycle due to the increment, and assigns the signal a new value for at least one element each simulation cycle without allowing the advancement of simulation time by not going quiescent.
You could note the simulator you used should have produced a 'console' output with a similar message if it were capable (and enabled).
So how it this problem cured? The easiest way is to use a register (not latch) sensitive to a clock edge:
architecture foo of genericreg is
begin
dataout <= datain when rising_edge(en);
end architecture;
Which gives us the full simulation:
I was implementing a multiplexer, but and gate returning "x" for no reason, pls help.
As you can see in screenshot, result just became "x" from "1".
i did a testbench for and gate, it works fine on its own.
It should have been a 3 bit 4:1 multiplexer.
this is the problem
This is source, i am using ghdl.
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
ENTITY mux41 IS
PORT (
i1 : IN std_logic_vector(2 DOWNTO 0);
i2 : IN std_logic_vector(2 DOWNTO 0);
i3 : IN std_logic_vector(2 DOWNTO 0);
i4 : IN std_logic_vector(2 DOWNTO 0);
sel : IN std_logic_vector(1 DOWNTO 0);
y : OUT std_logic_vector(2 DOWNTO 0)
);
END mux41;
ARCHITECTURE rtl OF mux41 IS
COMPONENT andgate
PORT (
input1 : IN std_logic;
input2 : IN std_logic;
input3 : IN std_logic;
and_output : OUT std_logic
);
END COMPONENT;
COMPONENT orgate
PORT (
input1 : IN std_logic;
input2 : IN std_logic;
input3 : IN std_logic;
input4 : IN std_logic;
or_output : OUT std_logic
);
END COMPONENT;
signal not_sel : std_logic_vector(1 DOWNTO 0);
signal and_result : std_logic_vector(3 DOWNTO 0);
signal or_result : std_logic_vector(2 DOWNTO 0);
BEGIN
not_sel <= not sel;
and_gate_assignment : for i in 0 to 2 generate
and_output1: andgate port map(input1=>i1(i), input2=>not_sel(1), input3=>not_sel(0), and_output=>and_result(0));
and_output2: andgate port map(input1=>i2(i), input2=>not_sel(1), input3=>sel(0), and_output=>and_result(1));
and_output3: andgate port map(input1=>i3(i), input2=>sel(1), input3=>not_sel(0), and_output=>and_result(2));
and_output4: andgate port map(input1=>i4(i), input2=>sel(1), input3=>sel(0), and_output=>and_result(3));
or_output: orgate port map(input1=>and_result(0), input2=>and_result(1), input3=>and_result(2), input4=>and_result(3), or_output=>or_result(i));
end generate and_gate_assignment;
y <= or_result;
END rtl;
Here is the and gate;
library ieee;
use ieee.std_logic_1164.all;
entity andgate is
port (
input1 : in std_logic;
input2 : in std_logic;
input3 : in std_logic;
and_output : out std_logic
);
end andgate;
architecture rtl of andgate is
signal and1 : std_logic;
signal and2 : std_logic;
begin
and1 <= input1 and input2;
and2 <= and1 and input3;
and_output <= and2;
end rtl;
there is not much to this really, could this be a timing issue?
Adding orgate's entity and architecture
use ieee.std_logic_1164.all;
entity orgate is
port (
input1: in std_logic;
input2: in std_logic;
input3: in std_logic;
input4: in std_logic;
or_output: out std_logic
);
end entity;
architecture foo of orgate is
begin
or_output <= input1 or input2 or input3 or input4;
end architecture;
and a testbench
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity mux41_tb is
end entity;
architecture foo of mux41_tb is
signal i1: std_logic_vector(2 downto 0);
signal i2: std_logic_vector(2 downto 0);
signal i3: std_logic_vector(2 downto 0);
signal i4: std_logic_vector(2 downto 0);
signal sel: std_logic_vector(1 downto 0);
signal y: std_logic_vector(2 downto 0);
begin
DUT:
entity work.mux41
port map (
i1 => i1,
i2 => i2,
i3 => i3,
i4 => i4,
sel => sel,
y => y
);
STIMULI:
process
begin
for i in 0 to 7 loop
i1 <= std_logic_vector(to_unsigned(i, 3));
for j in 0 to 7 loop
i2 <= std_logic_vector(to_unsigned(j, 3));
for k in 0 to 7 loop
i3 <= std_logic_vector(to_unsigned(k, 3));
for m in 0 to 7 loop
i4 <= std_logic_vector(to_unsigned(m, 3));
for n in 0 to 3 loop
sel <= std_logic_vector(to_unsigned(n,2));
wait for 10 ns;
end loop;
end loop;
end loop;
end loop;
end loop;
wait;
end process;
end architecture;
allows you readers to replicate your problem.
Adding more signals may help to understand the problem:
'X's come from driver conflict. Here there are multiple drivers connected to and_result(3 downto 0) across the generated blocks. When all the drivers are '0' the signal is resolved to '0'. When there is a conflict there's an 'X'.
The solution is to move the and_result declaration to the generate statement block declarative region (with a following begin separating declarations from statements):
signal not_sel : std_logic_vector(1 DOWNTO 0);
-- signal and_result : std_logic_vector(3 DOWNTO 0); -- MOVE FROM HERE
signal or_result : std_logic_vector(2 DOWNTO 0);
BEGIN
not_sel <= not sel;
and_gate_assignment : for i in 0 to 2 generate
signal and_result : std_logic_vector(3 DOWNTO 0); -- TO HERE
BEGIN -- AND ADD A FOLLOWING BEGIN
and_output1: andgate port map(input1=>i1(i), input2=>not_sel(1), input3=>not_sel(0), and_output=>and_result(0));
And that gives you
the intended result.
The generate statement represents zero or more block statements in elaboration. Here each of the three block statement contains a 4 to 1 multiplexer for a std_logic element of a slice.
An individual multiplexer has signal nets connecting the output of each of four andgate instantiations to an orgate instantiation. By relying on a common declaration for and_result you've shorted the andgate outputs together across all three blocks.
Moving the and_result declaration into the generate statement block declarative region results in it being replicated for each generated block statement. Because a block statement is a declarative region those three declarations of and_result aren't visible outside each generated block due to scope and visibility rules which match them being local to each block in a hierarchical block diagram - the three and_result elements are no longer connected to all three blocks. This eliminates multiple drivers.
i have created the structural and the behavioral code for a 1-bit ALU,as well as a control circuit .The control circuit decides the operation that will be conducted between two variables : a,b .
Here is my behavioral part of the code :
library ieee;
use ieee.std_logic_1164.all;
package erotima2 is
-- AND2 declaration
component myAND2
port (outnotA,outnotB: in std_logic; outAND: out std_logic);
end component;
-- OR2 declaration
component myOR2
port (outnotA,outnotB: in std_logic; outOR: out std_logic);
end component;
-- XOR2 declaration
component myXOR2
port (outnotA,outnotB: in std_logic; outXOR: out std_logic);
end component;
--fulladder declaration
component fulladder
port(CarryIn,outnotA,outnotB: in std_logic; sum,CarryOut: out std_logic);
end component;
--Ainvert declaration
component notA
port(a: in std_logic; signala: std_logic_vector(0 downto 0); outnotA: out std_logic);
end component;
--Binvert declaration
component notB
port(b: in std_logic; signalb: std_logic_vector(0 downto 0); outnotB: out std_logic);
end component;
--ControlCircuit declaration--
component ControlCircuit
port (
opcode : in std_logic_vector (2 downto 0);
signala,signalb : out std_logic_vector(0 downto 0);
operation : out std_logic_vector (1 downto 0);
CarryIn: out std_logic);
end component;
--mux4to1 declaration
component mux4to1
port(outAND, outOR, sum, outXOR: in std_logic; operation: in std_logic_vector(1 downto 0); Result: out std_logic);
end component;
end package erotima2;
--2 input AND gate
library ieee;
use ieee.std_logic_1164.all;
entity myAND2 is
port (outnotA,outnotB: in std_logic; outAND: out std_logic);
end myAND2;
architecture model_conc of myAND2 is
begin
outAND<= outnotA and outnotB;
end model_conc;
-- 2 input OR gate
library ieee;
use ieee.std_logic_1164.all;
entity myOR2 is
port (outnotA,outnotB: in std_logic; outOR: out std_logic);
end myOR2;
architecture model_conc2 of myOR2 is
begin
outOR <= outnotA or outnotB;
end model_conc2;
--2 input XOR gate
library ieee;
use ieee.std_logic_1164.all;
entity myXOR2 is
port(outnotA,outnotB: in std_logic; outXOR: out std_logic);
end myXOR2;
architecture model_conc3 of myXOR2 is
begin
outXOR <= outnotA xor outnotB;
end model_conc3;
--3 input full adder
library ieee;
use ieee.std_logic_1164.all;
entity fulladder is
port(CarryIn,outnotA,outnotB: in std_logic; sum,CarryOut: out std_logic);
end fulladder;
architecture model_conc4 of fulladder is
begin
CarryOut <= (outnotB and CarryIn) or (outnotA and CarryIn) or (outnotA and outnotB);
sum <= (outnotA and not outnotB and not CarryIn) or (not outnotA and outnotB and not CarryIn) or (not outnotA and not outnotB and CarryIn) or (outnotA and outnotB and CarryIn);
end model_conc4;
--1 input notA
library ieee;
use ieee.std_logic_1164.all;
entity notA is
port(a: in std_logic; signala:std_logic_vector(0 downto 0); outnotA: out std_logic);
end notA;
architecture model_conc6 of notA is
begin
with signala select
outnotA <= a when "0",
not a when others;
end model_conc6;
--1 input notB
library ieee;
use ieee.std_logic_1164.all;
entity notB is
port(b: in std_logic; signalb: std_logic_vector(0 downto 0); outnotB: out std_logic);
end notB;
architecture model_conc5 of notB is
begin
with signalb select
outnotB <= b when "0",
not b when others;
end model_conc5;
--4 input MUX
library ieee;
use ieee.std_logic_1164.all;
entity mux4to1 is
port(outAND, outOR, sum, outXOR: in std_logic; operation: in std_logic_vector(1 downto 0); Result: out std_logic);
end mux4to1;
architecture model_conc7 of mux4to1 is
begin
with operation select
Result<= outAND when "00",
outOR when "01",
sum when "10",
outXOR when OTHERS;
end model_conc7 ;
The behavioral part defines the logic gates of AND,OR,XOR, a full adder for numerical addition and substraction. It also contains a 4-to-1 multiplexer that chooses (depending on the value of the "operation" variable) which operation the alu will do. Lastly there is a function that inverts the variables in order to be more efficient with our logic gate usage( using the DeMorgan theorem so we don't have to create a NOR gate). The control unit initializes the variable inputs, as well as the carryIn variable of the full adder, depending on the variable "opcode". A board with every possible combination
Next is the Control Circuit part of the code, which implements the previous board.
`
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity ControlCircuit is
port (
opcode :in std_logic_vector (2 downto 0);
signala, signalb : out std_logic_vector(0 downto 0);
operation : out std_logic_vector(1 downto 0);
CarryIn : out std_logic);
end ControlCircuit;
architecture model_conc9 of ControlCircuit is
--signal outAND,outOR,outXOR,sum,outnotA,outnotB : std_logic;
--signal operation : out std_logic_vector(1 downto 0);
begin
process(opcode)
begin
case opcode is
--AND--
when "000"=>
operation <= "00";
signala <= "0";
signalb <= "0";
CarryIn <= '0';
--OR--
when "001" =>
operation <= "01";
signala <= "0";
signalb <= "0";
CarryIn <= '0';
--ADD--
when "011" =>
operation <= "10";
signala <= "0";
signalb <= "0";
CarryIn <= '0';
--SUB--
when "010" =>
operation <= "10";
signala <= "0";
signalb <="1";
CarryIn <= '1';
--NOR--
when "101"=>
operation <= "00";
signala <= "1";
signalb <= "1";
CarryIn <= '0';
--xor
when "100" =>
operation <= "11";
signala <= "0";
signalb <= "0";
CarryIn <= '0';
--Adiafores times--
when others =>
operation <= "00";
signala <= "0";
signalb <= "0";
CarryIn <= '0';
end case;
end process;
end model_conc9;
`
Lastly here is the code that uses all the previous parts and and an RTL diagram that shows the code's result
library IEEE;
use ieee.std_logic_1164.all;
use work.erotima2.all;
entity structural is
port (a,b: in std_logic;
opcode : in std_logic_vector ( 2 downto 0);
Result,CarryOut : out std_logic);
end structural;
architecture alu of structural is
signal outAND,outOR,outXOR,sum,outnotA,outnotB,CarryIn : std_logic;
signal signala,signalb : std_logic_vector (0 downto 0);
signal operation : std_logic_vector (1 downto 0);
begin
u0 : myAND2 port map (outnotA,outnotB,outAND);
u1 : myOR2 port map (outnotA,outnotB,outOR);
u2 : myXOR2 port map (outnotA,outnotB,outXOR);
u3 : fulladder port map (CarryIn,outnotA,outnotB,sum,CarryOut);
u4 : notA port map (a,signala,outnotA);
u5 : notB port map (b,signalb,outnotB);
u6 : mux4to1 port map (outAND, outOR,sum, outXOR, operation, Result );
u8 : ControlCircuit port map(opcode,signala,signalb,operation,CarryIn);
end alu;
Now for the tough part, i need to use the 1-bit ALU 16 times as a component, to create a 16-bit ALU. It is important to keep the control circuit independent from the rest of the code. I have tried using an std_logic_vector ( 15 downto 0) but it did not work and i would like to use the previous code segments as a component. Can anyone give any tips or ideas that will help connect 16 1-bit ALUs to a complete 16-bit ALU? Thanks in advance for those who read this massive wall of text.
Your recent comment
Yes i understand that my code is weird but we were intsructed to invert the inputs according to this diagram . As for the duplicate post, i checked before posting and they were implemented only structurally, while in my case i need to write the behavioral part too.
Explains the issue, misspellings aside. You'll notice your architecture structural of entity structural doesn't match the signals shown on the above 1 bit alu diagram which doesn't contain an instantiated ControlCircuit.
If you were to provide a design unit that matched the above diagram you can hook up the 1 bit alu carry chain while deriving the carryin for the lsb from the control block which provides a + 1 and inversion for subtraction:
library ieee;
use ieee.std_logic_1164.all;
entity alu_16_bit is
port (
a: in std_logic_vector (15 downto 0);
b: in std_logic_vector (15 downto 0);
opcode: in std_logic_vector (2 downto 0);
result: out std_logic_vector (15 downto 0);
carryout: out std_logic
);
end entity;
architecture foo of alu_16_bit is
component alu_1_bit is
port (
a: in std_logic;
b: in std_logic;
ainvert: in std_logic;
binvert: in std_logic;
carryin: in std_logic;
operation: in std_logic_vector (1 downto 0);
result: out std_logic;
carryout: out std_logic
);
end component;
component controlcircuit is
port (
opcode: in std_logic_vector(2 downto 0);
ainvert: out std_logic;
binvert: out std_logic;
operation: out std_logic_vector(1 downto 0);
carryin: out std_logic -- invert a or b, add + 1 for subtract
);
end component;
signal ainvert: std_logic;
signal binvert: std_logic;
signal operation: std_logic_vector (1 downto 0);
signal carry: std_logic_vector (16 downto 0);
begin
CONTROL_CIRCUIT:
controlcircuit
port map (
opcode => opcode,
ainvert => ainvert,
binvert => binvert,
operation => operation,
carryin => carry(0) -- for + 1 durring subtract
);
GEN_ALU:
for i in 0 to 15 generate
ALU:
alu_1_bit
port map (
a => a(i),
b => b(i),
ainvert => ainvert,
binvert => binvert,
carryin => carry(i),
operation => operation,
result => result(i),
carryout => carry(i + 1)
);
end generate;
carryout <= carry(16) when operation = "10" else '0';
end architecture;
This represents moving ControlCircuit out of structural - only one copy is needed, renaming structural alu_1_bit and making the ports match.
There's a new top level alu_16_bit containing a single instance of ControlCircuit along with sixteen instances of alu_1_bit elaborated from the generate statement using the generate parameter i to index into arrays values for connections.
This design has been behaviorally implemented independently using the Opcode table you provided the link to:
as well as an independent fulladder used in alu_1_bit and appears functional.
This implies your design units haven't been validated.
I'm writing something in VHDL about an essay and I'm facing a strange situation. I've written some components, simulated and tested them, and everything seems to works fine. However, when simulating the top entity, I'm getting zeros as a result! Please take a look at the following listings:
Top Entity:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity foobar is
port ( data_i : in std_logic_vector(39 downto 0);
sum_12bit_o : out std_logic_vector(11 downto 0)
);
end foobar;
architecture Behavioral of foobar is
--Declare components
component four_10bit_word_adder is
port( --Input signals
a_byte_in: in std_logic_vector(9 downto 0);
b_byte_in: in std_logic_vector(9 downto 0);
c_byte_in: in std_logic_vector(9 downto 0);
d_byte_in: in std_logic_vector(9 downto 0);
cin: in std_logic;
--Output signals
val12bit_out: out std_logic_vector(11 downto 0)
);
end component;
-- Signal declaration
signal int: std_logic_vector(11 downto 0);
signal intdata: std_logic_vector(39 downto 0);
begin
intdata <= data_i; --DEBUG
U1: four_10bit_word_adder port map (intdata(39 downto 30), intdata(29 downto 20),
intdata(19 downto 10), intdata(9 downto 0),
'0', int);
end Behavioral;
four_10bit_word_adder:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity four_10bit_word_adder is
generic (
bits: integer := 10
);
port( --Input signals
a_byte_in: in std_logic_vector(bits-1 downto 0);
b_byte_in: in std_logic_vector(bits-1 downto 0);
c_byte_in: in std_logic_vector(bits-1 downto 0);
d_byte_in: in std_logic_vector(bits-1 downto 0);
cin: in std_logic;
--Output signals
val12bit_out: out std_logic_vector(bits+1 downto 0)
);
end four_10bit_word_adder;
architecture Behavioral of four_10bit_word_adder is
-- Component Declaration
component compressor_4_2 is
port(a,b,c,d,cin : in std_logic;
cout, sum, carry : out std_logic
);
end component;
--------------------------------------------------------+
component generic_11bit_adder
port (
A: in std_logic_vector(10 downto 0); --Input A
B: in std_logic_vector(10 downto 0); --Input B
CI: in std_logic; --Carry in
O: out std_logic_vector(10 downto 0); --Sum
CO: out std_logic --Carry Out
);
end component;
--------------------------------------------------------+
-- Declare internal signals
signal int: std_logic_vector(bits-1 downto 0); -- int(8) is the final Cout signal
signal byte_out: std_logic_vector(bits-1 downto 0);
signal carry: std_logic_vector(bits-1 downto 0);
signal int11bit: std_logic_vector(bits downto 0);
-- The following signals are necessary to produce concatenated inputs for the 10-bit adder.
-- See the paper for more info.
signal Concat_A: std_logic_vector(bits downto 0);
signal Concat_B: std_logic_vector(bits downto 0);
signal co : std_logic;
begin
A0: compressor_4_2 port map (a_byte_in(0), b_byte_in(0),
c_byte_in(0), d_byte_in(0),
'0', int(0), byte_out(0), carry(0));
instances: for i in 1 to bits-1 generate
A: compressor_4_2 port map (a_byte_in(i), b_byte_in(i),
c_byte_in(i), d_byte_in(i), int(i-1),
int(i), byte_out(i), carry(i));
end generate;
R9: generic_11bit_adder port map (Concat_A, Concat_B, '0', int11bit, co);
Concat_A <= int(8) & byte_out;
Concat_B <= carry & '0';
process (co)
begin
if (co = '1') then
val12bit_out <= '1' & int11bit;
else
val12bit_out <= '0' & int11bit;
end if;
end process;
end Behavioral;
4:2 Compressor
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity compressor_4_2 is
port(a,b,c,d,cin : in std_logic;
cout, sum, carry : out std_logic
);
end compressor_4_2;
architecture Behavioral of compressor_4_2 is
-- Internal Signal Definitions
signal stage_1: std_logic;
begin
stage_1 <= d XOR (b XOR c);
cout <= NOT((b NAND c) AND (b NAND d) AND (c NAND d));
sum <= (a XOR cin) XOR stage_1;
carry <= NOT((a NAND cin) AND (stage_1 NAND cin) AND (a NAND stage_1));
end Behavioral;
Generic 11-bit Adder:
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
entity generic_11bit_adder is
generic (
bits: integer := 11
);
port (
A: in std_logic_vector(bits-1 downto 0);
B: in std_logic_vector(bits-1 downto 0);
CI: in std_logic;
O: out std_logic_vector(bits-1 downto 0);
CO: out std_logic
);
end entity generic_11bit_adder;
architecture Behavioral of generic_11bit_adder is
begin
process(A,B,CI)
variable sum: integer;
-- Note: we have one bit more to store carry out value.
variable sum_vector: std_logic_vector(bits downto 0);
begin
-- Compute our integral sum, by converting all operands into integers.
sum := conv_integer(A) + conv_integer(B) + conv_integer(CI);
-- Now, convert back the integral sum into a std_logic_vector, of size bits+1
sum_vector := conv_std_logic_vector(sum, bits+1);
-- Assign outputs
O <= sum_vector(bits-1 downto 0);
CO <= sum_vector(bits); -- Carry is the most significant bit
end process;
end Behavioral;
I've tried a ton of things, but without any success. Do you have any idea what am I doing wrong? Sorry for the long question and thank you for your time.
Take a look at your process to generate val12bit_out in your four_10bit_word_adder entity. It's missing an input.
Also, there are several other issues. Fixing this one issue will not fix everything. But once you fix it, I think things will be a lot more clear.
Last day, last 3 hours before we give the project and we just realized we have this error!
I am not very good in vhdl so I can't understand what the problem is!
Error (10588): VHDL Generic Map Aspect error at addsub16.vhd(31): too many actuals for block "fulladder16" with only 0 formals
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY addsub16 IS
PORT(X, Y :IN STD_LOGIC_VECTOR(15 DOWNTO 0);
Add_Sub :IN STD_LOGIC;
Result :OUT STD_LOGIC_VECTOR(15 DOWNTO 0);
Cout :OUT STD_LOGIC;
Overflow :OUT STD_LOGIC);
END addsub16;
ARCHITECTURE Structure OF addsub16 IS
COMPONENT fulladder16
PORT(Cin :IN STD_LOGIC;
X, Y :IN STD_LOGIC_VECTOR(15 DOWNTO 0);
Sum :OUT STD_LOGIC_VECTOR(15 DOWNTO 0);
Cout :OUT STD_LOGIC;
Overflow :OUT STD_LOGIC);
END COMPONENT;
SIGNAL y_mod :STD_LOGIC_VECTOR(15 DOWNTO 0);
BEGIN
gen_XOR:
FOR i IN 0 TO 15 GENERATE
y_mod(i) <= Y(i) XOR Add_Sub;
END GENERATE;
adder:fulladder16 GENERIC MAP(16)
PORT MAP(Add_Sub, X, y_mod, Result, Cout, Overflow);
END Structure;
The problem is the line:
adder:fulladder16 GENERIC MAP(16)
The "formal" is a port, generic, etc. declared in the prototype for a component (or whatever). The "actual" is what's mapped to it.
You are mapping 1 actual value to a component (fulladder16) whose declaration (just above that in your code) shows 0 formal generics.