iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] vec4-stack merge

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

I would assume that this special object would remove the requirement for the stacks as far as the system tasks/functions were concerned since you cannot know for sure that a value calculated before the call is acceptable or not. You also have to deal with the sensitivity issue, but yes evaluating the function on demand is what I was proposing (i.e. the special object just pops a single value off the stack after executing the anonymous function). This all implies that function call/return overhead will be critical. we are specifically talking about br681, but the same idea could likely be used for br772, br605 and br495. Some of these need the sensitivity list others just need anonymous function support.
What we are discussing here is the high level part of the expression rework. Most of the actual work I have done on this in the past was focused at the lower level implementation so there's no duplication of effort if we implement this using the existing infrastructure. 

I will note that this is complicated by br495 where we need to be able to traverse the expression in some manner to see if it matches during SDF back annotation (i.e. the condition expression is part of the match criteria). Maybe just keeping a string representation is enough for now.

Cary
 

     On Monday, December 8, 2014 3:38 PM, Stephen Williams <st...@ic...> wrote:
   

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

On 12/08/2014 03:23 PM, Cary R. wrote:
> For example: $strobe(a+1); should push an expression (pointer?) a+1
> onto the vec4 stack that when used is evaluated and the calculated
> value is returned.

True, but this never worked for the pre-stacked method either.

Off the cuff, I propose that we make a special object that is
a thread that calculates the value by running the function, and
wrap that expression thread into a VPI expression object. Thus,
there is no stack extension, in fact the existing instruction
set is used to evaluate the function on demand.

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

iEYEARECAAYFAlSGNmUACgkQrPt1Sc2b3inVpACeK9QOnT0TS6AOwxFnxSUeKMDM
EUcAn3s6Kghmt9mMDpb1x4GJgTFO+2z5
=DsWC
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


   

Re: [Iverilog-devel] vec4-stack merge

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

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

On 12/08/2014 03:23 PM, Cary R. wrote:
> For example: $strobe(a+1); should push an expression (pointer?) a+1
> onto the vec4 stack that when used is evaluated and the calculated
> value is returned.

True, but this never worked for the pre-stacked method either.

Off the cuff, I propose that we make a special object that is
a thread that calculates the value by running the function, and
wrap that expression thread into a VPI expression object. Thus,
there is no stack extension, in fact the existing instruction
set is used to evaluate the function on demand.

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

iEYEARECAAYFAlSGNmUACgkQrPt1Sc2b3inVpACeK9QOnT0TS6AOwxFnxSUeKMDM
EUcAn3s6Kghmt9mMDpb1x4GJgTFO+2z5
=DsWC
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] vec4-stack merge

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

I personally don't think I'm missing anything, but please correct me if I'm wrong.
In Verilog we need the ability to pass calculated values of a given type and for some special system tasks we need to instead pass expressions that will be evaluated later (e.g. $strobe, $monitor, etc.). I believe the stacks need to be enhanced to support not only constant values like they do now, but also have the ability to handle expressions that are type correct. Maybe all they really need to support are expressions. For example: $strobe(a+1); should push an expression (pointer?) a+1 onto the vec4 stack that when used is evaluated and the calculated value is returned. As a start we could add this for simple variable references and once that was working we could add a few of the common cases that were lost when converting to the stack system.
Since we cannot know which system tasks need this we probably should just pass expressions (anonymous functions) to every system task. I believe we could assume system function are run in zero time, but for consistency we could also treat them like tasks.
It's also likely more complicated than what's described above since we need to pop the expression off the stack and attach it to system task and then when the argument is processed we need to calculate the value. For $strobe this is not too bad since it is only run once at a specific time, though you may want to cache the calculated value in case the task implementation gets the value multiple times. For $monitor this is significantly more complicated since we need to be sensitive to expression changes and evaluate the expression each time one of them changes. My assumption is that the evaluation code will be the same for both cases, but for monitor we need to have the ability to say I am sensitive to any changes in this expression. The sensitivity code could traverse the expression(s) looking for variables to add to the sensitivity list or the compiler could create a sensitivity list for the anonymous function. I'm not sure how all this fits into the standard VPI interface. From an execution standpoint I see this as an anonymous zero argument function so all you need on the stack is a function pointer.
Okay that's more than enough for now.
Cary


 

     On Monday, December 8, 2014 2:10 PM, Stephen Williams <st...@ic...> wrote:
   

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

On 12/08/2014 01:28 PM, Cary R. wrote:
> I'm slightly concerned how we are going to get complex expression
> to work with the stack based calls. I think we may need to extend
> the stacks we have to also allow them to support expressions that
> return the given type (e.g. push 4'b1000 or push an expression that
> returns a 4 bit value to the vec4 stack). The expression would need
> to be evaluated when it was popped to generate the value that is
> actually returned by the pop.

I think you are missing that the stack based system is a well-
traveled path, blazed by things like Forth, and HP calculators.
Arbitrarily complex expressions are possible, unless I'm missing
something in your point.

> I need to look at the stack stuff in more detail before I make any
> other comments, but it seems like there could also be issues with
> deferred tasks that do not have a specific order of evaluation
> (e.g. multiple $strobe and/or $monitor calls in the same module
> (stack scope).

The issues that plague the vec4-stack version would be the same
that get in the way with the pre-stack version. In particular,
if $strobe were to try to access a value in the vec4 stack, the
problem is more obvious, but the same problem would come up in
the pre-stack implementation. You might be lucky enough to get
away with it in the pre-stack version, instead of making an obvious
mess post-stack.


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

iEYEARECAAYFAlSGIaEACgkQrPt1Sc2b3inkhQCgwz/oY7l7WI7PKxnp9lij1fzg
9zYAnRiv2bhbiXZ4/msxYfIhvJRjzvcZ
=wK6I
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


   

Re: [Iverilog-devel] vec4-stack merge

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

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

On 12/08/2014 01:28 PM, Cary R. wrote:
> I'm slightly concerned how we are going to get complex expression
> to work with the stack based calls. I think we may need to extend
> the stacks we have to also allow them to support expressions that
> return the given type (e.g. push 4'b1000 or push an expression that
> returns a 4 bit value to the vec4 stack). The expression would need
> to be evaluated when it was popped to generate the value that is
> actually returned by the pop.

I think you are missing that the stack based system is a well-
traveled path, blazed by things like Forth, and HP calculators.
Arbitrarily complex expressions are possible, unless I'm missing
something in your point.

> I need to look at the stack stuff in more detail before I make any
> other comments, but it seems like there could also be issues with
> deferred tasks that do not have a specific order of evaluation
> (e.g. multiple $strobe and/or $monitor calls in the same module
> (stack scope).

The issues that plague the vec4-stack version would be the same
that get in the way with the pre-stack version. In particular,
if $strobe were to try to access a value in the vec4 stack, the
problem is more obvious, but the same problem would come up in
the pre-stack implementation. You might be lucky enough to get
away with it in the pre-stack version, instead of making an obvious
mess post-stack.


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

iEYEARECAAYFAlSGIaEACgkQrPt1Sc2b3inkhQCgwz/oY7l7WI7PKxnp9lij1fzg
9zYAnRiv2bhbiXZ4/msxYfIhvJRjzvcZ
=wK6I
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] vec4-stack merge

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

I updated the expected results for two of the vlog95 tests since they now more closely match the normal output. The other test needed to be run with signed support since it was generating a signed undefined value and when displayed that value requires one more space than an unsigned undefined value (for the sign +/-). The current default translation is to generate unsigned undefined values, but these print with a field width that is one less than a signed undefined value when they are used directly in a print statement. They should work fine in an expression.

I'm slightly concerned how we are going to get complex expression to work with the stack based calls. I think we may need to extend the stacks we have to also allow them to support expressions that return the given type (e.g. push 4'b1000 or push an expression that returns a 4 bit value to the vec4 stack). The expression would need to be evaluated when it was popped to generate the value that is actually returned by the pop.
I need to look at the stack stuff in more detail before I make any other comments, but it seems like there could also be issues with deferred tasks that do not have a specific order of evaluation (e.g. multiple $strobe and/or $monitor calls in the same module (stack scope).

Cary
 

     On Sunday, December 7, 2014 7:18 PM, Stephen Williams <st...@ic...> wrote:
   

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

On 12/07/2014 02:57 PM, Stephan Böttcher wrote:
> * Both vvp executables identify with the same version string?

You need to "make version" to regenerate the version string.

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

iEYEARECAAYFAlSFGGUACgkQrPt1Sc2b3ik+8gCfRZ9d7KuJ/b0mhULgLPKnXdzk
SD8An1qRcQjEXzXUOxn0So1TfaIkb0CM
=x5fo
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


   

Re: [Iverilog-devel] vec4-stack merge

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

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

On 12/07/2014 02:57 PM, Stephan Böttcher wrote:
> * Both vvp executables identify with the same version string?

You need to "make version" to regenerate the version string.

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

iEYEARECAAYFAlSFGGUACgkQrPt1Sc2b3ik+8gCfRZ9d7KuJ/b0mhULgLPKnXdzk
SD8An1qRcQjEXzXUOxn0So1TfaIkb0CM
=x5fo
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] vec4-stack merge

