iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] How to get gate count and delay for a (combinatorial) circuit?

[Martin W. <mai...@ma...>]

For synthesis, I would suggest taking a look at

   http://www.clifford.at/yosys/about.html

Martin

ni...@ly... (Niels Möller) wrote:
> Hi,
>
> I'm trying to learn verilog (with the ultimate goal of eventually
> implementing a cpu of my own design). As a warmup, I'm starting with
> combinatorial circuits for arithmetic, and I've been reading up on
> Wallace trees and Kogge-Stone adders and variants.
>
> I organize this as a module implementing each circuit, and a "testbench"
> which exercises it with some inputs (exhaustive testing for small
> operations). I just realized that I could have the verilog testbench
> also check if the outputs are correct, at least for basic arithmetic.
> And after searching the net for quite a while I also found
> $finish_and_return, which is very handy to signal failures from the
> testbench. Which all seems pretty nice.
>
> For synthesis, I won't attempt real synthesis anytime soon, but it would
> be nice to be able to get some numbers for the gate count for a circuit,
> and the gate delay between inputs and outputs (and any other properties
> that indicate if the implementation makes sense). Initially for
> combinatorial circuits, since that's what I'm playing with. Is there any
> easy way to get that information from iverilog's synthesizer?
>
> Best regards,
> /Niels
>

Re: [Iverilog-devel] How to get gate count and delay for a (combinatorial) circuit?

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

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


The only accurate gate count fron synthesis is go get the gate count
from the synthesizer that you are using to targetting your device.
For FPGAs, that will be the vendor supplied synthesizer.

That said, you can use the "-tsizer" target to Icarus Verilog to
get a very (VERY!) rough estimate of gate counts. This is really
only useful for relative comparisons (i.e. "Did my last change
cause a lot of new resources to be required?").

But given where I think you are, you probably are not ready to
start thinking about stuff like that.

On 11/05/2014 12:39 PM, Niels Möller wrote:
> Hi,
> 
> I'm trying to learn verilog (with the ultimate goal of eventually 
> implementing a cpu of my own design). As a warmup, I'm starting
> with combinatorial circuits for arithmetic, and I've been reading
> up on Wallace trees and Kogge-Stone adders and variants.
> 
> I organize this as a module implementing each circuit, and a
> "testbench" which exercises it with some inputs (exhaustive testing
> for small operations). I just realized that I could have the
> verilog testbench also check if the outputs are correct, at least
> for basic arithmetic. And after searching the net for quite a while
> I also found $finish_and_return, which is very handy to signal
> failures from the testbench. Which all seems pretty nice.
> 
> For synthesis, I won't attempt real synthesis anytime soon, but it
> would be nice to be able to get some numbers for the gate count for
> a circuit, and the gate delay between inputs and outputs (and any
> other properties that indicate if the implementation makes sense).
> Initially for combinatorial circuits, since that's what I'm playing
> with. Is there any easy way to get that information from iverilog's
> synthesizer?
> 
> Best regards, /Niels
> 


- -- 
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

iEYEARECAAYFAlRbuXgACgkQrPt1Sc2b3inD5gCeLha4vfBA3nx65+dbNQ9cODsu
6dwAn3reG4LSyhxdW3xUGe7Es5l4F12l
=qWMz
-----END PGP SIGNATURE-----

[Iverilog-devel] How to get gate count and delay for a (combinatorial) circuit?

[<ni...@ly...>]

Hi,

I'm trying to learn verilog (with the ultimate goal of eventually
implementing a cpu of my own design). As a warmup, I'm starting with
combinatorial circuits for arithmetic, and I've been reading up on
Wallace trees and Kogge-Stone adders and variants.

I organize this as a module implementing each circuit, and a "testbench"
which exercises it with some inputs (exhaustive testing for small
operations). I just realized that I could have the verilog testbench
also check if the outputs are correct, at least for basic arithmetic.
And after searching the net for quite a while I also found
$finish_and_return, which is very handy to signal failures from the
testbench. Which all seems pretty nice.

For synthesis, I won't attempt real synthesis anytime soon, but it would
be nice to be able to get some numbers for the gate count for a circuit,
and the gate delay between inputs and outputs (and any other properties
that indicate if the implementation makes sense). Initially for
combinatorial circuits, since that's what I'm playing with. Is there any
easy way to get that information from iverilog's synthesizer?

Best regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

[Iverilog-devel] SystemVerilog enumerations should be (mostly) complete

[Cary R. <cy...@ya...>]

I have made a few changes and fixed a number of bugs in the enumeration elaboration code over the last few weeks and at this time other then casting, which Icarus does not currently support, I believe they should be fully functional. If you have had problems with enumerations in the past please check to see if they work correctly with the latest development code from git. If you find a bug/limitation other than casting please report it.




Cary

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-----

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-----

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

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

-----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-----

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

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

-----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-----

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

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

-----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-----

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

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

-----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-----

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

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

-----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-----

[Iverilog-devel] Expression concatenation in VHDL

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

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

Hi,

Branch that supports expression concatenation in VHDL is ready to be
merged [1] together with tests [2]. There is also support for VHDL's
integer() function.

I have investigated further the problem of range boundaries evaluation.
The problem with the following example code is a bit deeper.

- --------------
function test_func(word_i : std_logic_vector)
return std_logic_vector is
	for I in word_i'range loop
		-- do sth
	end loop;
end function;
- --------------

