Figure 2-1 shows that the e hierarchy and the design hierarchy (Verilog or VHDL) are two independent trees. The e hierarchy is focused on creating verification components. The Verilog or VHDL hierarchy represents the logic design components. For example, a Verilog design hierarchy consists of modules and module instances. Similarly, the e hierarchy consists of struct and struct instances. Figure 2-2 shows an example of e and Verilog hierarchies in the same simulation run.
As shown in Figure 2-2, the top of the e verification hierarchy is a struct called sys.[4] This is an implicitly defined struct in Specman Elite. In Verilog, the top level module can be given any name and it needs to defined explicitly. In e, the top level struct is always sys, and it is always defined implicitly. However, all other structs are instantiated explicitly inside sys. All structs such as driver1, checker1, and receiver1 that are defined in the e environment must be instantiated in the sys tree structure just as design modules such as IU, IBU, FPU need to be instantiated in the tree structure of the DUT which is located under the top level Verilog module. Example 2-1 shows how the described hierarchy is built in e code. A struct is defined for each verification component. Then the struct is instantiated under higher level structs. Finally, the highest level structs are instantiated under sys.
[4] In reality, sys is a unit. We have yet not introduced the concepts of units, so we refer to sys as a struct. Moreover, there are other structs above sys. However, from a verification engineer's perspective, sys represents the tree where the verification environment is built.
<' //Indicates starting of e code struct data { //Define the data struct. To be instantiated inside //checker -- <data internals> -- }; struct protocol {//Define the protocol struct. To be instantiated //inside checker -- <protocol internals> -- }; struct collect { //Define the collect struct. To be instantiated //inside receiver -- <collect internals> -- }; struct error { //Define the error struct. To be instantiated //inside receiver -- <error internals> -- }; struct driver { -- <driver internals> -- }; struct checker { data1: data; // Instantiate the struct data and call it data1 protocol1: protocol; // Instantiate the struct protocol and // call it protocol1 -- <checker internals> -- }; struct receiver { collect1: collect; // Instantiate the struct collect and // call it collect1 error1: error; // Instantiate the struct error and // call it error1 -- <receiver internals> -- }; extend sys { //sys is implicitly defined. So extend it to add //new instantiations. This is the topmost struct //for the verification environment. driver1: driver; checker1: checker; receiver1: receiver; }; //End of e code '>
As shown in Example 2-1 above, the extend keyword is used to add additional instances to sys. Similarly, the extend keyword can be used to enhance the definition of any user-defined struct. Thus e lends itself very well to a layered development approach. The functionality for the base structs can be extracted from the design specification. Any test-specific changes can then be added separately using the extend mechanism for the structs.
The following section explains the various components in a typical verification environment.