[<boe...@ph...>]

This diff shows the output of the simulation of my current project.
The -gold file was made with iverilog from end of August this year.
The +log file is the output of the current master from:

$ git branch -v
* master 0d7daf5 Fix vvp memory leak for user function calls in a continuous assignment.
$ git remote -v
origin  git://github.com/steveicarus/iverilog.git (fetch)
origin  git://github.com/steveicarus/iverilog.git (push)

The the simulation includes two FPGA designs (target: RTAX2000SL
radiation hard).  The clocks are 24MHz and 48MHz, the simulation covers
82ms.

 * Both vvp executables identify with the same version string?

 * 24000 lines of simulation output are the same :-)

 * The vec4-stack vvp runs 15% faster.

(I guess this is not compelling enough to switch to the new version
right now, before I burn the code into the first flight grade prototype
chips later this month, with 5-digit dollar prices per chip,
programmable once by burning antifuses.)

Stephan

--- heteptdig.gold      2014-12-07 20:08:15.763398768 +0100
+++ heteptdig.log       2014-12-07 23:30:37.984840530 +0100
@@ -1,21 +1,21 @@
 Compiling VVP ...
  ... VVP file version 0.10.0 (devel) (s20090923-819-g6a40d9e)
 Compile cleanup...
- ...    17094 functors (net_fun pool=786432 bytes)
-               3517 logic
+ ...    17115 functors (net_fun pool=786432 bytes)
+               3521 logic
                   0 bufif
                   0 resolv
                3005 signals
- ...    14464 filters (net_fil pool=1048576 bytes)
- ...    70623 opcodes (1146880 bytes)
+ ...    14485 filters (net_fil pool=1048576 bytes)
+ ...    64797 opcodes (1048576 bytes)
  ...    17418 nets
- ...    17094 vvp_nets (1048572 bytes)
+ ...    17115 vvp_nets (1048572 bytes)
  ...       24 arrays (268 words)
  ...       83 memories
                  83 logic (1190082 words)
                   0 real (0 words)
  ...     1240 scopes
- ... 0.546 seconds, 29308.0/23692.0/3820.0 KBytes size/rss/shared
+ ... 0.498 seconds, 30672.0/24892.0/3664.0 KBytes size/rss/shared
 Running ...
  ...execute EndOfCompile callbacks
  ...propagate initialization events
@@ -24744,14 +24744,14 @@
 PHA save @200: 0000b5ff
 $time             82000000 ns
  ...execute Postsim callbacks
- ... 13283.7 seconds, 46268.0/35532.0/3704.0 KBytes size/rss/shared
+ ... 11182 seconds, 47544.0/36744.0/3768.0 KBytes size/rss/shared
 Event counts:
     13952426 time steps (pool=227)
     233047263 thread schedule events
-    4292502096 assign events
+    4292533705 assign events
              ...assign(vec4) pool=16384
              ...assign(vec8) pool=409
              ...assign(real) pool=409
              ...assign(word) pool=256
              ...assign(word/r) pool=341
-    1923107023 other events (pool=8192)
+    1923202382 other events (pool=8192)


-- 
Stephan Böttcher                      Tel: +49-431-880-2508
Christian-Albrechts-Universität zu Kiel
Inst. f. Exp. u. Angew. Physik,  Abt. Extraterrestrische Physik
Leibnizstr. 11, 24118 Kiel, Germany

Re: [Iverilog-devel] pass -v to vvp in the #! header line

[<boe...@ph...>]

Cary,

"Cary R." <cy...@ya...> writes:

> This looks reasonable, but it doesn't work for all use cases (e.g. vvp
> <output_file>). We could modify vvp to look at the #! line to make
> sure the flag is found. 

I don't think you want that flag to be found in all cases.  This is only
for the case when you run the <outputfile> directly, and get the same
verbosity as iverilog used.   

If you run the simulation as vvp <output_file>, you can add the -v flag
at that occasion

  vvp -v <output_file>

If you run the outputfile as

  ./<output_file> -v

it does not work, since it translates to

  /usr/local/bin/vvp <output_file> -v

and in that position, the -v flag is ignored.

man vvp(1):

> EXTENDED ARGUMENTS
>        The  vvp options described above must come before the design file name.
>        After the design file name, however, there may be any number of unspec‐
>        ified  arguments.  These  arguments  are not interpreted by vvp but are
>        instead passed on to the executed design, and  are  available  via  the
>        $test$plusargs and $value$plusargs system functions.

I had the following Makefile rules:

> VERILOG=/usr/local/bin/iverilog
> VERILOGFLAGS = -v -Wall -Wno-timescale -DSIMULATION $($*_FLAGS)
> %.vvp:
>         $(VERILOG) $(VERILOGFLAGS) -o $@ $(filter %.v, $^)
> vcd/%.lxt: %.vvp
>         $< -lxt2 | tee $*.log

To run vvp -v, I had to do