It is not only about exact evaluation of range boundaries. As far as I
know, SystemVerilog does not allow to declare functions that take and
return vectors (i.e. packed arrays) of undefined size. There are dynamic
arrays, but they are valid only for unpacked dimensions.

Currently I see two possible solutions, one on ivl side and another in
vhdlpp:

* Support for unconstrained vectors in ivl

It does not solve the problem of determining the direction of for-loops
that use the 'range attribute, so the previously proposed solution would
have to be applied.
This would have to be explicitly enabled using a flag, so by default ivl
conforms to the IEEE standard.
Just to be clear, I do not ask anyone to implement it. If that is the
right method then it is a perfect opportunity for me to dive deeper into
ivl code.

* Create extra function instances with name mangling in vhdlpp

During the elaboration step the type of parameters for a particular
function call could be determined and used to create a copy of the
function that works with specific constrained types. For example:

- --------------
function test_func(word_i : std_logic_vector)
return std_logic_vector is
	-- function body
end function;
- --------------

could be instantiated as:

- --------------
function slv7_0__test_func__slv7_0(word_i : std_logic_vector(7 downto 0))
return std_logic_vector(7 downto 0) is
	-- function body
end function;

function slv1_4__test_func__slv1_4(word_i : std_logic_vector(1 to 4))
return std_logic_vector(1 to 4) is
	-- function body
end function;
- --------------

in case it is called with the presented argument types.

In VHDL functions that return unconstrained std_logic_vector are allowed
to return vectors of different sizes every time. Example:

- --------------
function func(sel : std_logic) return std_logic_vector is
begin
  if sel = '1' then
    return "001100";
  else
    return "111";
  end if;
end function;
- --------------

This can solved thanks to strong typing, so you could deduce the
returned type by looking up the assignment left hand's type.

I am not sure yet which one is the way to go, but maybe you already see
that one of them is wrong and could be rejected.

Regards,
Orson

1. https://github.com/steveicarus/iverilog/pull/47
2. https://github.com/orsonmmz/ivtest/tree/concat_test
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUQRhOAAoJEBRwGu1hpbJ1+iMH/jXToHF002yILeI+wQ0hZMcC
IVPfL2w1cxV7iC2dQyUIggXqX8ujEQqNb4Q3ueVqu4veAKQtsG+aOP4OxsbqFpEg
e7OuDTK7OyO7rTz7SJ4Tx1fHpYcMyIFtqByIItBr+9BrGSCHLiWSHXfb5fNgfXRM
gYht2PG5MdEBw3SYA3JS1JFeLX3rxXjLFPl1G4osnvxV8/3XahdRE1Td4xTTaNSo
B86s0bQDBAr9mrnvCMORC8vOQRDW/1WrAwlXb42uuaK2wwy2gQNH3e5KPPaHsY1h
vYS5LJAfM4rbwA8KRbOKFK1YqB6+kci92GHfC62idwD6LNieIrvocv5APyYrYuk=
=bNNa
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] New VHDL attributes

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

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

I have overlooked one important thing about ranges. There are cases
when one cannot evaluate array boundaries until the run-time. An
example is a function that takes std_logic_vector without specifying
its size, e.g.

function test_func(word_i : std_logic_vector)
return std_logic_vector is
	for I in word_i'range loop
		-- do sth
	end loop;
end function;

Because std_logic_vector may have indices increasing or decreasing (to
vs downto), the 'range attribute has to determine appropriate for-loop
condition and afterthought.
It would be easy to apply SystemVerilog's foreach here, but there is
no counterpart for 'reverse_range.
There is another solution that comes to my head:

for(i = $left(word_i), bool _rising = $left(word_i) < $right(word_i);
	_rising ? i <= $right(word_i) : i >= $right(word_i);
	i = i + (_rising ? 1 : -1))

It determines the right iteration direction during the run-time, but I
am not sure if that is the most elegant solution. Maybe someone else
knows what else could be applied to solve the problem.

Regards,
Orson

On 10/10/2014 07:03 PM, Maciej Sumiński wrote:
> Hi Steve,
> 
> There is a branch [1] that adds support for VHDL attributes:
> 'range, 'reverse_range, 'left & 'right. There are also tests for
> the mentioned features [2].
> 
> Before you merge the changes, I would like to attract your
> attention to two things that I might have potentially got wrong:
> 
> * patch for continuous assignment of 2-state nets (commit 1a4edca) 
> Previously VHDL 'integer' was translated to 'bool[31:0]', but as
> we agreed I have changed that to 'int'. I did so, because the
> attributes could not correctly recognize boundaries for arrays of
> integers ('left returned 31, 'right returned 0, no matter what was
> the actual size of the array). This caused some problems with vvp
> that had to simulate code containing continuous assignments for
> 2-state nets. I patched vvp to allow this, but I am not sure if it
> solves the problem right way.
> 
> * 'reverse_range (commit c7beef9) As 'range' is an official VHDL
> reserved keyword, it was easy to write a bison rule that recognizes
> the attribute. I was not sure how should I deal with
> 'reverse_range', so for the moment I added it to the gperf 
> dictionary. Intuitively I find it wrong, but I had no other idea
> how to solve it.
> 
> If anyone has a better idea for the above issues, I am all ears.
> 
> I am almost done with support for expressions concatenation, so you
> may expect it soon. I would have written this message a bit
> earlier, but I really did not know if the vvp patch is acceptable.
> 
> Regards, Orson
> 
> 1. https://github.com/steveicarus/iverilog/pull/46 2.
> https://github.com/orsonmmz/ivtest/tree/range_test
> 
> ------------------------------------------------------------------------------
>
> 
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS
> Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download
> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with
> EventLog Analyzer http://p.sf.net/sfu/Zoho 
> _______________________________________________ Iverilog-devel
> mailing list Ive...@li... 
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

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

