Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A Signal Connectivity Parser Within a Verilog Module #1599

Closed
veripoolbot opened this issue Nov 14, 2019 · 6 comments
Closed

A Signal Connectivity Parser Within a Verilog Module #1599

veripoolbot opened this issue Nov 14, 2019 · 6 comments

Comments

@veripoolbot
Copy link

@veripoolbot veripoolbot commented Nov 14, 2019


Author Name: Aimless Ramble
Original Redmine Issue: 1599 from https://www.veripool.org


I have trying to form a signal connectivity Parser within a Module file. It Can read (one or multiple) Verilog files and do following -

Understand a module and find different source and destinations inside that module. Different Signal Source and Desination inside A Verilog file (from a very good paper by Jianguo SONG et al)-
- Combo block
- Flop block
- condition blocks
- blocking statement (ass--ign statement/ wi--re declaration )
- non-blocking .
- instantiation of another file.

Create a hash/dictionary like data-structure with each signal (reg or wire within the file) as first level keys.
Then create source and destination keys for each of these signals as module ports or one of internal sources/destinations as mentioned above.

Of course, a signal vector can have multiple legal sources (given part of the vector comes from reach source) and multiple destinations. It can be suitably maintained.
Now the question -

I've been looking for a suitable precursor work on which we can start this. I've gone through BisonParser and tried to understand ANTLR grammar etc.

*Can Verilog-Perl or Verilog Signal-Parser can be used to extra connectivity in behavioral code inside a module....?
Any help is appreciated. Thanks in advance!..
*

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 14, 2019


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.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 15, 2019


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.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 15, 2019


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>

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 16, 2019


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.)

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 16, 2019


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.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 17, 2019


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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.