> VERILOG=/usr/local/bin/iverilog
> VVP=$(subst iverilog,vvp,$(VERILOG)) -v
> VERILOGFLAGS = -v -Wall -Wno-timescale -DSIMULATION $($*_FLAGS)
> %.vvp: %.v
>         $(VERILOG) $(VERILOGFLAGS) -o $@ $(filter %.v,$^)
> vcd/%.lxt: %.vvp
>         $(VVP) -v $< -lxt2 | tee $*.log

With the patch, the nice old rules default to pass -v to vvp.

This came up, because I want to run

     make VERILOG=/usr/local/test/bin/iverilog vcd/<FILE>.lxt

and make sure the Makefile picks the correct vvp executable, and compare
the execution times reported by -v.

Stephan

> This is probably better than adding a different construct to the
> output file to pass the information and this patch works for one use
> case until vvp is modified so I don;t have an objection to it being
> added.
>
> FYI I run this as vvp <output_file> not as <output_file> or the
> slightly safer ./<output_file> since the later two make an assumption
> that <output_file> is a vvp simulation file which may not always be
> 100% true and in an extreme case could be used for nefarious reasons.
> I'm not a complete security nut so I do have . in my path, but it is
> last so <output_file> would find any other system executable instead
> of the vvp file I just generated if there was a name collision.
>
> Cary
>
> On Sunday, December 7, 2014 12:42 PM, "boe...@ph..."
> <boe...@ph...> wrote:
>
> Resent with subscribed From address ... 
>
> Steven, Cary, Martin, ...
>
> please consider this patch to pass the -v flag from iverilog to vvp.
>
> Cheers, Stephan
>
> diff --git a/main.cc b/main.cc
> index 21d7232..b98c4d8 100644
> --- a/main.cc
> +++ b/main.cc
> @@ -859,6 +859,7 @@ int main(int argc, char*argv[])
> # if defined(HAVE_TIMES)
> times_flag = true;
> # endif
> + flags["VVP_EXTRA_ARG"] = strdup(" -v");
> break;
> case 'V':
> version_flag = true;
> diff --git a/tgt-vvp/vvp.c b/tgt-vvp/vvp.c
> index 55920f3..7cc180a 100644
> --- a/tgt-vvp/vvp.c
> +++ b/tgt-vvp/vvp.c
> @@ -59,7 +59,10 @@ __inline__ static void draw_execute_header
> (ivl_design_t des)
> {
> const char*cp = ivl_design_flag(des, "VVP_EXECUTABLE");
> if (cp) {
> - fprintf(vvp_out, "#! %s\n", cp);
> + const char *verbose_flag = ivl_design_flag(des, "VVP_EXTRA_ARG");
> + if (!verbose_flag)
> + verbose_flag = "";
> + fprintf(vvp_out, "#! %s%s\n", cp, verbose_flag);
> #if !defined(__MINGW32__)
> fchmod(fileno(vvp_out), 0755);
> #endif

-- 
Dr. Stephan Böttcher                      Tel: +49-431-880-2508
Christian-Albrechts-Universität zu Kiel
Inst. f. Exp. u. Angew. Physik,  Abt. Extraterrestrische Physik
Leibnizstr. 11, 24118 Kiel, Germany

Re: [Iverilog-devel] vec4-stack merge

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

OK, I've updated the expected results for pr1830834 to expect the sorry message.

I've also fixed the v0.9 regression tests and partially fixed the vlog95 
regression tests. The remaining failures for vlog95 are due to white space 
changes in displayed values - I'll leave these for Cary to review and decide 
whether he cares about them.

Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Awesome! Thanks for the patches.
>
> As for pr1830834, the problem is that before the vec4-stack merge,
> there was a vpi special symbol for referencing part selects, so this
> was able to work. Sorta. But even at that, it kinda violated the
> conceit of the vvp runtime model. I don't really know what do do
> about this now, so until we have a good solution, this should print
> a "sorry" message.
>
> On 12/07/2014 07:08 AM, Martin Whitaker wrote:
>> I've fixed all but one of the new failures, and have also fixed the
>> memory leak for user function calls in a continuous assignment
>> statement.
>>
>> The remaining new failure is pr1830834. A simplified example of the
>> problem is
>>
>> reg [3:0] i;
>>
>> reg [15:0] value = 16'h5555;
>>
>> initial begin i = 0; $strobe("Value is %b", value[i+1]); i = 1;
>> end
>>
>> With the vec4-stack merge, this results in the following run-time
>> error:
>>
>> SORRY: test.v:9: currently only simple signals or constant
>> expressions may be passed to $strobe.
>>
>> Before the merge, the output is
>>
>> Value is 0
>>
>> The correct result should be
>>
>> Value is 1
>>
>> The pr1830834 test only worked because it didn't change the index
>> variable after $strobe was called.
>>
>> I propose we change the regression tests to expect a run-time error
>> for this test. Any dissenters?
>
>
> - --
> 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
>
> iEYEARECAAYFAlSEga8ACgkQrPt1Sc2b3ikMJgCfX0hEUMg66ouRwA5EslCrmsP1
> cgEAoKL/uOu353BD6kR12zNgS5dk9tNS
> =EbA8
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Re: [Iverilog-devel] pass -v to vvp in the #! header line

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

This looks reasonable, but it doesn't work for all use cases (e.g. vvp <output_file>). We could modify vvp to look at the #! line to make sure the flag is found. This is probably better than adding a different construct to the output file to pass the information and this patch works for one use case until vvp is modified so I don;t have an objection to it being added.

FYI I run this as vvp <output_file> not as <output_file> or the slightly safer ./<output_file> since the later two make an assumption that <output_file> is a vvp simulation file which may not always be 100% true and in an extreme case could be used for nefarious reasons. I'm not a complete security nut so I do have . in my path, but it is last so <output_file> would find any other system executable instead of the vvp file I just generated if there was a name collision.

Cary
 

     On Sunday, December 7, 2014 12:42 PM, "boe...@ph..." <boe...@ph...> wrote:
   

 
Resent with subscribed From address ... 


Steven, Cary, Martin, ...

please consider this patch to pass the -v flag from iverilog to vvp.

Cheers, Stephan


diff --git a/main.cc b/main.cc
index 21d7232..b98c4d8 100644
--- a/main.cc
+++ b/main.cc
@@ -859,6 +859,7 @@ int main(int argc, char*argv[])
 #          if defined(HAVE_TIMES)
            times_flag = true;
 #          endif
+          flags["VVP_EXTRA_ARG"] = strdup(" -v");
            break;
          case 'V':
            version_flag = true;
diff --git a/tgt-vvp/vvp.c b/tgt-vvp/vvp.c
index 55920f3..7cc180a 100644
--- a/tgt-vvp/vvp.c
+++ b/tgt-vvp/vvp.c
@@ -59,7 +59,10 @@ __inline__ static void draw_execute_header(ivl_design_t des)
 {
      const char*cp = ivl_design_flag(des, "VVP_EXECUTABLE");
      if (cp) {
-          fprintf(vvp_out, "#! %s\n", cp);
+          const char *verbose_flag = ivl_design_flag(des, "VVP_EXTRA_ARG");
+          if (!verbose_flag)
+                  verbose_flag = "";
+          fprintf(vvp_out, "#! %s%s\n", cp, verbose_flag);
 #if !defined(__MINGW32__)
            fchmod(fileno(vvp_out), 0755);
 #endif


-- 
Stephan Böttcher                      Tel: +49-431-880-2508
Christian-Albrechts-Universität zu Kiel
Inst. f. Exp. u. Angew. Physik,  Abt. Extraterrestrische Physik
Leibnizstr. 11, 24118 Kiel, Germany

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


   

[Iverilog-devel] pass -v to vvp in the #! header line

[<boe...@ph...>]

Resent with subscribed From address ... 

Re: [Iverilog-devel] vec4-stack merge

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

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


Awesome! Thanks for the patches.

As for pr1830834, the problem is that before the vec4-stack merge,
there was a vpi special symbol for referencing part selects, so this
was able to work. Sorta. But even at that, it kinda violated the
conceit of the vvp runtime model. I don't really know what do do
about this now, so until we have a good solution, this should print
a "sorry" message.

On 12/07/2014 07:08 AM, Martin Whitaker wrote:
> I've fixed all but one of the new failures, and have also fixed the
> memory leak for user function calls in a continuous assignment
> statement.
> 
> The remaining new failure is pr1830834. A simplified example of the
> problem is
> 
> reg [3:0] i;
> 
> reg [15:0] value = 16'h5555;
> 
> initial begin i = 0; $strobe("Value is %b", value[i+1]); i = 1; 
> end
> 
> With the vec4-stack merge, this results in the following run-time
> error:
> 
> SORRY: test.v:9: currently only simple signals or constant
> expressions may be passed to $strobe.
> 
> Before the merge, the output is
> 
> Value is 0
> 
> The correct result should be
> 
> Value is 1
> 
> The pr1830834 test only worked because it didn't change the index
> variable after $strobe was called.
> 
> I propose we change the regression tests to expect a run-time error
> for this test. Any dissenters?


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

iEYEARECAAYFAlSEga8ACgkQrPt1Sc2b3ikMJgCfX0hEUMg66ouRwA5EslCrmsP1
cgEAoKL/uOu353BD6kR12zNgS5dk9tNS
=EbA8
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] vec4-stack merge

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

I've fixed all but one of the new failures, and have also fixed the memory 
leak for user function calls in a continuous assignment statement.

The remaining new failure is pr1830834. A simplified example of the problem is

   reg [3:0] i;

   reg [15:0] value = 16'h5555;

   initial begin
     i = 0;
     $strobe("Value is %b", value[i+1]);
     i = 1;
   end

With the vec4-stack merge, this results in the following run-time error:

SORRY: test.v:9: currently only simple signals or constant expressions may be 
passed to $strobe.

Before the merge, the output is

   Value is 0

The correct result should be

   Value is 1

The pr1830834 test only worked because it didn't change the index variable 
after $strobe was called.

I propose we change the regression tests to expect a run-time error for this 
test. Any dissenters?


Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> There are indeed a couple new failures, that were I think brought
> on be collisions between the new work and the original fix for
> them. This was bound to happen given that the branch was starting
> to diverge, and could have gotten even worse if I kept on. I tried
> merging master into the vec4-stack as I was going, but that is
> probably where I went wrong.

Re: [Iverilog-devel] vec4-stack merge

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

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


There are indeed a couple new failures, that were I think brought
on be collisions between the new work and the original fix for
them. This was bound to happen given that the branch was starting
to diverge, and could have gotten even worse if I kept on. I tried
merging master into the vec4-stack as I was going, but that is
probably where I went wrong.

On 12/06/2014 02:37 PM, Martin Whitaker wrote:
> I'm running in a 64-bit environment. It looks like merge problems -
> for example the pr3366217b/c/g failures seem to be because some of
> your enumeration fixes have been lost. I can sort this out if
> necessary, but will wait to hear from Steve.
> 
> Cary R. wrote:
>> Martin, I haven't synced to the new code, and probably won't for
>> a couple days, but is this a 32-bit vs 64-bit issue? Most people
>> seem to be running and testing under 64-bit, though I still have
>> one setup that is 32-bit to check for this specific problem and I
>> have fixed a few bugs related to that lately. Cary
>> 
>> On Saturday, December 6, 2014 11:56 AM, Martin Whitaker
>> <mai...@ma...> wrote:
>> 
>> 
>> I'm seeing 6 new failures when I run the regression tests:
>> 
>> % grep Failed regression_report.txt pr1830834: ==> Failed -
>> output does not match gold file. analog1: ==> Failed - running
>> iverilog. analog2: ==> Failed - running iverilog. fileline2: ==>
>> Failed - output does not match gold file. pr3366217b: ==> Failed
>> - CE - output does not match gold file. pr3366217c: ==> Failed -
>> CE (no error reported). pr3366217g: ==> Failed - CE - output does
>> not match gold file. br_gh13a: ==> Failed - output does not match
>> gold file. br605a: ==> Failed - output does not match gold file. 
>> br605b: ==> Failed - output does not match gold file. 
>> if_part_no_else2: ==> Failed - running iverilog. Total=2087,
>> Passed=2076, Failed=11, Not Implemented=0, Expected Fail=0
>> 
>> Are these known issues?
>> 
>> Stephen Williams wrote:
> 
> I've gone and done it, I've merged the vec4-stack branch into the
> master branch. This is a BIG set of changes that I've been working
> on for many months now, with the idea of cleaning up the vvp
> runtime and opening up some performance optimization 
> opportunities.
> 
> For those who care, what I've done is rework the vvp instruction 
> set for handling logic vectors. Up until now, the vvp engine kept a
> long vector of "register" space, and operations like add, subtract,
> etc. picked their operands out of that register space. After this
> merge, the register space has been converted into a stack of
> vectors. The instructions just pull operands of the stack, so fewer
> operands are needed, and there is no more picking operands out of a
> larger vector.
> 
> I have taken advantage of some of the benefits, some tests should 
> now run significantly faster. If you find any things that run 
> slower with the new system, I'd like to know about them.
> 
> The outputs in some cases are different. The Verilog standard has
> some ambiguous corners and with this merge Icarus Verilog may
> generate for you some different but still legal results, mostly
> related to vector widths. I have updated the regression test suite
> to account for most of these, but you may see some subtle
> differences in your run time results. Should still be legal, 
> though, so you should be fine.
> 
> 
>>> 
>>> ------------------------------------------------------------------------------
>>>
>>> 
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and
>>> Dashboards with Interactivity, Sharing, Native Excel Exports,
>>> App Integration & more Get technology previously reserved for
>>> billion-dollar corporations, FREE 
>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>
>>> 
_______________________________________________
>>> Iverilog-devel mailing list 
>>> Ive...@li... 
>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>>
>> 
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and
>> Dashboards with Interactivity, Sharing, Native Excel Exports, App
>> Integration & more Get technology previously reserved for
>> billion-dollar corporations, FREE 
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>
>> 
_______________________________________________
>> Iverilog-devel mailing list Ive...@li... 
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>> 
>> 
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>>
>> 
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and
>> Dashboards with Interactivity, Sharing, Native Excel Exports, App
>> Integration & more Get technology previously reserved for
>> billion-dollar corporations, FREE 
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>
>>
>>
>>
>> 
_______________________________________________
>> Iverilog-devel mailing list Ive...@li... 
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and
> Dashboards with Interactivity, Sharing, Native Excel Exports, App
> Integration & more Get technology previously reserved for
> billion-dollar corporations, FREE 
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>
> 
_______________________________________________
> Iverilog-devel mailing list Ive...@li... 
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

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

iEYEARECAAYFAlSDk64ACgkQrPt1Sc2b3inhygCfZcerQPpOq/W5pPQht/bqRos2
y64An1OnezuMOKOJJB0tS8NTp4BtU3/x
=Vd0M
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] vec4-stack merge

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

I'm running in a 64-bit environment. It looks like merge problems - for 
example the pr3366217b/c/g failures seem to be because some of your 
enumeration fixes have been lost. I can sort this out if necessary, but will 
wait to hear from Steve.

Cary R. wrote:
> Martin,
> I haven't synced to the new code, and probably won't for a couple days, but is this a 32-bit vs 64-bit issue? Most people seem to be running and testing under 64-bit, though I still have one setup that is 32-bit to check for this specific problem and I have fixed a few bugs related to that lately.
> Cary
>
>       On Saturday, December 6, 2014 11:56 AM, Martin Whitaker <mai...@ma...> wrote:
>
>
>   I'm seeing 6 new failures when I run the regression tests:
>
> % grep Failed regression_report.txt
>                    pr1830834: ==> Failed - output does not match gold file.
>                      analog1: ==> Failed - running iverilog.
>                      analog2: ==> Failed - running iverilog.
>                    fileline2: ==> Failed - output does not match gold file.
>                    pr3366217b: ==> Failed - CE - output does not match gold file.
>                    pr3366217c: ==> Failed - CE (no error reported).
>                    pr3366217g: ==> Failed - CE - output does not match gold file.
>                      br_gh13a: ==> Failed - output does not match gold file.
>                        br605a: ==> Failed - output does not match gold file.
>                        br605b: ==> Failed - output does not match gold file.
>              if_part_no_else2: ==> Failed - running iverilog.
>    Total=2087, Passed=2076, Failed=11, Not Implemented=0, Expected Fail=0
>
> Are these known issues?
>
> Stephen Williams wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> I've gone and done it, I've merged the vec4-stack branch into
>> the master branch. This is a BIG set of changes that I've been
>> working on for many months now, with the idea of cleaning up
>> the vvp runtime and opening up some performance optimization
>> opportunities.
>>
>> For those who care, what I've done is rework the vvp instruction
>> set for handling logic vectors. Up until now, the vvp engine
>> kept a long vector of "register" space, and operations like add,
>> subtract, etc. picked their operands out of that register space.
>> After this merge, the register space has been converted into a
>> stack of vectors. The instructions just pull operands of the
>> stack, so fewer operands are needed, and there is no more picking
>> operands out of a larger vector.
>>
>> I have taken advantage of some of the benefits, some tests should
>> now run significantly faster. If you find any things that run
>> slower with the new system, I'd like to know about them.
>>
>> The outputs in some cases are different. The Verilog standard
>> has some ambiguous corners and with this merge Icarus Verilog
>> may generate for you some different but still legal results,
>> mostly related to vector widths. I have updated the regression
>> test suite to account for most of these, but you may see some
>> subtle differences in your run time results. Should still be legal,
>> though, so you should be fine.
>>
>>
>> - --
>> 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
>>
>> iEYEARECAAYFAlSDOgUACgkQrPt1Sc2b3ikesgCg20PgbNMyXz8H3uwOuo9TAH8y
>> svMAoKC5oAfKNSu8o6TSENhBKecSYjqo
>> =0Ndq
>> -----END PGP SIGNATURE-----
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Re: [Iverilog-devel] vec4-stack merge

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

Martin,
I haven't synced to the new code, and probably won't for a couple days, but is this a 32-bit vs 64-bit issue? Most people seem to be running and testing under 64-bit, though I still have one setup that is 32-bit to check for this specific problem and I have fixed a few bugs related to that lately.
Cary 

     On Saturday, December 6, 2014 11:56 AM, Martin Whitaker <mai...@ma...> wrote:
   

 I'm seeing 6 new failures when I run the regression tests:

% grep Failed regression_report.txt
                  pr1830834: ==> Failed - output does not match gold file.
                    analog1: ==> Failed - running iverilog.
                    analog2: ==> Failed - running iverilog.
                  fileline2: ==> Failed - output does not match gold file.
                  pr3366217b: ==> Failed - CE - output does not match gold file.
                  pr3366217c: ==> Failed - CE (no error reported).
                  pr3366217g: ==> Failed - CE - output does not match gold file.
                    br_gh13a: ==> Failed - output does not match gold file.
                      br605a: ==> Failed - output does not match gold file.
                      br605b: ==> Failed - output does not match gold file.
            if_part_no_else2: ==> Failed - running iverilog.
  Total=2087, Passed=2076, Failed=11, Not Implemented=0, Expected Fail=0

Are these known issues?

Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> I've gone and done it, I've merged the vec4-stack branch into
> the master branch. This is a BIG set of changes that I've been
> working on for many months now, with the idea of cleaning up
> the vvp runtime and opening up some performance optimization
> opportunities.
>
> For those who care, what I've done is rework the vvp instruction
> set for handling logic vectors. Up until now, the vvp engine
> kept a long vector of "register" space, and operations like add,
> subtract, etc. picked their operands out of that register space.
> After this merge, the register space has been converted into a
> stack of vectors. The instructions just pull operands of the
> stack, so fewer operands are needed, and there is no more picking
> operands out of a larger vector.
>
> I have taken advantage of some of the benefits, some tests should
> now run significantly faster. If you find any things that run
> slower with the new system, I'd like to know about them.
>
> The outputs in some cases are different. The Verilog standard
> has some ambiguous corners and with this merge Icarus Verilog
> may generate for you some different but still legal results,
> mostly related to vector widths. I have updated the regression
> test suite to account for most of these, but you may see some
> subtle differences in your run time results. Should still be legal,
> though, so you should be fine.
>
>
> - --
> 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
>
> iEYEARECAAYFAlSDOgUACgkQrPt1Sc2b3ikesgCg20PgbNMyXz8H3uwOuo9TAH8y
> svMAoKC5oAfKNSu8o6TSENhBKecSYjqo
> =0Ndq
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


   

Re: [Iverilog-devel] vec4-stack merge

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

I'm seeing 6 new failures when I run the regression tests:

% grep Failed regression_report.txt
                   pr1830834: ==> Failed - output does not match gold file.
                     analog1: ==> Failed - running iverilog.
                     analog2: ==> Failed - running iverilog.
                   fileline2: ==> Failed - output does not match gold file.
                  pr3366217b: ==> Failed - CE - output does not match gold file.
                  pr3366217c: ==> Failed - CE (no error reported).
                  pr3366217g: ==> Failed - CE - output does not match gold file.
                    br_gh13a: ==> Failed - output does not match gold file.
                      br605a: ==> Failed - output does not match gold file.
                      br605b: ==> Failed - output does not match gold file.
            if_part_no_else2: ==> Failed - running iverilog.
   Total=2087, Passed=2076, Failed=11, Not Implemented=0, Expected Fail=0

Are these known issues?

Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> I've gone and done it, I've merged the vec4-stack branch into
> the master branch. This is a BIG set of changes that I've been
> working on for many months now, with the idea of cleaning up
> the vvp runtime and opening up some performance optimization
> opportunities.
>
> For those who care, what I've done is rework the vvp instruction
> set for handling logic vectors. Up until now, the vvp engine
> kept a long vector of "register" space, and operations like add,
> subtract, etc. picked their operands out of that register space.
> After this merge, the register space has been converted into a
> stack of vectors. The instructions just pull operands of the
> stack, so fewer operands are needed, and there is no more picking
> operands out of a larger vector.
>
> I have taken advantage of some of the benefits, some tests should
> now run significantly faster. If you find any things that run
> slower with the new system, I'd like to know about them.
>
> The outputs in some cases are different. The Verilog standard
> has some ambiguous corners and with this merge Icarus Verilog
> may generate for you some different but still legal results,
> mostly related to vector widths. I have updated the regression
> test suite to account for most of these, but you may see some
> subtle differences in your run time results. Should still be legal,
> though, so you should be fine.
>
>
> - --
> 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
>
> iEYEARECAAYFAlSDOgUACgkQrPt1Sc2b3ikesgCg20PgbNMyXz8H3uwOuo9TAH8y
> svMAoKC5oAfKNSu8o6TSENhBKecSYjqo
> =0Ndq
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

[Iverilog-devel] vec4-stack merge

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

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


I've gone and done it, I've merged the vec4-stack branch into
the master branch. This is a BIG set of changes that I've been
working on for many months now, with the idea of cleaning up
the vvp runtime and opening up some performance optimization
opportunities.

For those who care, what I've done is rework the vvp instruction
set for handling logic vectors. Up until now, the vvp engine
kept a long vector of "register" space, and operations like add,
subtract, etc. picked their operands out of that register space.
After this merge, the register space has been converted into a
stack of vectors. The instructions just pull operands of the
stack, so fewer operands are needed, and there is no more picking
operands out of a larger vector.

I have taken advantage of some of the benefits, some tests should
now run significantly faster. If you find any things that run
slower with the new system, I'd like to know about them.

The outputs in some cases are different. The Verilog standard
has some ambiguous corners and with this merge Icarus Verilog
may generate for you some different but still legal results,
mostly related to vector widths. I have updated the regression
test suite to account for most of these, but you may see some
subtle differences in your run time results. Should still be legal,
though, so you should be fine.


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

iEYEARECAAYFAlSDOgUACgkQrPt1Sc2b3ikesgCg20PgbNMyXz8H3uwOuo9TAH8y
svMAoKC5oAfKNSu8o6TSENhBKecSYjqo
=0Ndq
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] More vec4-stack progress

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

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


OK, that's very useful feedback. Given that, and assuming no other
complaints, I will merge the vec4-stack branch into git master tomorrow,
Saturday, 6 Dec. in the morning.

In the mean time, I've made a 20141205 snapshot available in the
usual FTP download site. That is the last snapshot before the big
merge.


On 12/05/2014 01:12 PM, Martin Whitaker wrote:
> I've tracked down the construct that is causing the problem - it's
> a user function call in a continuous assignment statement. Looks
> like there's a memory leak there. The leak is present in the master
> branch as well. I've got a simple test case that exposes the
> problem, so I'll work on a fix. I'll wait until after the Big Merge
> before I push anything!
> 
> Stephen Williams wrote:
>> 
>> OK, that's interesting. I theorize that what is going on here is
>> that with the vec4-stack branch there are more vvp_vector4_t 
>> instances running around, and since they allocate some memory to 
>> hold the bit values there is a lot of allocation overhead. The
>> way to address that may be to use a custom allocator within the
>> vvp_vector4_t to allocate the bit space.
>> 
>> Given that it is running faster then "master" even with the 
>> increased memory, I'm willing to accept the cost for now, and put
>> it off until after the Big Merge.
>> 
>> On 12/05/2014 12:38 PM, Martin Whitaker wrote:
>>> Memory use is reported by 'vvp -v'. With the master branch, I
>>> get
>>> 
>>> Compiling VVP ... ... VVP file version 0.10.0 (devel)
>>> (s20121218-480-g020e280-dirty) Compile cleanup... ... Linking 
>>> ... Removing symbol tables ... Compiletf functions ...     9343
>>> functors (net_fun pool=786432 bytes) 2807 logic 0 bufif 0
>>> resolv 2181 signals ...     8707 filters (net_fil pool=1310720
>>> bytes) ...    44817 opcodes (1081344 bytes) ...     5474 nets 
>>> ...     9343 vvp_nets (1048544 bytes) ...       12 arrays (129
>>> words) ...      125 memories 125 logic (277608 words) 0 real (0
>>> words) ...      407 scopes ... 0.167 seconds,
>>> 59244.0/17172.0/2052.0 KBytes size/rss/shared Running ... 
>>> ...execute EndOfCompile callbacks ...propagate initialization
>>> events ...execute StartOfSim callbacks ...run scheduler 
>>> Generating expected results Running test ...execute Postsim
>>> callbacks ... 59.719 seconds, 261020.0/219492.0/2344.0 KBytes
>>> size/rss/shared Event counts: 130139 time steps (pool=128) 
>>> 2411954 thread schedule events 23563521 assign events 
>>> ...assign(vec4) pool=18724 ...assign(vec8) pool=204 
>>> ...assign(real) pool=256 ...assign(word) pool=128 
>>> ...assign(word/r) pool=204 9721848 other events (pool=4096)
>>> 
>>> With the vec4-stack branch, the only differences are:
>>> 
>>> ...    45991 opcodes (1105920 bytes)
>>> 
>>> ... 0.17 seconds, 60368.0/18228.0/2044.0 KBytes
>>> size/rss/shared
>>> 
>>> ... 55.939 seconds, 555040.0/513392.0/2356.0 KBytes
>>> size/rss/shared
>>> 
>>> 
>>> Stephen Williams wrote:
>>>> 
>>>> Those are pretty encouraging results.
>>>> 
>>>> What are you looking at for the memory use?
>>>> 
>>>> On 12/05/2014 12:06 PM, Martin Whitaker wrote:
>>>>> Time taken for my long sequence of short tests:
>>>>> 
>>>>> master      22:48 vec4-stack  18:28
>>>>> 
>>>>> Time taken for my short sequence of longer tests:
>>>>> 
>>>>> master     (lossless)  12:12 vec4-stack (lossless)   9:53
>>>>> 
>>>>> master     (strict)    11:49 vec4-stack (strict)     9:35
>>>>> 
>>>>> So performance looks good. Memory use is still a bit of a
>>>>> concern - for the particular test I looked at, vvp
>>>>> reported
>>>>> 
>>>>> master      261,016 KB vec4-stack  554,984 KB
>>>>> 
>> 
>> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and
> Dashboards with Interactivity, Sharing, Native Excel Exports, App
> Integration & more Get technology previously reserved for
> billion-dollar corporations, FREE 
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>
> 
_______________________________________________
> Iverilog-devel mailing list Ive...@li... 
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 


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

iEYEARECAAYFAlSCLDIACgkQrPt1Sc2b3ikUFQCg5ZLBRVAgw8PNl8P2nzgjpRGh
kwIAoJcsuRC9AkEtJgG5G1r180b8dyKQ
=LeIP
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] More vec4-stack progress

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

