iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] VVP Performance boots

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

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

Cary R. wrote:
| --- On Wed, 4/23/08, Stephen Williams <st...@ic...> wrote:
|
|> Pushed into git. The scanmem3 vpi test now passes, so I
|> think we
|> are in good shape.
|
| We always assumed this was going to be a bit painful. Overall I think
things went very well! Now that this has settled down we can start
working on optimizing the logical operators and anything else that will
benefit from the new vector format. I have worked out many of the
equation if you are interested.


Yeah, at least post them. I'm curious.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFID6nxrPt1Sc2b3ikRAvtfAJ9yxo8w+y0APTDewu7ykCSZlNPylQCfUdeM
yd/W1M5yXLQ0nxdIPLk/ju8=
=JNJN
-----END PGP SIGNATURE-----

[Iverilog-devel] More performance improvements for addition and subtraction

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

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


I've pushed into git another wave of performance improvements for
thread add and subtract. They now take full advantage of the most
recent vector encoding changes. With these commits I've seen yet
another 14% improvement in run time of the multiple_long.v test
in the ivtest suite.

The logical operators will not fall so easily, but I think there
are still opportunities there.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFID6i8rPt1Sc2b3ikRAgZSAJ9/G5QmVjyBFjnZNaPMEtD2hHSRnQCeKSF4
3Ketucg3aT5IgZ7MqSl7stY=
=UMrW
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] VVP Performance boots

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

--- On Wed, 4/23/08, Stephen Williams <st...@ic...> wrote:

> Pushed into git. The scanmem3 vpi test now passes, so I
> think we
> are in good shape.

We always assumed this was going to be a bit painful. Overall I think things went very well! Now that this has settled down we can start working on optimizing the logical operators and anything else that will benefit from the new vector format. I have worked out many of the equation if you are interested.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Iverilog-devel] Development milestone

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

--- On Wed, 4/23/08, Stephen Williams <st...@ic...> wrote:

> It was a surprise and a psychological boost last night when
> I
> ran the regression test suite on the latest fix I pushed,
> and
> it went to 1000 tests Passed. That's a lot, folks?-)
> 
> And here's looking for another 1000 passed tests in the
> future!

Add to that the 30 VPI tests. I also have a few in my local testing directory that I need to cleanup and send in some day. I also just submitted two more! Only 998 more to go :-O.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Iverilog-devel] VVP Performance boots

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

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

Cary R. wrote:
| --- On Tue, 4/22/08, Stephen Williams <st...@ic...> wrote:
|> As for all the bit pattern references in
|> vpi_vthr_vector.cc, I
|> thought I got them all, but I can see that I missed a few
|> yet.
|> I would really like to change those last bits so that they
|> do
|> not in any way depend on vvp_bit4_t encoding. I would
|> rather
|> keep all code that depends on vvp_bit4_t encoding in the
|> vvp_net.h
|> and vvp_net.cc files, if possible. If that means putting
|> new map
|> arrays in vvp_net.h, that's OK I think.


| OK this is yours to fix. Once you fix the above string scanmem3 passes
correctly. I saw some strange aval/bval stuff in vpi_memory.cc,
vpi_signal.cc and vpi_vthr_vector.cc. All this is related to X vs Z values.
|
| Adding a bin_digits to table.cc would also help encapsulate this.
There are also a few places where the oct_digits array is incorrectly
given size 256 instead of 64.
|
| Cary

Pushed into git. The scanmem3 vpi test now passes, so I think we
are in good shape.

*Whew*

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFID33ErPt1Sc2b3ikRAhfsAJ9zTMqOV1sntzRAxBO4wQEPdfhaeQCgkxcD
xlcc0BjNICQ9nWiVI879mJU=
=HQcw
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Development milestone

[Larry D. <ldo...@re...>]

Steve -

