VHDL output is undifined in simulation but compilation is passed fine - vhdl

I am a fresh student and the assignment is to build 3 components with testbench and then to arrange them into one structure. All 3 components I have built work great but when I put them together one of the the outputs stays undefined. I tried to trace the signal called dat and it is fine, but probably I am not using correct syntax to assign the dat signal to data_out . The id_led_ind is the second output and it works fine but the data_out is undefined.
Here is the code (i think the problem is in lane 21 - "data_out <= dat")
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
entity peak_detect is
port(
input : in std_logic_vector (7 downto 0);
data_out : out std_logic_vector (7 downto 0);
reset : in std_logic;
clock : in std_logic;
enable : in std_logic;
id_led_ind : out std_logic);
end peak_detect;
architecture dataflow of peak_detect is
signal a_big_b : std_logic;
signal en : std_logic;
signal dat : std_logic_vector (7 downto 0);
begin
en <= (enable or a_big_b);
data_out <= dat;
end dataflow;
architecture structure of peak_detect is
signal a_big_b : std_logic;
signal en : std_logic;
signal dat : std_logic_vector (7 downto 0);
component comp_8bit is
port(
A : in std_logic_vector (7 downto 0);
B : in std_logic_vector (7 downto 0);
res : out std_logic);
end component;
component dff is
port (
data : in std_logic_vector (7 downto 0);
q : out std_logic_vector (7 downto 0);
clk : in std_logic;
reset : in std_logic;
en : in std_logic);
end component;
component id_sens is
port(
data_in : in std_logic_vector (7 downto 0);
led : out std_logic);
end component;
begin
reg : dff port map (data => input, q => dat, clk => clock, reset => reset, en => enable);
comp : comp_8bit port map (A => input, B => dat, res => a_big_b);
sens : id_sens port map (data_in => dat, led => id_led_ind);
end structure;

There appears to be confusion over having two architectures (dataflow and structure) for the entity peak_detect. The two architectures are mutually exclusive, and the last one analyzed is the default in absence of other configuration specifying one of the architectures directly.
For purposes of evaluating how the components are interconnected and their port mapped connections relate to the port declarations of peak_detect, the first architecture could be commented out (dataflow).
When you disregard the architecture dataflow we find there is no driver for data_out in architecture structure.
You're missing an assignment to data_out using dat as a source in architecture structure, as found in architecture dataflow. Copy or replicate the concurrent signal assignment statement data_out <= dat; into architecture structure.
You can't simply connect data_out to q in the port map of dff because the output of dff is also used as an input to id_sense.

dat is driven by q of dff. That is not how you connect components. port map should be used to connect ports of different components/entities, not signals of any entity to the port of another entity.

Related

Vivado stops simulation on feedback circuit

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:

lattice mackXO3 board output transient