iQEcBAEBAgAGBQJUPPNrAAoJEBRwGu1hpbJ1DUMH/RLswcxk9A05ME8hvJU1WgUD
kmdFKS4UcFq0RRju1IyW8JHnDIySDL2y34UaGcXOGY2w3H0g0MrZsc02/k/IslZE
p6Ahb9BDswFzljZOuAb+bYEnEWhO9BxBbxgwva9iM6wzw7dJ1rXf0rRBpj2PBhem
ADrftPpnIC54m417LzHIicrLo/bT1+g1ua6jFc3p2sxV77nzjA0wEmPdO5CmF8ZU
xMniuvcQL7VOaReHnXmalXlTuXHmVbxoLa5V7bIUD++lu0x7H9dj4OgFXgzzllyY
dJUqIhMdTyF0mKKgnYA1PGDgfk81tjP4PiXJb35SuMRdZrTnyknkUFycSv8twoI=
=tvlG
-----END PGP SIGNATURE-----

[Iverilog-devel] FOSDEM 2015 EDA devroom Call for Participation

[Javier S. <jav...@gm...>]

Dear all,

The Call for Participation in the FOSDEM 2015 EDA devroom is now online:

http://www.ohwr.org/projects/ohr-meta/wiki/FOSDEM2015

Looking forward to meeting many of you there. Cheers,

Javier

[Iverilog-devel] New VHDL attributes

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

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

Hi Steve,

There is a branch [1] that adds support for VHDL attributes: 'range,
'reverse_range, 'left & 'right. There are also tests for the mentioned
features [2].

Before you merge the changes, I would like to attract your attention to
two things that I might have potentially got wrong:

* patch for continuous assignment of 2-state nets (commit 1a4edca)
Previously VHDL 'integer' was translated to 'bool[31:0]', but as we
agreed I have changed that to 'int'. I did so, because the attributes
could not correctly recognize boundaries for arrays of integers ('left
returned 31, 'right returned 0, no matter what was the actual size of
the array).
This caused some problems with vvp that had to simulate code containing
continuous assignments for 2-state nets. I patched vvp to allow
this, but I am not sure if it solves the problem right way.

* 'reverse_range (commit c7beef9)
As 'range' is an official VHDL reserved keyword, it was easy to write
a bison rule that recognizes the attribute. I was not sure how should
I deal with 'reverse_range', so for the moment I added it to the gperf
dictionary. Intuitively I find it wrong, but I had no other idea how
to solve it.

If anyone has a better idea for the above issues, I am all ears.

I am almost done with support for expressions concatenation, so you may
expect it soon. I would have written this message a bit earlier, but I
really did not know if the vvp patch is acceptable.

Regards,
Orson

1. https://github.com/steveicarus/iverilog/pull/46
2. https://github.com/orsonmmz/ivtest/tree/range_test
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUOBFIAAoJEBRwGu1hpbJ1BGUH/0wn1p2F8ppNVIjS8K1sMymV
ljnOBofRZgOfzcX1RKRGKgM/wGE3den7bIrVHiVwblJ9MP+Uv9GyOaNnK5tebsL9
UNNYepKNUiuNS/d8vygp2PgU7cAr0rIeQ1IR5MsaDSyu83IDS/Cv0mlbfur3+r3u
w5LZIG0q1MCJbbvWFcofhgSiZH1FpiB55ZSe30Tcc8Fw8JrpFTeAdQ9OJDlq9aoB
zxiuHbuZxSNmnWFoMRJbdKsuh5J5W7xj8ZN40OqIaWp9wzzJMP58+SwAWge96UPz
aaEraEN18+gzFSgLtd5h15CAoGoPnvLTdty6vAESx9lgxSMEieVC9SOtVQqMUNQ=
=yd/i
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Variables in subprograms

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

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

Hi Cary,

Thank you for the remarks. I see here a lot of interesting points that
will surely help during the experiments and decision making.
I still have to learn much, but I really hoped that more complicated
functionality could be done in C/C++, translated to LLVM IR and then
simply called from the vvp output.
If there are people interested in the topic, then I will keep posting
my findings.

Regards,
Orson

