Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-11-14T21:04:40Z

Verilog-perl has some of this information, but from what you describe I would suggest first looking at Verilator's --xml output, which assuming your code is synthesizable should give you all you need to feed your analysis script.

Original Redmine Comment
Author Name: Aimless Ramble
Original Date: 2019-11-15T20:41:34Z

Wilson Snyder wrote:

Verilog-perl has some of this information, but from what you describe I would suggest first looking at Verilator's --xml output, which assuming your code is synthesizable should give you all you need to feed your analysis script.

Hi Wilson,

Thanks for your comments. I dug up the Verlator's XML output. It does capture input/output signals and modules etc, but it doesn't capture internal behavioral source/destination and thus it doesn't give a source/destination connectivity picture from internal nodes.

Would you be able to recommend a base where we can start this on - Verilog-Perl, Verilator (still) or something based on Bison or ANTLR grammar.

For clarity, I am attaching a paper which talks how different signal source/destination is monitored. (Counting dangles isn't our goal, but we need this picture.)

Any help will be greatly appreciated.

Regards.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-11-15T20:48:36Z

But it doesn't capture internal behavioral source/destination

It does, for example see the varref (references to variables aka wires/reg/logic) in the below:

       <always fl="d39">
         <sentree fl="d39">
           <senitem fl="d39" edgeType="POS">
             <varref fl="d39" name="clk" dtype_id="1"/>
           </senitem>
         </sentree>
         <assigndly fl="d40" dtype_id="2">
           <varref fl="d40" name="d" dtype_id="2"/>
           <varref fl="d40" name="q" dtype_id="2"/>
         </assigndly>

Original Redmine Comment
Author Name: Aimless Ramble
Original Date: 2019-11-16T19:25:41Z

Wilson Snyder wrote:

But it doesn't capture internal behavioral source/destination

It does, for example see the varref (references to variables aka wires/reg/logic) in the below:

[...]

Hi - thanks for your input. I have added an example behavioral code and corresponding XML from Verilator.

I can identify the always blocks out there and incoming and outgoing signals to it. But the bit-fields are missing. so which bits in LHS and RHS signals are involved in operation isn't mentioned.

I hope I am not missing something basic.

Do I need to add that support myself. And secondly, is there a manual of XML syntax of Verilator. (The normal user manual doesn't mention this in detail.)

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-11-16T20:18:19Z

All the bits are used, unless there is a "sel" (select) operation which pulls off a subset of the bits that are specified in that operation.

Unfortunately there isn't XML documentation currently, though it's based on the AstNode structure which has a (small) number of comments in V3AstNodes.h. The easiest thing to do is run examples and see what you get. Contributions to document it sorely needed & welcome. Sorry.

Original Redmine Comment
Author Name: Aimless Ramble
Original Date: 2019-11-17T18:39:48Z

Wilson Snyder wrote:

All the bits are used, unless there is a "sel" (select) operation which pulls off a subset of the bits that are specified in that operation.

Unfortunately there isn't XML documentation currently, though it's based on the AstNode structure which has a (small) number of comments in V3AstNodes.h. The easiest thing to do is run examples and see what you get. Contributions to document it sorely needed & welcome. Sorry.

Thanks Wilson.
I deliberately added different bit combinations (not sure if you got a chance to look into the attached .v file) of inputs in RHS to form LHS. To best of my understanding in the XML, it didn't put those together.

I'll go over the .h and corresponding classes to understand it more.

Will love to contribute more towards documentation. However my current depth of understanding/capacity is too limited to contribute. It will be a bit more time before we reach there.