Log book 1

The ALU was designed in a structural, modular fashion using mostly discretely instantiatied components. This improved readability and gave a clear indication of module hierarchy at the expense of design time.

The testbench used looping processes for both applying stimulus from external test vectors, as well as evaluating outputs against reference results. This method was chosen in order to more easily handle the 2 clock period discrepancy between stimulus and response. Assert statements were used to terminate the simulation upon an unexpected result or if all 1000 test vectors completed successfully. A report statement was also used to print relevant debugging information in case of a failure (or successful termination).

Both ALU variants passed functional verification using the "ncsim" suite of programs (ncvhdl for compilation, ncelab for elaboration and ncsim for simulation) and the "random" set of test vectors.

These programs were run multiple times as the source code was iteratively tweaked, and a shell script was thus used to automate this process.

The coverage of the functional verification was examined by adding coverage flags to the elaboration program (ncelab) and then inspecting the code graphically using Incisive Metrics Center (IMC) with respect to block and toggle coverage. 

The ALU did not receive 100% coverage and nor was it expected. 3 of 16 opcode combinations are unspecified and were thus excluded from the test vectors. Since the operation selection is implemented using multiplexers, 3 multiplexer "branches" are uncovered. Furthermore, bit-vectors that are hard-coded (though not declared as constants), such as bits 31 downto 1 of the SLT and SLTU outputs, are NOT considered to have toggle coverage, as they technically are modifiable. Finally, unused and inactive code remnants detract from the toggle coverage rating.

All of these issues can be addressed by disabling the coverage analysis for certain blocks of code that the designer knows to be inconsequential.

The model used to deterine the coverage metrics does, however, not extend to the notion of time and delays or behaviour stemming from certain combinations of inputs (and therefore combinations of activated circuits at the transistor level).



--======= Learning Outcomes =======--
-- Design, verify and debug an ALU and other units of such complexity, with associated testbench, using your updated hardware description language skills.

-- Describe what functional verification and what logic simulation is.

-- Describe the purpose of teestbenches for functional verification.

-- Describe what code coverage is.

-- Perform basic functional verification using an industrial EDA tool for logic simulation.

-- Elaborate on the issue of code coverage in logic simulation; that is, how many test vectors does it relly take to know that we have verifies a design.