Re: [sv-dc] Modular compile etc.

Kevin,

Vendors are aggressively looking to *reduce* such global requirements,
not increase them. Vendors already have vendor specific mechanisms for
mitigating many of the global effects that you mention. Yes, we could layer
on yet another such requirement, but I don't think that serves the
core digital community very well at all.

One huge concern is changing from a "pay for what you ask for" to a
"pay at every point" requirement for digital. For example, the presence
of certain SV constructs can invariably cost more than a basic "wire".
But most users understand that (at least to some extent) and synthesizable
DUT code is generally written in terms of optimizable constructs. If you
change fundamental "wire" certainty (i.e the underlying representation
might become a real or other complex type), then *every* wire use in
the *entire* system will pay the cost. That is unacceptable to me and I
won't
vote in favor of any change that implies such a model.

As I've said before, you have a particular model in your mind for how
"wire" works right now. I don't agree that your model is either
required nor even really correct with respect to modern digital simulators.
I can't comment to deeply on that as it gets into multiple company's
proprietary knowledge, but you might wonder a bit why the two main digital
implementation guys on DC are reacting so strongly to your positioning.

In any case, I'm not going to continue to argue this as I don't think there
is much more use in doing so. I've made my position and constraints about
what I would accept pretty clear. I think that you'll find that the wider
SV digital community will be quite inline with that position. So the
DC can either continue to spend time on this and try to get the rest
of the 1800 to change or can move on to more productive discussions.
I'm willing to do the latter. I'm not willing to waste additional time on
the former.

Gord.

On 11/17/2010 9:06 PM, Kevin Cameron wrote:
>
> I think Arturo registered some worries about optimizing/modular
> compilation with a more generalized type scheme. I think it's worth
> pointing out that there are a number of things that already get in the
> way of doing that:
>
> 1. Parameters
> 2. Cross module references
> 3. Defparams
> 4. Back annotation
> 5. Driver strength (inc. debug forcing)
> 6. Inability to identify need for resolution prior to elaboration
>
> Adding the general cross-type resolution scheme I'm thinking of is on
> a par with the last two items. At the code-generation level all it
> does is separate the driven data from the received data for a given
> wire in a given module, the types of the module's drivers and
> receivers do not change - which is the general case as SV stands. New
> types can be treated much the same as an extended strength value, and
> can be handled outside of the module code.
>
> I think there was also some confusion between the semantic model, and
> the resulting behavior. Changing the semantic model does not
> necessarily change the behavior, i.e. considering interconnect as
> untyped and only drivers and receivers as typed should give exactly
> the same behavior for existing Verilog as before.
>
> Kev.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.