I have a lattice MachXO3L starter kit and I'm having some trouble with inputs, I think. I'm tried reducing the code only to read 4 switches (MachXO3 Starter Kit User’s Guide page 26) and light 4 LEDs according to the state of the switch. The problem is the LEDs seem to be half off. I tried adding 'reveal' and it appears that I'm not getting any change from the switches when I expect change. I set the spreadsheet I set it the same as in the example. I'm still learning VHDL, this is the first time I'm actually trying to connect something to it and the example is on Verilog, so I can't really check what I'm doing wrong. I'm probably missing something basic, but I don't know what.
Top File:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity TOP is
GENERIC(
DATAWIDTH : natural := 4
);
PORT(
-- Input Buffer --
ADCInputBuffer : IN STD_LOGIC_VECTOR (DATAWIDTH-1 downto 0);
OUTPUT : OUT STD_LOGIC_VECTOR (DATAWIDTH-1 downto 0);
ADC_SRT : OUT STD_LOGIC
);
end TOP;
architecture ADReader of TOP is
SIGNAL INTERNAL_CLOCK : STD_LOGIC;
SIGNAL CLOCK : STD_LOGIC;
SIGNAL CLOCK_65 : STD_LOGIC;
-- BUFFER --
signal adcInPut : std_logic_vector(DATAWIDTH-1 downto 0);
---------------------------------------------------
-- Internal Clock. Mach0X3 --
---------------------------------------------------
COMPONENT OSCH is
GENERIC(NOM_FREQ: string := "133.00"); --133.00MHz, or can select other supported frequencies
PORT(
STDBY : IN STD_LOGIC; --'0' OSC output is active, '1' OSC output off
OSC : OUT STD_LOGIC; --the oscillator output
SEDSTDBY : OUT STD_LOGIC --required only for simulation when using standby
);
END COMPONENT;
---------------------------------------------------
-- Internal Clock multiplier. Mach0X3 --
---------------------------------------------------
COMPONENT MASTERCLOCK is
PORT(
CLKI : IN STD_LOGIC; --'0' OSC output is active, '1' OSC output off
CLKOP : OUT STD_LOGIC; --the oscillator output 260MHz
CLKOS : OUT STD_LOGIC --the oscillator output for adc 65Mhz
);
END COMPONENT;
---------------------------------------------------
-- Read data In --
---------------------------------------------------
COMPONENT InputBuffer is
GENERIC(n: natural :=DATAWIDTH );
PORT(
clk : in STD_LOGIC;
CLK65 : IN STD_LOGIC;
En : in STD_LOGIC;
STRT : OUT STD_LOGIC;
Ipin : in STD_LOGIC_VECTOR (n-1 downto 0);
Output : out STD_LOGIC_VECTOR (n-1 downto 0)
);
END COMPONENT;
begin
-- System Clock
OSC: OSCH
GENERIC MAP (NOM_FREQ => "133.0")
PORT MAP (STDBY => '0', OSC => INTERNAL_CLOCK, SEDSTDBY => OPEN);
-- System Clock Multiplied
OSCmain: MASTERCLOCK
PORT MAP (CLKI => INTERNAL_CLOCK, CLKOP => CLOCK, CLKOS => CLOCK_65);
-- Gets data from ONE ADC
ADCIn: InputBuffer
GENERIC MAP (n => DATAWIDTH)
PORT MAP( clk => CLOCK, CLK65 =>CLOCK_65, EN =>'0', Ipin => adcInPut, Output => OUTPUT, STRT => ADC_SRT );
adcInPut <= ADCInputBuffer;
end ADReader;
InputBuffer:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity InputBuffer is
generic(n: natural :=4 );
Port (
clk : in STD_LOGIC;
CLK65 : IN STD_LOGIC;
En : in STD_LOGIC;
STRT : OUT STD_LOGIC;
Ipin : in STD_LOGIC_VECTOR (n-1 downto 0);
Output : out STD_LOGIC_VECTOR (n-1 downto 0)
);
end InputBuffer;
architecture Behavioral of InputBuffer is
signal temp : STD_LOGIC_VECTOR(n-1 downto 0);
SIGNAL CLK2 : STD_LOGIC;
begin
-- invert the signal from the push button switch and route it to the LED
process(clk, En)
begin
if( En = '1') then
temp <= B"0000";
elsif rising_edge(clk) then
temp <= Ipin;
end if;
end process;
Output <= temp;
STRT <= CLK65;
end Behavioral;
this is the setting for MASTERCLOCK generated by lattice diamond:
this is how the pins are setup:
and here is the netlist generated by lattice-diamond:
here I'm just trying to have a static output:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity TOP is
GENERIC(
DATAWIDTH : natural := 4
);
PORT(
OUTPUT : OUT STD_LOGIC_VECTOR (DATAWIDTH-1 downto 0)
);
end TOP;
architecture ADReader of TOP is
begin
OUTPUT <= B"1010";
end ADReader;
Page 15 of the user guide (The link you provided) mentions different LED pins: H11,J13,J11,L12 which you have as ADC input. I think you might have swapped some pins around...

Port direction mismatch in simple VHDL component

