Re: [Iverilog-devel] Unbounded vectors as parameters in SV functions

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Look for the %cvt/xxx opcodes in vvp. That is one possibility.
Another is to generate a call to a system function to do the
conversion. I have used that trick for a variety of things.

You can define an Icarus Verilog specific system function to
have whatever meaning you want, and you can generate calls to
it as you see fit.

(I'm also kinda trying to discourage working directly in vvp
right now because I'm working on a big vvp vector handling rework.)

On 11/04/2014 05:04 AM, Maciej Sumiński wrote:
> Thank you Steve. There is no need to hurry, I still have other 
> features to code. Speaking of which, I am wondering how to
> implement casting of vectors to strings.
> 
> I have reached the stage where I need to write opcodes for vvp.
> The first trial is an extension of the code that ivl outputs for
> an assignment of a single character to a vector:
> 
> ------------------------------------- vector_variable .var
> "chars", 55 0; string_variable .var/str 	"str";
> 
> %pushi/str "0123456"; %store/str string_variable;
> 
> %load/str string_variable; %ix/load 4, 0, 0; %mov 4, 0, 1; 
> %substr/v 8, 4, 56; %pop/str 1;
> 
> %set/v vector_variable, 8, 56; %vpi_call/w 2 14 "$display", "%s",
> vector_variable {0 0}; -------------------------------------
> 
> I see two problems with the presented approach: - the string is
> reversed after casting - the string length is hardcoded
> 
> The first solution that comes to my head is to output a loop that 
> copies characters, one after another. $ivl_string_method$len could
> be used to determine the number of the loop iterations.
> 
> On the other hand, a VPI function could be more elegant, but I
> would like to know your opinion first. Is a new VPI function 
> ($ivl_string_method$to_vec?) acceptable or would you rather avoid
> such extensions?
> 
> Regards, Orson
> 
> On 11/03/2014 04:58 PM, Stephen Williams wrote:
> 
>> This is something I should fix. I am working on something else 
>> right now (on the vec4-stack branch) but as soon as I'm done with
>>  that I will tackle this.
> 
>> On 11/03/2014 01:43 AM, Maciej Sumiński wrote:
>>> Hi Steve,
> 
>>> I am really glad to hear that. I am wondering if it would be a
>>>  major problem to support dynamic arrays of single bit and
>>> logic? Current implementation works perfectly fine with
>>> integers, reals or packed arrays of bit, but for dynamic array
>>> of single bit I use the following workaround:
> 
>>> function fun(bit [0:0] var[]);
> 
>>> instead of:
> 
>>> function fun(bit var[]);
> 
>>> Also, I could not use 4-state logic with dynamic arrays, even 
>>> with the mentioned workaround:
> 
>>> function fun(logic var[]); / function fun(logic [0:0] var[]);
> 
>>> If you are busy at the moment, are there any hints that would 
>>> help me deal with the task? The first issue is not serious,
>>> but the second one I find very advantageous.
> 
>>> Regards, Orson
> 
>>> On 11/01/2014 11:04 PM, Stephen Williams wrote:
> 
>>>> The good news here is that the latest Icarus Verilog does 
>>>> support dynamic arrays, so what you propose should work.
>>>> There may be details of the implementation that does not work
>>>> yet, just let me know and I'll try to tackle the missing
>>>> bits.
> 
>>>> The example output that you propose does use dynamic arrays,
>>>> so should work. If it does not, I can address that.
> 
>>>> On 10/29/2014 06:03 AM, Maciej Sumiński wrote:
>>>>> Hi,
> 
>>>>> I evaluated the previously proposed solution and none of 
>>>>> them is feasible at the moment.
> 
>>>>> I rejected support for unbounded vectors in SV as I felt I
>>>>>  could not do that in a clean and reliable way. Aside from 
>>>>> that, it is not compliant with the standard, so it should
>>>>> be avoided if possible.
> 
>>>>> Function instancing will not work in at least one case. The
>>>>>  problem appears when someone tries to call a function that
>>>>>  takes unbounded std_logic_vector and passes as an argument
>>>>> a function that returns unbounded std_logic_vector:
> 
>>>>> --------- function strange_fun(inp : std_logic_vector)
>>>>> return std_logic_vector is begin -- body end function;
> 
>>>>> result <= strange_fun(strange_fun(B"1110")); ---------
> 
>>>>> In the above example, it is not possible to say what is the
>>>>>  size of the vector returned by the nested call, until the
>>>>>  runtime. vvp instruction set expects vector boundaries to
>>>>> be given as constants, therefore it is not possible to
>>>>> express the above code with available instructions.
> 
>>>>> If instead of packed arrays we could use unpacked arrays, 
>>>>> then dynamic arrays are suitable for the task.
>>>>> Fortunately, it is also possible to perform bit-stream
>>>>> casting between packed and unpacked arrays (including the
>>>>> dynamic type). That way vectors of unknown size can be
>>>>> casted to dynamic arrays as needed.
> 
>>>>> In the attachment you may find code examples that
>>>>> illustrate the way I would like to follow. It is still a
>>>>> bit twisted, but I think this is the simplest method.
>>>>> Please let me know if you notice any flaws.
> 
>>>>> The implementation will require support for type casting in
>>>>>  SystemVerilog. That is the first part I would like to code
>>>>>  unless there are objections.
> 
>>>>> Regards, Orson
> 

- -- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlRY80MACgkQrPt1Sc2b3imCigCgiFCBjf8TxxbuDkkuW7SkerSf
6v8AoKiPp23DWSfd+c8hPVPw7a2UeNUR
=GRb+
-----END PGP SIGNATURE-----