I've tracked down the construct that is causing the problem - it's a user 
function call in a continuous assignment statement. Looks like there's a 
memory leak there. The leak is present in the master branch as well. I've got 
a simple test case that exposes the problem, so I'll work on a fix. I'll wait 
until after the Big Merge before I push anything!

Stephen Williams wrote:
>
> OK, that's interesting. I theorize that what is going on here
> is that with the vec4-stack branch there are more vvp_vector4_t
> instances running around, and since they allocate some memory to
> hold the bit values there is a lot of allocation overhead.
> The way to address that may be to use a custom allocator within
> the vvp_vector4_t to allocate the bit space.
>
> Given that it is running faster then "master" even with the
> increased memory, I'm willing to accept the cost for now, and
> put it off until after the Big Merge.
>
> On 12/05/2014 12:38 PM, Martin Whitaker wrote:
>> Memory use is reported by 'vvp -v'. With the master branch, I get
>>
>> Compiling VVP ...
>>    ... VVP file version 0.10.0 (devel) (s20121218-480-g020e280-dirty)
>> Compile cleanup...
>>    ... Linking
>>    ... Removing symbol tables
>>    ... Compiletf functions
>>    ...     9343 functors (net_fun pool=786432 bytes)
>>                  2807 logic
>>                     0 bufif
>>                     0 resolv
>>                  2181 signals
>>    ...     8707 filters (net_fil pool=1310720 bytes)
>>    ...    44817 opcodes (1081344 bytes)
>>    ...     5474 nets
>>    ...     9343 vvp_nets (1048544 bytes)
>>    ...       12 arrays (129 words)
>>    ...      125 memories
>>                   125 logic (277608 words)
>>                     0 real (0 words)
>>    ...      407 scopes
>>    ... 0.167 seconds, 59244.0/17172.0/2052.0 KBytes size/rss/shared
>> Running ...
>>    ...execute EndOfCompile callbacks
>>    ...propagate initialization events
>>    ...execute StartOfSim callbacks
>>    ...run scheduler
>> Generating expected results
>> Running test
>>    ...execute Postsim callbacks
>>    ... 59.719 seconds, 261020.0/219492.0/2344.0 KBytes size/rss/shared
>> Event counts:
>>         130139 time steps (pool=128)
>>        2411954 thread schedule events
>>       23563521 assign events
>>                ...assign(vec4) pool=18724
>>                ...assign(vec8) pool=204
>>                ...assign(real) pool=256
>>                ...assign(word) pool=128
>>                ...assign(word/r) pool=204
>>        9721848 other events (pool=4096)
>>
>> With the vec4-stack branch, the only differences are:
>>
>>    ...    45991 opcodes (1105920 bytes)
>>
>>    ... 0.17 seconds, 60368.0/18228.0/2044.0 KBytes size/rss/shared
>>
>>    ... 55.939 seconds, 555040.0/513392.0/2356.0 KBytes size/rss/shared
>>
>>
>> Stephen Williams wrote:
>>>
>>> Those are pretty encouraging results.
>>>
>>> What are you looking at for the memory use?
>>>
>>> On 12/05/2014 12:06 PM, Martin Whitaker wrote:
>>>> Time taken for my long sequence of short tests:
>>>>
>>>>      master      22:48
>>>>      vec4-stack  18:28
>>>>
>>>> Time taken for my short sequence of longer tests:
>>>>
>>>>      master     (lossless)  12:12
>>>>      vec4-stack (lossless)   9:53
>>>>
>>>>      master     (strict)    11:49
>>>>      vec4-stack (strict)     9:35
>>>>
>>>> So performance looks good. Memory use is still a bit of a concern - for the
>>>> particular test I looked at, vvp reported
>>>>
>>>>      master      261,016 KB
>>>>      vec4-stack  554,984 KB
>>>>
>
>

Re: [Iverilog-devel] More vec4-stack progress

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

OK, that's interesting. I theorize that what is going on here
is that with the vec4-stack branch there are more vvp_vector4_t
instances running around, and since they allocate some memory to
hold the bit values there is a lot of allocation overhead.
The way to address that may be to use a custom allocator within
the vvp_vector4_t to allocate the bit space.

Given that it is running faster then "master" even with the
increased memory, I'm willing to accept the cost for now, and
put it off until after the Big Merge.

On 12/05/2014 12:38 PM, Martin Whitaker wrote:
> Memory use is reported by 'vvp -v'. With the master branch, I get
> 
> Compiling VVP ...
>   ... VVP file version 0.10.0 (devel) (s20121218-480-g020e280-dirty)
> Compile cleanup...
>   ... Linking
>   ... Removing symbol tables
>   ... Compiletf functions
>   ...     9343 functors (net_fun pool=786432 bytes)
>                 2807 logic
>                    0 bufif
>                    0 resolv
>                 2181 signals
>   ...     8707 filters (net_fil pool=1310720 bytes)
>   ...    44817 opcodes (1081344 bytes)
>   ...     5474 nets
>   ...     9343 vvp_nets (1048544 bytes)
>   ...       12 arrays (129 words)
>   ...      125 memories
>                  125 logic (277608 words)
>                    0 real (0 words)
>   ...      407 scopes
>   ... 0.167 seconds, 59244.0/17172.0/2052.0 KBytes size/rss/shared
> Running ...
>   ...execute EndOfCompile callbacks
>   ...propagate initialization events
>   ...execute StartOfSim callbacks
>   ...run scheduler
> Generating expected results
> Running test
>   ...execute Postsim callbacks
>   ... 59.719 seconds, 261020.0/219492.0/2344.0 KBytes size/rss/shared
> Event counts:
>        130139 time steps (pool=128)
>       2411954 thread schedule events
>      23563521 assign events
>               ...assign(vec4) pool=18724
>               ...assign(vec8) pool=204
>               ...assign(real) pool=256
>               ...assign(word) pool=128
>               ...assign(word/r) pool=204
>       9721848 other events (pool=4096)
> 
> With the vec4-stack branch, the only differences are:
> 
>   ...    45991 opcodes (1105920 bytes)
> 
>   ... 0.17 seconds, 60368.0/18228.0/2044.0 KBytes size/rss/shared
> 
>   ... 55.939 seconds, 555040.0/513392.0/2356.0 KBytes size/rss/shared
> 
> 
> Stephen Williams wrote:
>>
>> Those are pretty encouraging results.
>>
>> What are you looking at for the memory use?
>>
>> On 12/05/2014 12:06 PM, Martin Whitaker wrote:
>>> Time taken for my long sequence of short tests:
>>>
>>>     master      22:48
>>>     vec4-stack  18:28
>>>
>>> Time taken for my short sequence of longer tests:
>>>
>>>     master     (lossless)  12:12
>>>     vec4-stack (lossless)   9:53
>>>
>>>     master     (strict)    11:49
>>>     vec4-stack (strict)     9:35
>>>
>>> So performance looks good. Memory use is still a bit of a concern - for the
>>> particular test I looked at, vvp reported
>>>
>>>     master      261,016 KB
>>>     vec4-stack  554,984 KB
>>>


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