On Wed, Apr 23, 2008 at 08:03:06AM -0700, Stephen Williams wrote:
> It was a surprise and a psychological boost last night when I
> ran the regression test suite on the latest fix I pushed, and
> it went to 1000 tests Passed. That's a lot, folks?-)

It sure is.  Congratulations!  It also runs all my production
code without regressions.  I would not be opposed to a snapshot
about now.

   - Larry

[Iverilog-devel] Development milestone

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

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


It was a surprise and a psychological boost last night when I
ran the regression test suite on the latest fix I pushed, and
it went to 1000 tests Passed. That's a lot, folks?-)

And here's looking for another 1000 passed tests in the future!

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFID0+qrPt1Sc2b3ikRAhycAJ9v7DxfWFdn/FKLahCxkYjConVHcQCgxa4t
n4TUbj8TIwwdKL+ENeB4Kd4=
=jYgH
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] VVP Performance boots

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

--- On Tue, 4/22/08, Stephen Williams <st...@ic...> wrote:

> All the uses of the tables in tables.cc should be handled
> so that
> they are independent of the vvp_bit4_t encoding. I manually
> map
> vvp_bit4_t objects to bit pairs like are expected in the
> tables.
> Or at least I *think* I got it every where the hex and oct
> tables
> in tables.cc are used. Those are all the tables that are
> left
> in tables.cc.
> 
> Note that tables.cc is generated by draw_tt.c
> 
> As for all the bit pattern references in
> vpi_vthr_vector.cc, I
> thought I got them all, but I can see that I missed a few
> yet.
> I would really like to change those last bits so that they
> do
> not in any way depend on vvp_bit4_t encoding. I would
> rather
> keep all code that depends on vvp_bit4_t encoding in the
> vvp_net.h
> and vvp_net.cc files, if possible. If that means putting
> new map
> arrays in vvp_net.h, that's OK I think.
> 
> For example, I see a few remaining cases of expressions of
> the
> form ("01xz"[foo]) where foo is a vvp_bit4_t.
> Better to bury
> those as macros in vvp_net.h.

OK this is yours to fix. Once you fix the above string scanmem3 passes correctly. I saw some strange aval/bval stuff in vpi_memory.cc, vpi_signal.cc and vpi_vthr_vector.cc. All this is related to X vs Z values.

Adding a bin_digits to table.cc would also help encapsulate this. There are also a few places where the oct_digits array is incorrectly given size 256 instead of 64.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Iverilog-devel] VVP Performance boots

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

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

Cary R. wrote:
| --- On Tue, 4/22/08, Stephen Williams <st...@ic...> wrote:
|
|> Still, I'm fixing it here. Try pulling from git.
|
| That fixed the vvp tests. One VPI test is still failing and I know
why. When you changed the vvp_bit4_t type there were many places in
vpi_vthr_vector.cc and a few other files that had the specific bit
referenced by constant value not enum value! tables.cc also looks to be
in error and while we are at it it would be nice if tables.cc also
contained a single digit version that can be used to replace the ones in
vpi_vthr_vector.cc, vpi_signal.cc, etc.
|
| I have start down the path to fixing this, but could you confirm that
my assumptions are correct. I did find a few places where the different
VPI and internal bit patterns cause incorrect code of X and Z. Now that
they are the same life should be easier.

All the uses of the tables in tables.cc should be handled so that
they are independent of the vvp_bit4_t encoding. I manually map
vvp_bit4_t objects to bit pairs like are expected in the tables.
Or at least I *think* I got it every where the hex and oct tables
in tables.cc are used. Those are all the tables that are left
in tables.cc.

Note that tables.cc is generated by draw_tt.c

As for all the bit pattern references in vpi_vthr_vector.cc, I
thought I got them all, but I can see that I missed a few yet.
I would really like to change those last bits so that they do
not in any way depend on vvp_bit4_t encoding. I would rather
keep all code that depends on vvp_bit4_t encoding in the vvp_net.h
and vvp_net.cc files, if possible. If that means putting new map
arrays in vvp_net.h, that's OK I think.

For example, I see a few remaining cases of expressions of the
form ("01xz"[foo]) where foo is a vvp_bit4_t. Better to bury
those as macros in vvp_net.h.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIDp0arPt1Sc2b3ikRAoJMAKCrRtImvNh/Pctpr/YGs4MVAs9Y2wCfRDGc
BTQq1GxgDsGit1Tolfw6Wik=
=sSnC
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] VVP Performance boots

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

--- On Tue, 4/22/08, Stephen Williams <st...@ic...> wrote:

> Still, I'm fixing it here. Try pulling from git.

That fixed the vvp tests. One VPI test is still failing and I know why. When you changed the vvp_bit4_t type there were many places in vpi_vthr_vector.cc and a few other files that had the specific bit referenced by constant value not enum value! tables.cc also looks to be in error and while we are at it it would be nice if tables.cc also contained a single digit version that can be used to replace the ones in vpi_vthr_vector.cc, vpi_signal.cc, etc.

I have start down the path to fixing this, but could you confirm that my assumptions are correct. I did find a few places where the different VPI and internal bit patterns cause incorrect code of X and Z. Now that they are the same life should be easier.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Iverilog-devel] VVP Performance boots

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

--- On Tue, 4/22/08, Stephen Williams <st...@ic...> wrote:

> From: Stephen Williams <st...@ic...>
> Subject: Re: [Iverilog-devel] VVP Performance boots
> To: "Discussions concerning Icarus Verilog development" <ive...@li...>
> Date: Tuesday, April 22, 2008, 5:31 PM
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Cary R. wrote:
> | --- On Tue, 4/22/08, Stephen Williams
> <st...@ic...> wrote:
> |
> |
> |> We need to look more carefully at the of_ADDI
> instruction.
> |> The
> |> most likely problem is the vector_to_array() call
> returning
> |> a
> |> wrong value.
> |
> | A very good guess! It's actually in
> vvp_vector4_t::subarray() in
> vvp_net.cc. In this case we are getting 32 bits at address
> 32, so on a
> 32 bit machine we are word aligned. The problem is that the
> atmp and
> btmp masking is failing. before the masking we have the
> correct value
> after it we have zero. This is caused by the fact that you
> cannot shift
> a 32 bit value by 32 bits. The same thing could also happen
> with 64 bit
> values. The 100 was a red hearing since it broke the word
> alignment.
> |
> | I will let you decide how you want to fix this. As I
> remember I fixed
> something like this in the exact same routine not too long
> ago. Of
> course that was before you rewrote it to work with the new
> layout ;-)
> 
> 
> Tell me what the attached program does for you on your
> machine.
> When I compile it for 64bit (cc foo.c) and 32bits (cc -m32
> foo.c)
> I get the correct answer. And of course, on PPC32 I get the
> correct
> results. I expect (1<<32) to be 0 on a 32bit machine.
> 
> Still, I'm fixing it here. Try pulling from git.

This is printing:

foo before shift = 0x1
foo after shift = 0x1
foo after subtract = 0x0

The problem as I remember it is that a  bit shift that is greater than or equal to the machine variable width is undefined so in this case it is doing nothing. Though I agree I would also appreciate it if the left shift gave zero for this condition.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Iverilog-devel] VVP Performance boots

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

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

Cary R. wrote:
| --- On Tue, 4/22/08, Stephen Williams <st...@ic...> wrote:
|
|
|> We need to look more carefully at the of_ADDI instruction.
|> The
|> most likely problem is the vector_to_array() call returning
|> a
|> wrong value.
|
| A very good guess! It's actually in vvp_vector4_t::subarray() in
vvp_net.cc. In this case we are getting 32 bits at address 32, so on a
32 bit machine we are word aligned. The problem is that the atmp and
btmp masking is failing. before the masking we have the correct value
after it we have zero. This is caused by the fact that you cannot shift
a 32 bit value by 32 bits. The same thing could also happen with 64 bit
values. The 100 was a red hearing since it broke the word alignment.
|
| I will let you decide how you want to fix this. As I remember I fixed
something like this in the exact same routine not too long ago. Of
course that was before you rewrote it to work with the new layout ;-)


