Hierarchical Modeling Concepts part 1

[ Team LiB ] 2.1 Design Methodologies There are two basic types of digital design methodologies: a top-down design methodology and a bottom-up design methodology. In a top-down design methodology, we define the top-level block and identify the sub-blocks necessary to build the top-level block.
Nội dung trích xuất từ tài liệu:
Hierarchical Modeling Concepts part 1[ Team LiB ]2.1 Design MethodologiesThere are two basic types of digital design methodologies: a top-down designmethodology and a bottom-up design methodology. In a top-down design methodology,we define the top-level block and identify the sub-blocks necessary to build the top-levelblock. We further subdivide the sub-blocks until we come to leaf cells, which are thecells that cannot further be divided. Figure 2-1 shows the top-down design process. Figure 2-1. Top-down Design MethodologyIn a bottom-up design methodology, we first identify the building blocks that areavailable to us. We build bigger cells, using these building blocks. These cells are thenused for higher-level blocks until we build the top-level block in the design. Figure 2-2shows the bottom-up design process. Figure 2-2. Bottom-up Design MethodologyTypically, a combination of top-down and bottom-up flows is used. Design architectsdefine the specifications of the top-level block. Logic designers decide how the designshould be structured by breaking up the functionality into blocks and sub-blocks. At thesame time, circuit designers are designing optimized circuits for leaf-level cells. Theybuild higher-level cells by using these leaf cells. The flow meets at an intermediate pointwhere the switch-level circuit designers have created a library of leaf cells by usingswitches, and the logic level designers have designed from top-down until all modules aredefined in terms of leaf cells.To illustrate these hierarchical modeling concepts, let us consider the design of a negativeedge-triggered 4-bit ripple carry counter described in Section 2.2, 4-bit Ripple CarryCounter.[ Team LiB ][ Team LiB ]2.2 4-bit Ripple Carry CounterThe ripple carry counter shown in Figure 2-3 is made up of negative edge-triggeredtoggle flipflops (T_FF). Each of the T_FFs can be made up from negative edge-triggeredD-flipflops (D_FF) and inverters (assuming q_bar output is not available on the D_FF),as shown in Figure 2-4. Figure 2-3. Ripple Carry Counter Figure 2-4. T-flipflopThus, the ripple carry counter is built in a hierarchical fashion by using building blocks.The diagram for the design hierarchy is shown in Figure 2-5. Figure 2-5. Design HierarchyIn a top-down design methodology, we first have to specify the functionality of the ripplecarry counter, which is the top-level block. Then, we implement the counter with T_FFs.We build the T_FFs from the D_FF and an additional inverter gate. Thus, we breakbigger blocks into smaller building sub-blocks until we decide that we cannot break upthe blocks any further. A bottom-up methodology flows in the opposite direction. Wecombine small building blocks and build bigger blocks; e.g., we could build D_FF fromand and or gates, or we could build a custom D_FF from transistors. Thus, the bottom-upflow meets the top-down flow at the level of the D_FF.[ Team LiB ][ Team LiB ]2.3 ModulesWe now relate these hierarchical modeling concepts to Verilog. Verilog provides theconcept of a module. A module is the basic building block in Verilog. A module can bean element or a collection of lower-level design blocks. Typically, elements are groupedinto modules to provide common functionality that is used at many places in the design.A module provides the necessary functionality to the higher-level block through its portinterface (inputs and outputs), but hides the internal implementation. This allows thedesigner to modify module internals without affecting the rest of the design.In Figure 2-5, ripple carry counter, T_FF, D_FF are examples of modules. In Verilog, amodule is declared by the keyword module. A corresponding keyword endmodule mustappear at the end of the module definition. Each module must have a module_name,which is the identifier for the module, and a module_terminal_list, which describes theinput and output terminals of the module.module ();.........endmoduleSpecifically, the T-flipflop could be defined as a module as follows:module T_FF (q, clock, reset);....endmoduleVerilog is both a behavioral and a structural language. Internals of each module can bedefined at four levels of abstraction, depending on the needs of the design. The modulebehaves identically with the external environment irrespective of the level of abstractionat which the module is described. The internals of the module are hidden from theenvironment. Thus, the level of abstraction to describe a module can be changed withoutany change in the environment. These levels will be studied in detail in separate chapterslater in the book. The levels are defined below. • Behavioral or algorithmic level This is the highest level of abstraction provided by Verilog HDL. A module can be implemented in terms of the desired design algorithm without concern for the hardware implementation details. Designing at this level is very similar to C programming. • Dataflow level At this level, the module is designed by specifying the data flow. The designer is aware of how data flows between hardware registers and how the data is processed in the design. • Gate level The module is implemented in terms of logic gates and interconnections between these gates. Design at this level is similar to describing a design in terms of a gate- level logic diagram. • Switch level This is the lowest level of abstraction provided by Verilog. A module can be implemented in terms of switches, storage nodes, and the interconnections between them. Design at this level requires knowledge of switch-level implementation details.Verilog allows the des ...