Skip to main content

XMR: Cross Module Reference

Cross Module Reference 

Cross Module Reference abbreviated as XMR is a very useful concept in Verilog HDL (as well as system Verilog). However it seems to be less known among many users of Verilog.

XMR is a mechanism built into Verilog to globally reference (i.e., across the modules) to any nets, tasks, functions etc. Using XMR, one can refer to any object of a module in any other module, irrespective of whether they are present below or above its hierarchy. Hence, a XMR can be a:  
  • Downward reference OR
  • Upward reference 

Consider the following hierarchy: 
  •  Module A  
    • Net x  
    • Instance P of Module B   
      • Net x  
      • Instance M of Module D  
        • Net x  
    • Instance Q of Module C  
      • Net x  
      • Instance N of Module E   
        • Net x  
    • Instance R of Module B  
      • Net x  
      • Instance M of Module D  
        • Net x   

In test bench: 
  • Instance top of Module A 

In the above scenario, there is a net named x in all modules. Using XMR each x can be globally referenced anywhere within the test bench hierarchy as follows.
  •  top.x 
  •  top.P.x 
  •  top.P.M.x
  •  top.Q.x 
  • top.Q.N.
  •  top.R.x
  •  top.R.M.x 

The above references are full path based XMR, all the way from top. Such a full path name XMR starts with the top module, followed by each module instance name in the hierarchy, till the enclosing module is reached. Finally ending with name of the identifier to be referenced. A XMR can be on either side of an assignment/expression: both left hand side and right hand side. Writing full path XMRs is quite tedious thankfully Verilog  allows both upward and downward references.

Examples of XMRs:
  •  In Instance P the following XMRs are realized as follows: 
    • P.x refers to net x of Module B in instance P 
    • M.x refers to net x in instance P's instance M of module D 
    • Q.N.x refers to net x in instance Q's, instance N of module E 
      • Here, as the Q.N.x is not present in downward hierarchy, hence Verilog moves one step up the hierarchy, and then looks downwards from there. This is an example of upward reference. 
    • Q.x refers to net x in instance Q of module C
  • In Instance R the following XMRs are realized as follows: 
    • M.x refers to net x in instance R's instance of M of module D 
      • Note: M.x reference in instances P and R reference to different nets 
    • Q.N.x refers to net x in instance Q's, instance N of module E 
 Procedure for resolving XMRs: 
  1. First, search in the current module, then hierarchically downwards from here (children instances, followed by their children and so on). If found, resolve it as required XMR. 
  2. Else then, search one step up in the hierarchy (parent module) and hierarchically downwards.. If found, resolve it as required XMR. 
  3. Else repeat step 2, going further one step up in the hierarchy.  

After following above steps if Verilog is unable to resolve a XMR, it will result in a compilation error. 

In the given hierarchy, in top module M.x will result in resolution error. This is because, M.x can correspond to instance M in either P or R instances, and cannot be uniquely determined which net to refer. This issue can be resolved by using either P.M.x or R.M.x.

Uses of XMRs: 
  • Extremely useful in debug and verification. 
    • Can use XMRs to tap into any signal from anywhere in the entire design/test-suite 
    • Useful in writing coverpoints for functional coverage 
    • For debug purpose we can use XMRs to override/force any signals 

XMRs are one of the unique features that are available in Verilog (and System Verilog) compared to VHDL. 

As noted above, XMRs are not very well known for many, but having knowledge of XMRs really helps during verification and accelerates debugging. 

As a good implementation practice do not use XMRs in synthesizable RTL. Confine the use of XMRs only to debug/verification, irrespective of whether they are present in TB or modules themselves (i.e., only to non-synthesizable code).

<< Previous Home  Next >>


Pallavi karthi said…
There are many interesting information included and i can easily understand all given information.I post something on my blog to post something, or wait to post something worth saying. Keep update more information....
Journal Of Accountancy
Call For Papers
Copy Editing
Journal Of Mechanical Engineering
Civil Engineering Journals
Unknown said…

Learn about other Apache projects that are part of the Hadoop ecosystem, including Pig, Hive, HBase, ZooKeeper, Oozie, Sqoop, Flume, among others. Big Data University provides separate courses on these other projects, but we recommend you start here.

Bigdata training in Chennai OMR
Anonymous said…
Thank You for this detailed explanation. It's extremely easy to understand. Cheers!

Popular posts from this blog

Digital Design Interview Questions - All in 1

1. How do you convert a XOR gate into a buffer and a inverter (Use only one XOR gate for each)?

2. Implement an 2-input AND gate using a 2x1 mux.

3. What is a multiplexer?

A multiplexer is a combinational circuit which selects one of many input signals and directs to the only output.

4. What is a ring counter?

A ring counter is a type of counter composed of a circular shift register. The output of the last shift register is fed to the input of the first register. For example, in a 4-register counter, with initial register values of 1100, the repeating pattern is: 1100, 0110, 0011, 1001, 1100, so on.

5. Compare and Contrast Synchronous and Asynchronous reset.

Synchronous reset logic will synthesize to smaller flip-flops, particularly if the reset is gated with the logic generating the d-input. But in such a case, the combinational logic gate count grows, so the overall gate count savings may not be that significant. The clock works as a filter for small reset gl…

Gate-Level Modeling

>> Introduction
>> Gate Primitives
>> Delays
>> Examples


In Verilog HDL a module can be defined using various levels of abstraction. There are four levels of abstraction in verilog. They are:
Behavioral or algorithmic level: This is the highest level of abstraction. A module can be implemented in terms of the design algorithm. The designer no need to have any knowledge of hardware implementation.Data flow level: In this level the module is designed by specifying the data flow. Designer must how data flows between various registers of the design.Gate level: The module is implemented in terms of logic gates and interconnections between these gates. Designer should know the gate-level diagram of the design.Switch level: This is the lowest level of abstraction. The design is implemented using switches/transistors. Designer requires the knowledge of switch-level implementation details.
Gate-level modeling is virtually the lowest-level of abstraction, because t…

Synchronous Reset vs. Asynchronous Reset

Why Reset?

A Reset is required to initialize a hardware design for system operation and to force an ASIC into a known state for simulation.

A reset simply changes the state of the device/design/ASIC to a user/designer defined state. There are two types of reset, what are they? As you can guess them, they are Synchronous reset and Asynchronous reset.

Synchronous Reset

A synchronous reset signal will only affect or reset the state of the flip-flop on the active edge of the clock. The reset signal is applied as is any other input to the state machine.

The advantage to this type of topology is that the reset presented to all functional flip-flops is fully synchronous to the clock and will always meet the reset recovery time.Synchronous reset logic will synthesize to smaller flip-flops, particularly if the reset is gated with the logic generating the d-input. But in such a case, the combinational logic gate count grows, so the overall gate count savings may not be that significant…