Re: [Iverilog-devel] More vec4-stack progress

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

Memory use is reported by 'vvp -v'. With the master branch, I get

Compiling VVP ...
  ... VVP file version 0.10.0 (devel) (s20121218-480-g020e280-dirty)
Compile cleanup...
  ... Linking
  ... Removing symbol tables
  ... Compiletf functions
  ...     9343 functors (net_fun pool=786432 bytes)
                2807 logic
                   0 bufif
                   0 resolv
                2181 signals
  ...     8707 filters (net_fil pool=1310720 bytes)
  ...    44817 opcodes (1081344 bytes)
  ...     5474 nets
  ...     9343 vvp_nets (1048544 bytes)
  ...       12 arrays (129 words)
  ...      125 memories
                 125 logic (277608 words)
                   0 real (0 words)
  ...      407 scopes
  ... 0.167 seconds, 59244.0/17172.0/2052.0 KBytes size/rss/shared
Running ...
  ...execute EndOfCompile callbacks
  ...propagate initialization events
  ...execute StartOfSim callbacks
  ...run scheduler
Generating expected results
Running test
  ...execute Postsim callbacks
  ... 59.719 seconds, 261020.0/219492.0/2344.0 KBytes size/rss/shared
Event counts:
       130139 time steps (pool=128)
      2411954 thread schedule events
     23563521 assign events
              ...assign(vec4) pool=18724
              ...assign(vec8) pool=204
              ...assign(real) pool=256
              ...assign(word) pool=128
              ...assign(word/r) pool=204
      9721848 other events (pool=4096)