On 10/03/2014 01:47 AM, Cary R. wrote:
> Hi Orson,
> 
> On the surface translation to LLVM IR seems simple, but when you 
> start considering all the extra support needed for the VPI 
> interface, delays, scheduling, etc. it is a much bigger task. It 
> may still be beneficial. To me this turns into an effort like 
> SystemC where there is a large library that needs to be
> implemented that would allow the base LLVM IR to be used for
> implementing the code that looks like a normal programming
> language. Also don't forget that Verilog requires four state
> variables in the context of normal expressions, etc.
> 
> I was actually thinking about this the other day from a CPU 
> architecture point of view. Specifically if we have a standard
> well thought out instruction set then we could possibly use LLVM,
> C++, etc. as the micro architecture to implement the base
> instruction set. Using a standard instruction set may also allow us
> to synthesize to real hardware all or part of the simulator to 
> generate hardware speedup of the simulation. I think of this like 
> the Java processors for the JVM. The VPI interface or more 
> specifically the system tasks and functions that use the VPI 
> interface in their implementation complicate synthesis 
> significantly. The current vvp interface is like this for 
> procedural code, but the rest of the implementation uses different 
> concepts (e.g. gates, continuous assignments, etc.).
> 
> 
> Cary
> 
> 
> 
> On Wednesday, October 1, 2014 8:55 AM, Maciej Sumiński 
> <mac...@ce...> wrote:
> 
> 
> 
> Hi Steve,
> 
> Support for variables in VHDL subprograms is already done [1], 
> together with suitable tests [2].
> 
> Now I would like to take care of 'range and 'reverse_range 
> attributes. I think these should be easily translatable using
> $left & $right system functions. For example:
> 
> --------------------------------------------- library ieee; use 
> ieee.std_logic_1164.all;
> 
> entity range_test is port (inp : in std_logic_vector(8 downto 4); 
> outp : out std_logic_vector(8 downto 4)); end range_test;
> 
> architecture test of range_test is begin process(inp) begin for i 
> in inp'range loop outp(i) <= not inp(i); end loop; end process;
> end test; ---------------------------------------------
> 
> could be converted to:
> 
> --------------------------------------------- module 
> range_test(input wire logic[8:4] inp, output logic[8:4] outp); 
> always @(inp) begin longint i; for (i = $left(inp); i >= 
> $right(inp); i = i - 1) begin outp[i] <= ~(inp[i]); end end 
> endmodule ---------------------------------------------
> 
> There is also one thing that kept me pondering recently. I am not 
> that familiar with vvp principles, but it seems that its 
> assembly-like code format could be translated to the LLVM 
> Intermediate Representation [3]. It is just a general idea, but 
> maybe ivl could output the LLVM IR that could be interpreted by 
> llvm together with some kind of simulator runtime. Has anyone else 
> considered it? Do you already see any obstacles that would made
> the task impossibly hard?
> 
> Regards, Orson
> 
> [1] https://github.com/steveicarus/iverilog/pull/45 [2] 
> https://github.com/orsonmmz/ivtest/tree/subprogram_test [3] 
> https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/
> 
> ------------------------------------------------------------------------------
>
>
> 
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS 
> Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download 
> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with 
> EventLog Analyzer 
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
> 
_______________________________________________
> Iverilog-devel mailing list Ive...@li... 
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
> 
> 
> ------------------------------------------------------------------------------
>
>
> 
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS 
> Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download 
> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with 
> EventLog Analyzer 
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
> 
> 
> 
> _______________________________________________ Iverilog-devel 
> mailing list Ive...@li... 
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

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

iQEcBAEBAgAGBQJULmGDAAoJEBRwGu1hpbJ1c6wIAKUa4j2iKXz8kNRMnEBBhle0
DCn+pdTp4K031D9589BMKgL1v6O9LurxZadpPsL45FFIxrzHWOuilCl9aeUhEPeb
w71tg9PckE9mriQ/nAZfZgsWbO1y9e1NgilaNSzIuqQPX8YTvzFCfZgmtSbVFhwe
3qoB5QoLPHquiwEGiAiwJcQ8rtR9USpi40VlNcpJm4HbFZccJ0DSxbBMS1VTzlRY
Cz2hLMbELVGMxTMWSRiGl9mWDDDDF9MZ9RyjVoWKFKB0tsX1vQqqJ4G1hwc9pcA8
AXg8DuCFMkLByfD2uZ5A/OOwXexVuXm3sdXi4iigaeASJRY0hlB9PkaSKhiYhKQ=
=3Ydy
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Variables in subprograms

[Cary R. <cy...@ya...>]

Hi Orson,

On the surface translation to LLVM IR seems simple, but when you start considering all the extra support needed for the VPI interface, delays, scheduling, etc. it is a much bigger task. It may still be beneficial. To me this turns into an effort like SystemC where there is a large library that needs to be implemented that would allow the base LLVM IR to be used for implementing the code that looks like a normal programming language. Also don't forget that Verilog requires four state variables in the context of normal expressions, etc.

I was actually thinking about this the other day from a CPU architecture point of view. Specifically if we have a standard well thought out instruction set then we could possibly use LLVM, C++, etc. as the micro architecture to implement the base instruction set. Using a standard instruction set may also allow us to synthesize to real hardware all or part of the simulator to generate hardware speedup of the simulation. I think of this like the Java processors for the JVM. The VPI interface or more specifically the system tasks and functions that use the VPI interface in their implementation complicate synthesis significantly. The current vvp interface is like this for procedural code, but the rest of the implementation uses different concepts (e.g. gates, continuous assignments, etc.).


Cary



On Wednesday, October 1, 2014 8:55 AM, Maciej Sumiński <mac...@ce...> wrote:
 


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

Hi Steve,

Support for variables in VHDL subprograms is already done [1], together
with suitable tests [2].

Now I would like to take care of 'range and 'reverse_range attributes.
I think these should be easily translatable using $left & $right
system functions. For example:

- ---------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity range_test is
  port (inp : in std_logic_vector(8 downto 4);
        outp : out std_logic_vector(8 downto 4));
end range_test;

architecture test of range_test is
begin
  process(inp) begin
    for i in inp'range loop
        outp(i) <= not inp(i);
    end loop;
  end process;
end test;
- ---------------------------------------------

could be converted to:

- ---------------------------------------------
module range_test(input wire logic[8:4] inp,
                  output logic[8:4] outp);
always @(inp) begin
  longint i;
  for (i = $left(inp); i >= $right(inp); i = i - 1) begin
    outp[i] <= ~(inp[i]);
  end
end
endmodule
- ---------------------------------------------

