Support modports in interfaces

[veripoolbot]

---

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]

---

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]

---

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]

---

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]

---

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]

---

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]

---

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]

---

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]

---

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]

---

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]

---

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]

---

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

---

Via mail: "Yes, it works very well"

[veripoolbot]

---

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

---

In 3.230.