With the vec4-stack branch, the only differences are:

  ...    45991 opcodes (1105920 bytes)

  ... 0.17 seconds, 60368.0/18228.0/2044.0 KBytes size/rss/shared

  ... 55.939 seconds, 555040.0/513392.0/2356.0 KBytes size/rss/shared


Stephen Williams wrote:
>
> Those are pretty encouraging results.
>
> What are you looking at for the memory use?
>
> On 12/05/2014 12:06 PM, Martin Whitaker wrote:
>> Time taken for my long sequence of short tests:
>>
>>     master      22:48
>>     vec4-stack  18:28
>>
>> Time taken for my short sequence of longer tests:
>>
>>     master     (lossless)  12:12
>>     vec4-stack (lossless)   9:53
>>
>>     master     (strict)    11:49
>>     vec4-stack (strict)     9:35
>>
>> So performance looks good. Memory use is still a bit of a concern - for the
>> particular test I looked at, vvp reported
>>
>>     master      261,016 KB
>>     vec4-stack  554,984 KB
>>
>>
>> Stephen Williams wrote:
>>
>> I have received some feedback on the vec4-stack branch, and I've
>> responded to that feedback with some performance improvements.
>> Now, at least for the tests I've run so far, the new vec4-stack
>> branch runtime is significantly faster then that of the master branch.
>>
>> With this milestone, the merge of the vec4-stack branch into master
>> is becoming imminent. I'm thinking maybe early next week. So please
>> give it a go at your convenience, so we can find any issues as
>> soon as possible.
>>
>> Thanks,
>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Iverilog-devel mailing list
>>> Ive...@li...
>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
>