There is also one thing that kept me pondering recently. I am not that
familiar with vvp principles, but it seems that its assembly-like code
format could be translated to the LLVM Intermediate Representation [3].
It is just a general idea, but maybe ivl could output the LLVM IR that
could be interpreted by llvm together with some kind of simulator runtime.
Has anyone else considered it? Do you already see any obstacles that
would made the task impossibly hard?

Regards,
Orson

[1] https://github.com/steveicarus/iverilog/pull/45
[2] https://github.com/orsonmmz/ivtest/tree/subprogram_test
[3] https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJULCQKAAoJEBRwGu1hpbJ18FMIAJJvzHTTCSGyMkP1XKkczfhv
4a2PVlvTKtli+D4eDSDZz0Movt8ZukrZeEhlS5y7pzjntRdQgwY4UlGlGtL/Rtif
FOO3vKh7LHV2hv20QLtp31XPnn+dlWhT7em5JE2ZC7AR8oTwgQ2axQfgrJoHMlsa
zQfbDcjNK570r0aQuQ3obVuwC/NCIHZEzi6MNl/bQEeJkUJeT76rdK+t4BznrxdJ
2gNmXvb2grxoiAYA77C7H9iPZFCvC0BWTgiOn21orz/Xy5Mp9IWDVq3vkB0vvVch
XG+vIqYqC3o8u2vZ4wqHAxPncFyW4cnK6Sfgg6W2EeZfZ8ztUse91SDQjnWo6AY=
=vuaA
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] Variables in subprograms

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

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

On 10/01/2014 08:55 AM, Maciej Sumiński wrote:
> Now I would like to take care of 'range and 'reverse_range
> attributes. I think these should be easily translatable using $left
> & $right system functions. For example:

Yes, although you can also use "foreach" loops. For example,
translate "for i in inp'range" to "foreach (inp[i])" to get
a more direct match. The foreach loop support was added to
Icarus Verilog a month or two ago.

- -- 
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)

iEYEARECAAYFAlQsLVMACgkQrPt1Sc2b3ikgVwCg15Jz9GhVmyTffz3k4IEb4tAk
2D8AoLqzOvyj2eJsDKXplmwooOvLzLDc
=XAER
-----END PGP SIGNATURE-----

[Iverilog-devel] Variables in subprograms

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

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

Hi Steve,

Support for variables in VHDL subprograms is already done [1], together
with suitable tests [2].

Now I would like to take care of 'range and 'reverse_range attributes.
I think these should be easily translatable using $left & $right
system functions. For example:

- ---------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity range_test is
  port (inp : in std_logic_vector(8 downto 4);
        outp : out std_logic_vector(8 downto 4));
end range_test;

architecture test of range_test is
begin
  process(inp) begin
    for i in inp'range loop
        outp(i) <= not inp(i);
    end loop;
  end process;
end test;
- ---------------------------------------------

could be converted to:

- ---------------------------------------------
module range_test(input wire logic[8:4] inp,
                  output logic[8:4] outp);
always @(inp) begin
  longint i;
  for (i = $left(inp); i >= $right(inp); i = i - 1) begin
    outp[i] <= ~(inp[i]);
  end
end
endmodule
- ---------------------------------------------

There is also one thing that kept me pondering recently. I am not that
familiar with vvp principles, but it seems that its assembly-like code
format could be translated to the LLVM Intermediate Representation [3].
It is just a general idea, but maybe ivl could output the LLVM IR that
could be interpreted by llvm together with some kind of simulator runtime.
Has anyone else considered it? Do you already see any obstacles that
would made the task impossibly hard?

Regards,
Orson

[1] https://github.com/steveicarus/iverilog/pull/45
[2] https://github.com/orsonmmz/ivtest/tree/subprogram_test
[3] https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJULCQKAAoJEBRwGu1hpbJ18FMIAJJvzHTTCSGyMkP1XKkczfhv
4a2PVlvTKtli+D4eDSDZz0Movt8ZukrZeEhlS5y7pzjntRdQgwY4UlGlGtL/Rtif
FOO3vKh7LHV2hv20QLtp31XPnn+dlWhT7em5JE2ZC7AR8oTwgQ2axQfgrJoHMlsa
zQfbDcjNK570r0aQuQ3obVuwC/NCIHZEzi6MNl/bQEeJkUJeT76rdK+t4BznrxdJ
2gNmXvb2grxoiAYA77C7H9iPZFCvC0BWTgiOn21orz/Xy5Mp9IWDVq3vkB0vvVch
XG+vIqYqC3o8u2vZ4wqHAxPncFyW4cnK6Sfgg6W2EeZfZ8ztUse91SDQjnWo6AY=
=vuaA
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Elaboration of aggregates for records

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

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


I have a little catching up to do with you, I should be able to
take care of this today. Sorry for the delay!

On 09/18/2014 06:16 AM, Maciej Sumiński wrote:
> Hi Steve,
> 
> I have finished the recently mentioned elaboration step for 
> aggregates, so they could be used as initalizers for records [1]. 
> There is also a test for the new feature [2].
> 
> The next thing I would like to undertake is support for
> declarations of variables in subprograms (fix "sorry:
> variable_declaration not supported"). It should e.g. enable usage
> of variables in functions.
> 
> The plan is to bind the bison rule that currently displays the
> error to the rule that handles variables in processes and try to
> reuse the existing code as much as possible. Probably it will need
> some adjustments, but I feel it is almost there.
> 
> Regards, Orson
> 
> [1] https://github.com/steveicarus/iverilog/pull/43 [2]
> https://github.com/orsonmmz/ivtest/tree/record_elab_test
> 

- -- 
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)

