102
4 Verification and Testing
referred to as “black events”, which have data from collisions with an exceptionally
high amount of particle tracks.
As the testbench has been designed modularly, it is possible to include several
devices in a chain if needed. This only requires instantiating new modules and routing
the intercommunicating signals, if needed. However, the MCH only required two
devices in a chain for the final design [12].
The BFMs previously created for the module-based testbenches are also reused in
the system level testbench. This includes the JTAG and I
2 C BFMs. Additional BFMs
have been created for reading and writing from both the global register, channel
register, pedestal memory, and channel order register.
Configuring of the device happens through I
2 C and since it only operates at maximum 1 MHZ, it takes significant time to set up configurations for different tests.
To avoid this, the testbench instead forces values onto the internal signals between
the I
2 C module and the register module inside the SAMPA once the testbench has
been confirmed to be working satisfactorily in a separate test. Forcing and spying on
signals is a feature available in the 2008 version of VHDL, but the Cadence simulator
has unfortunately only limited support for VHDL-2008. Both Mentor and Cadence,
however, support these features through their own special function calls that are not
part of the standard. To make the testbench environment uniform across simulators, a
generic package per simulator has been created. It wraps each of these special function with a generic function name so that the testbench can call the functions with
a generic name and during compile, only the package file for the specific simulator
is included which has the version for the generic function translated to the internal
one. In this way, the testbench can be simulator agnostic.
The testbench sequence is mainly focused on verifying the functionality of the
design and the extensive verification is left to the module-based testbenches. The
testbench verifies that all interfaces to the device functions, this includes I
2 C, JTAG,
memory tester, scan chain, clocks, resets, and triggers. It also verifies all data output
modes, this would be the direct readout serialization, the packet based serialization,
and the daisy chaining. Additionally, it verifies that all test-modes like the bypass
mode, ring buffer, direct readout combinatorial, etc. operate correctly. Overall, this
covers the operational functionality of close to everything that can be controlled
externally.
4.1.3.1 Scan Chain Verification
To minimize the workload and to avoid errors, the scan chain insertion, see Sect. 3.3.1,
was done by a tool (Cadence Encounter Test, now Modus [13]) instead of manual
insertion. In addition to the scan chain insertion, the tool also creates vectors for
testing the design and creates a Verilog testbench that runs the complete vector test
on the digital code. To verify that the generated vectors do not produce any false
errors, the testbench was run on the gate level code with timing. To additionally
verify that the fault-finding algorithm correctly detects an error, a wire was deleted
4 Verification and Testing
referred to as “black events”, which have data from collisions with an exceptionally
high amount of particle tracks.
As the testbench has been designed modularly, it is possible to include several
devices in a chain if needed. This only requires instantiating new modules and routing
the intercommunicating signals, if needed. However, the MCH only required two
devices in a chain for the final design [12].
The BFMs previously created for the module-based testbenches are also reused in
the system level testbench. This includes the JTAG and I
2 C BFMs. Additional BFMs
have been created for reading and writing from both the global register, channel
register, pedestal memory, and channel order register.
Configuring of the device happens through I
2 C and since it only operates at maximum 1 MHZ, it takes significant time to set up configurations for different tests.
To avoid this, the testbench instead forces values onto the internal signals between
the I
2 C module and the register module inside the SAMPA once the testbench has
been confirmed to be working satisfactorily in a separate test. Forcing and spying on
signals is a feature available in the 2008 version of VHDL, but the Cadence simulator
has unfortunately only limited support for VHDL-2008. Both Mentor and Cadence,
however, support these features through their own special function calls that are not
part of the standard. To make the testbench environment uniform across simulators, a
generic package per simulator has been created. It wraps each of these special function with a generic function name so that the testbench can call the functions with
a generic name and during compile, only the package file for the specific simulator
is included which has the version for the generic function translated to the internal
one. In this way, the testbench can be simulator agnostic.
The testbench sequence is mainly focused on verifying the functionality of the
design and the extensive verification is left to the module-based testbenches. The
testbench verifies that all interfaces to the device functions, this includes I
2 C, JTAG,
memory tester, scan chain, clocks, resets, and triggers. It also verifies all data output
modes, this would be the direct readout serialization, the packet based serialization,
and the daisy chaining. Additionally, it verifies that all test-modes like the bypass
mode, ring buffer, direct readout combinatorial, etc. operate correctly. Overall, this
covers the operational functionality of close to everything that can be controlled
externally.
4.1.3.1 Scan Chain Verification
To minimize the workload and to avoid errors, the scan chain insertion, see Sect. 3.3.1,
was done by a tool (Cadence Encounter Test, now Modus [13]) instead of manual
insertion. In addition to the scan chain insertion, the tool also creates vectors for
testing the design and creates a Verilog testbench that runs the complete vector test
on the digital code. To verify that the generated vectors do not produce any false
errors, the testbench was run on the gate level code with timing. To additionally
verify that the fault-finding algorithm correctly detects an error, a wire was deleted