VHDL simulation does not display a waveform - vhdl

Question

I wrote code in VHDL and am using Active HDL Student edition to compile and simulate the code using a testbench. As I simulate for 500ns, the signals change but the signals on the waveform is stuck on U without anything displaying. I can't seem find what is causing this problem.
This is my code for the entity:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity idexreg is
port(
rst_bar : in std_logic;
clk : in std_logic;
immediate_in : in std_logic_vector(63 downto 0);
reg0_in : in std_logic_vector(63 downto 0);
reg1_in : in std_logic_vector(63 downto 0);
instruction_in : in std_logic_vector(3 downto 0);
pc_in : in std_logic_vector(3 downto 0);
immediate_out : out std_logic_vector(63 downto 0);
reg0_out : out std_logic_vector(63 downto 0);
reg1_out : out std_logic_vector(63 downto 0);
instruction_out : out std_logic_vector(3 downto 0);
pc_out : out std_logic_vector(3 downto 0)
);
end idexreg;
architecture idexreg_arch of idexreg is
begin
arch: process(clk, rst_bar)
begin
if rst_bar = '0' then
immediate_out <= std_logic_vector(x"0000000000000000");
reg0_out <= std_logic_vector(x"0000000000000000");
reg1_out <= std_logic_vector(x"0000000000000000");
instruction_out <= std_logic_vector(x"0");
pc_out <= std_logic_vector(x"0");
elsif falling_edge(clk) then
immediate_out <= immediate_in;
reg0_out <= reg0_in;
reg1_out <= reg1_in;
instruction_out <= instruction_in;
pc_out <= pc_in;
end if;
end process;
end idexreg_arch;
This is the code for the testbench:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use ieee.std_logic_arith.all;
entity idexreg_tb is
end idexreg_tb;
architecture test of idexreg_tb is
--input signals
signal rst_bar : std_logic;
signal clk: std_logic;
signal immediate_in : std_logic_vector(63 downto 0);
signal reg0_in : std_logic_vector(63 downto 0);
signal reg1_in : std_logic_vector(63 downto 0);
signal instruction_in : std_logic_vector(3 downto 0);
signal pc_in : std_logic_vector(3 downto 0);
--output signals
signal immediate_out : std_logic_vector(63 downto 0);
signal reg0_out : std_logic_vector(63 downto 0);
signal reg1_out : std_logic_vector(63 downto 0);
signal instruction_out : std_logic_vector(3 downto 0);
signal pc_out : std_logic_vector(3 downto 0);
-- boolean to signify end of simulation
signal end_sim : boolean := false;
constant period : time := 50ns;
begin
UUT: entity idexreg
port map(
rst_bar => rst_bar,
clk => clk,
immediate_in => immediate_in,
reg0_in => reg0_in,
reg1_in => reg1_in,
instruction_in => instruction_in,
pc_in => pc_in,
immediate_out => immediate_out,
reg0_out => reg0_out,
reg1_out => reg1_out,
instruction_out => instruction_out,
pc_out => pc_out);
-- Generate the Clock signal
clk_gen: process
begin
clk <= '0';
loop
wait for period/2;
clk <= not clk;
exit when end_sim = true;
end loop;
wait;
end process;
stim: process
begin
-- reset the register file first
rst_bar <= '0';
wait for 100ns;
rst_bar <= '1';
--Test 1
immediate_in <= std_logic_vector(x"AAAAAAAAAAAAAAAA");
reg0_in <= std_logic_vector(x"AAAAAAAAAAAAAAAA");
reg1_in <= std_logic_vector(x"AAAAAAAAAAAAAAAA");
instruction_in <= std_logic_vector(x"A");
pc_in <= std_logic_vector(x"1");
wait for 10ns;
--Test 2
immediate_in <= std_logic_vector(x"BBBBBBBBBBBBBBBB");
reg0_in <= std_logic_vector(x"BBBBBBBBBBBBBBBB");
reg1_in <= std_logic_vector(x"BBBBBBBBBBBBBBBB");
instruction_in <= std_logic_vector(x"B");
pc_in <= std_logic_vector(x"2");
wait for 30ns;
--Test 3
immediate_in <= std_logic_vector(x"CCCCCCCCCCCCCCCC");
reg0_in <= std_logic_vector(x"CCCCCCCCCCCCCCCC");
reg1_in <= std_logic_vector(x"CCCCCCCCCCCCCCCC");
instruction_in <= std_logic_vector(x"C");
pc_in <= std_logic_vector(x"3");
end_sim <= true;
wait;
end process;
end test;
Any help would be greatly appreciated!

