upwards cross module reference behave incorrectly

[aegean0228]

Hi MikePopoloski:
I was looking the source code of slang , when there is upwards cross module reference, the elaboration seems doesn't work properly. below is the small case to demonstrate this issue:

module Top();
dut_0 inst_0();
dut_1 inst_1();
endmodule

module dut_0();
dut inst_dut();
dummy_1 inst_dummy();
endmodule

module dut_1();
dut inst_dut();
dummy_2 inst_dummy();
endmodule

module dummy_1();
reg[1:0] data;
endmodule

module dummy_2();
reg[7:0] data;
endmodule

module dut();
sub inst();
endmodule

module sub();
reg[1:0] data;
initial begin
data = inst_dummy.data;
end
endmodule

for module sub, there are two hierarchies : Top.inst_0.inst_dut.inst and Top.inst_1.inst_dut.inst
and there is a upwards cross module reference: inst_dummy.data in module sub.
in this case under different hierarchy , ints_dummy.data will be resolved to different type in different module.
under Top.inst_0.inst_dut.inst it will be resolved to Top.inst_0.inst_dummy.data which is reg[1:0]
under Top.inst_1.inst_dut.inst it will be resolved to Top.inst_1.inst_dummy.data which is reg[7:0]

so ideally we have to create different instanceBody for Top.inst_0.inst_dut.inst and Top.inst_1.inst_dut.inst,
but I didn't see it happened, right now we will only use parameter value + interface port to decide whether
we need create a different instanceBody which i think is not sufficient , we should also include upwards cross reference.

i was working on other commercial simulators for long time, i am pretty sure they will split the hierarchy if the target of cross module reference pointing to different type. The elaboration flow between other tools and slang is very different. They usually create an elaborated instance view of the design to help effectively processing defparam/bind/cross module reference /etc.
i don't know how slang can properly handle it without elaborated view of the design.

did you aware of this issue, any comment ?

Thanks!

[MikePopoloski]

The splitting of the module hierarchy for upward names happens in the DesignTree code after all normal elaboration is done. There appears to be a bug in it though so it's not working for your particular case. I will put it on my list of things to fix.

[aegean0228]

Hi MikePopoloski:
could you please let me know what's the entry point of DesignTree code after all normal elaboration ?
upwards cross module reference is usually a tough problem both from functionality and performance point.
i am interested in how you handle this problem

[aegean0228]

I do see there is code in getSemanticDiagnostics calling DesignTreeNode::build, i think we need duplicate the module whenever the hierarchy underneath having upwards name.
One thing I want to mention is the way slang handle defparam/upwards name could cause too many splits , and this could eventually cause compile time / capacity issues. i once worked in VCS elaborator, there are lots of effort have done to minimize the splits to fix the compile time performance issues.
another thing is if there is upwards name in parameter expression or generate conditionals (LRM is not clear about it, but it is widely used by customers, at least on simulator side), I am interested in how we are going to handle it in this situation

[MikePopoloski]

Yes, the DesignTree code duplicates modules when it detects an upward name is used, but it needs some additional tweaking to be correct for nested modules. Note that the point here is not to ensure that there exists a separate object in memory for every module instance; the goal is to make sure all possible diagnostics are issued and that the design is legal code. A further pass (yet to be written, though I started prototyping with the "mir" subsystem) would handle actually creating separate objects for each net, variable, etc.

I'm not sure what you mean by too many splits, but it's worth noting that defparams and upward names by their very nature require more compile time processing. If customers really care about maximizing compile time performance they would stop using defparams and upward names in their designs, which seems desirable anyway since they are extremely obtuse features that make it hard to understand what the code does. slang will of course support these features but I don't think I will be able to prioritize optimizing their use when there are many other more impactful things I could work on instead. If you have ideas or would like to contribute to this area the help would of course be appreciated. Or, if one of these customers with large designs using defparams wanted to pay me the hundreds of thousands of dollars they pay VCS to work on optimizing defparam performance I would be happy to reprioritize :)

[aegean0228]

Thanks for your replay.
the splits means duplication , for example as i saw in the code, when there is defparam to certain hierarchy, it will stop caching ,
that could cause duplication of instanceBody (as defparam value could be same , i am also looking forward to see how upwards name can be handle in defparam). on simulator side, there are ways to avoid module duplication even with different parameter value (same for class ).
but i agree with you support functionalities maybe more important right now. Just hope slang have a strong infrastructure which can be further extended for performance purpose.
the reason i mentioned performance is because that's the key of the a simulator, we have a small team building a simulator from scratch.
we are looking around to see if there is any open source project which we can reuse as part of frontend instead of building by ourselves.
i like the syntax tree of slang, for elaboration side, I do have some concerns as we need to support hierarchy name in compile time constant context. also i didn't see any easy and efficient way to support defparam/binds/upwards names based on current slang infrastructure.
but any way as a open source project slang did a great job so far, and i am looking forward to see how those features can be supported in future, i am still looking the code to better understand it, hope i can contribute in the future

[MikePopoloski]

I don't think it's wise to try to guess at the performance characteristics simply by looking at the code; you really need to run it against a real world example to understand how it performs. slang is already very fast for most uses, and I haven't spent much time at all optimizing it so I suspect there is a lot that could be done to improve it if desired. If you have specific examples that are slow then I'd be happy to take a closer look.

[aegean0228]

I don't have any real design right now, but i can cook some test cases to test the performance once defparam/bind/upward name are supported , because those features can usually cause performance issues