Re: Another array question

Arpad,

> Sorry for beating the dead horse some more, but I
> ran into another problem with arrays.  I need to
> either resize an array or be able to declare an
> array after some number crunching.
> 
> My (limited) understanding is that the size of the
> array is determined at the time of the declaration
> and cannot be changed during simulation.  Correct?

This is correct.

> Do all declarations have to be placed before the
> "analog begin" keyword?  Also, my understanding is
> that all code has to be after the "analog begin"
> keyword.  Is this correct?

This is not correct, you can create a new array inside
a named block statement inside the analog block. Also in
a named analog block you can declare lcoal variables.
These have to be at the start of the block, according to
the standard (par 6.2.1).

Apart from the standard, a number of current implementations
of Verilog-A(MS) also allow local variables to be declared
in unnamed blocks. I cannot vouch for all, though.

There is nothing stopping you from using a local variable
to assign values to global variables, even very deep in a
named block hierarchy.
> 
> If this is all true, it doesn't seem to be possible
> to run some code and generate an array which has
> a size that depends on the outcome of that code.

This is true, as the (local) variables have to use a
constant_expression to define array boundaries. And
constant_expression means determinable at compile time.

> 
> Here is an example why this would be important:
> There are two or more x-y data tables which must be
> processed by some algorithm.  In order to process
> them, they must have a common distribution of x-axis
> points, but the raw incoming data is not guaranteed
> to obey that rule.  So I need to generate a new x-axis
> which includes all x-points of all tables without
> repetition, and then fill in the missing y points
> by interpolation.  The length of the new array will
> be determined by the raw data tables, and is unknown
> beforehand.
> 
> Could anyone tell me whether this can be done according
> to Verilog-AMS LRM v2.2?

My opinion is that it cannot be done with the current LRM.

To do this efficiently, I think Kevin's suggestion to use
System-Verilog's pass-by-reference function model is
reasonable, but I'm not sure that this will make it to
LRM 2.3. It seems to be more of a 3.0 thing to me. The impact
on the internal data structures and code generation in a
compiler seems to me a bit too much for the evolutionary
approach were working with to help vendors make a smooth
transition.

Regards,
Marq