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 '5a3cdc8b22'
${ noResults }
microwatt/divider_tb.vhdl

524 lines
23 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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. 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.decode_types.all;
use work.common.all;
use work.ppc_fx_insns.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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
entity divider_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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end divider_tb;
architecture behave of divider_tb is
signal clk : std_ulogic;
signal rst : std_ulogic;
constant clk_period : time := 10 ns;
Make divider hang off the side of execute1 With this, the divider is a unit that execute1 sends operands to and which sends its results back to execute1, which then send them to writeback. Execute1 now sends a stall signal when it gets a divide or modulus instruction until it gets a valid signal back from the divider. Divide and modulus instructions are no longer marked as single-issue. The data formatting step that used to be done in decode2 for div and mod instructions is now done in execute1. We also do the absolute value operation in that same cycle instead of taking an extra cycle inside the divider for signed operations with a negative operand. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
signal d1 : Execute1ToDividerType;
signal d2 : DividerToExecute1Type;
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
begin
divider_0: entity work.divider
port map (clk => clk, rst => rst, d_in => d1, d_out => d2);
clk_process: process
begin
clk <= '0';
wait for clk_period/2;
clk <= '1';
wait for clk_period/2;
end process;
stim_process: process
variable ra, rb, rt, behave_rt: std_ulogic_vector(63 downto 0);
variable si: std_ulogic_vector(15 downto 0);
variable d128: std_ulogic_vector(127 downto 0);
variable q128: std_ulogic_vector(127 downto 0);
divider: Return 0 for invalid and overflow cases, like P9 does This adds logic to detect the cases where the quotient of the division overflows the range of the output representation, and return all zeroes in those cases, which is what POWER9 does. To do this, we extend the dividend register by 1 bit and we do an extra step in the division process to get a 2^64 bit of the quotient, which ends up in the 'overflow' signal. This catches all the cases where dividend >= 2^64 * divisor, including the case where divisor = 0, and the divde/divdeu cases where |RA| >= |RB|. Then, in the output stage, we also check that the result fits in the representable range, which depends on whether the division is a signed division or not, and whether it is a 32-bit or 64-bit division. If dividend >= 2^64 or the result doesn't fit in the representable range, write_data is set to 0 and write_cr_data to 0x20000000 (i.e. cr0.eq = 1). POWER9 sets the top 32 bits of the result to zero for 32-bit signed divisions, and sets CR0 when RC=1 according to the 64-bit value (i.e. CR0.LT is always 0 for 32-bit signed divisions, even if the 32-bit result is negative). However, modsw with a negative result sets the top 32 bits to all 1s. We follow suit. This updates divider_tb to check the invalid cases as well as the valid case. This also fixes a small bug where the reset signal for the divider was driven from rst when it should have been driven from core_rst. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
variable q64: std_ulogic_vector(63 downto 0);
variable rem32: std_ulogic_vector(31 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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. 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);
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
rst <= '1';
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
wait for clk_period;
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
rst <= '0';
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. 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
d1.is_signed <= '0';
d1.neg_result <= '0';
d1.is_extended <= '0';
d1.is_32bit <= '0';
d1.is_modulus <= '0';
d1.valid <= '0';
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. 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
if run("Test interface") then
d1.valid <= '1';
d1.dividend <= x"0000000010001000";
d1.divisor <= x"0000000000001111";
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. 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
wait for clk_period;
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_false(?? d2.valid, result("for valid"));
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. 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
d1.valid <= '0';
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. 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
for j in 0 to 66 loop
wait for clk_period;
if d2.valid = '1' then
exit;
end if;
end loop;
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
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_true(?? d2.valid, result("for valid"));
check_equal(d2.write_reg_data, 16#f001#);
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. 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
wait for clk_period;
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_false(?? d2.valid, result("for valid"));
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. 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
d1.valid <= '1';
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. 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
wait for clk_period;
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_false(?? d2.valid, result("for valid"));
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. 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
d1.valid <= '0';
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. 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
for j in 0 to 66 loop
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
wait for clk_period;
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
if d2.valid = '1' then
exit;
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end if;
end loop;
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_true(?? d2.valid, result("for valid"));
check_equal(d2.write_reg_data, 16#f001#);
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
wait for clk_period;
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_false(?? d2.valid, result("for valid"));
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 divd") then
divd_loop : for dlength in 1 to 8 loop
for vlength in 1 to dlength loop
for i in 0 to 100 loop
ra := std_ulogic_vector(resize(signed(rnd.RandSlv(dlength * 8)), 64));
rb := std_ulogic_vector(resize(signed(rnd.RandSlv(vlength * 8)), 64));
d1.dividend <= ra when ra(63) = '0' else std_ulogic_vector(- signed(ra));
d1.divisor <= rb when rb(63) = '0' else std_ulogic_vector(- signed(rb));
d1.is_signed <= '1';
d1.neg_result <= ra(63) xor rb(63);
d1.valid <= '1';
wait for clk_period;
d1.valid <= '0';
for j in 0 to 66 loop
wait for clk_period;
if d2.valid = '1' then
exit;
end if;
end loop;
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_true(?? d2.valid, result("for valid"));
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
behave_rt := (others => '0');
if rb /= x"0000000000000000" and (ra /= x"8000000000000000" or rb /= x"ffffffffffffffff") then
behave_rt := ppc_divd(ra, rb);
end if;
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(d2.write_reg_data, behave_rt, result("for divd"));
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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end loop;
end loop;
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 divdu") then
divdu_loop : for dlength in 1 to 8 loop
for vlength in 1 to dlength loop
for i in 0 to 100 loop
ra := std_ulogic_vector(resize(unsigned(rnd.RandSlv(dlength * 8)), 64));
rb := std_ulogic_vector(resize(unsigned(rnd.RandSlv(vlength * 8)), 64));
d1.dividend <= ra;
d1.divisor <= rb;
d1.valid <= '1';
wait for clk_period;
d1.valid <= '0';
for j in 0 to 66 loop
wait for clk_period;
if d2.valid = '1' then
exit;
end if;
end loop;
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_true(?? d2.valid, result("for valid"));
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
behave_rt := (others => '0');
if rb /= x"0000000000000000" then
behave_rt := ppc_divdu(ra, rb);
end if;
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(d2.write_reg_data, behave_rt, result("for divdu"));
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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end loop;
end loop;
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 divde") then
divde_loop : for vlength in 1 to 8 loop
for dlength in 1 to vlength loop
for i in 0 to 100 loop
ra := std_ulogic_vector(resize(signed(rnd.RandSlv(dlength * 8)), 64));
rb := std_ulogic_vector(resize(signed(rnd.RandSlv(vlength * 8)), 64));
d1.dividend <= ra when ra(63) = '0' else std_ulogic_vector(- signed(ra));
d1.divisor <= rb when rb(63) = '0' else std_ulogic_vector(- signed(rb));
d1.is_signed <= '1';
d1.neg_result <= ra(63) xor rb(63);
d1.is_extended <= '1';
d1.valid <= '1';
wait for clk_period;
d1.valid <= '0';
for j in 0 to 66 loop
wait for clk_period;
if d2.valid = '1' then
exit;
end if;
end loop;
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_true(?? d2.valid, result("for valid"));
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
behave_rt := (others => '0');
if rb /= x"0000000000000000" then
d128 := ra & x"0000000000000000";
q128 := std_ulogic_vector(signed(d128) / signed(rb));
if q128(127 downto 63) = x"0000000000000000" & '0' or
q128(127 downto 63) = x"ffffffffffffffff" & '1' then
behave_rt := q128(63 downto 0);
end if;
end if;
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(d2.write_reg_data, behave_rt, result("for divde"));
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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end loop;
end loop;
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 divdeu") then
divdeu_loop : for vlength in 1 to 8 loop
for dlength in 1 to vlength loop
for i in 0 to 100 loop
ra := std_ulogic_vector(resize(unsigned(rnd.RandSlv(dlength * 8)), 64));
rb := std_ulogic_vector(resize(unsigned(rnd.RandSlv(vlength * 8)), 64));
d1.dividend <= ra;
d1.divisor <= rb;
d1.is_extended <= '1';
d1.valid <= '1';
wait for clk_period;
d1.valid <= '0';
for j in 0 to 66 loop
wait for clk_period;
if d2.valid = '1' then
exit;
end if;
end loop;
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_true(?? d2.valid, result("for valid"));
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
behave_rt := (others => '0');
if unsigned(rb) > unsigned(ra) then
d128 := ra & x"0000000000000000";
q128 := std_ulogic_vector(unsigned(d128) / unsigned(rb));
behave_rt := q128(63 downto 0);
end if;
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(d2.write_reg_data, behave_rt, result("for divdeu"));
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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end loop;
end loop;
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 divw") then
divw_loop : for dlength in 1 to 4 loop
for vlength in 1 to dlength loop
for i in 0 to 100 loop
ra := std_ulogic_vector(resize(signed(rnd.RandSlv(dlength * 8)), 64));
rb := std_ulogic_vector(resize(signed(rnd.RandSlv(vlength * 8)), 64));
d1.dividend <= ra when ra(63) = '0' else std_ulogic_vector(- signed(ra));
d1.divisor <= rb when rb(63) = '0' else std_ulogic_vector(- signed(rb));
d1.is_signed <= '1';
d1.neg_result <= ra(63) xor rb(63);
d1.is_32bit <= '1';
d1.valid <= '1';
wait for clk_period;
d1.valid <= '0';
for j in 0 to 66 loop
wait for clk_period;
if d2.valid = '1' then
exit;
end if;
end loop;
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_true(?? d2.valid, result("for valid"));
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
behave_rt := (others => '0');
if rb /= x"0000000000000000" and (ra /= x"ffffffff80000000" or rb /= x"ffffffffffffffff") then
behave_rt := ppc_divw(ra, rb);
end if;
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(d2.write_reg_data, behave_rt, result("for divw"));
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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end loop;
end loop;
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 divwu") then
divwu_loop : for dlength in 1 to 4 loop
for vlength in 1 to dlength loop
for i in 0 to 100 loop
ra := std_ulogic_vector(resize(unsigned(rnd.RandSlv(dlength * 8)), 64));
rb := std_ulogic_vector(resize(unsigned(rnd.RandSlv(vlength * 8)), 64));
d1.dividend <= ra;
d1.divisor <= rb;
d1.is_32bit <= '1';
d1.valid <= '1';
wait for clk_period;
d1.valid <= '0';
for j in 0 to 66 loop
wait for clk_period;
if d2.valid = '1' then
exit;
end if;
end loop;
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_true(?? d2.valid, result("for valid"));
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
behave_rt := (others => '0');
if rb /= x"0000000000000000" then
behave_rt := ppc_divwu(ra, rb);
end if;
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(d2.write_reg_data, behave_rt, result("for divwu"));
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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end loop;
end loop;
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 divwe") then
divwe_loop : for vlength in 1 to 4 loop
for dlength in 1 to vlength loop
for i in 0 to 100 loop
ra := std_ulogic_vector(resize(signed(rnd.RandSlv(dlength * 8)), 32)) & x"00000000";
rb := std_ulogic_vector(resize(signed(rnd.RandSlv(vlength * 8)), 64));
d1.dividend <= ra when ra(63) = '0' else std_ulogic_vector(- signed(ra));
d1.divisor <= rb when rb(63) = '0' else std_ulogic_vector(- signed(rb));
d1.is_signed <= '1';
d1.neg_result <= ra(63) xor rb(63);
d1.is_32bit <= '1';
d1.valid <= '1';
wait for clk_period;
d1.valid <= '0';
for j in 0 to 66 loop
wait for clk_period;
if d2.valid = '1' then
exit;
end if;
end loop;
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_true(?? d2.valid, result("for valid"));
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
behave_rt := (others => '0');
if rb /= x"0000000000000000" then
q64 := std_ulogic_vector(signed(ra) / signed(rb));
if q64(63 downto 31) = x"00000000" & '0' or
q64(63 downto 31) = x"ffffffff" & '1' then
behave_rt := x"00000000" & q64(31 downto 0);
end if;
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(d2.write_reg_data, behave_rt, result("for divwe"));
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 if;
end loop;
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end loop;
end loop;
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 divweu") then
divweu_loop : for vlength in 1 to 4 loop
for dlength in 1 to vlength loop
for i in 0 to 100 loop
ra := std_ulogic_vector(resize(unsigned(rnd.RandSlv(dlength * 8)), 32)) & x"00000000";
rb := std_ulogic_vector(resize(unsigned(rnd.RandSlv(vlength * 8)), 64));
d1.dividend <= ra;
d1.divisor <= rb;
d1.is_32bit <= '1';
d1.valid <= '1';
wait for clk_period;
d1.valid <= '0';
for j in 0 to 66 loop
wait for clk_period;
if d2.valid = '1' then
exit;
end if;
end loop;
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_true(?? d2.valid, result("for valid"));
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
behave_rt := (others => '0');
if unsigned(rb(31 downto 0)) > unsigned(ra(63 downto 32)) then
behave_rt := std_ulogic_vector(unsigned(ra) / unsigned(rb));
end if;
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(d2.write_reg_data, behave_rt, result("for divweu"));
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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end loop;
end loop;
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 modsd") then
modsd_loop : for dlength in 1 to 8 loop
for vlength in 1 to dlength loop
for i in 0 to 100 loop
ra := std_ulogic_vector(resize(signed(rnd.RandSlv(dlength * 8)), 64));
rb := std_ulogic_vector(resize(signed(rnd.RandSlv(vlength * 8)), 64));
d1.dividend <= ra when ra(63) = '0' else std_ulogic_vector(- signed(ra));
d1.divisor <= rb when rb(63) = '0' else std_ulogic_vector(- signed(rb));
d1.is_signed <= '1';
d1.neg_result <= ra(63);
d1.is_modulus <= '1';
d1.valid <= '1';
wait for clk_period;
d1.valid <= '0';
for j in 0 to 66 loop
wait for clk_period;
if d2.valid = '1' then
exit;
end if;
end loop;
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_true(?? d2.valid, result("for valid"));
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
behave_rt := (others => '0');
if rb /= x"0000000000000000" then
behave_rt := std_ulogic_vector(signed(ra) rem signed(rb));
end if;
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(d2.write_reg_data, behave_rt, result("for modsd"));
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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end loop;
end loop;
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 modud") then
modud_loop : for dlength in 1 to 8 loop
for vlength in 1 to dlength loop
for i in 0 to 100 loop
ra := std_ulogic_vector(resize(unsigned(rnd.RandSlv(dlength * 8)), 64));
rb := std_ulogic_vector(resize(unsigned(rnd.RandSlv(vlength * 8)), 64));
d1.dividend <= ra;
d1.divisor <= rb;
d1.is_modulus <= '1';
d1.valid <= '1';
wait for clk_period;
d1.valid <= '0';
for j in 0 to 66 loop
wait for clk_period;
if d2.valid = '1' then
exit;
end if;
end loop;
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_true(?? d2.valid, result("for valid"));
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
behave_rt := (others => '0');
if rb /= x"0000000000000000" then
behave_rt := std_ulogic_vector(unsigned(ra) rem unsigned(rb));
end if;
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(d2.write_reg_data, behave_rt, result("for modud"));
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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end loop;
end loop;
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 modsw") then
modsw_loop : for dlength in 1 to 4 loop
for vlength in 1 to dlength loop
for i in 0 to 100 loop
ra := std_ulogic_vector(resize(signed(rnd.RandSlv(dlength * 8)), 64));
rb := std_ulogic_vector(resize(signed(rnd.RandSlv(vlength * 8)), 64));
d1.dividend <= ra when ra(63) = '0' else std_ulogic_vector(- signed(ra));
d1.divisor <= rb when rb(63) = '0' else std_ulogic_vector(- signed(rb));
d1.is_signed <= '1';
d1.neg_result <= ra(63);
d1.is_32bit <= '1';
d1.is_modulus <= '1';
d1.valid <= '1';
wait for clk_period;
d1.valid <= '0';
for j in 0 to 66 loop
wait for clk_period;
if d2.valid = '1' then
exit;
end if;
end loop;
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_true(?? d2.valid, result("for valid"));
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
behave_rt := (others => '0');
if rb /= x"0000000000000000" then
rem32 := std_ulogic_vector(signed(ra(31 downto 0)) rem signed(rb(31 downto 0)));
if rem32(31) = '0' then
behave_rt := x"00000000" & rem32;
else
behave_rt := x"ffffffff" & rem32;
end if;
end if;
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(d2.write_reg_data, behave_rt, result("for modsw"));
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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end loop;
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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. 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 moduw") then
moduw_loop : for dlength in 1 to 4 loop
for vlength in 1 to dlength loop
for i in 0 to 100 loop
ra := std_ulogic_vector(resize(unsigned(rnd.RandSlv(dlength * 8)), 64));
rb := std_ulogic_vector(resize(unsigned(rnd.RandSlv(vlength * 8)), 64));
d1.dividend <= ra;
d1.divisor <= rb;
d1.is_32bit <= '1';
d1.is_modulus <= '1';
d1.valid <= '1';
wait for clk_period;
d1.valid <= '0';
for j in 0 to 66 loop
wait for clk_period;
if d2.valid = '1' then
exit;
end if;
end loop;
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_true(?? d2.valid, result("for valid"));
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
behave_rt := (others => '0');
if rb /= x"0000000000000000" then
behave_rt := x"00000000" & std_ulogic_vector(unsigned(ra(31 downto 0)) rem unsigned(rb(31 downto 0)));
end if;
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(d2.write_reg_data(31 downto 0), behave_rt(31 downto 0), result("for moduw"));
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 loop;
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end loop;
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 if;
Add a divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. 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 divider unit and a testbench for it This adds a divider unit, connected to the core in much the same way that the multiplier unit is connected. The division algorithm is very simple-minded, taking 64 clock cycles for any division (even 32-bit division instructions). The decoding is simplified by making use of regularities in the instruction encoding for div* and mod* instructions. Instead of having PPC_* encodings from the first-stage decoder for each of the different div* and mod* instructions, we now just have PPC_DIV and PPC_MOD, and the inputs to the divider that indicate what sort of division operation to do are derived from instruction word bits. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
5 years ago
end process;
end behave;