Re: [sv-dc] Modular compile etc.

On 11/18/2010 07:47 AM, Gordon Vreugdenhil wrote:
> 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.

What requirement? - I'm not setting requirements merely proposing
approaches to defining the semantic model.

>
> 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.

Only if your compiler isn't smart enough. Since none of this is
currently implemented in anyone's simulator I think there is plenty of
opportunity not to incur any penalty for unaffected nets.

As I said: the penalty in performance is pretty much the same as adding
a non-normal strength driver to a net, and you should already be
handling that.

>
> 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.

My model is based on what was required to make Verilog-AMS work - with
respect to plug-and-play and auto-insertion of conversion elements. I
should also say that the motivation for me in doing Verilog-AMS was to
enable accurate modeling of wiring in a digital design flow rather than
anything to do with analog design.

The existing LRM view of Verilog is a degenerate case where there is
only one driver/receiver type, so people have confused that with the
wires being typed.

+ I have worked on three commercial simulators including VCS (a parallel
processing version), HSpice and VHDL, so claiming I'm not one of the
main simulator implementation guys on this committee is misguided (at best).

>
> 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.

I'll repeat: changing the semantic model does not change the existing
behavior. All it does is give us the right framework for proposing new
syntax for the new constructs that are needed to model circuits with
user-defined types on wires to enable modeling analog behavior in a
discrete (or continuous) manner.

If you think that my analysis is technically wrong I'll be quite happy
to reassess, but as far as I can tell all you're saying is that you
don't want to change anything - which has been Cadence's approach to
Verilog-AMS for most of the last 15 years, and has not been helpful.

Kev.

>
> 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.