Re: Revised issues list

Subject: Re: Revised issues list
From: Jonathan Sanders (jons@cadence.com)
Date: Sun Feb 25 2001 - 17:17:46 PST

Ian,

Working to catch up on my email.  Responses below.

Jon

At 03:13 PM 2/5/01, Ian Wilson wrote:
This is a reduced list of issues, with proposals or workarounds, and
with suggested 'bins'.

--ian

Verilog-AMS 2.0 LRM Issues (revised)
Ian Wilson
Date:   02/04/01

3.4.3.{2,3} Empty disciplines; undeclared nets [bin: disciplines]
Description allows for netlists with uncommitted interconnect.
The intention is clear although the explanatory text is highly ambiguous.

Alternate proposal: treat 'wire' (and other intrinsic Verilog types) as
pseudodisciplines. This supports the LRM examples (such as connect modules
of the wire_to_electrical variety without requiring changes to user libraries).

The net type property is treated as a pseudodiscipline (not sure what it means
but I'll explain my use of your term) as defined by the LRM (3.4.3.3).  For net types
other than "wire and tri" they are digital domain and will pick up the default
discipline unless defined.    For "wire and tri" if they connect to digital behavioral
code they are also digital domain and will also pick up the default discipline unless
defined.  For nets of type "wire or tri" that do not connect to digital behavioral they
are treated the same as interconnect without a net type and will be resolved
using the discipline resolution method.  The LRM does describe  this although
the alias net type of wire, "tri" was not included and it could probably be written
in a more obvious way.    


3.5 Real net declarations [bin: wreal]
Changed (and relocated) from previous definition.
This is an attempt to formalize $realtobits(), etc.  Most of the semantics and syntax is missing
from the definition.  No rules provided for conversions with other net types. Expect Verilog-2k
to conflict.  This looks like a highly unportable feature.

Proposal: move this to an 'optional features' Annex.


This feature has been praised by almost every customer I have shown it too
as they hate $bits2real(), etc.  I would like to better understand your concerns
on what is missing, note the syntax is shown in A.4 in the BNF.  Also, where do
you expect the conflict from Verilog 2K?   I think we need to get them to add/support
this functionality but it is of high value for faster simulation.   When you say conversion
to other net types do you mean Connect Modules or to a digital wire?  It clearly
states that connection to other net types is illegal in 3.5

With that being said there are a few open issues which I know of and presented
in my list that do need to get addressed to prevent the user from doing extra
work to get pass these issues.  Of course the examples were also in error and
I provided corrections.



3.6 Default discipline [bin: disciplines]
This applies to discrete disciplines only.  Requires further definition (e.g. relationship
with `reset_all).

Proposal: change name (?default_discrete_disc) to make clear. Add to set of things
cleared by `reset_all.

I'm ok with this.

4.4.1 Restrictions on analog operators [bin: ?]
The LRM introduces null arguments to these and other
functions; this in turn introduces the need for various default values (which are not all
provided by the LRM).

Proposal: add table of default values for analog operators, etc.


4.5 Analysis dependent functions [bin: ?]
Meaning of some cases (see also initial_step) is not clear for AC analysis, etc.

Proposal: add words to make clear what happens on first/any/last steps of AC
analysis, and what happens to sequential code such as $fopen().

When we deal with 1364-2001 we will have to address all of the file I/O issues
to ensure that they read and write at predictable times in the analog block.  Can
we delay the $fopen() until we get to IEEE and address them all together?


6.7 Events [bin: MS]
Constructs like @(posedge clk or cross(V(1), 1)) require analog/digital synchronization
semantics.

Proposal: provide rewriting rules for new constructs in terms of existing
structural and single-domain language.

7.3.3 Real valued ports [bin: wreal]
Require considerably more in the way of definition, especially how these interoperate with
existing Verilog-D types, semantics, and syntax.

Proposal (see above): move to Annex.

8.2.{1,2} Domains. Contexts [bin: MS]
The concept of variables being associated with a particular domain depending on assignment is
ambiguous.

Proposal: disallow cross-domain access to variables.


Highly disagree.  As we discussed in the last effort we would consider removing
this restriction at a later date but chose to be restrictive for now.  Not sure how
it is ambiguous as if it shows up on the LHS of both an analog block and an initial
or always block then it is an error.  Otherwise it is owned by the block that has it
on the LHS.   Again, customers are finding this feature quite valuable and several
while desiring us to remove the restriction have told me they understand the
rational for doing that for now.


8.3 Behavioral Interaction,
8.3.6 Concurrency [bin: MS]
Totally inadequate to write portable code that accesses variables from multiple domains.
This is important since these mechanisms are proposed for constructing connect modules, etc.
Whole area requires some clear semantics and possibly additional synchronization constructs.

Proposal: either disallow mixed domain access to variables, or add constructs
to allow deterministic code to be written in the concurrent Verilog environment.
For example: add semaphore to language.

Ian, I think we are going to need your help in defining what you need to clarify this.
We have implemented this and I have trained many users without this being a problem
so while I am opposed to removing mixed signal from a mixed signal language I am
certainly open to adding clarifications that will allow your product and mine to give
the same answers.   Could you at some time provide examples of the problem you
see as you have made these statements since the 2.0 timeframe and we attempted
to address your concerns with section 8.3.6, maybe examples will help us see
what else you expect to see.



8.4 Discipline Resolution [bin: disciplines]

Proposal: there are at least two competing practical view on this: the 'islands'
approach, and the 'common view' approach. Put something simple in Chapter 8, and
defer implementations to an Annex.

The issue of multiple digital islands or a single digital island (for digital nets of the
same disciplines on a signal) does need to be resolved as part of the semantics for
resolution.  I am looking for arguments on both sides before I cast my vote but this
is not an implementation issue in my mind.


8.4.3 Connection of continuous-time disciplines [bin: disciplines]
Makes it illegal to have incompatible continuous disciplines on the same net (previously
undefined). Antrim AMS allows this; standard rules for connect module insertion apply.
User has complete control and it’s a useful feature.

Proposal: remove restriction.

Not sure if a clarification effort is the time to remove restrictions like this but I
understand the desire.  The other end of the spectrum is that we did not connect
modules being used to insert real components such as transducers into the
design as that is a misuse of autoinsertion and thus the reason for the restriction.
Down the road we might also consider allowing CM's with more than two ports but
I think those issues should be pushed out for now.


8.10 Driver Access and net resolution [bin: MS]
These are defined to work in connect modules only.  Connect modules are not allowed
to be instantiated as normal modules. Result: how can a user debug a connect module?

Proposal: remove restrictions on 'manual' instantiation of connect modules. Define
results of driver access functions in different use cases.

Ian, don't see where there is a restriction on manual instantiation of connect module,
can you show me the sentence and or section?  The purpose of these functions is
as a modeling tool and not a debugging tool but I don't see how this prevents debugging
either?  (cannot use function to find CM drivers?)

As for these only working in CM's, that is a restriction we started with but certainly
we believe that the digital folks will desire this type of functionality.  I know that there
is already a system task $count_drivers out there but this I think is better and we
should work with the digital team to remove this part of the restriction.


10 System tasks and functions [bin: ?]

Proposal: $table has been offered. May want to convert to analog operator status
or add to an Annex.

While I believe a table model will add much value did the committee agree that the
current effort was for clarification and that this would be addressed at a later time?
I have not spent cycles analyzing this to the requirements of my users and was not
planning on it until later this year. 


D Standard definitions
The file names have changed from <foo>.h to <foo>.vams.
When? Why?

Because several on the committee felt that these were not header files but
definitions, also note that disciplines was missing the plural "s".  This was
changed early in the 2.0 cleanup and is one of many things that has effected
my existing users.  Fortunately we can make this one invisible by linking these
files together so that either work.  Unfortunately changing $limexp to limexp and
boundstep to $boundstep among others are much more painful for the hundreds
and thousands of Verilog-A modules my users must convert.


E SPICE compatibility
Material in Annex is Spectre-specific (see syntax for sources for example).
Proposal: use something neutral like SPICE3.

Additional constructs required to import existing Spice in an automated way -
in particular, global nodes/global parameters.

Proposal: details of these as extensions available if there's interest.

I hate to share with you bad news but the structural syntax of Spectre is based
on the SPICE3  MOS model card.  If one want to argue the port names and
parameter names then there are possible issue except that you find that SPICE
syntax sucks and it is not consistent nor complete.  ( I spent a long year dealing
with attempting to support every SPICE syntax version known to man kind and
it will make you crazy).  Before I go farther lets make sure we understand and
hopefully still agree to the purpose in annex E. 

The pupose of SPICE support in Annex E was not to support the SPICE2G6, SPICE3,
HSPICE, ELDO, SABER, SPECTRE, PSPICE and any other specific syntax but
to provide a method to access the models (not syntax) of these simulators in the
Verilog structural netlist.

So you look at the SPICE3 resistor statement (from the SPICE3 manual):

RXXXXXXX N1 N2 VALUE

Are the portnames N1 and N2?  what is the name of the parameter? r, R, res, resistance, ...

Of course some of us also remember the optional TC parameter:

TC=x,y   (TC=.0005, .0001)

How does this map to Verilog?

Also, if you believe that the portnames are N1 and N2 then for controlled sources
you will need to always ask the user to escape them due to illegal characters:

GXXXXXXX N+ N- NC+ NC- VALUE

Needless to say many SPICE devices do not have a "module" name, would you name
the above device "G" or vcvs or something else?

If you remember many of you requested that we break the sources into separate
functions to be SPICE like and which clearly is not Spectre syntax.  It is also
something that our installed based highly opposed, thus we will support the method
defined by the committee and what our users want and expect.

I will agree that many of the undefined parameters name and even some of the
defined ones like V1 and V2 in the sources look to be the same as Spectre and
several other simulators like HSPICE, PSTAR, .... 

If we want to rename all of the ports and parameters I recommend rather than trying
to match SPICE which will not be possible due to illegal characters and missing
data that we pick names that make sense.


-Jon

This archive was generated by hypermail 2b28 : Mon Feb 26 2001 - 09:02:07 PST