I am implementing the MIPS processor in VHDL using Quartus II, and one of my components is causing an error that has me completely baffled.
I have the following component:
library ieee;
use ieee.std_logic_1164.all;
entity HazardDetectionUnit is
port(
--Datapath inputs
IFIDrt : in std_logic_vector(4 downto 0);
IDEXrt : in std_logic_vector(4 downto 0);
IFIDrs : in std_logic_vector(4 downto 0);
--Controlpath inputs
IDEXMemRead : in std_logic;
PCWrite : out std_logic;
IFIDWrite : out std_logic;
IDEXFlush : out std_logic);
end HazardDetectionUnit;
architecture structural of HazardDetectionUnit is
signal same1 : std_logic;
signal same2 : std_logic;
signal NZ1 : std_logic;
signal stall : std_logic;
component comp5
port( a : in std_logic_vector(4 downto 0);
b : in std_logic_vector(4 downto 0);
comp_output : out std_logic);
end component;
component zerocomp5
port ( a : in std_logic_vector(4 downto 0);
zero : out std_logic);
end component;
begin
--Port Map
comparator1 : comp5 port map(IFIDrt, IDEXrt, same1);
comparator2 : comp5 port map(IDEXrt, IFIDrs, same2);
nonzero1 : zerocomp5 port map(IDEXrt, NZ1);
--Concurrent Signal Assignment
stall <= NZ1 and IDEXMemRead and (same1 or same2);
--Output Driver
PCWrite <= not(stall);
IFIDWrite <= not(stall);
IDEXFlush <= stall;
end structural;
I'm having an issue with the comp5 component. The error I'm getting is Error (12012): Port direction mismatch for entity "MIPS_PROCESSOR:inst|HazardDetectionUnit:inst22|comp5:comparator1" at port "comp_output". Upper entity is expecting "Input" pin while lower entity is using "Output" pin.
The sub-component comp5, which is a 5-bit equality comparator, is as follows:
library ieee;
use ieee.std_logic_1164.all;
entity comp5 is
port( a : in std_logic_vector(4 downto 0);
b : in std_logic_vector(4 downto 0);
comp_output : out std_logic
);
end comp5;
architecture structural of comp5 is
signal xor_out : std_logic_vector(4 downto 0);
component nxor2_5bit
port( a : in std_logic_vector(4 downto 0);
b : in std_logic_vector(4 downto 0);
o : out std_logic_vector(4 downto 0));
end component;
begin
--Port Map
xor_gate : nxor2_5bit port map(a, b, xor_out);
--Output Driver
comp_output <= xor_out(4) and xor_out(3) and xor_out(2) and xor_out(1) and xor_out(0);
end structural;
How is this possible? The comp5 component is clearly defined as having two 5-bit inputs, a and b, and a single one-bit output, comp_output. So why does the compiler insist that comp_output is actually an input?
I tried to debug the issue by implementing HazardDetectionUnit as a block diagram, but I got the same error.
I don't get it. comp5 is just a simple two-input, one-output logic unit. I've never had an error like this before, and I can't find any posts about a similar error. Would anyone be able to offer advice?
Edit: for completeness, here is the nxor2_5bit component:
--5-bit NXOR gate.
library ieee;
use ieee.std_logic_1164.all;
entity nxor2_5bit is
port( a : in std_logic_vector(4 downto 0);
b : in std_logic_vector(4 downto 0);
o : out std_logic_vector(4 downto 0));
end nxor2_5bit;
architecture structural of nxor2_5bit is
begin
--Output Driver
o <= not(a(4) xor b(4)) & not(a(3) xor b(3)) & not(a(2) xor b(2)) & not(a(1) xor b(1)) & not(a(0) xor b(0));
end structural;

Type Error in VHDL

