iverilog-devel — Conversations on matters of Icarus Verilog development

[Iverilog-devel] Wondering aloud about extended operand lists

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

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


There are a handful of instructions in the vvp opcodes set that
are really pressed for operands. They are reduced to using implicit
index variables to carry operands that really can generally be
immediate.

So I'm wondering aloud if maybe it *is* time to extend the size
of the opcode space. In particular, I've been thinking of
adding to the second union a pointer to a vvp_code_extend_s
struct. This struct can be *much* more liberal, and can carry
more number values. This may wind up allowing us to replace
several hackish instructions with instructions with longer
operand lists.

- --
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 v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHiB7SrPt1Sc2b3ikRAoRyAJ496qz5lfZjWOiOEFKYJtbkAHhWRwCfX2O4
3qpvD9glHEqy106uhGwKev0=
=C0Yp
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Snapshot today?

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

--- Stephen Williams <st...@ic...> wrote:
 
> In the interest of stability, I've decided to actually skip the
> patch that you just submitted to the Patches tracker.

Understand. I'm fairly sure everything is correct, but a little seasoning
never hurts either.

> I've pushed
> the tag that I used, and I have release notes in the ftp directory.
> Note that the list of changes since 20070812 is so huge that I
> got bored writing the release notes and started using generalizations:-)

That's what you get for waiting five month between snapshots ;-).

> Comments before I post an announcement?

Correct file and line information is currently only generated and passed
for system functions and only two functions ($bitstoreal and $realtobits)
have been actually updated to use this new information. Other objects
return dummy values ("N/A", 0). This allows programs that use vpiFile and
vpiLineNo to be compiled, but it will be a while before everything
meaningful in Icarus fully supports this. Hopefully most of the system
functions will be updated by the next snapshot.

Cary


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Re: [Iverilog-devel] Snapshot today?

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

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

Cary R. wrote:
> --- Stephen Williams <st...@ic...> wrote:
> 
>> I find myself waiting on simulations today so am looking into making
>> a devel snapshot. Are there any outstanding patches that people really
>> want to see in this snapshot? I'm in the process of going through the
>> Patches tracker to apply those already submitted patches.
> 
> At this point I am GTG. I just submitted my last active patch. I wanted to
> get the VA math code into the next snapshot, but since I had not planned
> to package it until the weekend it is not ready for release today.

In the interest of stability, I've decided to actually skip the
patch that you just submitted to the Patches tracker. I've pushed
the tag that I used, and I have release notes in the ftp directory.
Note that the list of changes since 20070812 is so huge that I
got bored writing the release notes and started using generalizations:-)

<ftp://ftp.icarus.com/pub/eda/verilog/snapshots/verilog-20080111.txt>

Comments before I post an announcement?

- --
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 v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHiA8hrPt1Sc2b3ikRAi+9AJ9sl27axUfBbHRxD59JBDIuoQog1wCgiw79
Mz2eJRztdGrRbSkMsMzXGAk=
=LhA2
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Snapshot today?

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

--- Stephen Williams <st...@ic...> wrote:

> I find myself waiting on simulations today so am looking into making
> a devel snapshot. Are there any outstanding patches that people really
> want to see in this snapshot? I'm in the process of going through the
> Patches tracker to apply those already submitted patches.

At this point I am GTG. I just submitted my last active patch. I wanted to
get the VA math code into the next snapshot, but since I had not planned
to package it until the weekend it is not ready for release today.

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] Snapshot today?

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

Steve -

On Fri, Jan 11, 2008 at 02:20:08PM -0800, Stephen Williams wrote:
> Are there any outstanding patches that people really
> want to see in this snapshot? I'm in the process of going through the
> Patches tracker to apply those already submitted patches.

Nope, everything's fine here.  I just verified that the
build-in-another-directory step works even without write access to
the source directory (a test that pcb flunks).

It Would Be Nice if you could get rid of
vvp/vpi_priv.cc:121: warning: deprecated conversion from string constant to 'char*'
I never researched how info->code gets used.

     - Larry

[Iverilog-devel] Snapshot today?

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

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


