Catálogo de publicaciones - libros

We have started down the path of using OOP in a verification system. We talked about the main theme, creating roles and responsibilities by using abstraction. We talked about the common design biases used when we design a verification system.

You probably are still surrounded by clouds of uncertainty. This is understandable. The next chapters are more specific, talking about making classes and the different ways to connect them.

For now, however, know that designing with OOP is about defining roles and responsibilities and making levels of abstraction, a “layering” for which there are many examples in our everyday lives. To achieve your own design objectives in silicon, use your experience to guide the process.

On the basis of their ever-expanding roles, not only in sensory signaling but also in a plethora of other, often Ca-mediated actions in cell and whole body homeostasis, it is suggested that mutations in TRP channel genes not only cause disease states but also contribute in more subtle ways to simple and complex diseases. A survey is therefore presented of diseases and syndromes that map to one or multiple chromosomal loci containing TRP channel genes. A visual map of the chromosomal locations of TRP channel genes in man and mouse is also presented.

This Chapter introduced Truss, an open-source application framework.

We revisited the benefits of an OOP language such as C++, but stressed the need to keep things simple despite the power of this language, to avoid writing code that is unnecessarily complicated.

We talked about the key algorithm of verification, which the authors called the “dance.” We showed how the dance is used by the verification_top() program to run a test. We discussed the roles and responsibilities of the test, testbench, and watchdog timer, the main parts of the top-level dance.

We discussed the verification_component abstract base class, which provides pure virtual methods for the dance.

We then discussed the test_componentand irritatorclasses, including their responsibilities and interfaces.

This Chapter talked about layers. We talked about using layers to increase productivity, by managing the complexity of a verification system.

We talked about “ends-in” coding, where you start at the bottom and top of the test and code towards the middle. We considered this technique of looking at the chip and creating Interface layers as the first step in creating a verification system. We then went to the top layer, and talked about the verification top and the three top components: the watchdog timer, the test, and the testbench.

Next, we entered the middle layer, where we talked about using a test component to exercise a particular configuration or data path of a chip interface. The idea that a test really should have several interfaces exercised at once formed the reasoning behind the irritator layer.

We ended the Chapter with a quick tour of a completed test, noting that there are still more decisions to be made as the implementation of the verification system proceeds.

This chapter took a look at a system-level verification system. We adapted the components from the block-level test.

The first test that was talked, just re-used the test_component from the block-level test on all four UART interfaces.

The next test brought in the concept of irritators, background traffic for a main test focus.

The system-level test quad_uart_vectors was used to show how the template library can be harnessed to make small, efficient standard-form code.

In general, this chapter showed that many of the block-level components could be adapted without modification to the code. We did, however, need to modify the uart_16550_sfm to handle a specific address range.

We have started down the path of using OOP in a verification system. We talked about the main theme, creating roles and responsibilities by using abstraction. We talked about the common design biases used when we design a verification system.

You probably are still surrounded by clouds of uncertainty. This is understandable. The next chapters are more specific, talking about making classes and the different ways to connect them.

For now, however, know that designing with OOP is about defining roles and responsibilities and making levels of abstraction, a “layering” for which there are many examples in our everyday lives. To achieve your own design objectives in silicon, use your experience to guide the process.