On Mon, Nov 07, 2005 at 05:22:25PM -0200, Richard Maciel wrote:
> I kept the original message so others can see the context
Good.
[...]
> > > Im working on the ghdl simulation kernel (grt) to implement the
> > > vpi_put_value function and the ReadWriteSync callback of VPI using
> > > your code as an example. But, even doing so, im having some problems
> > > to implement that function. Basically, I saw you separated the actual
> > > grt signal reading from VPI using avhpi functions. My questions are:
> VHPI is the VPI for VHDL. The GHDL VPI interface is based on VHPI.
> Not every VPI interface can be mapped to VHPI (and vice-versa).
> Within GHDL, only a few interfaces of VHPI are implemented.
>
> - Checked. Have both specs here for reference.
>
> > > - How can I do the same for vpi_put_value? I saw the Vhpi_Put_Value
> > > function (is there a way to not use it - I mean, convert from a
> > > p_vpi_handle to a Ghdl_Signal_Ptr?), but it only works with
> > > VhpiIndexedName objects and I must confess that I didnt understand
> > > what do those objects do. Specifically, Im asking for some hint about
> > > which functions I should take a look to succesfully implement
> > > vpi_put_value.
> The Vhpi_Put_Value only works on generics and variables. It is used to do
> VITAL annotations. Currently, it doesn't work with signals.
> Unless you want to force or override a signal, you need a driver to assign
> a value to a signal. Unfortunatly, there is no concept of drivers in Verilog.
>
> You should start with modifying vhpi_put_value and vpi_put_value so that it
> works on a simple example and then adding more features.
> To understand how to assign a value to a signal, see
> ghdl_signal_simple_assign_XX (but these functions use a driver).
>
> - In fact I want to force a signal assignment, so I will use the
> Set_Effective_Value on the signal.
> Follows my "sketch" of the vpi_put_value function:
>
> function vpi_put_value (aObj: vpiHandle;
> aValue: p_vpi_value;
> aWhen: p_vpi_time;
> aFlags: integer)
> return vpiHandle
> is
> begin
> -- A very simple write procedure for VPI.
> -- Basically, it accepts bin_str values and converts to appropriate
> -- types (only std_logic and bit values and vectors).
>
> -- It'll use Set_Effective_Value procedure to update signals
>
> -- Ignoring aWhen and aFlags, for now.
>
> -- Step 1: convert vpi object to internal format.
> -- p_vpi_handle -> Ghdl_Signal_Ptr
> -- * The vpiHandle has a reference (field Ref) to a VhpiHandleT
> when it doesnt come from a callback.
>
>
>
>
> -- Step 2: convert datum to appropriate type.
> -- p_vpi_value -> Value_Union
>
> -- Checks the format of aValue. Only vpiBinStrVal will be
> accepted for now.
> case aValue.Format is
> when vpiObjTypeVal=>
> dbgPut_Line ("vpi_put_value: vpiObjTypeVal");
> when vpiBinStrVal=>
> -- The format must be converted to a
> dbgPut_Line ("vpi_put_value: vpiBinStrVal");
> when vpiOctStrVal=>
> dbgPut_Line("vpi_put_value: vpiNet, vpiOctStrVal");
> when vpiDecStrVal=>
> dbgPut_Line("vpi_put_value: vpiNet, vpiDecStrVal");
> when vpiHexStrVal=>
> dbgPut_Line("vpi_put_value: vpiNet, vpiHexStrVal");
> when vpiScalarVal=>
> dbgPut_Line("vpi_put_value: vpiNet, vpiScalarVal");
> when vpiIntVal=>
> dbgPut_Line("vpi_put_value: vpiIntVal");
> when vpiRealVal=> dbgPut_Line("vpi_put_value: vpiRealVal");
> when vpiStringVal=> dbgPut_Line("vpi_put_value: vpiStringVal");
> when vpiTimeVal=> dbgPut_Line("vpi_put_value: vpiTimeVal");
> when vpiVectorVal=> dbgPut_Line("vpi_put_value: vpiVectorVal");
> when vpiStrengthVal=> dbgPut_Line("vpi_put_value: vpiStrengthVal");
> when others=> dbgPut_Line("vpi_put_value: unknown mFormat");
> end case;
>
> -- Step 3: assigns value to object using Set_Effective_Value
> -- call (from grt-signals)
> -- Set_Effective_Value(sig_ptr, conv_value);
You should set the driving value too.
> -- Must return a scheduled event caused by vpi_put_value()
> -- Still dont know how to do it.
Scheduled event doesn't exist in VHDL. I suppose vpi_put_value returns a
scheduled event so that it can be removed ? This can be difficult to do in
VHDL.
> return null;
>
> end vpi_put_value;
>
> - Could you comment it, mr. Gingold?
[See inside]
> > > - I didnt find any check in the ReadOnlySynch callback which prevents
> > > write access to objects. Is that because there is no write functions?
> Yes.
> > > Because if this is right, I should add some checks in the
> > > vpi_put_value function.
> Right.
>
> - Checked.
>
> > > - I saw that the vpi interface cannot even select a signal or port of
> > > other types than bit and bit_vector. The funny thing is: the
> > > vpi_get_value function has code to convert std_logic and
> > > std_logic_vector types to a binary string - by the way, the vcd print
> > > "engine" has the same problem. Is that a bug, or is something missing
> > > in this puzzle? And if this is the right behavior, can you give some
> For sure, VCD works with bit and std_logic (and their vectors). For VPI,
> I *think* it should handle std_logic and its vectors. Otherwise this is
> a bug (or a miss).
> > > hints for me so I can alter the simulation kernel to select those
> > > types.
>
> If you use the VPI to iterate over the nets of a "module", you will
> see the kernel getting only bit and bit_vector values. If you need an
> example, I can send as an attachment.
Oh yes please.
> > > - Last question (I swear! :-) ): When you receive a ReadOnlySynch
> > > callback, one of its parameters is a structure containing the callback
> > > generator. The problem is: that field is always null! Can you give me
> > > some hints so I can implement the right behavior?
> Which field are you speaking about ?
> Only the minimum was implemented. Most fields are not initialized. But they
> could be either during the registration or just before the call.
>
> - Im talking about the Obj field of the s_cb_data structure passed as
> an argument to a vpi callback.
>
> type s_cb_data is record
> Reason : Integer;
> Cb_Rtn : cb_rtn_type;
> Obj : vpiHandle; <===== This field
> Time : p_vpi_time;
> Value : p_vpi_value;
> Index : Integer;
> User_Data : Address;
> end record;
>
> - According to the vpi std, when you receive a VPI callback you should
> receive a pointer to that structure. Specifically in the
> cbReadOnlySynch (and cbReadWriteSynch) callback the Obj field points
> to the VPI object which generated the callback.
I am not an expert on VPI. What is that VPI object ? A net/reg or a scheduled
event ? If many nets are updated, is this call-back called several times ?
In any cases, GHDL can be modified to emulate more correctly this VPI
call-back.
> > > Sorry for sending so many questions - I confess I keep them with me
> > > and tried to resolve then by myself, but couldnt.
> Do not hesitate to ask questions. But the more specific they are the better
> and
> quicker the reply is.
>
> BTW, you should use the ghdl mailing list (gna.org/projects/ghdl). Other
> people might be interested and this leaves traces too.
>
> - Signed. :-)
Good.
Tristan.
