I kept the original message so others can see the context
---------- Forwarded message ----------
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Nov 4, 2005 10:49 AM
Subject: Re: GHDL with IVI
To: Felix Bertram <[EMAIL PROTECTED]>
Cc: Richard Maciel <[EMAIL PROTECTED]>
Selon Felix Bertram <[EMAIL PROTECTED]>:
Hi,
> Tristan: This is the student I mentioned before. I attached his
> ealier questions below, so you have a better understanding of what
> Richard is looking for.
> > Mr. Bertram,
> >
> > 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);
-- Must return a scheduled event caused by vpi_put_value()
-- Still dont know how to do it.
return null;
end vpi_put_value;
- Could you comment it, mr. Gingold?
> > - 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.
> > - 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.
> > 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. :-)
Thank you for your interest in GHDL,
Tristan.
- Thanks for your help!
--
Richard Maciel
----------------------------------------------------
Computer Engineer
M.S. Student at LSC - IC - Unicamp
