Re: hierarchical parameter passing in DC sweep

The important thing about a Verilog-AMS description is that when
it describes a specific design/implementation it should be portable
between tools. Varying parameters  is part  of design exploration/
verification and if it can be done from outside the design hierarchy
(e.g. in testbanch code) then it's less of an issue if it isn't portable.

Most of the stuff that gets put into LRMs at Accellera and the IEEE
is originally non-standard extension done by vendors, so it's not
unusual for support to be inconsistent for "new" features.

The committee's job to a large extent is to look at proposed extensions
and merge them into the LRM in clean and extensible ways - which
is generally easier if you have an implementation you can try out.
Since some ideas don't work that well in practice it's better for someone
to try them out first, also, the fact that someone has spent resource on
adding a feature implies that it is actually needed.

Ideally anyone thinking of doing an extension to Verilog-AMS should
run it past the committee for comment prior to starting to avoid having
to do a lot of rework, but profit motives probably prohibit that.

Kev.


Muranyi, Arpad wrote:

>Even though the statement below is true, we need to be
>extremely careful with these kinds of things!
>
>It is enough for just one simulator to allow this (which by
>the way is a nice feature to have), and people will start
>making models using this capability - not realizing that
>this is a tool specific "extension" of the language.  Pretty
>soon we will be in for a big (and bad) surprise that these
>model doesn't work in (any) other vendor's tools.
>
>A direct consequence of such situations is that models will
>immediately become tool specific which contradicts one of
>the main reasons for having an "industry standard" language.
>We will end up where the SPICE world is today with its
>millions of vendor specific variants that prevents any
>reasonable model exchange in the industry.
>
>In my opinion it is much better to implement the LRM strictly,
>even if there are missing capabilities or bad features that
>any idiot knows how to do better, than allow the tool vendors
>to deviate from it.  Our industry suffers a great deal from
>the inability to exchange models freely because of vendor
>specific features, which results in having to make duplicate
>models in many languages or language variants.  Of course
>the better solution would be to write an LRM that is well
>thought out, and has little if no unreasonable limitations,
>i.e. a language that is useful for modern practice, and is
>not bogged down by idiosyncrasies driven by historical and
>other limiting forces.
>
>Keep in mind that most of these limitations stem from the fact
>that they are easier to implement in the software.  I feel it
>is time to wake up and write software that lends itself to be
>easy to use by its users, and not easier to implement by the
>software companies.  Being an electronic engineer and not a
>software expert, I would rather not have to remember that
>parameters are constants as opposed to variables, I would 
>much rather spend my energy on writing my model algorithms.
>Most modern programming languages allow arguments to come
>in almost any shape or form, as long as they evaluate to
>the correct type (string, integer, etc...)  Whether it comes
>from a pointer (by reference), or a variable (by value), or a
>literal, etc... shouldn't matter.  Yet in Verilog-A we are
>still wrestling with the file argument of $table_model etc.
>required to be literals (hard coded, grrrrrrr)...  I feel I
>am in the stone age!
>
>Sorry for the harsh words, but I wonder is there a way out
>of this situation in a language which is being developed
>in year 2005?
>
>Arpad
>=============================================================
>
>-----Original Message-----
>From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Geoffrey.Coram
>Sent: Tuesday, August 23, 2005 6:57 AM
>To: Marq Kole
>Cc: verilog-ams@eda.org
>Subject: Re: hierarchical parameter passing in DC sweep
>
>...
>...
>I still think this is a simulator issue: if the simulator vendor
>relieves the restriction on parameters being constant at run-time,
>then the vendor is also responsible for logical extensions such
>as passing that varied parameter.
>...
>...
>
>-Geoffrey
>
>
>  
>