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

Support modports in interfaces #200

Closed
veripoolbot opened this issue Jan 8, 2010 · 12 comments
Closed

Support modports in interfaces #200

veripoolbot opened this issue Jan 8, 2010 · 12 comments
Assignees

Comments

@veripoolbot
Copy link
Collaborator

@veripoolbot veripoolbot commented Jan 8, 2010


Author Name: Wilson Snyder (@wsnyder)
Original Redmine Issue: 200 from https://www.veripool.org
Original Date: 2010-01-08
Original Assignee: Wilson Snyder (@wsnyder)


Support modports in interfaces, see http://www.veripool.org/boards/18/topics/show/183-Verilog-Perl-How-to-traverse-modport-in-interface

@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jan 8, 2010


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-01-08T13:49:16Z


I need to think about if/how to add Modports to the netlist; as you suggest it may be better to have a new object.

Meanwhile please switch to using the patch below; it's like yours but I made some trivial cleanups and more importantly fixed parsing modports separated by commas.

@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jan 8, 2010


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-01-08T13:58:17Z


P.S. The patch is made to apply to the latest git version, 8267e39.

@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jan 9, 2010


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-01-09T00:51:47Z


I'm trying to understand what you're after with this change:

  portE:                          // ==IEEE: [ port ]
  ...
  |       portDirNetE id/*interface*/                   idAny/*port*/ rangeListE sigAttrListE
                   { VARDTYPE($2); VARDONE($<fl>2, $3, $4, ""); PARSEP->instantCb($<fl>2, $2, $3, $4); PINNUMINC(); }
  |       portDirNetE yINTERFACE                        idAny/*port*/ rangeListE sigAttrListE
                   { VARDTYPE($2); VARDONE($<fl>2, $3, $4, ""); PINNUMINC(); }
- //|     portDirNetE id/*interface*/ '.' idAny/*modport*/ idAny/*port*/ rangeListE sigAttrListE
- //                         if                  port range                            iface port range
- //              { VARDTYPE($2); VARDONE($<fl>2, $5, $6, ""); PARSEP->instantCb($<fl>2, $2, $5, $6); PINNUMINC(); }
+ //                                            if  mod                   port range
+ |       portDirNetE id/*interface*/ '.' idAny/*modport*/ idAny/*port*/ rangeListE sigAttrList
+                 { VARIO("interface");VARDTYPE($2+"."+$4); VARDONE($<fl>2, $5, $6, ""); PINNUMINC(); }

  |       portDirNetE yINTERFACE      '.' idAny/*modport*/ idAny/*port*/ rangeListE sigAttrListE
  //                                              port range
                   { VARDTYPE($2); VARDONE($<fl>2, $5, $6, ""); PINNUMINC(); }

I understand why VARDTYPE should be interface.modport, and it probably
makes sense for vario to be "interface", but why did you drop the
instantCb?

Also, shouldn't the other interface declarations match using
VARIO("interface") and the .modport for dtype?

@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jan 9, 2010


Original Redmine Comment
Author Name: Thriller Wu
Original Date: 2010-01-09T05:30:29Z


I think it's a little confusing if treat interface/modport in port list as instance. For example ad module defintion:

module unit1(
nets.master master_port,
input clk,
input rstn);

"master_port" is only a set of wires with direction. It's more like normal ports than a instance. When I trace signal in "master_port", I will find the definition of "nets.master" and process the signal as a port. It's difficult to process if get a instance with type "nets.master" and name "master_port".

In Debussy, the parser have IO type named "MIXIO" to hint it's a interface, how about to add it to your parser?
dtype's information should contain interface type name and modport type name.

@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jan 9, 2010


Original Redmine Comment
Author Name: Thriller Wu
Original Date: 2010-01-09T05:31:15Z


Thriller Wu wrote:

I think it's a little confusing if treat interface/modport in port list as instance. For example a module defintion:

module unit1(
nets.master master_port,
input clk,
input rstn);

"master_port" is only a set of wires with direction. It's more like normal ports than a instance. When I trace signal in "master_port", I will find the definition of "nets.master" and process the signal as a port. It's difficult to process if get a instance with type "nets.master" and name "master_port".

In Debussy, the parser have IO type named "MIXIO" to hint it's a interface, how about to add it to your parser?
dtype's information should contain interface type name and modport type name.

@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jan 10, 2010


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-01-10T14:07:56Z


I looked through past mail to find out why interfaces had the instantCb. There were these: First it really is like an instantiation in that it needs to read the interface definition, and more importantly if using non-ANSI style declarations you can't tell what is an interface versus just a module instantiation. Thus it's more orthogonal to include it. Finally I'd prefer not to break existing users. So I'll leave them in; I think you can easily remove them, if not let me know and I'll add another variable to the callback indicating it's a interface (but this will only work for ANSI ports.)

I'll also stick with your original IO type "interface" as I think that's more obvious than "MIXIO".

@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jan 11, 2010


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-01-11T00:55:15Z


I applied your additional patches, modified to still do instantCb, and to make a new Netlist::ModPort object.

Please port your application and give it a try.

@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jan 11, 2010


Original Redmine Comment
Author Name: Thriller Wu
Original Date: 2010-01-11T03:01:43Z


I thinks it's ok to save instantCb.

Another question:
If treat interface port as instance, maybe we need add "ENDCELL" corresponding to "INSTANT". For example in "35.dmp" line 426:

@verilog/parser_sv.v:019: INSTANT 'itf' 'modported_int' ''@

but no "ENDCELL"

@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jan 11, 2010


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-01-11T16:39:47Z


You're right there should be a endcell. Pushed to git.

@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jan 20, 2010


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-01-20T00:04:40Z


Is the git version working for you? I'd like to push a new release.

@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jan 21, 2010


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-01-21T15:29:33Z


Via mail: "Yes, it works very well"

@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jan 21, 2010


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-01-21T21:23:32Z


In 3.230.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.