Re: paramset resolution

From: Kevin Cameron <kevin_at_.....>
Date: Fri Dec 15 2006 - 10:16:44 PST
Geoffrey.Coram wrote:
> Hi, Marq -
> I just had a look at the two new criteria added for
> paramset resolution, namely:
>
>   . The underlying module shall have a port declared for
>     each port connected in the instance line.
>
>   . The paramset with the fewest ports not connected in
>     the instance line shall be selected.
>
>
> The first criterion should say
>   . If the instance connects module ports by name, each
>     port name specified in the connection list shall
>     correspond to a port declared by the underlying module.
>     If the instance connects module ports by ordered list,
>     then the number of connections specified shall not
>     exceed the number of ports declared by the underlying
>     module.
>
> and the second should say:
>   . The paramset whose underlying module would have the
>     fewest ports not connected (by name or by ordered list)
>     shall be selected.
>   
[Is there a rationale somewhere for allowing unconnected ports?]

This sounds to me like something that needs explicit syntax to say that 
it is OK to leave ports unconnected. Just using the "fewest unconnected 
ports" seems pretty arbitrary, and presumably the more complicated 
(accurate?) a model the more likely it would be to have unconnected 
ports so the bias would be to using less accurate models.

I suggest that any module in a paramset is only considered if there is a 
connection specification for all ports, and that specification can be in 
either the paramset or module definition. For the modules I would 
suggest going with the C++ prototype approach of adding an assignment e.g.:

       module foo (input a = 1'bz,...); // Input a can be left floating

Note: SV has module prototypes, and prototypes and definitions do not 
necessarily have to match wrt to default connectivity, a prototype only 
tells the caller how to call/instantiate something, so a prototype could 
be local to the paramset.

Kev.
>
> Should there be some text stating that paramsets cannot
> change the port list, neither in number nor in name?
>
> -Geoffrey
>
>   
Received on Fri Dec 15 10:16:49 2006

This archive was generated by hypermail 2.1.8 : Fri Dec 15 2006 - 10:16:58 PST