I find myself waiting on simulations today so am looking into making
a devel snapshot. Are there any outstanding patches that people really
want to see in this snapshot? I'm in the process of going through the
Patches tracker to apply those already submitted patches.
- --
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 v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHh+uYrPt1Sc2b3ikRAr1iAJ9oMsuUg5UTASFgIIgsZK+VpTJDTQCeLpGs
urRXCfSwNunw0yGIc+ynvyA=
=kY2y
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Partial fix for pr1867161

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

The opcode/code stream change appears to be a moot point.

draw_select_signal() and draw_select_array() appear to be the only places
that have the logic to do a combined load and part select. They do not use
%load/vp0, so I think we are safe. I'll look the patch over one more time
and submit it shortly.

Cary


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Re: [Iverilog-devel] Partial fix for pr1867161

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

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

Cary R. wrote:
> --- Stephen Williams <st...@ic...> wrote:
>> Actually, I think there was an obscure reason for the way it is
>> currently. I recall that it's current behavior is used to do some
>> specialized part selects in place. For example, if a smaller
>> load width N is given, then only the first N bits are loaded.
>> This is a common case. It might be that %load/vp0 is not used
>> that way, but I'm pretty sure that %load/v is.
> 
> I didn't change %load/v so it should be safe. I'll double check %load/vp0
> to make sure it's not used in this manner. If it is I think we will have
> to add a parameter to pass the value and increase the size of the opcode
> table or do the part select a different way. Do you have a preference?

You mean increasing the size of the vvp_code_s struct? This is
the fixed size of each instruction in the code stream, so increasing
this will increase proportional to the number of instructions the
run-time use. This might not be significant in the end.

> To me increasing the size of the opcode table is the most straight forward
> way to solve this if it is a problem. I don't think the increased table
> size is that significant.

It is true that there are some instructions that are just plain
bizarre in the lengths taken to avoid adding another operand. Maybe
it's time to add another operand slot just for that reason:-/ It
would mean updating the rather intense opcode table, but that's
just grunt work.

Another way to handle this that doesn't increase the size of
the table might me to create a bit_idx2[4] member in the second
union of the table that has 4 small integers. Instructions that
are heavily laden with index numbers could take advantage of this
new operand format, would remain compact, and would make lots of
better use of word registers.

- --
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 v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHh7s8rPt1Sc2b3ikRAiggAJ44EF9rkQx7JAEchHVRuwh/PN9ZtACfT1Rt
d4zRMovVQ9HBNhaXGShNsPw=
=dS1y
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Partial fix for pr1867161

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

--- Stephen Williams <st...@ic...> wrote:
> Actually, I think there was an obscure reason for the way it is
> currently. I recall that it's current behavior is used to do some
> specialized part selects in place. For example, if a smaller
> load width N is given, then only the first N bits are loaded.
> This is a common case. It might be that %load/vp0 is not used
> that way, but I'm pretty sure that %load/v is.

I didn't change %load/v so it should be safe. I'll double check %load/vp0
to make sure it's not used in this manner. If it is I think we will have
to add a parameter to pass the value and increase the size of the opcode
table or do the part select a different way. Do you have a preference?

To me increasing the size of the opcode table is the most straight forward
way to solve this if it is a problem. I don't think the increased table
size is that significant.

Other then looking at this I think I'm done.

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] Partial fix for pr1867161

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

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

Cary R. wrote:
> In the solution to the second problem I am considering changing %load/vp0
> to take the result width not the vector width. The vector does contain
> width information and I'm using that when copying bits to the result. I
> could add another parameter, but then %load/vp0 would have 4 and that will
> require increasing the size of the opcode table.

Actually, I think there was an obscure reason for the way it is
currently. I recall that it's current behavior is used to do some
specialized part selects in place. For example, if a smaller
load width N is given, then only the first N bits are loaded.
This is a common case. It might be that %load/vp0 is not used
that way, but I'm pretty sure that %load/v is.

The opcode.txt file give some guidance here.

- --
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 v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHh5UTrPt1Sc2b3ikRAvJGAJ9PdcycvleqY/aeWoWXxBKw8FXuTgCfY/Bm
yXtYgA+FwYjx9S9Nbj29DBs=
=Dhhp
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Partial fix for pr1867161

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

