AW: AW: [sv-dc] SVDC roadmap contribution

Hi John,

I am not sure if this would be a strong methodology or just a hack:

> John: "If a connectrules (or similar) block could be declared inside of a
module, most of the problem would be solved without new resolution
protocols."

You might pass through constant parameters to a split connect module by
this, but what if e.g. the parameter for the driving strength or the
associated supply voltage changes, because a component is set to standby?
And if split/scattered connect modules convert ports "individually", does
this guarantee a clean resolution of the mixed net's value? Wouldn't it
evtl. be better if all contributors just meet at one table with all their
particular information and are resolved there alltogether? If we specify a
struct type, why not use it for passing the required information?

I would also like to make a general remark to the following statement of
yours:
(please excuse, that I drew it a bit out of context)

> John: "I would suggest starting up a new "p1800.1" standard proposal to
separate all A/MS issues from mainstream digital design in SV. This would
allow vendors to claim 1800 conformance while representing analogue
functionality as an optional enhancement. Feature creep already is a
terrible burden on SV, and adding analogue features without restructuring
the language would make the burden grow."

I think the central question is: what do we want to accomplish with the new
real port type ???
If we want to be able to verify mixed systems, then we should worry about
the practical requirements for this and not about if we may add a 1000th
feature to heavily-burdened SystemVerilog. Otherwise we better should not
implement anything at all and spare SystemVerilog from it.

Theoretically a mixed system can be set-up/partitioned in a way so that you
do not need any connect modules or type conversion,
and no way to describe quasi-continuous transition of nets
and so, that there are no lumped analog components that bother you
and no multiple-driver nets.
Unfortunately I have never ever seen this happen in practice when verifying
(already implemented) complex mixed systems.

My opinion is, that we should rather specify a set of features, that is
practice-proof and not a reduced, simplified precursor set, that looks good
on the paper, but is insufficient for real-world projects. I am not sure, if
it is a good solution to outsource the "analog" aspects, since actually
these aspects might be the ones that make the difference.

Regards,
        Achim

-----Ursprüngliche Nachricht-----
Von: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] Im Auftrag von John
Michael Williams
Gesendet: Mittwoch, 18. August 2010 23:06
An: sv-dc@eda.org
Betreff: Re: AW: [sv-dc] SVDC roadmap contribution

Hi Achim.

Verilog-A/MS allows automatic insertion of connectmodules, by declaring
connectrules blocks. So it is possible to avoid explicit instantiation of
them under many conditions.

The problem would become significant for designs which included instances
wired to different
supply voltage levels, I think. Level-shifters, etc.

If a connectrules (or similar) block could be declared inside of a module,
most of the problem would be solved without new resolution protocols.

On 08/18/2010 01:43 PM, Achim Bauer wrote:
...
>
> 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.

-- 
      John Michael Williams
      Senior Adjunct Faculty
Silicon Valley Technical Institute
--
This message has been scanned for viruses and dangerous content by
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.