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

[Maciej S. <mac...@ce...>]

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

I am sorry, there is a mistake - it is about casting strings to
vectors, not the other way round.

Regards,
Orson

On 11/04/2014 02:04 PM, 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.
             ^^^^^^^^^^^^^^^^^^ => strings to vectors
> 
> 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
> 
> ------------------------------------------------------------------------------
>
> 
_______________________________________________
> Iverilog-devel mailing list Ive...@li... 
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUWM+PAAoJEBRwGu1hpbJ1KpQH/iyLUYJMIynJpLrwmiGYmt1u
e4lv9QAbwXcvBMuStrYpSNKgQXDS8+swdxYr702ZlyTKyl3rxmm4mDQHDJLadZbF
sRVQSDTaPhNlvJ+NpkS9Mg20ciSNAtlpQC/5wB2/Tw2qRy50sW/A419RP1rh1t1t
BfwiMcVgC+3L8BPfX7MNCdrOPJIuRGjApBZh34cw/3IgffmWPVTbqL+DQK5pkB3e
GBoDmycRd9Ej9aSLDswQkw01n0EKLvP6nVJ4N86VHb2A4+nH3DPXELvDEh54VS4y
3Mgg8Q/1DuYrluO+ZreV6gt1tBMN/2McqqZ6gICqiHZEMcTqpCPwH723gEMwHaQ=
=6Alu
-----END PGP SIGNATURE-----