AW: [sv-dc] SVDC roadmap contribution

Hi Scott,
thank you very much for having a close look!
I corrected the document, i.e. clarified the mixed-net stuff, removed the
wreal requirement and converted it to pdf (attached).
 
My opinion about whether connect modules are required for a purely discrete
simulation is also not solid.
I just have a gut feeling, that they might be indispensable, if we specify a
weak resolution methodology
and that they become unnecessary, if we go for a strong methodology.
 
Regards,
             Achim

  _____

Von: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] Im Auftrag von Little
Scott-B11206
Gesendet: Mittwoch, 18. August 2010 20:19
An: Achim Bauer; sv-dc@eda.org
Betreff: 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  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.