[logo] 
 
Home
News
Activity
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  BugVise
  CovVise
  Force-Gate-Sim
  Gspice
  IPC::Locker
  Rsvn
  SVN::S4
  SystemPerl
  Voneline
  WFH
General Info
  Papers

Issue #200

Support modports in interfaces

Added by Wilson Snyder over 3 years ago. Updated over 3 years ago.

Status:Closed Start date:01/08/2010
Priority:Normal Due date:
Assignee:Wilson Snyder % Done:

0%

Category:-
Target version:-

Description

modport.patch (13.7 kB) Wilson Snyder, 01/08/2010 01:49 pm

History

Updated by Wilson Snyder over 3 years ago

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.

Updated by Wilson Snyder over 3 years ago

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

Updated by Wilson Snyder over 3 years ago

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 and the .modport for dtype?

Updated by Thriller Wu over 3 years ago

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.

Updated by Thriller Wu over 3 years ago

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.

Updated by Wilson Snyder over 3 years ago

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

Updated by Wilson Snyder over 3 years ago

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.

Updated by Thriller Wu over 3 years ago

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"

Updated by Wilson Snyder over 3 years ago

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

Updated by Wilson Snyder over 3 years ago

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

Updated by Wilson Snyder over 3 years ago

  • Status changed from Feature to Resolved

Via mail: "Yes, it works very well"

Updated by Wilson Snyder over 3 years ago

  • Status changed from Resolved to Closed

In 3.230.

Also available in: Atom