Answer 1

With two other standard compliant simulators three classes of errors were found.
Semantic error:
UUT: entity idexreg
should be
UUT: entity work.idexreg
Without a use clause use.work.all; the declaration for previously analyzed entity idexreg won't be visible (unbound, this would account for 'U's). A selected named can be used when the name is not directly visible.
IEEE Std 1076-2008 12.3 Visibility
The meaning of the occurrence of an identifier at a given place in the text is defined by the visibility rules and also, in the case of overloaded declarations, by the overloading rules. The identifiers considered in this subclause include any identifier other than a reserved word or an attribute designator that denotes a predefined attribute. The places considered in this subclause are those where a lexical element (such as an identifier) occurs. The overloaded declarations considered in this subclause are those for subprograms and enumeration literals.
12.4 Use clauses
A use clause achieves direct visibility of declarations that are visible by selection.
(the fix shown above)
13.2 Design libraries
Every design unit except a context declaration and package STANDARD is assumed to contain the following implicit context items as part of its context clause:
library STD, WORK; use STD.STANDARD.all;
Note the library name WORK is made directly visible by the library clause but the design units analyzed into the library work are not made directly visible without a use clause.
back to 12.4 Use clauses:
Each selected name in a use clause identifies one or more declarations that will potentially become directly visible. If the suffix of the selected name is a simple name other than a type mark, or is a character literal or operator symbol, then the selected name identifies only the declaration(s) of that simple name, character literal, or operator symbol contained within the package or library denoted by the prefix of the selected name.
...
If the suffix is the reserved word all, then the selected name identifies all declarations that are contained within the package or library denoted by the prefix of the selected name.
There are also two additional error classes, the first your simulator does not require adherence by a design description.
The first, a syntax rule:
15.3 Lexical elements, separators, and delimiters
At least one separator is required between an identifier or an abstract literal and an adjacent identifier or abstract literal.
There's at least one successful commercial simulator out there that ignores this rule. It's harder to ignore it for -2008.
The second, another semantic rule:
9.3.6 Type conversions
— Array types—Two array types are closely related if and only if the types have the same dimensionality and the element types are closely related
Character string and std_logic_vector are not closely related for type conversion. You can drop the unneeded type conversions - bit string's type is from context:
9.3.6:
The type of the operand of a type conversion shall be determined by applying the rules of 12.5 to the operand considered as a complete context.
Which means all you see is the expanded bit string (15.8), e.g.:
std_logic_vector(x"0000000000000000")
as a string, an array type with a character element type, while std_logic_vector has a std_ulogic or std_logic element type (depending on the VHDL revision). That means the operand and type mark of the type conversion are not closely related.
This rule shouldn't be ignored.
9.3.2 Literals
String and bit string literals are representations of one-dimensional arrays of characters. The type of a string or bit string literal shall be determinable solely from the context in which the literal appears, excluding the literal itself but using the fact that the type of the literal shall be a one-dimensional array of a character type. The lexical structure of string and bit string literals is defined in Clause 15.
You could likewise use qualified expressions.
9.3.5 Qualified expressions
A qualified expression is a basic operation (see 5.1) that is used to explicitly state the type, and possibly the subtype, of an operand that is an expression or an aggregate.
Both methods are shown below, the amount of effort required dictated most were changed to qualified expression, requiring only an additional ' character.
Your code then will analyze successfully on any standard compliant VHDL tool:
library ieee;
use ieee.std_logic_1164.all;
-- use ieee.numeric_std.all;
entity idexreg is
port(
rst_bar : in std_logic;
clk : in std_logic;
immediate_in : in std_logic_vector(63 downto 0);
reg0_in : in std_logic_vector(63 downto 0);
reg1_in : in std_logic_vector(63 downto 0);
instruction_in : in std_logic_vector(3 downto 0);
pc_in : in std_logic_vector(3 downto 0);
immediate_out : out std_logic_vector(63 downto 0);
reg0_out : out std_logic_vector(63 downto 0);
reg1_out : out std_logic_vector(63 downto 0);
instruction_out : out std_logic_vector(3 downto 0);
pc_out : out std_logic_vector(3 downto 0)
);
end idexreg;
architecture idexreg_arch of idexreg is
begin
arch: process(clk, rst_bar)
begin
if rst_bar = '0' then
immediate_out <= std_logic_vector'(x"0000000000000000");
reg0_out <= std_logic_vector'(x"0000000000000000");
reg1_out <= std_logic_vector'(x"0000000000000000");
instruction_out <= std_logic_vector'(x"0");
pc_out <= std_logic_vector'(x"0");
elsif falling_edge(clk) then
immediate_out <= immediate_in;
reg0_out <= reg0_in;
reg1_out <= reg1_in;
instruction_out <= instruction_in;
pc_out <= pc_in;
end if;
end process;
end idexreg_arch;
library ieee;
use ieee.std_logic_1164.all;
-- use ieee.numeric_std.all;
-- use ieee.std_logic_arith.all;
entity idexreg_tb is
end idexreg_tb;
architecture test of idexreg_tb is
--input signals
signal rst_bar : std_logic;
signal clk: std_logic;
signal immediate_in : std_logic_vector(63 downto 0);
signal reg0_in : std_logic_vector(63 downto 0);
signal reg1_in : std_logic_vector(63 downto 0);
signal instruction_in : std_logic_vector(3 downto 0);
signal pc_in : std_logic_vector(3 downto 0);
--output signals
signal immediate_out : std_logic_vector(63 downto 0);
signal reg0_out : std_logic_vector(63 downto 0);
signal reg1_out : std_logic_vector(63 downto 0);
signal instruction_out : std_logic_vector(3 downto 0);
signal pc_out : std_logic_vector(3 downto 0);
-- boolean to signify end of simulation
signal end_sim : boolean := false;
constant period : time := 50 ns;
begin
UUT: entity work.idexreg -- ERROR HERE was entity idexreg
port map (
rst_bar => rst_bar,
clk => clk,
immediate_in => immediate_in,
reg0_in => reg0_in,
reg1_in => reg1_in,
instruction_in => instruction_in,
pc_in => pc_in,
immediate_out => immediate_out,
reg0_out => reg0_out,
reg1_out => reg1_out,
instruction_out => instruction_out,
pc_out => pc_out);
-- Generate the Clock signal
clk_gen: process
begin
clk <= '0';
loop
wait for period/2;
clk <= not clk;
exit when end_sim = true;
end loop;
wait;
end process;
stim: process
begin
-- reset the register file first
rst_bar <= '0';
wait for 100 ns;
rst_bar <= '1';
--Test 1
immediate_in <= x"AAAAAAAAAAAAAAAA"; -- std_logic_vector'(x"AAAAAAAAAAAAAAAA");
reg0_in <= std_logic_vector'(x"AAAAAAAAAAAAAAAA");
reg1_in <= std_logic_vector'(x"AAAAAAAAAAAAAAAA");
instruction_in <= std_logic_vector'(x"A");
pc_in <= std_logic_vector'(x"1");
wait for 10 ns;
--Test 2
immediate_in <= std_logic_vector'(x"BBBBBBBBBBBBBBBB");
reg0_in <= std_logic_vector'(x"BBBBBBBBBBBBBBBB");
reg1_in <= std_logic_vector'(x"BBBBBBBBBBBBBBBB");
instruction_in <= std_logic_vector'(x"B");
pc_in <= std_logic_vector'(x"2");
wait for 30 ns;
--Test 3
immediate_in <= std_logic_vector'(x"CCCCCCCCCCCCCCCC");
reg0_in <= std_logic_vector'(x"CCCCCCCCCCCCCCCC");
reg1_in <= std_logic_vector'(x"CCCCCCCCCCCCCCCC");
instruction_in <= std_logic_vector'(x"C");
pc_in <= std_logic_vector'(x"3");
end_sim <= true;
wait;
end process;
end test;
And fixing the above mentioned errors gives you something besides 'U's:
.
immediate_in is the signal assignment in Test 1 not using a qualified expression relying instead on 9.3.2's rule for determining the type of a bit string literal. The innermost complete context (12.5) used to determine the bit string literal type is the assignment statement itself.
The method of assigning immediate_in would normally be widely used as the preferred method. The type is taken from the target of the assignment.