-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VPI interface function vpi_put_value() NEEDS a delay capability #2485
Comments
Although full VPI support might be too far fetched, yes I plan to
implement useful features. Delay in vpi_put_value is part of it.
|
well, by full.. lets say supporting old obsolete ACC/TF or anything "_systf" stuff is not needed. but fully functioning vpi_get_value/vpi_put_value/vpi_register_cb (with ALL flags support) as well as vecval data types passing is a must. and ability to force any signal deep in design. in a current state its practically not even usable. |
@r2com @tgingold @r2com Shall we communicate in the email,i want to ask some question about the vpi port meaasage.My email address is [email protected] |
So in a file:
./src/grt/grt-vpi.adb
function:
function vpi_put_value (aObj : vpiHandle;
aValue : p_vpi_value;
aWhen : p_vpi_time;
aFlags : integer)
return vpiHandle
does not implement the delay capability of p_vpi_time type, thru aWhen parameter.
in fact its uncommented:
-- Ignoring aWhen and aFlags, for now.
This is a main roadblock for me to use GHDL, the thing is; for verification I am using solely the software based custom in-house written code which heavily using VPI.
And another requirement is - no HDL testbench, just c/c++ code.
If I want in one callback function initiated by vpi_register_cb modify MANY signals, each with own delays, the only way when using ghdl+cosim is: call multiple vpi_register_cb() [each with own delay] each with its own vpi_put_value() [without delays], however; that is very inefficient in terms of execution time since vpi_register_cb() is an expensive operation.
so.. are there plans to make fully functional VPI in ghdl or not?
OR, are there any plans to give fully functional VHPIDIRECT then?
or cosim is kinda always gonna stay on low priority and not extend to full capability?
right now, for me the only way is - if my HDL is in Verilog, and then I use icarus (which does implement delay in vpi_put_value())
but if my source is VHDL - ghdl is a no go.
The text was updated successfully, but these errors were encountered: