iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] Support for dynamic arrays in the VPI

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

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


Oh, you did nothing wrong. Don't worry about it at this point as
the vec4-stack branch is still not merged into master. I am merging
master into the vec4-stack branch so that when the merge does
happen, it will be free of surprises.

So far, the only thing keeping me from merging into master is some
performance issues that I think need to be addressed.

On 12/02/2014 11:51 AM, Maciej Sumiński wrote:
> Hi Steve,
> 
> I am sorry - as you know, it was not intentional. I do my best to 
> deliver good quality code, and that includes rebasing my changes
> on the top of the master branch and running the test suite to be
> sure that the merge process is going to be as smooth as it can be.
> 
> I have recently seen posts about the vec4-stack branch. I felt a
> bit relaxed, thinking that it had been already pushed to the
> master, but just a moment ago I realized it is not the case. If it
> is not too late, I can still rebase my changes on the top of
> vec4-stack - just let me know.
> 
> Regards, Orson
> 
> On 12/02/2014 08:23 PM, Stephen Williams wrote:
> 
>> This created some chaos in the vec4-stack branch. Totally not
>> your fault, but it is encouraging me to get my act together and
>> get it merged into the master branch as soon as possible.
> 
> 
>> On 11/28/2014 05:33 AM, Maciej Sumiński wrote:
>>> Hi Steve,
> 
>>> The VPI functions to access dynamic arrays are ready to be 
>>> merged. This is the groundwork that will allow me to write 
>>> support for functions working with std_logic_vectors of
>>> undefined size, that has been my desire for a long time
>>> already.
> 
>>> The pull request [1] also includes a previously sent branch
>>> that introduced type casting in SV. As usual, the new features
>>> are demonstrated with tests [2].
> 
>>> I think changes to VPI code deserve some further explanation.
>>> I did my best to reuse as much of existing code as possible.
>>> As the result, I added __vpiArrayBase type that gathers common 
>>> traits of both static and dynamic arrays (respectively
>>> __vpiArray and __vpiDarray). There are also __vpiArrayIndex,
>>> __vpiArrayWord and __vpiArrayIterator that are used by both
>>> classes.
> 
>>> A few static C functions that were called only by class methods
>>>  are moved directly to appropriate methods (e.g. grep for 
>>> vpi_array_var_word_get_value). A bunch of others are
>>> transformed to methods, in case they were operating on an
>>> instance of a class (see decode_array_word_pointer).
> 
>>> As I have written recently, there is one thing left. If vectors
>>>  are used as the array element type, then there is no way to 
>>> check the details (2 vs 4-state logic and signedness).
> 
>>> Regards, Orson
> 
>>> 1. https://github.com/steveicarus/iverilog/pull/49 2. 
>>> https://github.com/orsonmmz/ivtest/tree/darray_vpi_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

iEYEARECAAYFAlR+IB8ACgkQrPt1Sc2b3im7IACfSex4f/2ksrLDTe1e7fo+FVcn
YB0AoKmPhmKsZfoWfJQqi1SQnC+1hEgK
=1g4+
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Support for dynamic arrays in the VPI

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

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

Hi Steve,

I am sorry - as you know, it was not intentional. I do my best to
deliver good quality code, and that includes rebasing my changes on
the top of the master branch and running the test suite to be sure
that the merge process is going to be as smooth as it can be.

I have recently seen posts about the vec4-stack branch. I felt a bit
relaxed, thinking that it had been already pushed to the master, but
just a moment ago I realized it is not the case. If it is not too
late, I can still rebase my changes on the top of vec4-stack - just
let me know.

Regards,
Orson

On 12/02/2014 08:23 PM, Stephen Williams wrote:
> 
> This created some chaos in the vec4-stack branch. Totally not your
> fault, but it is encouraging me to get my act together and get it
> merged into the master branch as soon as possible.
> 
> 
> On 11/28/2014 05:33 AM, Maciej Sumiński wrote:
>> Hi Steve,
> 
>> The VPI functions to access dynamic arrays are ready to be
>> merged. This is the groundwork that will allow me to write
>> support for functions working with std_logic_vectors of undefined
>> size, that has been my desire for a long time already.
> 
>> The pull request [1] also includes a previously sent branch that
>>  introduced type casting in SV. As usual, the new features are 
>> demonstrated with tests [2].
> 
>> I think changes to VPI code deserve some further explanation. I
>> did my best to reuse as much of existing code as possible. As
>> the result, I added __vpiArrayBase type that gathers common
>> traits of both static and dynamic arrays (respectively __vpiArray
>> and __vpiDarray). There are also __vpiArrayIndex, __vpiArrayWord
>> and __vpiArrayIterator that are used by both classes.
> 
>> A few static C functions that were called only by class methods 
>> are moved directly to appropriate methods (e.g. grep for 
>> vpi_array_var_word_get_value). A bunch of others are transformed 
>> to methods, in case they were operating on an instance of a
>> class (see decode_array_word_pointer).
> 
>> As I have written recently, there is one thing left. If vectors 
>> are used as the array element type, then there is no way to
>> check the details (2 vs 4-state logic and signedness).
> 
>> Regards, Orson
> 
>> 1. https://github.com/steveicarus/iverilog/pull/49 2. 
>> https://github.com/orsonmmz/ivtest/tree/darray_vpi_test
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUfhhaAAoJEBRwGu1hpbJ1x6IIAIEeF9afrDwN4JSaE20hV1cp
+R88PLN0PVbUYG7oBs/yS1RR03fTpcUrprnw9XucIIe7hrNhW8uxhLZKgtfkniwd
5wfFR+cO5RgM6v88sfBz090nVl9MkuGxaPkNSTJImR3CLf7zbwBib3XlCeV0E1So
jFEWWJPpnOph/7BGwGL4weZZnFFc/rKKXEfLVl7IHJMyTrvJXoge/d9WlnAGpcVL
mY3y9nNGh/oCWsVTN5pRA4Y4t6BXop7/hN0VIkYi//d6RJqQIvseGbeYC6t9rERv
NEgxcNHqmgNSYVmcfWZU95ZRVop9Ula3aovRzyRJrkiDJg/WeM3BxzEXMSwdy3k=
=Uyn0
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Support for dynamic arrays in the VPI

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

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


This created some chaos in the vec4-stack branch. Totally not
your fault, but it is encouraging me to get my act together and
get it merged into the master branch as soon as possible.


On 11/28/2014 05:33 AM, Maciej Sumiński wrote:
> Hi Steve,
> 
> The VPI functions to access dynamic arrays are ready to be merged. 
> This is the groundwork that will allow me to write support for 
> functions working with std_logic_vectors of undefined size, that
> has been my desire for a long time already.
> 
> The pull request [1] also includes a previously sent branch that 
> introduced type casting in SV. As usual, the new features are 
> demonstrated with tests [2].
> 
> I think changes to VPI code deserve some further explanation. I did
> my best to reuse as much of existing code as possible. As the
> result, I added __vpiArrayBase type that gathers common traits of
> both static and dynamic arrays (respectively __vpiArray and
> __vpiDarray). There are also __vpiArrayIndex, __vpiArrayWord and
> __vpiArrayIterator that are used by both classes.
> 
> A few static C functions that were called only by class methods
> are moved directly to appropriate methods (e.g. grep for 
> vpi_array_var_word_get_value). A bunch of others are transformed
> to methods, in case they were operating on an instance of a class
> (see decode_array_word_pointer).
> 
> As I have written recently, there is one thing left. If vectors
> are used as the array element type, then there is no way to check
> the details (2 vs 4-state logic and signedness).
> 
> Regards, Orson
> 
> 1. https://github.com/steveicarus/iverilog/pull/49 2.
> https://github.com/orsonmmz/ivtest/tree/darray_vpi_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

iEYEARECAAYFAlR+EbwACgkQrPt1Sc2b3ikRrwCfVuQ4Gi8Esyt1BvgZKtV4X/JQ
Yf4AnR5n/DSqFP/uCkqzUw+MKV49Z6Xk
=dKF3
-----END PGP SIGNATURE-----

[Iverilog-devel] Support for dynamic arrays in the VPI

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

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

Hi Steve,

The VPI functions to access dynamic arrays are ready to be merged.
This is the groundwork that will allow me to write support for
functions working with std_logic_vectors of undefined size, that has
been my desire for a long time already.

The pull request [1] also includes a previously sent branch that
introduced type casting in SV. As usual, the new features are
demonstrated with tests [2].

I think changes to VPI code deserve some further explanation. I did my
best to reuse as much of existing code as possible. As the result, I
added __vpiArrayBase type that gathers common traits of both static
and dynamic arrays (respectively __vpiArray and __vpiDarray). There
are also __vpiArrayIndex, __vpiArrayWord and __vpiArrayIterator that
are used by both classes.

A few static C functions that were called only by class methods are
moved directly to appropriate methods (e.g. grep for
vpi_array_var_word_get_value). A bunch of others are transformed to
methods, in case they were operating on an instance of a class (see
decode_array_word_pointer).

As I have written recently, there is one thing left. If vectors are
used as the array element type, then there is no way to check the
details (2 vs 4-state logic and signedness).

Regards,
Orson

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

iQEcBAEBAgAGBQJUeHmTAAoJEBRwGu1hpbJ1NGUH/0JuSTaZNbTOT8u4tz87eE4a
D4pZ0iqY6N+fm+e3VZwgyFKRVuZIMwp8lr61T7Xrd9H8UhJyyTpFdaHfn6l4VKez
TQGmRNTegKkF+rQDIYvyH5lN4SgqTxQxebztQmltqAMZBWKnvs5YiHlAXPvlWA++
wUeEV/RJFVXj3717npMtp6sKA0+xaGXlYUUQGXtjqrYQOIaMAM9DD8USKJYhnqIM
L3srLkjBp9iL0Puh9tQxVy0Sz22eNWRy/19cjK3kv9ODTMHGnuQ2uIdR+J3wGxdd
AwlaSCDCb0/gcmkkyEJP+pwFQXVeRdcPdllhM4A4H9LYpYqo7gRpij9Br35C3PQ=
=OQ/7
-----END PGP SIGNATURE-----

[Iverilog-devel] iverilog 0.10.0 updated on EDA Playground

[Victor L. <vi...@vi...>]

FYI.

I updated iverilog 0.10.0 to a recent commit on EDA Playground.

Also, you can now run iverilog with Specman e.
Trivial XOR example: http://www.edaplayground.com/x/Pfq
Simple e testbench: http://www.edaplayground.com/x/5Wj

Regards,
Victor

Re: [Iverilog-devel] Handling of constant inputs and unused outputs

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

Martin Whitaker <mai...@ma...> writes:

> This is getting a bit off-topic for this list, but I'll risk annoying the 
> readership with one more reply...

Thanks, I appreciate your guidance.

Regards,
/Niels

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

Re: [Iverilog-devel] Handling of constant inputs and unused outputs

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

This is getting a bit off-topic for this list, but I'll risk annoying the 
readership with one more reply...

ni...@ly... (Niels Möller) wrote:
> Martin Whitaker <mai...@ma...> writes:
>
>> A simulator will not usually perform this type of optimisation. For Verilog in
>> particular, the VPI routines give the user a backdoor mechanism to probe any
>> signals in the design, so it is not generally safe to do so.
>
> Probing is an obstacle for eliminating outputs, but as far as I see,
> it's no fundamental obstacle for constant propagation; the verilog
> compiler could compute the constant value for each eliminated signal
> that could possibly be probed.

The VPI routines also allow the user to force values onto signals.

>> Any decent synthesis tool will do this type of optimisation.
>
> Does it infer automatically which outputs are unused? Or is there some
> kind of verilog syntax to tell it? For now, I do this like
>
>     wire [5:0] dummy;
>     ...
>     /* Final 11-bit add */
>     add_bk16 add ({e0[15:8], 1'b0, e0[6:5], 5'b0},
> 		 {1'b0, e1[14:5], 5'b0}, 1'b0,
> 		 {dummy[5], p[15:5], dummy[4:0]});

A good synthesis tool will automatically remove any logic that can't directly 
or indirectly affect the top-level output signals of a design. It will work 
its way back through flip-flops, removing the flip-flops as well.

Note that the iverilog synthesis option is very basic, and, as far as I'm 
aware, does little or no optimisation of this kind.

>> However, if you are using a synthesis tool, you would normally leave
>> it to generate the optimum adder architecture for each adder instance,
>> inferred from the "+" operator.
>
> With some guidelines for the optimization, to say, e.g., if you want an
> adder with low latency or small area?

You normally give a synthesis tool timing constraints (e.g. minimum clock 
period) and it will try to minimise cell area whilst still meeting those 
constraints. If the timing constraints are easy to meet, it will choose a 
low-area architecture (e.g. ripple carry); if they are hard to meet, it will 
choose a more complex architecture.

> I'm looking into adders and multipliers right now, in part because I
> think they're good examples for learning verilog, in part because the
> state-of-the-art seems to be so far ahead of what I was taught in the
> digital electronics courses. And for a pipelined multiplier, it seems
> difficult rely on the '*' operator when one wants to split it into
> multiple stages with registers in between?

The more advanced synthesis tools will move pipeline registers into a logic 
cone. So you can write the Verilog as a multiply operator followed by one or 
more pipeline register stages, and the synthesis tool will create a suitably 
pipelined multiplier.

Martin

Re: [Iverilog-devel] Handling of constant inputs and unused outputs

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

Martin Whitaker <mai...@ma...> writes:

> A simulator will not usually perform this type of optimisation. For Verilog in 
> particular, the VPI routines give the user a backdoor mechanism to probe any 
> signals in the design, so it is not generally safe to do so.

Probing is an obstacle for eliminating outputs, but as far as I see,
it's no fundamental obstacle for constant propagation; the verilog
compiler could compute the constant value for each eliminated signal
that could possibly be probed.

> Any decent synthesis tool will do this type of optimisation.

Does it infer automatically which outputs are unused? Or is there some
kind of verilog syntax to tell it? For now, I do this like

   wire [5:0] dummy;
   ...
   /* Final 11-bit add */
   add_bk16 add ({e0[15:8], 1'b0, e0[6:5], 5'b0},
		 {1'b0, e1[14:5], 5'b0}, 1'b0,
		 {dummy[5], p[15:5], dummy[4:0]});

> However, if you are using a synthesis tool, you would normally leave
> it to generate the optimum adder architecture for each adder instance,
> inferred from the "+" operator.

With some guidelines for the optimization, to say, e.g., if you want an
adder with low latency or small area?

I'm looking into adders and multipliers right now, in part because I
think they're good examples for learning verilog, in part because the
state-of-the-art seems to be so far ahead of what I was taught in the
digital electronics courses. And for a pipelined multiplier, it seems
difficult rely on the '*' operator when one wants to split it into
multiple stages with registers in between?

And I do use the '+' and '*' operators in my testbench code.

Regards,
/Niels

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

Re: [Iverilog-devel] Handling of constant inputs and unused outputs

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

ni...@ly... (Niels Möller) wrote:
> Say I have a module implementing a 16-bit adder (using a Brent-Kung
> circuit), and in some other module I need an 11-bit adder. Then I can
> use the 16-bit adder with some of the low or high inputs hardwired to
> zero.
>
> Are the constants propagated when instantiating the module, eliminating
> unneeded operations? And when passing *output* parameters to a module,
> is it possible to specify that some output wires are unused, and then
> eliminate all operations needed only for producing those outputs? For the
> example of an adder module, the carry output may be unneeded for some
> instances, and then a couple of operations can be eliminated.
>
A simulator will not usually perform this type of optimisation. For Verilog in 
particular, the VPI routines give the user a backdoor mechanism to probe any 
signals in the design, so it is not generally safe to do so.

Any decent synthesis tool will do this type of optimisation. However, if you 
are using a synthesis tool, you would normally leave it to generate the 
optimum adder architecture for each adder instance, inferred from the "+" 
operator. This will also have the benefit that your simulations will run much 
faster.

Martin

[Iverilog-devel] Handling of constant inputs and unused outputs

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

Say I have a module implementing a 16-bit adder (using a Brent-Kung
circuit), and in some other module I need an 11-bit adder. Then I can
use the 16-bit adder with some of the low or high inputs hardwired to
zero.

Are the constants propagated when instantiating the module, eliminating
unneeded operations? And when passing *output* parameters to a module,
is it possible to specify that some output wires are unused, and then
eliminate all operations needed only for producing those outputs? For the
example of an adder module, the carry output may be unneeded for some
instances, and then a couple of operations can be eliminated.

Regards,
/Niels

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

Re: [Iverilog-devel] vec4-stack branch: I just pushed some performance improvements

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

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


A profile of the vvp run may be helpful.

I just pushed some new updates with even more vvp tweaks, as well
as some vvp code generator updates to generate more efficient code.
So give that a try.

Then, to profile vvp:

1) in the "vvp" directory of the source, "make clean" to remove
all of the .o files, then edit the Makefile to add "-pg" to to
CC and CXX macros: i.e. "CC = gcc -std=gnu99 -pg" and "CXX = g++ -pg".
Rebuild the vvp, and this will be a profiled version of the vvp
runtime.

2) Use this vvp to run your iverilog compiled design. Note to use
the latest updates from the git vec4-stack to get the gest code
that matches the current vvp.

3) Step 2 will create a gmon.out file. Convert it to a text file
that I can read with the command: "gprof vvp gmon.out > gmon.txt".

Send me that txt file and I'll get an idea what corners of the vvp
runtime you are using, and I should be able to make something of
that. If you feel like you can share the vvp file that is the
compiled form of your design, I may be able to peruse that for
opportunities to optimize the generated code.


On 11/19/2014 02:35 PM, Martin Whitaker wrote:
> Stephen Williams wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Working on the "multiply_large" test in the ivtest test suite, I
>> was able to substantially improve its performance, and I have 
>> pushed to the git vec4-stack branch those improvements. The 
>> changes suggest whole categories of performance improvements, so
>> there is plenty of room for more, if you have any simple examples
>> that I can performance-test with the profiler.
>> 
> Definitely improved. For one particular test, the master branch vvp
> reports
> 
> ...    45208 opcodes (1105920 bytes) ... 60.972 seconds,
> 252652.0/210984.0/2336.0 KBytes size/rss/shared
> 
> Before pulling the latest changes, the vec4-stack branch vvp
> reports
> 
> ...    49735 opcodes (1204224 bytes) ... 114.567 seconds,
> 556200.0/514564.0/2364.0 KBytes size/rss/shared
> 
> After pulling the latest changes, the vec4-stack branch vvp
> reports
> 
> ...    48493 opcodes (1179648 bytes) ... 93.482 seconds,
> 556204.0/514672.0/2344.0 KBytes size/rss/shared
> 
> (also note that memory use has more than doubled c.f. the master
> branch).
> 
> I can't share the Verilog code, but could run the profiler and send
> you the results if that would help.
> 
> Martin
> 
> ------------------------------------------------------------------------------
>
> 
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=157005751&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

iEYEARECAAYFAlRtPBUACgkQrPt1Sc2b3ilxXgCbBAKXxQgL1uVojpWjOAwipaje
xUkAoIKl3z341XqyRZvjeD+0H1EXJbLB
=qMxb
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] vec4-stack branch: I just pushed some performance improvements

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

Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Working on the "multiply_large" test in the ivtest test suite,
> I was able to substantially improve its performance, and I have
> pushed to the git vec4-stack branch those improvements. The
> changes suggest whole categories of performance improvements,
> so there is plenty of room for more, if you have any simple
> examples that I can performance-test with the profiler.
>
Definitely improved. For one particular test, the master branch vvp reports

  ...    45208 opcodes (1105920 bytes)
  ... 60.972 seconds, 252652.0/210984.0/2336.0 KBytes size/rss/shared

Before pulling the latest changes, the vec4-stack branch vvp reports

  ...    49735 opcodes (1204224 bytes)
  ... 114.567 seconds, 556200.0/514564.0/2364.0 KBytes size/rss/shared

After pulling the latest changes, the vec4-stack branch vvp reports

  ...    48493 opcodes (1179648 bytes)
  ... 93.482 seconds, 556204.0/514672.0/2344.0 KBytes size/rss/shared

(also note that memory use has more than doubled c.f. the master branch).

I can't share the Verilog code, but could run the profiler and send you the 
results if that would help.

Martin

[Iverilog-devel] vec4-stack branch: I just pushed some performance improvements

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

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

Working on the "multiply_large" test in the ivtest test suite,
I was able to substantially improve its performance, and I have
pushed to the git vec4-stack branch those improvements. The
changes suggest whole categories of performance improvements,
so there is plenty of room for more, if you have any simple
examples that I can performance-test with the profiler.

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

iEYEARECAAYFAlRs0U8ACgkQrPt1Sc2b3inkcQCghKsu+Iu9fMeIIU2kZ4OC7o7g
0GEAmgPXKFDxlvs5CTO5v1nAWxtYbIlL
=LRVj
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] vec4-stack branch, and the vvp rework

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

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


I'm looking at performance now. I'm not too concerned about compile
time, but I want run times to at least match the performance of the
master version before I merge it in. I've got gprof profiles going,
and I've already pushed some minor improvements.

On 11/14/2014 05:02 PM, Cary R. wrote:
> For the short tests I'm guessing the initial setup and parsing is
> a significant part of the total run time and that the longer tests
> are a more accurate measure of the change in simulation speed
> caused by the vec4-stack changes. Given that Icarus is already slow
> I would hope that this rework does not get merged into master until
> it is at least on par with the current implementation. Ideally this
> rework would give us a significant speedup, but that may be
> optimistic without a more expansive rework.
> 
> I may have some time to test this branch later, but work and my
> personal life are swamping me right now.
> 
> Cary
> 
> 
> On Friday, November 14, 2014 4:38 PM, Martin Whitaker 
> <mai...@ma...> wrote:
> 
> 
> I've run all my regressions tests that Icarus can handle without 
> exposing any bugs. Run time for a large group of relatively short
> tests increased by 25%. Run time for a small group of moderately
> long tests increased by 50%.
> 
> Stephen Williams wrote:
> 
> A little while ago I took on a redesign of the handling of vectors 
> in the vvp run-time. For those of you in the know, the idea is to 
> replace the flat thread vector space with a vector stack. The
> intent is to remove some vector length constraints and to allow for
> some theoretical performance improvements.
> 
> That work is in the vec4-stack branch. Almost all of the
> regression test now works with the new branch and I want to start
> building up confidence in it by putting it out there for the more
> daring of you to try out.
> 
> The intent is that version perform better then the existing style, 
> but those performance benefits are almost surely not realized yet. 
> I will be doing some profiling soon and really tackling execution 
> times, but if you have any feedback there, that would be good,
> too.
> 
> Right now, however, I'm mostly interested in quality of the
> results. Did I introduce any new bugs? There are a very few that I
> see in the ivtest results, but I would like to hear about any new
> bugs.
> 
> Thanks,
>> 
>> 
> ------------------------------------------------------------------------------
>>
> 
Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month. Get alerted through email, SMS,
>> voice calls or mobile push notifications. Take corrective actions
>> from your mobile device.
>> 
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
>>
> 
_______________________________________________
>> Iverilog-devel mailing list Ive...@li...
> <mailto:Ive...@li...>
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
>> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month. Get alerted through email, SMS,
> voice calls or mobile push notifications. Take corrective actions
> from your mobile device. 
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
>
> 
_______________________________________________
> Iverilog-devel mailing list Ive...@li... 
> <mailto:Ive...@li...> 
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month. Get alerted through email, SMS,
> voice calls or mobile push notifications. Take corrective actions
> from your mobile device. 
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&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

iEYEARECAAYFAlRmp0IACgkQrPt1Sc2b3iksfgCfdPeq5n7J/ZvkH+pX5KeRJru6
3ZsAn0qIrNwsniUx/cSQd4AdxH1ovHOk
=rHsW
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] vec4-stack branch, and the vvp rework

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

For the short tests I'm guessing the initial setup and parsing is a significant part of the total run time and that the longer tests are a more accurate measure of the change in simulation speed caused by the vec4-stack changes. Given that Icarus is already slow I would hope that this rework does not get merged into master until it is at least on par with the current implementation. Ideally this rework would give us a significant speedup, but that may be optimistic without a more expansive rework.
I may have some time to test this branch later, but work and my personal life are swamping me right now.
Cary
 

     On Friday, November 14, 2014 4:38 PM, Martin Whitaker <mai...@ma...> wrote:
   

 I've run all my regressions tests that Icarus can handle without exposing any 
bugs. Run time for a large group of relatively short tests increased by 25%. 
Run time for a small group of moderately long tests increased by 50%.

Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> A little while ago I took on a redesign of the handling of vectors
> in the vvp run-time. For those of you in the know, the idea is to
> replace the flat thread vector space with a vector stack. The intent
> is to remove some vector length constraints and to allow for some
> theoretical performance improvements.
>
> That work is in the vec4-stack branch. Almost all of the regression
> test now works with the new branch and I want to start building up
> confidence in it by putting it out there for the more daring of you
> to try out.
>
> The intent is that version perform better then the existing style,
> but those performance benefits are almost surely not realized yet.
> I will be doing some profiling soon and really tackling execution
> times, but if you have any feedback there, that would be good, too.
>
> Right now, however, I'm mostly interested in quality of the results.
> Did I introduce any new bugs? There are a very few that I see in
> the ivtest results, but I would like to hear about any new bugs.
>
> 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
>
> iEYEARECAAYFAlRlT5wACgkQrPt1Sc2b3im5XwCfahimBgWhFZorOYIQGRpYfikL
> rT4An16enYKeG5BD/cVCzflCxoT7paSy
> =okya
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


   

Re: [Iverilog-devel] vec4-stack branch, and the vvp rework

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

I've run all my regressions tests that Icarus can handle without exposing any 
bugs. Run time for a large group of relatively short tests increased by 25%. 
Run time for a small group of moderately long tests increased by 50%.

Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> A little while ago I took on a redesign of the handling of vectors
> in the vvp run-time. For those of you in the know, the idea is to
> replace the flat thread vector space with a vector stack. The intent
> is to remove some vector length constraints and to allow for some
> theoretical performance improvements.
>
> That work is in the vec4-stack branch. Almost all of the regression
> test now works with the new branch and I want to start building up
> confidence in it by putting it out there for the more daring of you
> to try out.
>
> The intent is that version perform better then the existing style,
> but those performance benefits are almost surely not realized yet.
> I will be doing some profiling soon and really tackling execution
> times, but if you have any feedback there, that would be good, too.
>
> Right now, however, I'm mostly interested in quality of the results.
> Did I introduce any new bugs? There are a very few that I see in
> the ivtest results, but I would like to hear about any new bugs.
>
> 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
>
> iEYEARECAAYFAlRlT5wACgkQrPt1Sc2b3im5XwCfahimBgWhFZorOYIQGRpYfikL
> rT4An16enYKeG5BD/cVCzflCxoT7paSy
> =okya
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

[Iverilog-devel] vec4-stack branch, and the vvp rework

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

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


A little while ago I took on a redesign of the handling of vectors
in the vvp run-time. For those of you in the know, the idea is to
replace the flat thread vector space with a vector stack. The intent
is to remove some vector length constraints and to allow for some
theoretical performance improvements.

That work is in the vec4-stack branch. Almost all of the regression
test now works with the new branch and I want to start building up
confidence in it by putting it out there for the more daring of you
to try out.

The intent is that version perform better then the existing style,
but those performance benefits are almost surely not realized yet.
I will be doing some profiling soon and really tackling execution
times, but if you have any feedback there, that would be good, too.

Right now, however, I'm mostly interested in quality of the results.
Did I introduce any new bugs? There are a very few that I see in
the ivtest results, but I would like to hear about any new bugs.

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

iEYEARECAAYFAlRlT5wACgkQrPt1Sc2b3im5XwCfahimBgWhFZorOYIQGRpYfikL
rT4An16enYKeG5BD/cVCzflCxoT7paSy
=okya
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Dynamic arrays and VPI

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

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

Yes, that is the exact plan. The other part is type casting, but it is
a smaller change. Icarus already knows how transfer data between some
of the types, I am just adding a few new ones.

Regards,
Orson

On 11/12/2014 05:58 PM, Stephen Williams wrote:
> 
> Great. So you are working out getting dynamic arrays into and out 
> of VPI based functions so that you can implement your cast in a VPI
> function. That has the added benefit that dynamic arrays become 
> accessible to user VPI code as well. I got that right?
> 
> On 11/12/2014 08:53 AM, Maciej Sumiński wrote:
>> Thank you for the prompt response. The big plan is to have a way 
>> to translate VHDL functions that work with std_logic_vectors of 
>> undefined size, that do not have a direct counterpart in 
>> SystemVerilog.
> 
>> To address this issue I would like to cast vectors to dynamic 
>> arrays and the other way round. Such casting is permitted by the
>> SV standard and functions may take and return dynamic arrays, so
>> it is a twisted way to handle the problem.
> 
>> As a warm-up, I have already written code for casting between 
>> strings and vectors in ivl [1]. It makes use of VPI, and I would 
>> like to follow the same route with dynamic arrays. I know the 
>> branch is not approved yet, but I hope there are no
>> show-stoppers that could not be treated with a few small
>> patches.
> 
>> Regards, Orson
> 
>> 1. https://github.com/orsonmmz/iverilog/tree/sv_cast
> 
>> On 11/12/2014 05:38 PM, Stephen Williams wrote:
> 
>>> I think vvp/vpi_darray.c is safe enough for you to work in
>>> right now. Remind me what specifically you are trying to add?
>>> I remember that I approved of what you're doing, but a quick 
>>> reminder what that is exactly will help me.
> 
>>> Sometime soon, I'm going to want to merge the vec4-stack branch
>>>  into the master branch, so that may turn my distraction into 
>>> everybody's distraction;-)
> 
>>> On 11/12/2014 08:31 AM, Maciej Sumiński wrote:
>>>> Hi Steve,
> 
>>>> As far as I could see, there are no VPI functions to access 
>>>> dynamic arrays contents and that is a dependency for my
>>>> further work. I have already started implementing the missing
>>>> bits, ending up with code that resembles the part that
>>>> handles standard arrays. To avoid code duplication, I would
>>>> like to use templates for a few functions or create a common
>>>> ancestor class.
> 
>>>> You have recently mentioned that you are in the middle of vvp
>>>>  rework. I do not want to cause too many conflicts, therefore
>>>> I ask - do you think it is safe to modify vvp/vpi_darray.c &
>>>>  vvp/vpi_priv.h? For the time being they seem to be untouched
>>>> in vec4-stack branch, but I would rather get a green light
>>>> from you.
> 
>>>> Regards, Orson
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUY673AAoJEBRwGu1hpbJ1gVcH+wSGCjRnN9wdEs/AFuTTVXy6
g8A//m1OwqYsNG+vFvyjAFgrIXXHmhGQ59BM9S26XpI4fNUhLcr19kABtAxO44cl
xFHrbneHAdmdxyWUYn/ybV79scJbfwoxP/KjjPFBrr1UdBg/i9qVvbYwnaLdajwJ
oX5zQbUazlYzD3MwtArFrA6y59edkZgvJYlKM2QkzevPPMQV8Paga+S0zYpaK7VQ
SKob5dvgT/kOtxqJe2CrHGIDMbMAgWtd/lFK0WOHns5aT2tWWEaj6KuJa3GrlifJ
FdhoxOr13qrNfsA568hIoMI0qvAg/sCjymYQk8R770Gpz9xKLT0qZBaPBkVA/kk=
=vu12
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Dynamic arrays and VPI

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

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


Great. So you are working out getting dynamic arrays into and out
of VPI based functions so that you can implement your cast in a
VPI function. That has the added benefit that dynamic arrays become
accessible to user VPI code as well. I got that right?

On 11/12/2014 08:53 AM, Maciej Sumiński wrote:
> Thank you for the prompt response. The big plan is to have a way
> to translate VHDL functions that work with std_logic_vectors of
> undefined size, that do not have a direct counterpart in
> SystemVerilog.
> 
> To address this issue I would like to cast vectors to dynamic
> arrays and the other way round. Such casting is permitted by the SV
> standard and functions may take and return dynamic arrays, so it is
> a twisted way to handle the problem.
> 
> As a warm-up, I have already written code for casting between
> strings and vectors in ivl [1]. It makes use of VPI, and I would
> like to follow the same route with dynamic arrays. I know the
> branch is not approved yet, but I hope there are no show-stoppers
> that could not be treated with a few small patches.
> 
> Regards, Orson
> 
> 1. https://github.com/orsonmmz/iverilog/tree/sv_cast
> 
> On 11/12/2014 05:38 PM, Stephen Williams wrote:
> 
>> I think vvp/vpi_darray.c is safe enough for you to work in right
>>  now. Remind me what specifically you are trying to add? I
>> remember that I approved of what you're doing, but a quick
>> reminder what that is exactly will help me.
> 
>> Sometime soon, I'm going to want to merge the vec4-stack branch 
>> into the master branch, so that may turn my distraction into 
>> everybody's distraction;-)
> 
>> On 11/12/2014 08:31 AM, Maciej Sumiński wrote:
>>> Hi Steve,
> 
>>> As far as I could see, there are no VPI functions to access 
>>> dynamic arrays contents and that is a dependency for my further
>>>  work. I have already started implementing the missing bits, 
>>> ending up with code that resembles the part that handles
>>> standard arrays. To avoid code duplication, I would like to use
>>> templates for a few functions or create a common ancestor
>>> class.
> 
>>> You have recently mentioned that you are in the middle of vvp 
>>> rework. I do not want to cause too many conflicts, therefore I 
>>> ask - do you think it is safe to modify vvp/vpi_darray.c & 
>>> vvp/vpi_priv.h? For the time being they seem to be untouched in
>>>  vec4-stack branch, but I would rather get a green light from 
>>> you.
> 
>>> 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

