Catálogo de publicaciones - libros

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.

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.

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.

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 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 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.

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.

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.

We have started “thinking OOP.” We talked about how verification is complex, and how this complexity must be managed. We talked about the goal of creating flexible, adaptable code, and how achieving this goal may complicate the code.

We got into coding a bit by talking about the separation between interface and implementation. We also touched on the subject of base classes and the different ways they can be used.

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.