Subject: [sv-bc] RE: Questions
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Thu Jan 08 2004 - 18:17:02 PST
Dave,
Thanks for the speedy replies.
A couple followups below...
Doug
> -----Original Message-----
> From: Dave Rich [mailto:David.Rich@synopsys.COM]
> Sent: Thursday, January 08, 2004 6:01 PM
> To: Warmke, Doug
> Cc: sv-bc@eda.org
> Subject: Re: Questions
>
>
>
>
> Warmke, Doug wrote:
>
> >In the SV-BC minutes:
> > Nested modules with no ports that are not explicitly
> > instantiated shall be implicitly instantiated once with
> > an instance name identical to the module name. Otherwise,
> > if they have ports, if not explicitly instantiated, they
> > are ignored.
> >
> >Why is there the restriction about modules that have ports?
> >I think it would be better if modules with and without ports
> >were treated identically, just as modules declared in $unit scope.
> >In such cases, the ports are left dangling and the user gets what
> >they ask for. Why not treat nested modules identically?
> >
> >
> This functionality mirrors the way program blocks work. The
> idea is that
> programs/modules with no ports almost always have one instances, so
> implicitly instantiating them make sense; programs/modules with ports
> need to get connected up in an explicit instantiation.
DOUG: Again, I don't see that it is required to make a distinction
between modules with ports and modules without ports.
We've been living without this requirement for years with
top level modules that have ports. As you note below, an exception
could be made for nested modules with interface or ref ports.
I think that if we changed the rule to be:
Nested modules with no ports that are not explicitly
instantiated shall be implicitly instantiated once with
an instance name identical to the module name.
You will get what you want, plus more consitency and intuitive feel
compared to legacy Verilog. Probably a similar change would need to
be made to keep consistency with program blocks.
>
> We may have to go back and change the implicit instation
> rules for $root
> because we don't want programs/modules with interface or ref
> ports to be
> implicitly instantiated.
DOUG: Sounds good - I would be for such a proposal.
>
>
> >
> >Second question:
> >
> >For packed structs, the keyword "packed" is required to make
> >the structure packed. A tool must check that all constituent
> >struct members are of integral types - this can help a user
> >make sure that the struct truly is packed and that they haven't
> >introduced an element which makes it non-packed.
> >
> >It is simple for a tool to automatically determine the
> >"packedness" of a struct just by examining the members.
> >Is there any point to that "packed" keyword other than
> >the friendly user-oriented semantic check I mentioned above?
> >
> >
>
> Oh yes.
>
> A packed struct can be used as a integral primary in any
> expression. An
> unpacked struct can only be copied or compared.
DOUG: Yes - that is clear. But my point is that a tool can
automatically determine the "packedness" of a struct in a
straightforward way, thus making the "packed" keyword irrelevant
except for documentation and checking purposes. I was wondering
if I'm missing anything else the keyword brings to the table?
Thanks,
Doug
>
> Dave
>
> >Thanks,
> >Doug
> >
> >
> >
> >
>
> --
> --
> David.Rich@Synopsys.com
> Technical Marketing Consultant
> http://www.SystemVerilog.org
> tele: 650-584-4026
> cell: 510-589-2625
>
>
>
This archive was generated by hypermail 2b28 : Thu Jan 08 2004 - 18:29:55 PST