From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Tue Jun 25 2002 - 16:59:32 PDT
Precedence: bulk
Steven Sharp wrote:
>
Actually, the "text preprocessor" mode is exactly the mental
model I have in my head. The problem is bringing that into
line with hierarchical names that talk about scopes. I can
easily determine what is valid/invalid in terms of the
implied declarations, the issue is the handling of names
in terms of vpi and module scopes. If the names of the
implied declarations show up in vpi *as module declarations*
then they have very weird names (with dots). If they don't,
then there are real scopes involved that vpi has no model
to access. Personally, I think it makes more sense to keep
the named generate scopes as real scopes and extend vpi
to deal with that aspect.
It certainly is painful in an implementation to deal with
unknown bindings of a simple identifier to the final declaration
in the implied final module, but I can live with that if that
is actually the model that other vendors are implementing to.
Gord.
> It may help to understand the desired behavior of generates if you take
> into account the mental model that it seems to be based on. Whoever
> originally specified it, and some of the people who continued to be
> involved in its development, seemed to think that it would work like
> some kind of text preprocessor.
>
> This is obviously impossible, since it can depend on the values of
> parameters, which are not known until after the source has been parsed
> and mostly elaborated. If you know how the compiler actually has to work
> and try to apply that, this specification will not make sense to you.
> However, if you view it as then changing the source code appropriately
> and magically propagating that change into the internal data structures,
> you get some idea about what was intended.
>
> For example, consider the issue of the same identifier being declared in
> two different ways using a generate-if, and then referenced elsewhere.
> >From a compiler viewpoint, you think in terms of entering declarations
> into a symbol table and using that to resolve references. When there
> are multiple declarations of the same name, it seems like a conflict, and
> you start thinking about scoping rules and wondering if there are some
> scopes involved here.
>
> If you switch to the preprocessor mindset, the expected behavior becomes
> clear. All of the unselected declarations "disappear" from the source
> code, leaving only the single selected declaration. There are no
> duplicate declarations, and no scopes required. The declarations appear
> at the level of the module, because once the generates are resolved, that
> is where they appear. The generate syntax clearly doesn't generate a
> scope, since it also "disappears" from the source text after it is dealt
> with.
>
> Not that recognizing this makes it any easier to implement in a real
> compiler...
>
> Steven Sharp
> sharp@cadence.com
-- ---------------------------------------------------------------------- Gord Vreugdenhil gvreugde@synopsys.com Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054 Synopsys Inc., Beaverton OR
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:37 PDT
and
sponsored by Boyd Technology, Inc.