Re: Proposal: Implicit Port Instantiation in SystemVerilog


Subject: Re: Proposal: Implicit Port Instantiation in SystemVerilog
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Mon Dec 17 2001 - 14:54:22 PST


> From cliffc@sunburst-design.com Mon Dec 17 11:42:42 2001
>
> Hi, Kev -
>
> This explanation is starting to help.
>
> True that .* covers one level of downward connection.
>
> Do I understand correctly that the following is covered by Verilog-AMS
> inherit/export?

Verilog-AMS doesn't actually have this functionality (yet), but it does need
it. There are a couple of reasons:

1) Schematics.

   A lot of Verilog-A is derived from (Cadence) schematic entry,
   signals like Vdd and Gnd are there in the schematic but are not necessarily
   connected explicitly up through the hierarchy in derived Verilog (if
   mentioned at all).

2) Automatic A/D conversion module insertion wiring.

   When a net has both analog and digital use in Verilog-AMS an A2D and/or D2A
   module will be instantiated. Threshold voltages for A2Ds and output drive
   for D2As depend on Vdd/Vss, and you want to get the most local to the
   driver or receiver for best accuracy, however the auto-inserted A/D modules
   can't tell where above them in the hierarchy those signals exist, and it
   will vary depending on how far down the design flow you are.
   
 
> Top module - has an "export" net Vcc connected to a power pad on the Top module
> Middle module - has no Vcc port and no Vcc net but has an instantiated leaf
> module, "A"
> Leaf module, "A" - has a Vcc "inherit"-port, ignored by the Middle module,
> but connects upward and finds the "export" net in the Top module and makes
> the connection
>
> In the above design, if the Top module is missing the export keyword, a
> syntax error would be reported? As you say, "inherit" must find a
> corresponding "export" so modules don't freely and unexpectedly inherit a
> net in a higher module. The "export" keyword is the documentation that we
> expect the exported net to be potentially inherited elsewhere in the design
> (but not specifically noted which module(s) can inherit the net).
>
> I believe "inherit" ports would be ignored by the .* implicit port
> connection proposal. Seems like inherit/export are almost a completely
> separate proposal, but should be considered and then document that .*
> ignores "inherit nets."
>
> Is this the idea? Could you give a useful simple example of a simple but
> real circuit that would use this construct?
>
> The light bulb is turning on but I need some help to power the filament!
>
> Regards - Cliff

Yep, that's more-or-less it, but I think I would prefer "inherit" just to
extend the "input" semantics so that you can bind an "inherit" port
explicitly if you need to. E.g. if you have -

  module modA (clock,data)
    inherit clock;
    input clock,data;
    ....
  endmodule

- a parent can do -

    reg clock,D;
    export clock;
 
    modA(.data(D)); // just inherit clock

- or -

    reg clck2,D;
    
    modA(clck2,D); // old style

It would be an error to not connect an inherited input. Also, I
would give ".*" precedence over "export" as it is new syntax and
therefore doesn't require backward compatibility protection.

In digital design this might be handy if you decide to do something
like change all your FFs to gated FFs to conserve power. The gated
FFs could just inherit their clock control signal from the top
encompassing block which can be any number of levels up in the
hierarchy. E.g.

   module G_FF(Clk,D,Q,Q_, // Standard pins
               G_FF_ClkEn) // Non-standard
     ....
     input G_FF_ClkEn;
     inherit G_FF_ClkEn;
     ...
   endmodule

   module top;
     assign G_FF_ClkEn = 1'b1; // Catch all.
     scsi_lgc(clk_en1,...);
     ide_lgc (clk_en2,...);
     ...
   endmodule

   module ide_lgc(clk_en,...)
     assign G_FF_ClkEn = clk_en;
     export G_FF_ClkEn;

     ide_sub(...);

   endmodule

   module scsi_lgc(clk_en,...)
     assign G_FF_ClkEn = clk_en;
     export G_FF_ClkEn;

     scsi_sub(...);

   endmodule

Any G_FF under scsi_lgc gets clk_en1 for G_FF_ClkEn, and
under ide_lgc get clk_en2, and otherwise get "1".

For tighter control and to avoid name clashes you might
want to do something smarter with exports to particular
modules e.g.:

   export <module name>:<inherited port> = <local signal>

 in the example above this would then replace the
 assign & export in ide/scsi_lgc:

   export G_FF:G_FF_ClkEn = clk_en;

Regards,
Kev.

> At 11:05 AM 12/17/01 -0800, Kevin Cameron x3251 wrote:
> >The .* syntax covers downward declared connection (any input
> >in the child can be connected to [?]). "Inherit" would handle
> >upward connection, i.e. when a module is instantiated with signals
> >declared with inherit you would search straight up the instance
> >hierarchy until you find a matching exported signal. The keyword
> >"inherit" would be required (and would be like "input" syntactically),
> >and the keyword "export" is desirable to avoid false connection in
> >modules that are unaware of inheritance.
> >
> >Since inheritance skips levels in the hierarchy, it may be worth
> >using the "export" syntax for the same purpose downwards since the
> >.* syntax only works over a single port boundary, e.g. any signal
> >declared "export" would match an otherwise unbound port of the same
> >name in lower levels (not declared "inherit").
> >
> >NB: my main reason for wanting this is kind of thing is for the
> >connection of signals like Vdd/Vss, substrate and thermal modelling
> >connections that are left off logic/RTL modules but are needed by
> >analog models of library cells in a mixed analog/digital flow. How
> >useful it is in general I'm not sure.
> >
> >Regards,
> >Kev.
>
> //*****************************************************************//
> // Cliff Cummings Phone: 503-641-8446 //
> // Sunburst Design, Inc. FAX: 503-641-8486 //
> // 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
> // PMB 501 Web: www.sunburst-design.com //
> // Beaverton, OR 97005 //
> // //
> // Expert Verilog, Synthesis and Verification Training //
> //*****************************************************************//
>
>
>



This archive was generated by hypermail 2b28 : Mon Dec 17 2001 - 14:55:40 PST