Tell me what the attached program does for you on your machine.
When I compile it for 64bit (cc foo.c) and 32bits (cc -m32 foo.c)
I get the correct answer. And of course, on PPC32 I get the correct
results. I expect (1<<32) to be 0 on a 32bit machine.

Still, I'm fixing it here. Try pulling from git.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIDoNxrPt1Sc2b3ikRAvrqAJ9o+E9LANsuubWO2Y4rAofm3ovSCQCgl4Es
MMQ8ASQhb0m0NPOnotmpK0k=
=3dVZ
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] VVP Performance boots

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

--- On Tue, 4/22/08, Stephen Williams <st...@ic...> wrote:


> We need to look more carefully at the of_ADDI instruction.
> The
> most likely problem is the vector_to_array() call returning
> a
> wrong value.

A very good guess! It's actually in vvp_vector4_t::subarray() in vvp_net.cc. In this case we are getting 32 bits at address 32, so on a 32 bit machine we are word aligned. The problem is that the atmp and btmp masking is failing. before the masking we have the correct value after it we have zero. This is caused by the fact that you cannot shift a 32 bit value by 32 bits. The same thing could also happen with 64 bit values. The 100 was a red hearing since it broke the word alignment.

I will let you decide how you want to fix this. As I remember I fixed something like this in the exact same routine not too long ago. Of course that was before you rewrote it to work with the new layout ;-)

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Iverilog-devel] VVP Performance boots

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

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

Stephen Williams wrote:
| Try modifying the vhtread_run() function in vthread.cc to include
| a simple print after the call to the opcode, like this:
|
| ~   bool rc = (cp->opcode)(thr, cp);
| ~   cerr << "thr pc=" << thr->pc << " bit4=" << thr->bits4 << endl;

OK, I'm seeing something interesting. The second %addi is not
working. Judging by the symptoms, it appears to be reading a
32'd0 from the thread where it should be reading a 32'd1.

~   %load/v 12, v0xa0296d8_0, 4; "small1"
pc=0x84469e0
bit4=64'b000000000000000000000000000000010001111111111111_0001_0001X010ZX10

~   %mov 32, 12, 4;
pc=0x84469f0
bit4=64'b0000000000000000000000000000_0001_0001111111111111_0001_0001X010ZX10

~   %mov 36, 0, 28;
pc=0x8446a00
bit4=64'b_0000000000000000000000000000_0001000111111111111100010001X010ZX10

~   %addi 32, 1, 32;
pc=0x8446a10
bit4=64'b_00000000000000000000000000000001_000111111111111100010001X010ZX10

The 32'd1 stays 32'd1 in the thread, and hence the loop.

We need to look more carefully at the of_ADDI instruction. The
most likely problem is the vector_to_array() call returning a
wrong value. Then we need to look closely at the lvb array that
is made up by from the immediate data. This is probably OK if
the first %addi created an addition. Then we also need to look
at the final result that is lva. That is probably OK (given the
initial lva and lvb) because the thread got modified with the
correct result after the first %addi.

Can you put a test print in of_ADDI that prints lva[0] and lvb[0]
right before the "for" loop in the of_ADDI instruction? I'm going
to best that lva!=0 and lva[1]==0 every time through the of_ADDI
instruction.
- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIDnLcrPt1Sc2b3ikRArjLAJ9rU6RGHgcIpw8QHoeraH3pUaBLewCfda1E
DgNvhyHBwnRWwmyvtPd2kg4=
=SHQK
-----END PGP SIGNATURE-----

[Iverilog-devel] An interesting milestone.

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

We currently have fewer open bug reports in the development branch (13) then we do in V0.8/stable (15). It looks like it is getting about time for a stable bug fest. Stable is in even worse shape when you looked at the test suite results, since almost all the recent development bug fixes are fails or worse for stable.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Iverilog-devel] VVP Performance boots

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

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

Cary R. wrote:
| --- On Tue, 4/22/08, Stephen Williams <st...@ic...> wrote:
|
|> I think you are saying that changing this:
|> ~    %load/v 12, v0x855918_0, 4;
|> ~    %mov 132, 12, 4;
|> ~    %mov 136, 0, 28;
|> ~    %addi 132, 1, 32;
|> ~    %set/v v0x855918_0, 132, 4;
|>
|> to this:
|> ~    %load/v 12, v0x855918_0, 4;
|> ~    %mov 32, 12, 4;
|> ~    %mov 36, 0, 28;
|> ~    %addi 32, 1, 32;
|> ~    %set/v v0x855918_0, 32, 4;
|>
|> will bring the infinite loop back for you?
|
| That is correct.
|
|> I don't see anything wrong. I think we need to see the
|> value of
|> the thread bit4 after every opcode:-(
|
| I was expecting this. A tutorial or a patch with #ifdef code would be
most appreciated.
|

Try modifying the vhtread_run() function in vthread.cc to include
a simple print after the call to the opcode, like this:

~   bool rc = (cp->opcode)(thr, cp);
~   cerr << "thr pc=" << thr->pc << " bit4=" << thr->bits4 << endl;

That is, put the cerr on around line 335. It won't be pretty, but
I should be able to decode what it is saying. It will print the
thread bit4 bits after every instruction. Then send me the output
(truncated to a few hundred lines) and the .out that you used.


- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIDloQrPt1Sc2b3ikRApUXAJ9EuvRLXo3GRgJj1KJonSgfWGZOYACeLPRn
3GLVByAUluh/0oPFt5TD7Mg=
=zbu6
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] VVP Performance boots

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

--- On Tue, 4/22/08, Stephen Williams <st...@ic...> wrote:

> I think you are saying that changing this:
> ~    %load/v 12, v0x855918_0, 4;
> ~    %mov 132, 12, 4;
> ~    %mov 136, 0, 28;
> ~    %addi 132, 1, 32;
> ~    %set/v v0x855918_0, 132, 4;
> 
> to this:
> ~    %load/v 12, v0x855918_0, 4;
> ~    %mov 32, 12, 4;
> ~    %mov 36, 0, 28;
> ~    %addi 32, 1, 32;
> ~    %set/v v0x855918_0, 32, 4;
> 
> will bring the infinite loop back for you?

That is correct.
 
> I don't see anything wrong. I think we need to see the
> value of
> the thread bit4 after every opcode:-(

I was expecting this. A tutorial or a patch with #ifdef code would be most appreciated.

Cary



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[Iverilog-devel] Is it time for a real logical OR/AND in the runtime?

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

Currently logical OR (||) and AND (&&) are synthesized using other gates (bitwise and hopefully reduction when needed). The problem is this is often done incorrectly when the argument has multiple bit (see pr1948342). The other problem is that this gives us no straight forward path to implement the logical operators for real values. I think it is time for a LAND, LOR and probably a LNOT functor/statement. This is a major rework of the logical operators, but it will allow us to finish the missing logical operators for real values, it will simplify the compiler since we do not need to figure out when to insert reductions and it puts the relevant code in one (well actually two % and functor) places.

Any thoughts/recommendations?

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Iverilog-devel] VVP Performance boots

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

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


I think you are saying that changing this:
~    %load/v 12, v0x855918_0, 4;
~    %mov 132, 12, 4;
~    %mov 136, 0, 28;
~    %addi 132, 1, 32;
~    %set/v v0x855918_0, 132, 4;