iEYEARECAAYFAlRjkbcACgkQrPt1Sc2b3imaWACeJB+S8lQJjZnAjadVGwxEE7ku
6MQAn3MNnVKSwVHhG1jPx6Oe4TfRzKoE
=iaXO
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Dynamic arrays and VPI

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

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

Thank you for the prompt response. The big plan is to have a way to
translate VHDL functions that work with std_logic_vectors of undefined
size, that do not have a direct counterpart in SystemVerilog.

To address this issue I would like to cast vectors to dynamic arrays
and the other way round. Such casting is permitted by the SV standard
and functions may take and return dynamic arrays, so it is a twisted
way to handle the problem.

As a warm-up, I have already written code for casting between strings
and vectors in ivl [1]. It makes use of VPI, and I would like to
follow the same route with dynamic arrays. I know the branch is not
approved yet, but I hope there are no show-stoppers that could not be
treated with a few small patches.

Regards,
Orson

1. https://github.com/orsonmmz/iverilog/tree/sv_cast

On 11/12/2014 05:38 PM, Stephen Williams wrote:
> 
> I think vvp/vpi_darray.c is safe enough for you to work in right 
> now. Remind me what specifically you are trying to add? I remember 
> that I approved of what you're doing, but a quick reminder what 
> that is exactly will help me.
> 
> Sometime soon, I'm going to want to merge the vec4-stack branch 
> into the master branch, so that may turn my distraction into 
> everybody's distraction;-)
> 
> On 11/12/2014 08:31 AM, Maciej Sumiński wrote:
>> Hi Steve,
> 
>> As far as I could see, there are no VPI functions to access 
>> dynamic arrays contents and that is a dependency for my further 
>> work. I have already started implementing the missing bits,
>> ending up with code that resembles the part that handles standard
>> arrays. To avoid code duplication, I would like to use templates
>> for a few functions or create a common ancestor class.
> 
>> You have recently mentioned that you are in the middle of vvp 
>> rework. I do not want to cause too many conflicts, therefore I
>> ask - do you think it is safe to modify vvp/vpi_darray.c & 
>> vvp/vpi_priv.h? For the time being they seem to be untouched in 
>> vec4-stack branch, but I would rather get a green light from
>> you.
> 
>> Regards, Orson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUY5CGAAoJEBRwGu1hpbJ1GYIH/iiA9bz91KBjPcillqNeajKx
KeBqpzUn5BsGEA5dManHKQdUktvwBt0yuaK/9yTpf1PX/39i5oPpBTjyOGvzcfNb
5bwoa0U2xJ5P2LaZbTWoePDzI+HkEra2Ak2HOvQefHjUbLyAGdqg3fcuBWmALEsx
faa/ehIN3/a9niyiIXcHCuKEIqor6HuorC45L2//OrmDpGpe0tYNS4bM6H+HhD1m
zGNoixM2GT5ghmZsHEm+dqoKoM6pMs9nI9Y6DoV7fFaTE7Y4eNNqQRTDz2odw9FO
RIfDclFmUs0uXWXJWvg+JNxNjh4Tz/+tQRKnXghAC7d7s+cMjh+47EEL4HhVgEo=
=n/Xk
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Dynamic arrays and VPI

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

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


I think vvp/vpi_darray.c is safe enough for you to work in right
now. Remind me what specifically you are trying to add? I remember
that I approved of what you're doing, but a quick reminder what
that is exactly will help me.

Sometime soon, I'm going to want to merge the vec4-stack branch
into the master branch, so that may turn my distraction into
everybody's distraction;-)

On 11/12/2014 08:31 AM, Maciej Sumiński wrote:
> Hi Steve,
> 
> As far as I could see, there are no VPI functions to access
> dynamic arrays contents and that is a dependency for my further
> work. I have already started implementing the missing bits, ending
> up with code that resembles the part that handles standard arrays.
> To avoid code duplication, I would like to use templates for a few
> functions or create a common ancestor class.
> 
> You have recently mentioned that you are in the middle of vvp
> rework. I do not want to cause too many conflicts, therefore I ask
> - do you think it is safe to modify vvp/vpi_darray.c &
> vvp/vpi_priv.h? For the time being they seem to be untouched in
> vec4-stack branch, but I would rather get a green light from you.
> 
> 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

iEYEARECAAYFAlRjjQkACgkQrPt1Sc2b3inCzACeJn+H+HfeePpbE87OT4EtITV9
Ig4AoK8QFS0oo31d2+1DMXB8RZlmSWKc
=lugz
-----END PGP SIGNATURE-----

