Menu
▾
▴
iverilog-devel
|
From: Maciej S. <mac...@ce...> - 2014-10-29 13:03:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUUOWsAAoJEBRwGu1hpbJ1IvIH/jTRRZ0+tfFNsJhQY08i/20A viwKwKRBsUxEaqlDtA57A69Uli/bwnNzxhERUr/Ulv0K63FhuqH3okiLhNTYxWyD mBpqxj+xh6o7VxVyRowiNnL0bEroEuTyWTAP3cdV7ZwD2j5cr8t4E6ne192Sk6Sm aQ9VVpcUYhymNhSPQKhx1a23tlDQekLP4Utkcn6TgkWz7dzP+ejZzwO/MuEaN5an zLF23HLiD6B/oAEVj9e9SsLSIS5eqTpza/AiUpmTlzlXjE6CstdUwvGWzXSiW17W o0E2Q5AMSQro85i3w4kdR9GOsfBVZtDQ0p/Rrm9EEeJhm8Y2JUiRxHMVGgUhhKA= =nJRf -----END PGP SIGNATURE----- |
|
From: Stephen W. <st...@ic...> - 2014-11-01 22:04:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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) iEYEARECAAYFAlRVWOQACgkQrPt1Sc2b3iljbwCggnooxsbJg9Nd9mEkGA25PjFg wykAoOtpbTHKkr7iaMx/mDYv5Gze9fLh =QjmI -----END PGP SIGNATURE----- |
|
From: Maciej S. <mac...@ce...> - 2014-11-03 09:43:37
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUV04wAAoJEBRwGu1hpbJ1LOcH/i0chaJDTCBNWaMyFc4AT2G/ E0W7DQuR+Vrys+evCtZNdpBpg+5sNDIrIKfSmfrczzUrI9Al5yMO69wPS3X/EIFS AhErfpqrxXaMblaguRQrjt/4Z0n99lZB0FoJ/EiM+nOk8eRPuIV0KNGx3iiEZCzb KsQGQDLU9gMI9zpNTkdyZrg5hdL6hDdmJ/xdL2A/GA5R0Z9foZvW+0Wm0AkeNu6H erfE+CftB+1kXgITCBYKOfZRyYvSyklAaYrYr9uaN5L0rTOT0bgfvTK0ss6P5Q3c lRJX10kdeq5FCYqyG00YW8v3xmu7qMXO/w55LRel3nKQPA7k3yNZtrLW9+jEBdg= =nZkx -----END PGP SIGNATURE----- |
|
From: Stephen W. <st...@ic...> - 2014-11-03 15:59:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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) iEYEARECAAYFAlRXpkEACgkQrPt1Sc2b3ik/kwCgwoijTHBr3cq9YlGNgg+61FDe DroAoLNTM7YM8Im3yEv26KN6+wcvi9It =Lg1y -----END PGP SIGNATURE----- |
|
From: Maciej S. <mac...@ce...> - 2014-11-04 13:04:28
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBAgAGBQJUWM7GAAoJEBRwGu1hpbJ1X/0H/0Yy4SUfrVZ1tCaQVjYMYrjZ
Flgad3SoAeQ08npY1SWSrRDo1wy+cXa9KtM350huDkjSwwQo7jJY1FZwhBtdJMho
Llbwjj4jjI33oEE7Zz2beBSCpjwaK9R8dR3fJdZgosGFQQyVtXfCAC7RI2KRsztb
PG2aedraBUN4R1v5F4VbCjkeuaJWa+CUBC0j55aN5HFZ34A8hr3dzoYZWDfYWTIx
OJCNM2i1XGzrVeEv4fha9yDHMgvqkrNXUOe8DbExEwzx4mJehfsKgJVnff08kBqo
lqZ73oAeU5ccT94t2eg8yLtXPsns3F79uimphlrWugsk0u7MMcWcLAen9Y4XLCA=
=LcCL
-----END PGP SIGNATURE-----
|
|
From: Maciej S. <mac...@ce...> - 2014-11-04 13:07:37
|
-----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-----
|
|
From: Stephen W. <st...@ic...> - 2014-11-04 15:39:55
|
-----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-----
|
Thanks for helping keep SourceForge clean.
X