Discussion in todays call was centered around the recent enhancements that Achim put forward (Mantis: 3392)

Enhancement #1: request for an event driven solver for implicit non-linear equation systems. This sort of solver would be very useful with respect to initial parametrization and would allow us to map the high level input parameters into a low level representation.

Would also also optimisations where the equations inside the discrete event are not even solved unless the event fires.

Would constant UDF's allow you to do some of this?
Not really, having the initialization of certain functions using static input parameters is very limiting.

Achim to provide a more detailed proposal of what he would like to have for this enhancement.

A subrequest of this enhancement is to remove the restriction on the laplace/zi transform filters to contain "constant" pole/zero vectors. Scott mentioned that this is very useful for models that have characteristics of the filter changing over time.

This issue will be tracked separately, there doesn't seem to be any reason why these filters need this restriction.

Another possible change was to allow the use of the transform filters within the digital domain.
We would need to investigate this.

Enhancement #2: Dynamic arrays
Would this be useful. Sometimes it is painful to pre-determine the size of the array. It ends up that the user stores the largest array they ever need which can take up a lot of space.
Would be nice to be able to define the array size on the fly.

This is something that we will look at with SV merge. System Verilog has this concept as a Dynamic Array (Sect. 7.5 P1800-2009)

Enhancement #3: OOMR read&write for logic, real, electrical
Request is to remove the limitations from writing to OOMR's of analog quantities (branch, variables).

We currently have very strict limitations on OOMR's, specifically you can't access analog variables (read or write) and you can't assign to branches. (LRM 2.3.1 Sect: 6.7.1)

The reason these restrictions were put in place is because we couldn't resolve some of the issues before LRM 2.3 was finalised.

Most of the issues revolve around "race" conditions, and how to prevent them.
However "race" conditions exist in digital today.
Should we be trying to stop race conditions from occurring? Or is it simply a matter of user beware.

Specifically in analog, the race condition we are most concerned with, is when does the OOMR assignment take place? Does an OOMR assignment only take affect the next time step or does it modify the value of the object during the iteration cycle. If both a module and an OOMR are modifying a local variable, does the module assignment take precedence?

Enhancement 4: Bind
This is in the System Verilog language so will be part of the merged language.

However the concern is that the bind as defined in SV is quite static. It would be quite useful if we allowed a more flexible way to perform the bind with wildcards etc. (note, as I write these minutes, I am not very familiar with SV bind and the restrictions, so some research is needed).

However just to caution, we need to be very careful if we start discussing enhancements or changes to existing SV features. These may not be possible/accepted by the SV committee.

Our changes to bind may be also useful to pure SV, it may be something that we want to propose and pursue via that committee instead.

All of these enhancements are listed in Mantis item 3392:
http://www.verilog.org/mantis/view.php?id=3392

David will update Mantis to split these enhancements into separate items to allow for individual tracking.

Next Call

The next call will be Thursday 17th March.

An agenda will be distributed two days prior to the call.

Dialin Details:
San Francisco, 11.30a
Austin, 1.30p
Boston, 2.30p
Amsterdam, 8.30p
Tel Aviv, 9.30p
New Delhi, 1a (next day)
Adelaide, 6a

Call-In Details:
USA Toll Free : 8008671147
Australia Toll Free: 1800009128
India Toll Free : 0008006501482
Netherlands : 08002658223
Passcode: 0970751#

-- DavidMiller - 2011-03-04