Re: [sv-bc] Proposal for extern modules


Subject: Re: [sv-bc] Proposal for extern modules
From: Steven Sharp (sharp@cadence.com)
Date: Wed Feb 19 2003 - 16:06:00 PST


>What if the "extern"ed module comes into a tool in another format, like a
>black box,
>.db, .lib, or through the netlister, or so on.

I'm not sure what the question is here. If the tool accepts modules
in another format, the tool needs a way of specifying where to get them,
independent of this port issue. If the tool accepts modules in another
format, then the tool needs to be able to extract all the information
it needs from that format, including port lists.

If that format is not Verilog, then this is a tool issue anyway, not a
Verilog language issue.

> If the user also creates a
>dummy so that
>the RTL engine sees it, which one gets linked in? The dummy or the black box?

This is no different from the many other situations where a user may have
multiple variants of a module and needs to select one.

>If it turns out to be the dummy by accident, the user will be upset. But
>then, in
>another situation someone will want the dummy, and to have the black box
>ignored,
>so how can the tool decide?

It is my understanding that Verilog-2001 configurations are supposed to
help with this sort of thing.

>What if a dummy is used, and the tool decides to do an auto-ungroup on the down
>design, replacing it in the top design with an empty design (rather than
>recognizing
>that it can't because the down design is unlinked?) The down design
>instantiation
>will correctly disappear in the up design. Since the down design
>description exists
>for the tool, it should be safe to ungroup that logic into the upper module
>if the
>timing or area is better met that way.
>
>If the user doesn't know what the downside is, but does know the ports, it
>is better
>if the user just says that.....

This sounds like you want to specify a property of the dummy module to
control the operation of the tool. That is exactly what Verilog-2001
attributes are defined to do.

Steven Sharp
sharp@cadence.com



This archive was generated by hypermail 2b28 : Wed Feb 19 2003 - 16:07:35 PST