Open avelure opened 2 months ago
This is a big mess at the moment and I'm not sure of the right way to fix it.
int64_t
length argument for each array dimension (if you want left/right/direction you need to pass that separately). So your example above should be void str_vffi(char *str, int64_t length);
and the string is not null-terminated.const vhpiCbDataT *
argument that you then need to extract the parameter values from using the VHPI API. The only difference between "VHPI" and "VHPIDIRECT" is that for the former subprograms need to be registered explicitly with the vhpi_register_foreignf
VHPI function and for the latter they are looked up automatically. NVC implements only "VHPI" (see test/regress/vhpi14.vhd
and test/vhpi/vhpi14.c
for an example). As far as I know only Aldec implements fully compliant "VHPI" and "VHPIDIRECT". Questa might too but I haven't tried.I think the situation I'd like to get to is:
const vhpiCbDataT *
argument).I see, this is a bit of a hot mess. I don't know if having 4 standards is the way to go unless it is to keep backwards compatibility.
At present time, what do you think would be the most cross compatible way to pass bulk data to/from VHPIDIRECT procedures?
At present time, what do you think would be the most cross compatible way to pass bulk data to/from VHPIDIRECT procedures?
I don't think there's anything that works across all simulators at the moment. But if you restrict the procedure to take a constrained array with static bounds then I think GHDL and NVC VHPIDIRECT are compatible:
procedure str_vffi_impl(constant str : in string(1 to 100)) is
begin report "VHPIDIRECT str_vffi" severity failure; end;
-- NVC does not support library name in attribute but I can add that...
attribute foreign of str_vffi_impl : procedure is "VHPIDIRECT str_vffi";
procedure str_vffi(constant str : in string) is
variable padded : string(1 to 100) := (others => NUL);
begin
padded(1 to str'length) := str;
str_vffi_impl(padded);
end procedure;
void str_vffi(const char *str) {
printf("'%s'\n", str);
}
"GHDL lib.so my_func" emulates the GHDL calling convention including fat pointer passing. This would only really make sense if we could get GHDL to agree to also accept "GHDL" as an alias for "VHPIDIRECT" so code could be portable.
I raised this in ghdl/ghdl#2760.
I'm testing out VHPIDIRECT with strings and I'm running into some crashes. As I understand from the GHDL documentation the strings are treated as unconstrained arrays and passed as fat pointers. There is a header in ghdl_cosim to unwrap them https://github.com/ghdl/ghdl-cosim/blob/master/vhpidirect/vffi_user.h Before I tried with the vffi header I assumed it was just passed as null terminated c-strings, which I got working in NVC (though I realized later it is passing them as unterminated strings), but this just gives garbage characters in GHDL. With the fat pointer it works in GHDL, but NVC gives tracebacks.
On a side note I see GHDL supports passing the name of the library to load in the foreign string so that it is not neceseary to pass it on the commandline. NVC supports parsing it in the foreign string, but does not seem to load it if the
--load
parameter is not passed.When working from native commandline I normally have the path pointing to msys64/ucrt64/bin before msys64/clang64/bin. I see this gives another kind of traceback in nvc (as I compile it for clang64), but I don't know if this error is something that is fixable.