matthew1kalasky3
/
microwatt
forked from cores/microwatt
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
master
fpu-init
loadstore-init
core_debug-init
icache-unused-sig
icache-insn-u-state
dcache-unused-sig
unused-sig
divider-init
loadstore-pmu-init
icache-pmu-events
fpu-typo
less-fpga-init
caravel-mpw6-20220530
caravel-mpw5-20220323
caravel-mpw5-20220322
alt-reset-address
log2ceil-issue
fpu-constant
asic-3
boxarty-20211011
icbi-issue
orange-crab-freq
dcache-nc-fix
remove-potato-uart
cache-tlb-parameters-2
caravel-20210114
caravel-20210105
jtag-port-2
jtag-port
nia-debug
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'bc0f7cf236'
${ noResults }
microwatt/rotator_tb.vhdl

290 lines
12 KiB
VHDL
Raw Normal View History Unescape Escape

Make core testbenches recognized by VUnit This commit also removes the dependencies these testbenches have on VHPIDIRECT. The use of VHPIDIRECT limits the number of available simulators for the project. Rather than using foreign functions the testbenches can be implemented entirely in VHDL where equivalent functionality exists. For these testbenches the VHPIDIRECT-based randomization functions were replaced with VHDL-based functions. The testbenches recognized by VUnit can be executed in parallel threads for better simulation performance using the -p option to the run.py script Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
library vunit_lib;
context vunit_lib.vunit_context;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
library work;
use work.common.all;
use work.ppc_fx_insns.all;
use work.insn_helpers.all;
Make core testbenches recognized by VUnit This commit also removes the dependencies these testbenches have on VHPIDIRECT. The use of VHPIDIRECT limits the number of available simulators for the project. Rather than using foreign functions the testbenches can be implemented entirely in VHDL where equivalent functionality exists. For these testbenches the VHPIDIRECT-based randomization functions were replaced with VHDL-based functions. The testbenches recognized by VUnit can be executed in parallel threads for better simulation performance using the -p option to the run.py script Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
library osvvm;
use osvvm.RandomPkg.all;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
entity rotator_tb is
Make core testbenches recognized by VUnit This commit also removes the dependencies these testbenches have on VHPIDIRECT. The use of VHPIDIRECT limits the number of available simulators for the project. Rather than using foreign functions the testbenches can be implemented entirely in VHDL where equivalent functionality exists. For these testbenches the VHPIDIRECT-based randomization functions were replaced with VHDL-based functions. The testbenches recognized by VUnit can be executed in parallel threads for better simulation performance using the -p option to the run.py script Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
generic (runner_cfg : string := runner_cfg_default);
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end rotator_tb;
architecture behave of rotator_tb is
constant clk_period: time := 10 ns;
signal ra, rs: std_ulogic_vector(63 downto 0);
signal shift: std_ulogic_vector(6 downto 0) := (others => '0');
signal insn: std_ulogic_vector(31 downto 0) := (others => '0');
signal is_32bit, right_shift, arith, clear_left, clear_right: std_ulogic := '0';
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
signal res: std_ulogic_vector(63 downto 0);
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
signal carry_out: std_ulogic;
Implement the extswsli instruction This mainly required the addition of an entry to the opcode 31 decode table and a 32-bit sign-extender in the rotator. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
signal extsw: std_ulogic;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
begin
rotator_0: entity work.rotator
Reformat testbenches Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
4 years ago
port map (
rs => rs,
ra => ra,
shift => shift,
insn => insn,
is_32bit => is_32bit,
right_shift => right_shift,
arith => arith,
clear_left => clear_left,
clear_right => clear_right,
Implement the extswsli instruction This mainly required the addition of an entry to the opcode 31 decode table and a 32-bit sign-extender in the rotator. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
sign_ext_rs => extsw,
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
result => res,
Reformat testbenches Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
4 years ago
carry_out => carry_out
);
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
stim_process: process
variable behave_ra: std_ulogic_vector(63 downto 0);
Reformat testbenches Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
4 years ago
variable behave_ca_ra: std_ulogic_vector(64 downto 0);
Make core testbenches recognized by VUnit This commit also removes the dependencies these testbenches have on VHPIDIRECT. The use of VHPIDIRECT limits the number of available simulators for the project. Rather than using foreign functions the testbenches can be implemented entirely in VHDL where equivalent functionality exists. For these testbenches the VHPIDIRECT-based randomization functions were replaced with VHDL-based functions. The testbenches recognized by VUnit can be executed in parallel threads for better simulation performance using the -p option to the run.py script Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
variable rnd : RandomPType;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
begin
Make core testbenches recognized by VUnit This commit also removes the dependencies these testbenches have on VHPIDIRECT. The use of VHPIDIRECT limits the number of available simulators for the project. Rather than using foreign functions the testbenches can be implemented entirely in VHDL where equivalent functionality exists. For these testbenches the VHPIDIRECT-based randomization functions were replaced with VHDL-based functions. The testbenches recognized by VUnit can be executed in parallel threads for better simulation performance using the -p option to the run.py script Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
rnd.InitSeed(stim_process'path_name);
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
-- TODO: Consider making debug messages visible with a command line option
-- rather than uncommenting this line:
-- show(display_handler, debug);
Make core testbenches recognized by VUnit This commit also removes the dependencies these testbenches have on VHPIDIRECT. The use of VHPIDIRECT limits the number of available simulators for the project. Rather than using foreign functions the testbenches can be implemented entirely in VHDL where equivalent functionality exists. For these testbenches the VHPIDIRECT-based randomization functions were replaced with VHDL-based functions. The testbenches recognized by VUnit can be executed in parallel threads for better simulation performance using the -p option to the run.py script Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
test_runner_setup(runner, runner_cfg);
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
while test_suite loop
if run("Test rlw[i]nm") then
ra <= (others => '0');
is_32bit <= '1';
right_shift <= '0';
arith <= '0';
clear_left <= '1';
clear_right <= '1';
extsw <= '0';
rlwnm_loop : for i in 0 to 1000 loop
rs <= rnd.RandSlv(64);
shift <= rnd.RandSlv(7);
insn <= x"00000" & '0' & rnd.RandSlv(10) & '0';
wait for clk_period;
behave_ra := ppc_rlwinm(rs, shift(4 downto 0), insn_mb32(insn), insn_me32(insn));
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
check_equal(res, behave_ra, result("for rlwnm"));
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
end loop;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
elsif run("Test rlwimi") then
is_32bit <= '1';
right_shift <= '0';
arith <= '0';
clear_left <= '1';
clear_right <= '1';
rlwimi_loop : for i in 0 to 1000 loop
rs <= rnd.RandSlv(64);
ra <= rnd.RandSlv(64);
shift <= "00" & rnd.RandSlv(5);
insn <= x"00000" & '0' & rnd.RandSlv(10) & '0';
wait for clk_period;
behave_ra := ppc_rlwimi(ra, rs, shift(4 downto 0), insn_mb32(insn), insn_me32(insn));
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
check_equal(res, behave_ra, result("for rlwnimi"));
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
end loop;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
elsif run("Test rld[i]cl") then
ra <= (others => '0');
is_32bit <= '0';
right_shift <= '0';
arith <= '0';
clear_left <= '1';
clear_right <= '0';
rldicl_loop : for i in 0 to 1000 loop
rs <= rnd.RandSlv(64);
shift <= rnd.RandSlv(7);
insn <= x"00000" & '0' & rnd.RandSlv(10) & '0';
wait for clk_period;
behave_ra := ppc_rldicl(rs, shift(5 downto 0), insn_mb(insn));
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
check_equal(res, behave_ra, result("for rldicl"));
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
end loop;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
elsif run("Test rld[i]cr") then
ra <= (others => '0');
is_32bit <= '0';
right_shift <= '0';
arith <= '0';
clear_left <= '0';
clear_right <= '1';
rldicr_loop : for i in 0 to 1000 loop
rs <= rnd.RandSlv(64);
shift <= rnd.RandSlv(7);
insn <= x"00000" & '0' & rnd.RandSlv(10) & '0';
wait for clk_period;
behave_ra := ppc_rldicr(rs, shift(5 downto 0), insn_me(insn));
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
debug("rs = " & to_hstring(rs));
debug("ra = " & to_hstring(ra));
debug("shift = " & to_hstring(shift));
debug("insn me = " & to_hstring(insn_me(insn)));
debug("result = " & to_hstring(res));
check_equal(res, behave_ra, result("for rldicr"));
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
end loop;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
elsif run("Test rldic") then
ra <= (others => '0');
is_32bit <= '0';
right_shift <= '0';
arith <= '0';
clear_left <= '1';
clear_right <= '1';
rldic_loop : for i in 0 to 1000 loop
rs <= rnd.RandSlv(64);
shift <= '0' & rnd.RandSlv(6);
insn <= x"00000" & '0' & rnd.RandSlv(10) & '0';
wait for clk_period;
behave_ra := ppc_rldic(rs, shift(5 downto 0), insn_mb(insn));
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
check_equal(res, behave_ra, result("for rldic"));
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
end loop;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
elsif run("Test rldimi") then
is_32bit <= '0';
right_shift <= '0';
arith <= '0';
clear_left <= '1';
clear_right <= '1';
rldimi_loop : for i in 0 to 1000 loop
rs <= rnd.RandSlv(64);
ra <= rnd.RandSlv(64);
shift <= '0' & rnd.RandSlv(6);
insn <= x"00000" & '0' & rnd.RandSlv(10) & '0';
wait for clk_period;
behave_ra := ppc_rldimi(ra, rs, shift(5 downto 0), insn_mb(insn));
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
check_equal(res, behave_ra, result("for rldimi"));
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
end loop;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
elsif run("Test slw") then
ra <= (others => '0');
is_32bit <= '1';
right_shift <= '0';
arith <= '0';
clear_left <= '0';
clear_right <= '0';
slw_loop : for i in 0 to 1000 loop
rs <= rnd.RandSlv(64);
shift <= rnd.RandSlv(7);
wait for clk_period;
behave_ra := ppc_slw(rs, std_ulogic_vector(resize(unsigned(shift), 64)));
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
check_equal(res, behave_ra, result("for slv"));
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
end loop;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
elsif run("Test sld") then
ra <= (others => '0');
is_32bit <= '0';
right_shift <= '0';
arith <= '0';
clear_left <= '0';
clear_right <= '0';
sld_loop : for i in 0 to 1000 loop
rs <= rnd.RandSlv(64);
shift <= rnd.RandSlv(7);
wait for clk_period;
behave_ra := ppc_sld(rs, std_ulogic_vector(resize(unsigned(shift), 64)));
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
check_equal(res, behave_ra, result("for sld"));
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
end loop;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
elsif run("Test srw") then
ra <= (others => '0');
is_32bit <= '1';
right_shift <= '1';
arith <= '0';
clear_left <= '0';
clear_right <= '0';
srw_loop : for i in 0 to 1000 loop
rs <= rnd.RandSlv(64);
shift <= rnd.RandSlv(7);
wait for clk_period;
behave_ra := ppc_srw(rs, std_ulogic_vector(resize(unsigned(shift), 64)));
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
check_equal(res, behave_ra, result("for srw"));
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
end loop;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
elsif run("Test srd") then
ra <= (others => '0');
is_32bit <= '0';
right_shift <= '1';
arith <= '0';
clear_left <= '0';
clear_right <= '0';
srd_loop : for i in 0 to 1000 loop
rs <= rnd.RandSlv(64);
shift <= rnd.RandSlv(7);
wait for clk_period;
behave_ra := ppc_srd(rs, std_ulogic_vector(resize(unsigned(shift), 64)));
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
check_equal(res, behave_ra, result("for srd"));
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
end loop;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
elsif run("Test sraw[i]") then
ra <= (others => '0');
is_32bit <= '1';
right_shift <= '1';
arith <= '1';
clear_left <= '0';
clear_right <= '0';
sraw_loop : for i in 0 to 1000 loop
rs <= rnd.RandSlv(64);
shift <= '0' & rnd.RandSlv(6);
wait for clk_period;
behave_ca_ra := ppc_sraw(rs, std_ulogic_vector(resize(unsigned(shift), 64)));
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
debug("rs = " & to_hstring(rs));
debug("ra = " & to_hstring(ra));
debug("shift = " & to_hstring(shift));
debug("result = " & to_hstring(carry_out & res));
check_equal(res, behave_ca_ra(63 downto 0), result("for sraw"));
check_equal(carry_out, behave_ca_ra(64), result("for sraw carry_out"));
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
end loop;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
elsif run("Test srad[i]") then
ra <= (others => '0');
is_32bit <= '0';
right_shift <= '1';
arith <= '1';
clear_left <= '0';
clear_right <= '0';
srad_loop : for i in 0 to 1000 loop
rs <= rnd.RandSlv(64);
shift <= rnd.RandSlv(7);
wait for clk_period;
behave_ca_ra := ppc_srad(rs, std_ulogic_vector(resize(unsigned(shift), 64)));
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
debug("rs = " & to_hstring(rs));
debug("ra = " & to_hstring(ra));
debug("shift = " & to_hstring(shift));
debug("result = " & to_hstring(carry_out & res));
check_equal(res, behave_ca_ra(63 downto 0), result("for srad"));
check_equal(carry_out, behave_ca_ra(64), result("for srad carry_out"));
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
end loop;
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
elsif run("Test extswsli") then
ra <= (others => '0');
is_32bit <= '0';
right_shift <= '0';
arith <= '0';
clear_left <= '0';
clear_right <= '0';
extsw <= '1';
extswsli_loop : for i in 0 to 1000 loop
rs <= rnd.RandSlv(64);
shift <= '0' & rnd.RandSlv(6);
wait for clk_period;
behave_ra := rs;
behave_ra(63 downto 32) := (others => rs(31));
behave_ra := std_ulogic_vector(shift_left(unsigned(behave_ra),
to_integer(unsigned(shift))));
Replaced VHDL assert and report with VUnit checking and logging The VUnit log package is a SW style logging framework in VHDL and the check package is an assertion library doing its error reporting with VUnit logging. These testbenches don't use, and do not need, very advanced logging/checking features but the following was possible to improve - Checking equality in VHDL can be quite tedious with a lot of type conversions and long message strings to explain the data received and what was expected. VUnit's check_equal procedure allow comparison between same or similar types and automatically create the error message for you. - The code has report statements used for testbench progress reporting and debugging. These were replaced with the info and debug procedures. info logs are visible by default while debug is not. This means that debug logs don't have to be commented, which they are now, when not used. Instead there is a show procedure making debug messages visible. The show procedure has been commented to hide the debug messages but a more elegant solution is to control visibility from a generic and then set that generic from the command line. I've left this as a TODO but the run script allow you to extend the standard CLI of VUnit to add new options and you can also set generics from the run script. - VUnit log messages are color coded if color codes are supported by the terminal. It makes it quicker to spot messages of different types when there are many log messages. Error messages will always be made visible on the terminal but you must use the -v (verbose) to see other logs. - Some tests have a lot of "metvalue detected" warning messages from the numeric_std package and these clutter the logs when using the -v option. VUnit has a simulator independent option allowing you to suppress those messages. That option has been enabled. Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
debug("rs = " & to_hstring(rs));
debug("ra = " & to_hstring(ra));
debug("shift = " & to_hstring(shift));
debug("result = " & to_hstring(carry_out & res));
check_equal(res, behave_ra, result("for extswsli"));
Organized VUnit testbenches into test cases. Several of the testbenches have stimuli code divided into sections preceded with a header comment explaining what is being tested. These sections have been made into VUnit test cases. The default behavior of VUnit is to run each test case in a separate simulation which comes with a number of benefits: * A failing test case doesn't prevent other test cases to be executed * Test cases are independent. A test case cannot fail as a side-effect to a problem with another test case * Test execution can be more parallelized and the overall test execution time reduced Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
end loop;
end if;
Implement the extswsli instruction This mainly required the addition of an entry to the opcode 31 decode table and a 32-bit sign-extender in the rotator. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end loop;
Make core testbenches recognized by VUnit This commit also removes the dependencies these testbenches have on VHPIDIRECT. The use of VHPIDIRECT limits the number of available simulators for the project. Rather than using foreign functions the testbenches can be implemented entirely in VHDL where equivalent functionality exists. For these testbenches the VHPIDIRECT-based randomization functions were replaced with VHDL-based functions. The testbenches recognized by VUnit can be executed in parallel threads for better simulation performance using the -p option to the run.py script Signed-off-by: Lars Asplund <lars.anders.asplund@gmail.com>
4 years ago
test_runner_cleanup(runner);
Add a rotate/mask/shift unit and use it in execute1 This adds a new entity 'rotator' which contains combinatorial logic for rotating and masking 64-bit values. It implements the operations of the rlwinm, rlwnm, rlwimi, rldicl, rldicr, rldic, rldimi, rldcl, rldcr, sld, slw, srd, srw, srad, sradi, sraw and srawi instructions. It consists of a 3-stage 64-bit rotator using 4:1 multiplexors at each stage, two mask generators, output logic and control logic. The insn_type_t values used for these instructions have been reduced to just 5: OP_RLC, OP_RLCL and OP_RLCR for the rotate and mask instructions (clear both left and right, clear left, clear right variants), OP_SHL for left shifts, and OP_SHR for right shifts. The control signals for the rotator are derived from the opcode and from the is_32bit and is_signed fields of the decode_rom_t. The rotator is instantiated as an entity in execute1 so that we can be sure we only have one of it. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end process;
end behave;