RE: [sv-bc] Should the LRM allow a frustrated bind statement?

From: Rich, Dave <Dave_Rich@mentor.com>
Date: Wed Mar 26 2014 - 08:18:48 PDT
A very similar issue came up on one of the forums<https://verificationacademy.com/forums/systemverilog/i-have-share-moduleused-inside-many-other-modules-parameterizable-input/output-bus-width-how-do-i-write-sva-so-i-dont-have-bind-individual-instance> recently.  There is no way to connect the parameters of the target instances to the parameters bound instance. This may force you into the situation you encountered.

Have you considered using a checker instead?

Dave


From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Jonathan Bromley
Sent: Wednesday, March 26, 2014 4:23 AM
To: sv-bc@eda.org
Subject: [sv-bc] Should the LRM allow a frustrated bind statement?

hello BC,

We recently encountered a problem where we have a bind statement that specifies binding into a target module (not a named instance), but certain parameterizations of the design can cause there to be no elaborated instance of the target module. Tools complain about this, and that's probably correct per 1800-2012 because the preamble to 23.11 says

"a bind construct that is used to specify one or more instantiations"

I can't find any other part of the LRM that describes how to handle this situation, nor can I find any Mantis relating to it.

In practice this corner case is extremely inconvenient, and it would be much preferable for tools to report only a warning in this case. Does SV-BC have an opinion on this? If there is no obvious reason for prohibiting such "frustrated" binds, I will raise a Mantis item about it.

Thanks

Jonathan Bromley

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Mar 26 08:19:03 2014

This archive was generated by hypermail 2.1.8 : Wed Mar 26 2014 - 08:19:11 PDT