When I try to compile this code I keep getting an error that says:
line 13: Error, 'std_logic' is not a known type.
Line 13 is Clock : IN std_logic;in the ALU_tb entity.
I am confused by this error, because it is my understanding that the reason for said error is normally a missing library/package. I'm almost sure I have the appropriate libraries and packages. Plus none of the other signals of type std_logic are getting errors.
If anyone could help me figure this out, I would greatly appreciate it.
-- VHDL Entity ALU.ALU_tb.symbol
--
-- Created:
-- by - ClarkG.UNKNOWN (COELABS15)
-- at - 19:58:20 09/ 8/2014
--
-- Generated by Mentor Graphics' HDL Designer(TM) 2011.1 (Build 18)
--
ENTITY ALU_tb IS
PORT(
Clock : IN std_logic;
Reset_N : IN std_logic
);
-- Declarations
END ALU_tb ;
--
-- VHDL Architecture ALU.ALU_tb.struct
--
-- Created:
-- by - ClarkG.UNKNOWN (COELABS15)
-- at - 19:58:20 09/ 8/2014
--
-- Generated by Mentor Graphics' HDL Designer(TM) 2011.1 (Build 18)
--
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_arith.ALL;
LIBRARY ALU;
ARCHITECTURE struct OF ALU_tb IS
-- Architecture declarations
-- Internal signal declarations
SIGNAL A : std_logic_vector(31 DOWNTO 0);
SIGNAL ALUOp : std_logic_vector(3 DOWNTO 0);
SIGNAL B : std_logic_vector(31 DOWNTO 0);
SIGNAL Overflow : std_logic;
SIGNAL R : std_logic_vector(31 DOWNTO 0);
SIGNAL SHAMT : std_logic_vector(4 DOWNTO 0);
SIGNAL Zero : std_logic;
-- Component Declarations
COMPONENT ALU
PORT (
A : IN std_logic_vector (31 DOWNTO 0);
ALUOp : IN std_logic_vector (3 DOWNTO 0);
B : IN std_logic_vector (31 DOWNTO 0);
SHAMT : IN std_logic_vector (4 DOWNTO 0);
Overflow : OUT std_logic ;
R : OUT std_logic_vector (31 DOWNTO 0);
Zero : OUT std_logic
);
END COMPONENT;
COMPONENT ALU_tester
PORT (
A : IN std_logic_vector (31 DOWNTO 0);
ALUOp : IN std_logic_vector (3 DOWNTO 0);
B : IN std_logic_vector (31 DOWNTO 0);
Clock : IN std_logic ;
Overflow : IN std_logic ;
R : IN std_logic_vector (31 DOWNTO 0);
Reset_N : IN std_logic ;
SHAMT : IN std_logic_vector (4 DOWNTO 0);
Zero : IN std_logic
);
END COMPONENT;
COMPONENT Test_transaction_generator
PORT (
Clock : IN std_logic ;
A : OUT std_logic_vector (31 DOWNTO 0);
ALUOp : OUT std_logic_vector (3 DOWNTO 0);
B : OUT std_logic_vector (31 DOWNTO 0);
SHAMT : OUT std_logic_vector (4 DOWNTO 0)
);
END COMPONENT;
-- Optional embedded configurations
-- pragma synthesis_off
FOR ALL : ALU USE ENTITY ALU.ALU;
FOR ALL : ALU_tester USE ENTITY ALU.ALU_tester;
FOR ALL : Test_transaction_generator USE ENTITY ALU.Test_transaction_generator;
-- pragma synthesis_on
BEGIN
-- Instance port mappings.
U_0 : ALU
PORT MAP (
A => A,
ALUOp => ALUOp,
B => B,
SHAMT => SHAMT,
Overflow => Overflow,
R => R,
Zero => Zero
);
U_1 : ALU_tester
PORT MAP (
A => A,
ALUOp => ALUOp,
B => B,
Clock => Clock,
Overflow => Overflow,
R => R,
Reset_N => Reset_N,
SHAMT => SHAMT,
Zero => Zero
);
U_2 : Test_transaction_generator
PORT MAP (
Clock => Clock,
A => A,
ALUOp => ALUOp,
B => B,
SHAMT => SHAMT
);
END struct;
The context clause comprised of a library clauses and use clauses should be moved to before the entity declaration instead of just before the architecture body. An entity and an architecture form a common declarative region allowing those library and use clauses to be in effect across both instead of just the architecture, as in your code presently.
You also don't appear to be using package std_logic_arith in the code you've shown. (The architecture only contains components).
At line 13, you have not yet imported the ieee libraries required to define std_logic which is why you're getting the error.