to this:
~    %load/v 12, v0x855918_0, 4;
~    %mov 32, 12, 4;
~    %mov 36, 0, 28;
~    %addi 32, 1, 32;
~    %set/v v0x855918_0, 32, 4;

will bring the infinite loop back for you?

I don't see anything wrong. I think we need to see the value of
the thread bit4 after every opcode:-(


Cary R. wrote:
| --- On Tue, 4/22/08, Stephen Williams <st...@ic...> wrote
|
|> When you say that %addi is getting a 0, do you mean
|> lva[0]==0,
|> or lva==0? The latter means that there were XZ bits in the
|> vector
|> so it will cancel the add. That's probably not
|> what's happening,
|> but I'm just double-checking.
|
| I was checking inside the loop so I'm fairly sure it is lva[idx].
|
|> Can you send me the a.out from your compile of the reduced
|> test
|> program? (And the reduced test program as well.)  Need to
|> make
|> sure we are generating the same code from a given input.
|
| Attached. The a.out is the modified add 100 to get things to work. It
should be obvious what needs to be removed to bring the inf. loop back.
|
|
- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIDlPMrPt1Sc2b3ikRAnQAAJ93NeWINaAv2nJn/liX2kqanLJQuwCbBZvu
bhhzLyi7lwExTEP1oPDs2sA=
=eTvY
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Left shift of unsized constant

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

The patch in git fixed the $writemem* problems on both my machines.




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Iverilog-devel] VVP Performance boots

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

--- On Tue, 4/22/08, Stephen Williams <st...@ic...> wrote

> When you say that %addi is getting a 0, do you mean
> lva[0]==0,
> or lva==0? The latter means that there were XZ bits in the
> vector
> so it will cancel the add. That's probably not
> what's happening,
> but I'm just double-checking.

I was checking inside the loop so I'm fairly sure it is lva[idx].

> Can you send me the a.out from your compile of the reduced
> test
> program? (And the reduced test program as well.)  Need to
> make
> sure we are generating the same code from a given input.

Attached. The a.out is the modified add 100 to get things to work. It should be obvious what needs to be removed to bring the inf. loop back.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Iverilog-devel] VVP Performance boots

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

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

Cary R. wrote:
| --- On Mon, 4/21/08, Stephen Williams <st...@ic...> wrote:
|
|
|> I think we are looking for some sort of uninitialized
|> memory problem.
|> It appears that the %xnor opcode is fine in your case, but
|> there is
|> some problem managing the index variable. Try putting a
|> test print
|> in the of_ADDI function to look at the first word of the
|> lva array
|> that is returned by the vector_to_array before and after
|> the "for"
|> loop that does the addition. At the very least, this will
|> confirm
|> that the index variable value is stuck.
|>
|> Perhaps the %set/v or %load/v (if not the %addi) are not
|> working
|> properly? Seeing what's going into/out of the %addi may
|> help us pin
|> it down.
|
| This appears to be some kind of race condition! Oh fun!!. I can
simplify the the loop down to the large1 assign and the two xnor
assignments. Deleting either one of the xnor assignments will make the
inf looping go away. The %addi is always getting 0 from the tread
vector, so it appears to be working correctly. It also looks like the
%load/v has the correct signal value (it starts at zero and then goes to
1). The only thing between the %load/v and the %addi are a couple of
%mov instructions to pad the value.

When you say that %addi is getting a 0, do you mean lva[0]==0,
or lva==0? The latter means that there were XZ bits in the vector
so it will cancel the add. That's probably not what's happening,
but I'm just double-checking.

