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.
 
> 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").
 
> 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.
 
> 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.
 
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 MailScanner, and is
believed to be clean.