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