Order of ports in the design module should be known for a correct connection. This is very inconvenient because the order might change if a new port is added to the list or when the number of ports in the design is very large. A better way to connect ports is by explicitly linking ports on both the sides using their port name.
The dot. The signal name to which the design port has to be connected is given next within parentheses. It is recommended to code each port connection in a separate line so that any compilation error message will correctly point to the line number where the error occured.
This is much easier to debug and resolve compared to not knowing which port created the error had they been all in the same line. Because these connections are made by name, the order in which they appear is irrelevant. Multiple module instance port connections are not allowed.
Ports that are not connected to any wire in the instantiating module will have a value of high-impedance. Let us take the shift register example we had seen before , and leave some ports unconnected. Note that outputs from instances u1 and u2 are left unconnected in the RTL schematic obtained after synthesis. Since the input d to instances u2 and u3 are now connected to nets that are not being driven by anything it is grounded.
Instead of building up from smaller blocks to form bigger design blocks, the reverse can also be done.
Consider the breakdown of a simple GPU engine into smaller components such that each can be represented as a module that implements a specific feature. The GPU engine shown below can be divided into five different sub-blocks where each perform a specific functionality.
The bus interface unit gets data from outside into the design, which gets processed by another unit to extract instructions. Other units down the line process data provided by previous unit. Each sub-block can be represented as a module with a certain set of input and output signals for communication with other modules and each sub-block can be further divided into more finer blocks as required. A top-level module is one which contains all other modules.
A top-level module is not instantiated within any other module. For example, design modules are normally instantiated within top level testbench modules so that simulation can be run by providing input stimulus.
But, the testbench is not instantiated within any other module because it is a block that encapsulates everything else and hence is the top-level module. The design code shown below has a top-level module called design. This is because it contains all other sub-modules requried to make the design complete. The submodules can have more nested sub-modules like mod3 inside mod1 and mod4 inside mod2.
Anyhow, all these are included into the top level module when mod1 and mod2 are instantiated. So this makes the design complete and is the top-level module for the design. The testbench module contains stimulus to check functionality of the design and is primarily used for functional verification using simulation tools. Hence the design is instantiated and called d0 inside the testbench module.
From a simulator perspective, testbench is the top level module. A hierarchical structure is formed when modules can be instantiated inside one another, and hence the top level module is called the root. Since each lower module instantiations within a given module is required to have different identifier names, there will not be any ambiguity in accessing signals. A hierarchical name is constructed by a list of these identifiers separated by dots.
Any signal can be accessed within any module using the hierarchical path to that particular signal.
0コメント