Major Tools
Other Tools
General Info

Issue #1305

Error messages do not contain hierarchical information

Added by Todd Strader 9 months ago. Updated 9 months ago.

% Done:



Please see the t_func_const2_bad test in:

I currently get this error message:
%Error: t/t_func_const2_bad.v:21: Expecting expression to be constant, but can't determine constant for FUNCREF 'f_add2'

Which gives me the line number, but not the hierarchical location of the problem. The error occurs in module 'c9', however there are multiple instances of 'c9'. It would be handy if the error message told me that the location of the problem was in 't.b8_a7.c9'.

I suspect that the most useful time to get this information would be during V3Const. However, I would ideally like to see it whenever possible.

I don't see any simple way to add this, but I could obviously be missing something. Is there a way to ask a node if it has a scope and what it is? If so, this additional reporting could be added to v3error(). If not, I could collect this information while traversing the AST for V3Const and add it to the error message when needed.

Any thoughts on how to proceed would be appreciated.

last.tree (43.6 KB) Todd Strader, 05/03/2018 06:03 PM


#1 Updated by Wilson Snyder 9 months ago

  • Category set to Lint
  • Status changed from New to Confirmed

I can see how that is useful.

In theory try from the nodep causing the error to follow backp() looking for any AstScope's. Note these only exist at some phases, elsewhere it would be a mess and non-general.

#2 Updated by Todd Strader 9 months ago

I dumped the tree (attached) at the time of the error and I also traced the backp()'s. Here is the latter:
FUNCREF 0x161c0d0 <e714#> {e21} @dt=0x160a990@(sw32)  f_add2 pkg=0x160a760 -> FUNC 0x160aa70 <e497#> {e13} @dt=0x160a990@(sw32)  f_add2
VAR 0x161bec0 <e715#> {e21} u5=0x1 @dt=0x15da5f0@(G/sw32)  SOMEP LPARAM
VAR 0x161bb90 <e708#> {e19} u4=0x42 u5=0x1 @dt=0x1609b60@(G/swu32/4)  B GPARAM
VAR 0x161b860 <e704#> {e18} u4=0x41 u5=0x1 @dt=0x1610750@(G/swu32/3)  A GPARAM
MODULE 0x161b750 <e606#> {e17} u5=0x1  c9__A7_B8  L4
MODULE 0x160dad0 <e332> {e17}  c9  L4
MODULE 0x1614e90 <e525#> {e25} u5=0x1  b8__A6  L3
MODULE 0x15db170 <e534#> {e25} u5=0x1  b8__A7  L3
MODULE 0x160f0b0 <e331> {e25} u5=0x1  b8  L3
PACKAGE 0x160a760 <e330> {a0}  __024unit  L3 [LIB]
MODULE 0x1610300 <e326> {e35} u5=0x1  t  L2
NETLIST 0x15c9c20 <e1> {a0}
I only see one SCOPENAME in the whole AST, which is somehow attached to the $fatal():
1:2:3:2: DISPLAY 0x160a2c0 <e81> {e9}
1:2:3:2:1: SFORMATF 0x160a380 <e87> {e9} u3=0x161d9b0 @dt=0x160a460@(G/str)  f_add = 15
1:2:3:2:1:2: SCOPENAME 0x15d99e0 <e400> {e9} @dt=0x15d8530@(G/w64)
1:2:3:2: STOP 0x160a590 <e89> {e9}

I don't think that is useful.

What I really seem to want is to be able to trace the CELL -> MODULE linkage. Starting here:
1: MODULE 0x161b750 <e606#> {e17} u5=0x1  c9__A7_B8  L4
Find a cell that points to the module:
1:2: CELL 0x16158f0 <e242> {e31}  c9 -> MODULE 0x161b750 <e606#> {e17} u5=0x1  c9__A7_B8  L4
Use backp() to find the parent module, repeat until you find the top:
1: MODULE 0x15db170 <e534#> {e25} u5=0x1  b8__A7  L3
1:2: CELL 0x1613080 <e311> {e43}  b8_a7 -> MODULE 0x15db170 <e534#> {e25} u5=0x1  b8__A7  L3
1: MODULE 0x1610300 <e326> {e35} u5=0x1  t  L2
 NETLIST 0x15c9c20 <e1> {a0}

Of course, this means I need to search for the CELL -> MODULE links because I don't think there are back pointers for them. I believe we can limit the searching by following backp() until we find modules and then look in the module for cells that we're searching for. I'm game if you don't think this is a crazy idea. Beyond that, we could add the module stack information to this particular stage (V3Const) because I think it's most likely that this information would be handy at this stage. But I'd prefer a more generic solution.

I also realized that there's not always going to be one right answer for what the hierarchical location of the error is since a module with a problem can be instantiated multiple times. However, I still think it's beneficial to have even one of the offending hierarchical paths.

Thoughts? I'll probably try the CELL -> MODULE reverse searching next, but if there's a better way I'd love to hear it.

#3 Updated by Wilson Snyder 9 months ago

That there are cells means the design hasn't yet been flattened. Your find-a-cell approach will only work until that happens (in V3LinkDot), then the scope scheme mentioned originally should work ok. FWIW I want to long term move to more processing happening after flattening because this will solve several internal issues and some bugs related to the late elaboration of the current method.

Also available in: Atom