[Iverilog-devel] Dynamic arrays and VPI

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

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

Hi Steve,

As far as I could see, there are no VPI functions to access dynamic
arrays contents and that is a dependency for my further work. I have
already started implementing the missing bits, ending up with code
that resembles the part that handles standard arrays. To avoid code
duplication, I would like to use templates for a few functions or
create a common ancestor class.

You have recently mentioned that you are in the middle of vvp rework.
I do not want to cause too many conflicts, therefore I ask - do you
think it is safe to modify vvp/vpi_darray.c & vvp/vpi_priv.h? For the
time being they seem to be untouched in vec4-stack branch, but I would
rather get a green light from you.

Regards,
Orson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUY4tfAAoJEBRwGu1hpbJ1LEAH/Rw7mvvDQzxHjscGJm3OoxYP
q7F0v4QCsfoPU0DAGu5XZUR2hbB61hY8STHfTM6vYgKJBwNN24Nw7iFVlhXBiRhF
XqoDQbdNkwLHWxrhjSSX51GoiUFRuNkLTDyuRVER5bOYOxc3KiIqSCejWLbozexW
SxO0jBq2idNpSPZQma0mR4d7XB5YZULjgLX6cs1VrVGEl5j+LX5uN0MSsNhOdoVk
gD5bqhDSogCzh2an16OIpazUQDHD3JiLUALR8XDclVe5e/yxE1AUCxxutZfo1jaJ
Jb4WKygYlQz+K5UAjwa3Wc0LH1A3+icdPkrML1hZDXLcYwpQAYkIR3ylJjlODSs=
=niZe
-----END PGP SIGNATURE-----

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

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

Stephen Williams <st...@ic...> writes:

> Humm, the sizer target is only available in the git repository,
> in the master branch:-(

That explains why it didn't work ;-)

I've now checked out and built iverilog from git. Which worked with no
problem. And in the mean time, I also got my 64-bit adder working (based
on the ideas on
http://robey.lag.net/2012/11/14/how-to-add-numbers-2.html). iverilog
-tsizer add-h64.vl ... now says

**** TOTALS
     Flip-Flops   : 0
     Logic Gates  : 724
     MUX[2]: 63 slices

I guess the "MUX" count is from the final carry select logic, with a
couple of lines of the type

   assign c[1] = c[0] ? s1c1[8] : s1c0[8];
   assign c[2] = c[1] ? s2c1[8] : s2c0[8];
   ...
   assign s[15:8]  = c[0] ? s1c1[7:0] : s1c0[7:0];
   assign s[23:16] = c[1] ? s2c1[7:0] : s2c0[7:0];
   ...

Right?

And if anyone would like to have a look at this code (total of 150 lines
divided into 4 modules) and teach me how to do it better (maybe using
generate for repeated blocks like above, or multidimensional arrays
instead of variables like sXc0, X = 1,2,...,7), I'd be most grateful.

Thanks and regards,
/Niels

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

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

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

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


Humm, the sizer target is only available in the git repository,
in the master branch:-( It may be time to make a snapshot.

On 11/09/2014 05:20 AM, Niels Möller wrote:
> Stephen Williams <st...@ic...> writes:
> 
>> 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.
> 
> I think I'm more interested in a rough gate count for an asic 
> implementation, than resources used in any particular fpga.
> 
>> 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?").
> 
> I think my use will be to (i) get a feeling for the relative
> complexity of different parts of a cpu, and (ii) compare different
> implementations of the same interface.
> 
> But how do I use this target? I'm trying as follows,
> 
> ~/hack/instr16/hw$ iverilog -tsizer -s add_bk8 add-bk8.vl
> add-gp.vl ERROR: Unable to read config file:
> /usr/lib/ivl/sizer.conf : error: target_design entry point is
> missing. error: Code generator failure: -2
> 
> add-bk8.vl defines a moule add_bk8, implementing an 8-bit
> Brent-Kung adder. Which is my intended "top-level" circuit.
> add-gp.vl is a helper module to combine two sets of
> generate/propagate signals, instantiated multiple times in
> add-bk8.vl.
> 
> And what about gate delay, can I get that for selected
> input/output pairs? I guess it's possible to try synthesis using
> iverilog or yosys and then do postprocessing of the generated
> netlist, but I was hoping for something simpler...
> 
> 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

iEYEARECAAYFAlRf/o4ACgkQrPt1Sc2b3ilnlACfTXpFM0cT2hc9be039GDH/w9p
e8YAoIjuYtA3jNlerxQYgXRvUyNKq5Ec
=6mUj
-----END PGP SIGNATURE-----

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

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

Stephen Williams <st...@ic...> writes:

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

I think I'm more interested in a rough gate count for an asic
implementation, than resources used in any particular fpga.

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

I think my use will be to (i) get a feeling for the relative complexity
of different parts of a cpu, and (ii) compare different implementations
of the same interface.

But how do I use this target? I'm trying as follows,

  ~/hack/instr16/hw$ iverilog -tsizer -s add_bk8 add-bk8.vl add-gp.vl
  ERROR: Unable to read config file: /usr/lib/ivl/sizer.conf
  : error: target_design entry point is missing.
  error: Code generator failure: -2

add-bk8.vl defines a moule add_bk8, implementing an 8-bit Brent-Kung
adder. Which is my intended "top-level" circuit. add-gp.vl is a helper
module to combine two sets of generate/propagate signals, instantiated
multiple times in add-bk8.vl.

And what about gate delay, can I get that for selected input/output
pairs? I guess it's possible to try synthesis using iverilog or yosys
and then do postprocessing of the generated netlist, but I was hoping
for something simpler...

Regards,
/Niels

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