--- Stephen Williams <st...@ic...> wrote:
>
> Does this take into account all the different uses of the
> draw_signal_dest function? It is not just called from the
> draw_load_add_immediate, as you saw. I suspect your logic is
> correct. The patch looks reasonable on that score at least.

Yes it does. There are only three calls to draw_signal_dest and only one
of them supplies an immediate value (add_index == 0) the others do not use
the immediate value, but it is set to 0L.

In the solution to the second problem I am considering changing %load/vp0
to take the result width not the vector width. The vector does contain
width information and I'm using that when copying bits to the result. I
could add another parameter, but then %load/vp0 would have 4 and that will
require increasing the size of the opcode table.

Cary


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Re: [Iverilog-devel] Partial fix for pr1867161

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

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

Cary R. wrote:

> My solution, all in tgt-vvp/eval_expr.c, is to move the index 0 load out
> of draw_load_add_immediate() and into draw_signal_dest() just before the
> %load.

Does this take into account all the different uses of the
draw_signal_dest function? It is not just called from the
draw_load_add_immediate, as you saw. I suspect your logic is
correct. The patch looks reasonable on that score at least.


- --
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 v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHhsZqrPt1Sc2b3ikRAlmbAJ0TqCtQIXPDfyPlgdYhmSyKQCc7SwCgyUyA
GVM+FbojlKdJo0RvDbmAeTs=
=gyEb
-----END PGP SIGNATURE-----

[Iverilog-devel] Partial fix for pr1867161

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

I have a fix for the problem reported in pr1867161, but I would like some
feedback if this is an appropriate solution.

The fundamental problem is that the right shift b<<3 is using index 0 and
the immediate value add is also using index 0. The assert appears to be
catching this double use of the same index 0 (overwrite)

My solution, all in tgt-vvp/eval_expr.c, is to move the index 0 load out
of draw_load_add_immediate() and into draw_signal_dest() just before the
%load. This left one other problem in that this construct is doing an
array access with a constant increment. This is a combination of %load/av
and %load/vp0. In that spirit I created a new %load/avp0. This does an
array access with an immediate add using index 0 for the value to add like
/vp0 and index 3 for the array element to access like /av.

My preliminary patch is attached. It passes the current test suite.

The second problem which is not noticeable until a after the assert is
fixed/bypassed is that invalid results will be calculated for some array
accesses. The problem is that if the net used to calculate the offset from
the base index is not large enough to contain the largest index value you
will get incorrect results. This is because the addition is done at the
width of the offset, not the width of the maximum array index. So

reg [31:0] array [10:5];
reg [2:0] offset;

array[5+offset] = 0;

would only work correctly for array elements 5, 6 and 7 since they are the
only indexes that fix in 3 bits.

My thought on a solution is to enhance %load/vp0 and now /avp0 to take an
additional parameter that is the final width. The addition and any padding
would be done at that width. This means /vp0 and /avp0 would auto pad.

Let me know if all this sounds reasonable.

Cary




      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Re: [Iverilog-devel] The test suite is OK

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

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

Cary R. wrote:
> Steve,
> 
> The test suite matched what I had. Here is a patch for the regress.list
> that switches the three new "wire real" fails in V0.8 to NI. In general
> there should be no running iverlog failures. This usually indicates a
> syntax error or in the case of V0.8 something that is not implemented.

Applied.

Remember, there are some tests where the compiler is *supposed*
to find an error. For example, it tests to make sure the compiler
detects an incorrect syntax. But otherwise, yes I understand.

- --
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 v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHhUFCrPt1Sc2b3ikRAs3pAJ9NlmCiWYNtgQmX2v77BkzAMHkEuQCg5Z4u
TYVz4U4NHcW9RJcWHnCufC8=
=Ymtn
-----END PGP SIGNATURE-----

[Iverilog-devel] Normal user test

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

Test the iverilog-devel list by posting from a normal user.


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

[Iverilog-devel] Test

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

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

This is just to make sure the iverilog-devel list is alive.

Testing, testing, 1, 2, 3, testing.

- --
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 v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHg7XTrPt1Sc2b3ikRAif/AJ0Y7g5KaR/tSWIqOahJnL4BQTBZIACfRgyY
7u3QqEjBoXWhzlp21cHJFtY=
=TvAb
-----END PGP SIGNATURE-----