Without seeing the error message and/or the declaration for ssegDigit
it may be impossible to provide a definitive answer.
This analyzes:
library ieee;
use ieee.std_logic_1164.all;
entity module is
port (
signal x: in std_logic_vector (3 downto 0);
signal y: in std_logic_vector (3 downto 0);
signal enteredDigit1: out std_logic_vector (3 downto 0)
);
end entity;
architecture foo of module is
begin
end architecture;
library ieee;
use ieee.std_logic_1164.all;
entity ssegDigit_tb is
end entity;
architecture foo of ssegDigit_tb is
signal asyncClock: std_logic;
signal x: std_logic_vector(3 downto 0);
signal y: std_logic_vector(3 downto 0);
signal ssegDigit: std_logic_vector(3 downto 0);
signal enteredDigit1 : std_logic_vector(3 downto 0);
begin
u3: entity work.module port map (x,y, enteredDigit1);
process(asyncClock, enteredDigit1)
begin
ssegDigit <= enteredDigit1;
end process;
end architecture;
Notice that ssegDigit
has the same index range of enteredDigit1
, and I corrected the declaration for enteredDigit1
which was:
signal enteredDigit1 : std_logic_vector(3 down 0);
Where the VHDL reserved word downto
was not complete and should be:
signal enteredDigit1 : std_logic_vector(3 downto 0);
Without knowing your exact methodology for causing the ISE tool to crash there's an outside possibility that it's parser isn't robust enough.
In general a simulator's analyzer is going to be more robust than one found in a synthesis tool. Synthesizers are written anticipating a valid VHDL design specification, which also points to the utility of validating your design before synthesis.
If neither the declaration for ssegDigit
having a matching element for each element in enteredDigit1
nor fixing the reserved word downto
in declaration for enteredDigit1 is your problem, by definition you haven't provided enough information. Also notice the semicolon following the assignment statement in the process and after end process
.
Let us know, and elaborate the question if needed.
Noted you corrected the downto
in your example but not the missing semicolons.
After your comment:
... The sseg digits are declared as you expected, and port mapped to the same range. I was thinking maybe its a case of the synthesizer flipping out because the signal enteredDigit1 is being modified in a few places. Any idea why it would work outside the process? synchronous issues?
It appears that ssegDigit
is declared as a signal and connected to a port. This points to the futility of playing twenty questions in comments, where each time around a bit more information is revealed (we'd eventually get a message suggesting moving dialogs to a wiki chat if nothing else).
Perhaps you could show port declarations including mode, signal declarations for the involved elements and any assignment statements for the signals particularly enteredDigit1
.
It might also be useful for you to demonstrate the indications leading you to conclude the synthesis tool 'crashing'.
See How do I ask a good question? , Help others reproduce the problem, "Include just enough code to allow others to reproduce the problem. For help with this, read How to create a Minimal, Complete, Valid Example" (How to create a Minimal, Complete, and Verifiable example).