Driving GPIO pins shared with SRAM in VHDL

I've bought a Spartan 3A development board from Micronova (http://micro-nova.com/mercury) and I've got some problems interfacing with its SRAM.
This board has 30 GPIO pins that are shared with Cypress SRAM and two pins to switch between them.
Obviously, connecting two VHDL modules (one for controlling SRAM and the other to drive GPIO) to the same pin leads to "Multiple driver error" when synthetizing.
So, to solve the problem I've created a third module as a middle controller that connects both modules with another variable for choosing which one to operate.
This works well for output, but when it comes to read input I always get 1, independently of the real value.
I don't know which pins will be used as input and which ones are for output because I would like an independent module that I can use for other projects.
This is what I got so far:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity DMA2 is
Port (
IOphys : inout STD_LOGIC_VECTOR (29 downto 0);
IOin1 : out STD_LOGIC_VECTOR (29 downto 0);
IOin2 : out STD_LOGIC_VECTOR (29 downto 0);
IOout1 : in STD_LOGIC_VECTOR (29 downto 0);
IOout2 : in STD_LOGIC_VECTOR (29 downto 0);
SwitchEn2 : in STD_LOGIC
);
end DMA2;
architecture Behavioral of DMA2 is
begin
IOin2 <= IOphys;
IOin1 <= IOphys;
IOphys <= IOout2 when SwitchEn2 = '1' else IOout1;
end Behavioral;
IOphys are the physical pins on the board, SwitchEn2 is for choosing the driving module and the others are the inputs and outputs of the modules.
You don't seem to be driving your outputs. As a starter, how about defining a tristate driver like so
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity tristate is
port (
signal data_in : out std_logic;
signal data_out : in std_logic;
signal data_tristate : inout std_logic;
signal tristate_select : in std_logic
);
architecture rtl of tristate is
begin
data_in <= data_tristate;
data_tristate <= 'z' when tristate_select = '1' else data_out;
end architecture;
Then selecting between its use like so
entity arbitrate_bus
port(
-- the pins
IOphys : inout STD_LOGIC_VECTOR (29 downto 0);
IOin1 : out STD_LOGIC_VECTOR (29 downto 0);
IOout1 : in STD_LOGIC_VECTOR (29 downto 0);
IO_direction1 : in STD_LOGIC_VECTOR (29 downto 0);
IOin2 : out STD_LOGIC_VECTOR (29 downto 0);
IOout2 : in STD_LOGIC_VECTOR (29 downto 0);
IO_direction2 : in STD_LOGIC_VECTOR (29 downto 0);
SwitchEn2 : in STD_LOGIC
);
architecture like_this of arbitrate_bus is
signal input : STD_LOGIC_VECTOR (29 downto 0);
signal output_selected : STD_LOGIC_VECTOR (29 downto 0);
signal direction_selected : STD_LOGIC_VECTOR (29 downto 0);
begin
output_selected <= IOout1 when SwitchEn2 = '0' else IOout2;
direction_selected <= IO_direction1 when SwitchEn2 = '0' else IO_direction2;
g_ts: for g in output_selected'range generate
begin
u_ts: entity tristate
port map(
data_in => input(g),
data_out => output_selected(g),
data_tristate => IOphys(g),
tristate_select => direction_selected(g)
);
end generate;
IOin1 <= input;
IOin2 <= input;
end architecture;
What value are you assigning to the pins that are supposed to be inputs?
You may be able to infer proper operation if you assign 'Z' to the IOout1 and IOout2 signals when that pin is supposed to be an input, but I recommend you actually instantiate tri-state I/O pins. In addition to multiplexing the output state, you should also multiplex the output enable between the two modules, then your input code should work properly.
So each module generates output signals and a set of output enables. These signals get multiplexed and tied to the one set of physical pins, with the output enables determining which pins are inputs and which are outputs. This way, everything in the FPGA is binary logic and you are not relying on the synthesizer to infer a tri-state bus.

Resources