Can you send me the a.out from your compile of the reduced test
program? (And the reduced test program as well.)  Need to make
sure we are generating the same code from a given input. Given
that, I think we'll need to dump the thread state between every
instruction to make sure all the operations are doing exactly
what we expect. This can be done by dumping the thr->bit4 value
in vthread_run after (and maybe also before) each call to the
opcode function pointer. Getting desperate here:-(

| If I add 100 to the thread addresses for the code that increments the
loop counter everything works correctly, so it appears that when we have
two xnor statements the second one is some how changing values after it
should be and is zeroing the loop counter. I'm not certain how this is
happening since the xnor should be producing all ones as output. I can
send the reduced test case and a.out file if that helps. FYI the second
xnor and the loop counter increment use the same or overlapping thread
space addresses.

Or more likely the second one has a different input value that is
triggering an X values. Or vectors running off their ends. Or
something like that. I think it is unlikely that there is a race
because there are no nets to race against.


- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIDjLYrPt1Sc2b3ikRAoL9AJ9tbi1o9uIfk3S9CgxZRiwWAAd39QCgzkzi
9H1PDCnOtxrkCrz+G8g42Yg=
=JXOS
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Left shift of unsized constant

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

--- On Tue, 4/22/08, Stephen Williams <st...@ic...> wrote:

> Hmm, ideally, I would like the left shift in a
> self-determined
> context like this to take on the size of the largest
> possible
> value that it can emit, but I think that can lead to
> crazyness.
> For example, if val were an integer (32bits) then the width
> of
> the shift expression would be 2**32. NAK!
> 
> So I'm thinking that for left shift, if the left side
> is an
> unsized constant and the right side is non-consant, then it
> should take on the size of the integer. If both sides are
> constant, then it should take on exactly the right size.
> Does
> that sound workable to you?

The standard says this should be the same as integer, but given that this is a self determined context I don't see how making constant values smaller would be a problem. They will be zero extended to fit whatever is really needed in the end. And I like the idea of a constant larger than an integer doing the right thing.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[Iverilog-devel] Left shift of unsized constant

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

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

Cary R. wrote:
| It appears that the writemem* problems are created by the
1<<(6-count). It look like the 1 is being interpreted as a two bit wide
value instead of the normal integer 32 bits. This means that for values
of count less than five the result is zero. The following simple program
is producing incorrect results:
|
| module main;
|   reg [2:0] val;
|
|   initial begin
|     for (val=0; val<=6; val=val+1) begin
|       $displayh(val,, 1<<(6-val));
|     end
|   end
| endmodule

Hmm, ideally, I would like the left shift in a self-determined
context like this to take on the size of the largest possible
value that it can emit, but I think that can lead to crazyness.
For example, if val were an integer (32bits) then the width of
the shift expression would be 2**32. NAK!

So I'm thinking that for left shift, if the left side is an
unsized constant and the right side is non-consant, then it
should take on the size of the integer. If both sides are
constant, then it should take on exactly the right size. Does
that sound workable to you?

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIDiCgrPt1Sc2b3ikRAptZAJ43AjMaVsHynLfvAQ0O+q+Q0TAfQgCeLax4
c/zH3+a7fATvkUnJJxF3gPk=
=mDP2
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] VVP Performance boots

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

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

Cary R. wrote:
| It appears that the writemem* problems are created by the
1<<(6-count). It look like the 1 is being interpreted as a two bit wide
value instead of the normal integer 32 bits. This means that for values
of count less than five the result is zero. The following simple program
is producing incorrect results:
|
| module main;
|   reg [2:0] val;
|
|   initial begin
|     for (val=0; val<=6; val=val+1) begin
|       $displayh(val,, 1<<(6-val));
|     end
|   end
| endmodule
|
| This problem appear to be related to a different patch since this is
in the compiler not the runtime. I'm not certain when I last ran the
tests with a synced source tree, but I know it was not too long ago.

This program goes wrong for me too. File it, give it a high priority,
and assign it to me. I want to tackle this quickly.


- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIDhk7rPt1Sc2b3ikRAhWBAJsFWMlNGKQIH9FMEGBfrbmvEBfLlACeJQJG
1OoCuLtC4aN1N3RGNmE4oSc=
=5miW
-----END PGP SIGNATURE-----