RE: [sv-dc] SVDC roadmap contribution

Hi Achim:

Busy? Who is busy?

See my responses below following SL:

From: Achim Bauer [mailto:a-bauer@exl-modeling.com]
Sent: Wednesday, August 18, 2010 11:28 AM
To: Little Scott-B11206; sv-dc@eda.org
Subject: AW: [sv-dc] SVDC roadmap contribution

Hi Scott,

you are keeping me busy ;)

Here are my answers:

> What do you mean by adjacent ports?

All contributors that are connected to a particular net; e.g. there might be a real-value driver and a digital driver far up in the hierarchy, a load far down in the hierarchy and an oomr-driver from within a toplevel testbench and all of them are connected with the same net/node.

[SL:] Okay, so "mixed real and digital adjacent ports" are the same situation you discuss under realódigital conversion in the Requirements section and call them "mixed discrete digital/real nets"? I was a bit confused because in the use cases you seemed to be advocating against CMs and then questioned whether we needed them in the Requirements section. I was trying to puzzle out if these were two different situations. So, is it fair to say that those are the same situation and you would prefer to avoid CMs for the reason you state below in this e-mail?

> When you say avoid connect modules, why is this necessary?

> Is this because connect modules hide or lose information?

Exactly. If we already have a powerful hierarchical resolution process/function, why would we need further connect modules on the discrete side? And if we use them for real<=>digital conversion, they might destroy or block valuable information, when they break up the net into several pieces. E.g. if we have a digital driver and a real driver and some load, a powerful resolution process might do as following: it "asks" the digital port (struct): what is your driving strength and your associated supply voltage and it asks basically the same question to the real ports struct and then resolves the whole net. If some of the contributors has no answer (e.g. a "plain" digital logic net might have no value for its loading strength), the resolution simply assumes some default (like the CM would do too).

Connect modules i.m.o. are necessary if you connect digital/real-ports with electrical ports: in that case the CM basically maps the discrete side into an equivalent circuit for the analog solver, that "resolves" the whole mixed net (because he "knows best").

[SL:] I agree. My understanding is that the current VAMS standard uses CMs to connect continuous and discrete disciplines (at least that is the first sentence of clause 7.5). Inside SV we would just be mixing different types of discrete representations, so at first glance I am not sure CMs need to be involved. It wouldn't hurt to have an eye toward the situation where one might add continuous disciplines into the mix with the different types of discrete representations. That isn't a direct situation I expect this committee to address, but we should try to avoid breaking or significantly complicated the already existing VAMS methods. I think that resolution is different from what I term "type" conversion. It may be possible to accomplish both in the user-defined resolution functions we are discussing, but they may also require two different solutions. I don't have solid opinion on that topic right now.

> Is this something that can be checked statically at say elaboration time or is there a need to check this dynamically?

I thought about a dynamical check. Just imagine, you are verifying a low/multi-power design and a part of the digital circuit is switched to a very low supply voltage while another directly connected circuit part erroneously stays at high supply, so lets say a 0.6V inverter "meets" a 1.2V inverter. As already said, for the resolution it plays no role if the signal values are digital or real; as long as we are using gate models that support a "struct"-port respectively supply the required information, the resolution function can verify the correct power domains.

[SL:] Ok.

> full implementation of the wreal-donation. What do you mean by this? Are you talking about the wreal donation from Cadence to the Verilog-AMS committee or something else?

Yes, but I forgot that this was donated just to Verilog-AMS. So I guess, it is no matter for us.

[SL:] Well, my concern is that the wreal donation deals with a lot of VAMS issues like disciplines, CMs, etc. I am not sure we need or want to bring in all of that complexity here. Do you believe this is still a requirement? As we stated in the Freescale contribution, we want to be compatible with wreal, but we need to be careful bringing VAMS constructs into SV unless there is a very good justification.

Best regards,

                    Achim

________________________________

Von: Little Scott-B11206 [mailto:B11206@freescale.com]
Gesendet: Mittwoch, 18. August 2010 16:59
An: Achim Bauer; sv-dc@eda.org
Betreff: RE: [sv-dc] SVDC roadmap contribution

Hi Achim:

I just had a few questions based on a quick read.

* resolve a net with mixed real and digital adjacent ports
        à avoid connect modules and hiding/loosing information for a clean resolution

What do you mean by adjacent ports? When you say avoid connect modules, why is this necessary? Is this because connect modules hide or lose information? Can you elaborate?

* assert compatibility of power/supply domains around a rv-net
        à e.g. to verify missing/inappropriate level shifters

Is this something that can be checked statically at say elaboration time or is there a need to check this dynamically? I guess my question gets at could this be dealt with by the elaborator detecting that nets of two different domains are connected w/out a level shifter or are you envisioning more complex checks?

four-state (w)-real

full implementation of the wreal-donation

What do you mean by this? Are you talking about the wreal donation from Cadence to the Verilog-AMS committee or something else?

Thanks,

Scott

From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of Achim Bauer
Sent: Wednesday, August 18, 2010 9:18 AM
To: sv-dc@eda.org
Subject: [sv-dc] SVDC roadmap contribution

Hi,

attached I send you my two-page contribution.

I shortly listed a few application cases and related implementation requirements.

Hope, it blends well with what we already have.

Thanks,

            Achim

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