Re: [Iverilog-devel] More vec4-stack progress

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

Those are pretty encouraging results.

What are you looking at for the memory use?

On 12/05/2014 12:06 PM, Martin Whitaker wrote:
> Time taken for my long sequence of short tests:
> 
>    master      22:48
>    vec4-stack  18:28
> 
> Time taken for my short sequence of longer tests:
> 
>    master     (lossless)  12:12
>    vec4-stack (lossless)   9:53
> 
>    master     (strict)    11:49
>    vec4-stack (strict)     9:35
> 
> So performance looks good. Memory use is still a bit of a concern - for the 
> particular test I looked at, vvp reported
> 
>    master      261,016 KB
>    vec4-stack  554,984 KB
> 
> 
> Stephen Williams wrote:
> 
> I have received some feedback on the vec4-stack branch, and I've
> responded to that feedback with some performance improvements.
> Now, at least for the tests I've run so far, the new vec4-stack
> branch runtime is significantly faster then that of the master branch.
> 
> With this milestone, the merge of the vec4-stack branch into master
> is becoming imminent. I'm thinking maybe early next week. So please
> give it a go at your convenience, so we can find any issues as
> soon as possible.
> 
> Thanks,
> 
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
> 
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

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

Re: [Iverilog-devel] More vec4-stack progress

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

Time taken for my long sequence of short tests:

   master      22:48
   vec4-stack  18:28

Time taken for my short sequence of longer tests:

   master     (lossless)  12:12
   vec4-stack (lossless)   9:53

   master     (strict)    11:49
   vec4-stack (strict)     9:35

So performance looks good. Memory use is still a bit of a concern - for the 
particular test I looked at, vvp reported

   master      261,016 KB
   vec4-stack  554,984 KB


Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> I have received some feedback on the vec4-stack branch, and I've
> responded to that feedback with some performance improvements.
> Now, at least for the tests I've run so far, the new vec4-stack
> branch runtime is significantly faster then that of the master branch.
>
> With this milestone, the merge of the vec4-stack branch into master
> is becoming imminent. I'm thinking maybe early next week. So please
> give it a go at your convenience, so we can find any issues as
> soon as possible.
>
> Thanks,
>
> - --
> 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
>
> iEYEARECAAYFAlSA/aIACgkQrPt1Sc2b3ikYIQCgxfm1wWFPOTEDEDmdrsLssd3S
> 0bcAoJY00ERPjoaHsTHMc0u9eUCNB75V
> =+Jcg
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

[Iverilog-devel] More vec4-stack progress

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

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


I have received some feedback on the vec4-stack branch, and I've
responded to that feedback with some performance improvements.
Now, at least for the tests I've run so far, the new vec4-stack
branch runtime is significantly faster then that of the master branch.

With this milestone, the merge of the vec4-stack branch into master
is becoming imminent. I'm thinking maybe early next week. So please
give it a go at your convenience, so we can find any issues as
soon as possible.

Thanks,

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

iEYEARECAAYFAlSA/aIACgkQrPt1Sc2b3ikYIQCgxfm1wWFPOTEDEDmdrsLssd3S
0bcAoJY00ERPjoaHsTHMc0u9eUCNB75V
=+Jcg
-----END PGP SIGNATURE-----