iEYEARECAAYFAlQa+DcACgkQrPt1Sc2b3ilRFgCgol5zqKR/9jFG+nl6TUlbSZTq
MOgAnRPiXM3iT24Ze+qS8FqvCQR3BHzW
=sC3o
-----END PGP SIGNATURE-----

[Iverilog-devel] Elaboration of aggregates for records

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

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

Hi Steve,

I have finished the recently mentioned elaboration step for
aggregates, so they could be used as initalizers for records [1].
There is also a test for the new feature [2].

The next thing I would like to undertake is support for declarations
of variables in subprograms (fix "sorry: variable_declaration not
supported"). It should e.g. enable usage of variables in functions.

The plan is to bind the bison rule that currently displays the error
to the rule that handles variables in processes and try to reuse the
existing code as much as possible. Probably it will need some
adjustments, but I feel it is almost there.

Regards,
Orson

[1] https://github.com/steveicarus/iverilog/pull/43
[2] https://github.com/orsonmmz/ivtest/tree/record_elab_test
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUGtsXAAoJEBRwGu1hpbJ12r0H/1jbaDSpYPyKt0kFxP7pC7Bv
Bz0la48y8mL6JSQwAo0p+7pF3O6A9BWG1CK7dQDNwhUKD6PZiGCjZUVhtCQCTtlA
LN0Tia6MEhRhwLrP0HnPfBAtDK9cSB44vf27XdL7+BMRRQxTeK1MBA9j2HBnRz8k
pFMHtR5oTHvm5/3jDek1Y6cg5jev9M2KqB+HrJMdUY4V9U3KF4SJpkiU3WYtER4X
vXv+cXOGi8X9r3PjE+qE6VQWYuPgN4kZ7hqbkaErGMLHXZJy/Gp4SRZ6b0+B39Bw
+IJByUEPkBLIaBSubZ+XVh6KlShhSnxEwC//CIuczH/tcxSl1LenPjzFMCOb778=
=cxC3
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Initalizers for constants in packages

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

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


Looks like a good plan. We should look at getting SystemVerilog to
understand resord literals (the `{...} syntax) but since it doesn't
yet, and you are generating packed structs anyhow, the regular
concatenation will work fine for now.

As for why vhdlpp emits \name instead of just name for vhdl literals?
That is because the available character set for identifiers in vhdl
and Verilog don't exactly match, so I thought it best to use Verilog
escaped names so that you can not worry about mangling VHDL names to
fit into Verilog standards.

On 09/15/2014 08:40 AM, Maciej Sumiński wrote:
> Hi Steve,
> 
> I have managed to solve the problem of elaboration of constants 
> initializers in packages, so there is a new pull request [1]. I
> have prepared tests too, but as we have recently agreed - I will
> merge them to the test suite repository as soon as the iverilog
> changes are merged. Now, I would like to implement elaboration for
> aggregate expressions that serve as record initializers. To
> illustrate:
> 
> --- VHDL version --- library ieee; use ieee.std_logic_1164.all;
> 
> entity foo_entity is end foo_entity;
> 
> architecture test of foo_entity is
> 
> type word is record high: std_logic_vector (3 downto 0); low:
> std_logic_vector (3 downto 0); end record;
> 
> signal my_word: word := (high => "0100", low => "0110");
> 
> begin my_word <= (high => "0100", low => "0110"); end test;
> 
> --- SystemVerilog version --- module foo_entity; typedef struct
> packed {logic[3:0] high; logic[3:0] low;} word; wire word my_word =
> {4'b0100, 4'b0110};                // 1 //assign my_word =
> '{4'b0100, 4'b0110};                // 2 //assign my_word = '{
> high: 4'b0100, low: 4'b0110 };   // 3 assign my_word  = {4'b0100,
> 4'b0110};                  // 4
> 
> endmodule
> 
> The SystemVerilog-2012 standard says that assignment and 
> initialization should be done in the way marked with "// 2". I
> have seen in a few places that it can be assigned like in "// 3",
> but could not find an excerpt in the standard that allows it. 
> Icarus currently accepts and correctly executes initalization & 
> assignment using the method shown in "// 1" and "// 4". Do you
> agree that I implement it that way in vhdlpp? Later it could be
> easily changed - it needs just one apostrophe to be added.
> 
> By the way: I am wondering why e.g. variable names outputted by
> vhdlpp are prefixed with '\'?
> 
> Regards, Orson
> 
> [1] https://github.com/steveicarus/iverilog/pull/42 [2]
> https://github.com/orsonmmz/ivtest/tree/const_package_test
> 

- -- 
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)

iEYEARECAAYFAlQXCesACgkQrPt1Sc2b3ik2KACgzK0bnkFg6IVEHzWA+3mBCwou
6iAAn0m6hwDHFPfEu2jgQzIktejstVmw
=sDL2
-----END PGP SIGNATURE-----

[Iverilog-devel] Initalizers for constants in packages

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

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

Hi Steve,

I have managed to solve the problem of elaboration of constants
initializers in packages, so there is a new pull request [1]. I have
prepared tests too, but as we have recently agreed - I will merge them
to the test suite repository as soon as the iverilog changes are merged.
Now, I would like to implement elaboration for aggregate expressions
that serve as record initializers. To illustrate:

- --- VHDL version ---
library ieee;
use ieee.std_logic_1164.all;

entity foo_entity is
end foo_entity;

architecture test of foo_entity is

type word is record
  high: std_logic_vector (3 downto 0);
  low: std_logic_vector (3 downto 0);
end record;

signal my_word: word := (high => "0100", low => "0110");

begin
  my_word <= (high => "0100", low => "0110");
end test;

- --- SystemVerilog version ---
module foo_entity;
typedef struct packed {logic[3:0] high; logic[3:0] low;} word;
wire word my_word = {4'b0100, 4'b0110};                // 1
//assign my_word = '{4'b0100, 4'b0110};                // 2
//assign my_word = '{ high: 4'b0100, low: 4'b0110 };   // 3
assign my_word  = {4'b0100, 4'b0110};                  // 4

endmodule

The SystemVerilog-2012 standard says that assignment and
initialization should be done in the way marked with "// 2". I have
seen in a few places that it can be assigned like in "// 3", but could
not find an excerpt in the standard that allows it.
Icarus currently accepts and correctly executes initalization &
assignment using the method shown in "// 1" and "// 4". Do you agree
that I implement it that way in vhdlpp? Later it could be easily
changed - it needs just one apostrophe to be added.

By the way: I am wondering why e.g. variable names outputted by vhdlpp
are prefixed with '\'?

Regards,
Orson

[1] https://github.com/steveicarus/iverilog/pull/42
[2] https://github.com/orsonmmz/ivtest/tree/const_package_test
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUFwhjAAoJEBRwGu1hpbJ1ocsH/RuPYVe9kLzAbumPCud8k+aY
Zc4jmIPdD46IfG1XijXoISZIegmT+FWZP/IAsmMCSSfCV+qIAyivQ8nZr/ITL9AV
ccAGAYcmcTVlibBrTImcHaLlHm+wb8vgZOwCgXXLD6bb3etKpgV5GJoSBa1J6WxT
3DLksoSYqtC4lzMv5JpbefW1RUD9ZEpbwEEgWSppHNZBhGX0aMMrHArW6sEn6558
OMvDwOZg50+MLB8YOZqZEQ8FE3K5oFXDwRCUqgCqfr3GTwKxLiel1mCiupTNDRMv
t8OKYTo45oBFgFxmdWVIdEFaO6AYthWXU5qgfEKAGr3kkWDntnfr+G4BGTuTGOA=
=0nzK
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Running ivtest on multiple cores

[Martin W. <mai...@ma...>]

My initial thought on this was that the regression tests are sufficiently 
quick (~1 minute on my PC as well, even with a standard hard disk) that it is 
hardly worth the effort. The regression tests have usually completed by the 
time I have finished composing the commit message!

Having said this, we are continually adding tests and increasing the test 
time, so I certainly wouldn't discourage you from doing this.

One thing I do think would be useful, if we are reworking the test scripts, 
would be to split regress.list into a set of separate files, something like:

   regress-vlg.list          traditional Verilog tests that should
                             work with any Verilog compiler
   regress-sv.list           SystemVerilog tests that should
                             work with any SystemVerilog compiler
   regress-vhdl.list         VHDL tests that should
                             work with any VHDL compiler
   regress-ivl.list          tests using Icarus Verilog extensions
   regress-syn.list          tests using Icarus Verilog synthesis
   regress-0.9.list          exceptions for V0.9
   regress-0.8.list          exceptions for V0.8

and then selecting the appropriate subset of files depending on the compiler 
version. This would eliminate a lot of the V0.8 and V0.9 exceptions (and save 
us adding a lot more).

What do other people think of this idea?

Martin

Maciej Sumiński wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I would like to ask for your opinion about executing the ivtest suite
> on parallel cores. I have modified the vvp_reg.pl script [1], so it
> can use multiple instances of vvp at the same time.
>
> The script uses Parallel::ForkManager (available in CPAN) to run
> iverilog & vvp instances in separate processes to decrease the time
> required to perform tests on modern CPUs.
> I have managed to go down from ~1 minute to ~15 seconds on 8-core i7
> with SSD. The approximate performance boost increases linearly up to 4
> cores, then the difference becomes insignificant.
> You may specify the number of used processes by modifying the CPUS
> environmental variable, e.g. "CPUS=8 ./par_vvp_reg.pl" runs with 8
> processes. Otherwise the number of available cores is autodetected
> (works only in Linux, relies on /proc/cpuinfo).
>
> Unfortunately, there are drawbacks too:
> * I modified fscanf* tests, because they were using the same file and
> therefore stayed in conflict. It does not change results for the
> default vvp_reg.pl script. It is an example of restrictions that test
> writers would have to obey.
> * The output is not fully compatible with the default output stored in
> the repository. I decided to sort the test results in lexical order,
> otherwise the order would be random each run (depends on the time when
> a test ends).
> * There are two tests (pr2509349a & sys_func_task_error) that I could
> not fix. I guess this might be a result of changing the iverilog
> output file name from vsim to $tname.vsim (to avoid conflicts). I did
> not modified them, because I do not want to break the default test
> scripts.
> * Output files are saved in the main directory, they are removed at
> the end of the script. I do not remove ivl_vhdl_work directory between
> tests, because it could be used in another process. More elegant
> solution would be to use separate directories. If you think this is
> completely wrong - please let me know.
> * This is the first time I write code in Perl, therefore I am not sure
> if everything is done in accordance with the art.
>
> With all the mentioned shortcomings, I think that it might be a good
> tool for quick, preliminary checks that could save developer's time.
> What do you think?
>
> Regards,
> Orson
>
> [1] https://github.com/orsonmmz/ivtest/tree/parallel_test
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBAgAGBQJUBXzJAAoJEBRwGu1hpbJ1etMIAJyQSFeF0/p4YWlBQgpWQPml
> NIv2YZeKlCQHYSYfNFDIVkevnfCSNXvv6+4l0BWy4F66yfOJiZ8Y01KOH/sPWg11
> 2NLfnlYxbMNKLpnvERsxp6NVe41ylxjg/QPS9RFqg4NvXEAhbIW4rtd9wT1GRG3y
> 1+tSj4IIrC0PrVS7t0vB18dA/MB1X38aiP8yRav0EzZoRPGQHKT+yhvuoesfjtbO
> fD10GPqjaZnVTK+2TBfh7R00XwwVgIVuxaqall78OuKk5s1Xr5nWD7XZjsGSQGRu
> S/gjOtd77KSTXRNq+1jkOf/DR1DhVsBXLtaSk5tvLn1JJtjS431vMyxXxro7bjo=
> =w7yz
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Re: [Iverilog-devel] Running ivtest on multiple cores

[Cary R. <cy...@ya...>]

Hi Orson,

Conceptually I like the idea of running the tests in parallel, but this implementation seems a bit fragile

When I have though about this it always seemed like each run need its own environment so we did not need to make sure test results/files were unique. This also allows the test files to continue to have a standard name that should avoid the failing tests you mentioned.

As far as the order is concerned, can the test results be cached as needed and then emitted in the correct order as the jobs finish. I realize that output blocks when a long test is running since any results for tests after the long test must be held in the cache until the long test finishes and then the cache can be flushed. Basically as each thread is started it is given a new entry at the end of a buffer to put its result and the emitting routine works off the other end emitting and reclaiming results as they become available.

Something like the following for two threads:

Thread 1 is given the first test and the first buffer location.
Thread 2 is given the second test and the second buffer location.
Thread 2 finishes and puts the result in buffer location two.
Thread 2 is given the third test and the third buffer location.
Thread 2 finishes and puts the result in the third buffer location.
Thread 2 is given the fourth test and the fourth buffer location.
Thread 1 finishes and puts the result in buffer location one
Thread 1 is given the fifth test and the fifth buffer location.
The emitting routine print the results for tests one, two and three and reclaims the space.
etc.

Of course in perl this may get more complicated than this, but I'm guessing a list may work for this though I'm not sure since I have never looked at multi-threaded code in perl.


I used to be very fluent in perl so I can help refine the code as needed.



On Tuesday, September 2, 2014 9:26 AM, Maciej Sumiński <mac...@ce...> wrote:
 


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

Hi,

I would like to ask for your opinion about executing the ivtest suite
on parallel cores. I have modified the vvp_reg.pl script [1], so it
can use multiple instances of vvp at the same time.

The script uses Parallel::ForkManager (available in CPAN) to run
iverilog & vvp instances in separate processes to decrease the time
required to perform tests on modern CPUs.
I have managed to go down from ~1 minute to ~15 seconds on 8-core i7
with SSD. The approximate performance boost increases linearly up to 4
cores, then the difference becomes insignificant.
You may specify the number of used processes by modifying the CPUS
environmental variable, e.g. "CPUS=8 ./par_vvp_reg.pl" runs with 8
processes. Otherwise the number of available cores is autodetected
(works only in Linux, relies on /proc/cpuinfo).

Unfortunately, there are drawbacks too:
* I modified fscanf* tests, because they were using the same file and
therefore stayed in conflict. It does not change results for the
default vvp_reg.pl script. It is an example of restrictions that test
writers would have to obey.
* The output is not fully compatible with the default output stored in
the repository. I decided to sort the test results in lexical order,
otherwise the order would be random each run (depends on the time when
a test ends).
* There are two tests (pr2509349a & sys_func_task_error) that I could
not fix. I guess this might be a result of changing the iverilog
output file name from vsim to $tname.vsim (to avoid conflicts). I did
not modified them, because I do not want to break the default test
scripts.
* Output files are saved in the main directory, they are removed at
the end of the script. I do not remove ivl_vhdl_work directory between
tests, because it could be used in another process. More elegant
solution would be to use separate directories. If you think this is
completely wrong - please let me know.
* This is the first time I write code in Perl, therefore I am not sure
if everything is done in accordance with the art.

With all the mentioned shortcomings, I think that it might be a good
tool for quick, preliminary checks that could save developer's time.
What do you think?

Regards,
Orson

[1] https://github.com/orsonmmz/ivtest/tree/parallel_test
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUBXzJAAoJEBRwGu1hpbJ1etMIAJyQSFeF0/p4YWlBQgpWQPml
NIv2YZeKlCQHYSYfNFDIVkevnfCSNXvv6+4l0BWy4F66yfOJiZ8Y01KOH/sPWg11
2NLfnlYxbMNKLpnvERsxp6NVe41ylxjg/QPS9RFqg4NvXEAhbIW4rtd9wT1GRG3y
1+tSj4IIrC0PrVS7t0vB18dA/MB1X38aiP8yRav0EzZoRPGQHKT+yhvuoesfjtbO
fD10GPqjaZnVTK+2TBfh7R00XwwVgIVuxaqall78OuKk5s1Xr5nWD7XZjsGSQGRu
S/gjOtd77KSTXRNq+1jkOf/DR1DhVsBXLtaSk5tvLn1JJtjS431vMyxXxro7bjo=
=w7yz
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel