pascalkuthe / OpenVAF

An innovative Verilog-A compiler
https://openvaf.semimod.de/
GNU General Public License v3.0
123 stars 20 forks source link

String parameters in OpenVAF #74

Closed arpadbuermen closed 1 year ago

arpadbuermen commented 1 year ago

Does OpenVaf support string parameters? I tried compiling a .va file containing the following line

(desc= "Dummy", type="instance", units = "none") parameter string dummy = "abc";

OpenVAF crashed (says it panicked because it entered unreachable code).

On the OSDI side, calling access() for a string parameter returns a void* pointer. How should I interpret this pointer? Should I cast it to char**?

Suppose I do this for a string parameter:

char ptr = (char)(osdiDescriptor->access(...)); free(ptr); ptr = (char)malloc(...); strcpy(ptr, "new string");

Is this OK in the spirit of OSDI and OpenVAF?

pascalkuthe commented 1 year ago

thanks for reporting that crash. OpenVAF does support string parameters/variables but because they aren't used much some issues went unnoticed. I fixed the bugs I found in #75 and added a dummy testcase. You can use the nightly version linked in the README unil the next release. If you have a real-world model that makes use of string parameters then I would love to add it to the testruit?

Regrding OSDI integration the usage you can indeed cast the pointer to a (char **) pointer. Note however that the model will never allocate a string itself. The value is initialized to a null pointer (and only populated with the default value in steup_model/setup_instance if no value is supplied) so freeing the pointer will likely cause a use after free (unless you ase sure you previously populated the value).

arpadbuermen commented 1 year ago

Where is the default value of a string parameter (the one to which the *ptr points) stored? Is it in the .text section as a string constant or is it allocated on the heap at parameter defaulting?

pascalkuthe commented 1 year ago

It's in text, OSDI models never allocate anything. The only exception is $display (and similar functions) because there is no alternative

pascalkuthe commented 1 year ago

But before you call setup_model/setup_instant the pointer is just null

arpadbuermen commented 1 year ago

In that case it would really be welcome to expose somehow the param_given bitfield of the instance and model data structure. When a new string is set, the old one has to be freed. One really does not know if a string parameter was allocated by the user or it points to the default value in the .text section, unless one stores this information somewhere in the simulator (waste of space because the same info is already stored in the model/instance structure).

There are two possibilities: 1) adding a driver function to the desscriptor with the following form int param_given(void model, void instance, uint32_t osdi_id); If instance is NULL then the param_given() call applies to the model, otherwise it applies to the instance.

2) exposing the internal structure of the model and the instance object (I guess both of them are structs) in the form of an .h file generated by the OpenVAF compiler.

Case 1 would be much cleaner and simple to use on the side of the simulator.

Does the same problem occur with vector parameters too?

pascalkuthe commented 1 year ago

Adding a param_given function sounds reasonable. I dont really want to expose the internal memory lsyout but adding a function makes sense. The intention was that allocations are tracked by the simulator (in an arena allocator for example, usually paramter are just referwnces to the netlist which woild be kept for the entire duration of the simulation). I think a param_given functon is useful and has other usecases too so I will add it anyway when I habe tine. I created #76 to track that.

OoenVAF currently doesn't support vector parameters so that issue hasn't come up yet.