iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] Potential rework of nets/wires support in VVP

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

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

Cary R. wrote:
> --- Stephen Williams <st...@ic...> wrote:
>> It looks like I'm going to have to rework the handling of Verilog
>> wires so that they are not themselves nodes in the vvp_net netlist
>> but instead point to the place in an existing vvp_net. The problem
>> here is that force/release work on the nodes that represent wires.
>> This is obviously already a problem because there is a chance that
>> forcing a wire, like the vpi_put_value, may wind up forcing its
>> value into a spur of the vvp_net netlist. But if the vvp_net nodes
>> for wires are removed, then force/release are going to have to
>> work on general vvp_net nodes, and not just "wire" nodes.
> 
> I must confess that this net stuff is still a bit opaque to me, so I don't
> have much to add except I would ask that you look at some of the other
> limitations we currently have in this area and see if they all in
> aggregate suggest a solution. Off the top of my head the other limitations
> I can remember are multiple output support, net delays (from SDF files),
> net traversal from the PLI. I'm sure there are more, but I'll leave
> finding them as an exercise for the reader.

Add to that switch level modeling such as tranif* and rtran*. These
are odd devices in that they are bidirectional. The resistive
devices in particular escape me. (I was kinda holding off on resistive
transistors to see if the problem goes away when AMS support gets
figured out.)

I think that net delays can be understood in term of vvp_net nodes.
In particular, one can find ways to attach delays between drivers
of nets and the nets themselves. It may be possible to handle this
in the elaborator by propagating the net delays to the delays of
all the driving expressions, but putting a .delay node in place
is probably the best way of handling it. Specify delays for module
ports are handled this way.

Actually, the vvp_net infrastructure inside vvp is probably the
cleanest and easiest to understand aspect of the vvp runtime:-)
- --
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

iD8DBQFH2/QLrPt1Sc2b3ikRAjCTAJ0V64KzvJ/ogtxUINznj5zv4ren1QCgymms
lUU5OlZ+fWOriiSsc/QIWuw=
=Pddy
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] OpenSPARCT2.1.0 compiles/elaborates with only one line changed

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

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

Stefan Thiede wrote:
> Hi Folks,
> 
> after changing one line in he code (pr1914678) and switching to a 64-bit version of icarus and a machine with lot's of ram, I was able to compile the T2 rtl.
> 
> iverilog -c t2.inpfile -s cpu takes ~30min and needs 8.5Gb, 
> a.out takes 6 min and 4.5GB.

Thanks for these results. Yeah, the performance issues kinda sting
when I'm reminded, so we need to gradually start giving them more
attention. As Icarus Verilog gets ever more complete and bug free,
people throw ever larger designs at it. In some cases, the limiting
factor for adoption is no longer its completeness but its performance:-O

Still, there is plenty to do on many axis and I think we can stand
to attract and retain a slightly larger cadre of core developers.
This is such specialized work, though.

> Many thanks for your effort, keep up the good work.

I cannot overstate the importance of critical sets of eyes bearing
down on things dispassionately. That's what keeps things on course.

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

iD8DBQFH2/DgrPt1Sc2b3ikRAiOFAJ9WBC8pAhq5J9OajOTLp64orDGqLQCg1sTD
bCQG02yyHonxa8rXtf2C3ec=
=fomj
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Potential rework of nets/wires support in VVP

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

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> It looks like pr1652096 is going to cause me some real grief. The
> root of the problem is that nets (the things that are visible to
> VPI) are special functors, and in particular they are placed in the
> vvp_net netlist as *receivers* of the data that flows through the
> vvp_net network. Normally that is OK, but when some VPI code tries
> to vpi_put_value to these vpi nets, the value goes into a spur of
> the vvp_net netlist instead of into the net as a whole.
> 
> Variables work out differently because they are handled as drivers
> in the vvp_net netlist, and so the netlist is built around them
> appropriately. Wires cannot be handled that way because of the
> tying together that is expected of a wire in a Verilog netlist.
> 
> It looks like I'm going to have to rework the handling of Verilog
> wires so that they are not themselves nodes in the vvp_net netlist
> but instead point to the place in an existing vvp_net. The problem
> here is that force/release work on the nodes that represent wires.
> This is obviously already a problem because there is a chance that
> forcing a wire, like the vpi_put_value, may wind up forcing its
> value into a spur of the vvp_net netlist. But if the vvp_net nodes
> for wires are removed, then force/release are going to have to
> work on general vvp_net nodes, and not just "wire" nodes.

I must confess that this net stuff is still a bit opaque to me, so I don't
have much to add except I would ask that you look at some of the other
limitations we currently have in this area and see if they all in
aggregate suggest a solution. Off the top of my head the other limitations
I can remember are multiple output support, net delays (from SDF files),
net traversal from the PLI. I'm sure there are more, but I'll leave
finding them as an exercise for the reader.

My rational for this approach is since you are already making significant
changes to this section of code you might as well fix everything you can.
The amount of code you need to understand/relearn is about the same.
That's where I am with expressions (it all started with an implementation
for **). Months later my primarily focus is still fixing problems in the
compiler expression code.

Cary


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

[Iverilog-devel] OpenSPARCT2.1.0 compiles/elaborates with only one line changed

[Stefan T. <Ste...@gm...>]

Hi Folks,

after changing one line in he code (pr1914678) and switching to a 64-bit version of icarus and a machine with lot's of ram, I was able to compile the T2 rtl.

iverilog -c t2.inpfile -s cpu takes ~30min and needs 8.5Gb, 
a.out takes 6 min and 4.5GB.

Many thanks for your effort, keep up the good work.

Stefan
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx

[Iverilog-devel] Potential rework of nets/wires support in VVP

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

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


It looks like pr1652096 is going to cause me some real grief. The
root of the problem is that nets (the things that are visible to
VPI) are special functors, and in particular they are placed in the
vvp_net netlist as *receivers* of the data that flows through the
vvp_net network. Normally that is OK, but when some VPI code tries
to vpi_put_value to these vpi nets, the value goes into a spur of
the vvp_net netlist instead of into the net as a whole.

Variables work out differently because they are handled as drivers
in the vvp_net netlist, and so the netlist is built around them
appropriately. Wires cannot be handled that way because of the
tying together that is expected of a wire in a Verilog netlist.

It looks like I'm going to have to rework the handling of Verilog
wires so that they are not themselves nodes in the vvp_net netlist
but instead point to the place in an existing vvp_net. The problem
here is that force/release work on the nodes that represent wires.
This is obviously already a problem because there is a chance that
forcing a wire, like the vpi_put_value, may wind up forcing its
value into a spur of the vvp_net netlist. But if the vvp_net nodes
for wires are removed, then force/release are going to have to
work on general vvp_net nodes, and not just "wire" nodes.

Hmm...

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

iD8DBQFH2wzDrPt1Sc2b3ikRAjWNAJ41U5hJowvMHvOtXsBxehcCfmu+WACeLqCV
osLh2jQXANlZbB9R45Vjk+M=
=1R+9
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Ready for a Snapshot

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

--- Stephen Williams <st...@ic...> wrote:
 
> I'm thinking it's getting to be time for another snapshot. It's
> been a little while since the last snapshot, and a lot has happened
> since then. Also, I'm pondering a big rework of vpi net/wire
> handling in vvp and might want to get a snapshot out before I
> start down that road.
> 
> So anybody object to a snapshot real soon now?

Sounds fine with me. I don't have anything that I feel must be done before
the next snapshot. Have fun with the change log ;-)!

Cary


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

[Iverilog-devel] Ready for a Snapshot

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

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


I'm thinking it's getting to be time for another snapshot. It's
been a little while since the last snapshot, and a lot has happened
since then. Also, I'm pondering a big rework of vpi net/wire
handling in vvp and might want to get a snapshot out before I
start down that road.

So anybody object to a snapshot real soon now?
- --
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

iD8DBQFH2v3ArPt1Sc2b3ikRApC5AKCM6BRLwbj8mV2rg8fzbVRnda6f5wCg7r2Y
MDcr8TOJC5Fmg9bW9ZbUR/s=
=JN1I
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Constant function definition.

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

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

> No, that makes sense. A constant function can call other constant
> functions and that is the "functions" they refer to there. They are
> specifically exempting functions and parameters as identifiers that
> must be declared locally. Note that arguments *are* declared locally
> so no exemption is needed for them. This rule allows one to use
> local temporaries as well.

OK that makes sense.
 
> They don't say anything about this, but I can see this restriction
> as there to prevent the (perceived) threat of dependency loops
> during elaboration.

To me, given that you can already call other constant functions you have
the potential for dependency loops and as long as they terminate looping
is usually OK. Maybe as I work on a solution I'll see the light!

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] Constant function definition.

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

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

Cary R. wrote:
> There appears to be some ambiguity in the 1364-2001 definition of constant
> functions, so I would like to know what the 2005 version has to say on the
> matter. I have the errata which removed the $display exclusion.
> 
> 1. All identifiers which are not parameters or [functions] shall be
> declared locally to the current function. I believe the "functions" should
> be "function arguments", because as written this doesn't make sense.

No, that makes sense. A constant function can call other constant
functions and that is the "functions" they refer to there. They are
specifically exempting functions and parameters as identifiers that
must be declared locally. Note that arguments *are* declared locally
so no exemption is needed for them. This rule allows one to use
local temporaries as well.

> 2. They shall not themselves use constant functions in any context
> requiring a constant expression. I'm assuming the constant expression here
> is the grammar definition of a constant expression. Does 2005 give a
> reason for this exclusion? To me it seems overly restrictive.

They don't say anything about this, but I can see this restriction
as there to prevent the (perceived) threat of dependency loops
during elaboration. I can't say I really know, and I'm not seeing
anything about it in the standard that is in front of me.

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

iD8DBQFH2rHWrPt1Sc2b3ikRAoODAJ48PLDybodfID7/oxUQ76Zle8uGCwCdG/Bs
exSgvRZwWgkC/BSbhu3o1to=
=KWNt
-----END PGP SIGNATURE-----

[Iverilog-devel] Constant function definition.

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

There appears to be some ambiguity in the 1364-2001 definition of constant
functions, so I would like to know what the 2005 version has to say on the
matter. I have the errata which removed the $display exclusion.

1. All identifiers which are not parameters or [functions] shall be
declared locally to the current function. I believe the "functions" should
be "function arguments", because as written this doesn't make sense.

2. They shall not themselves use constant functions in any context
requiring a constant expression. I'm assuming the constant expression here
is the grammar definition of a constant expression. Does 2005 give a
reason for this exclusion? To me it seems overly restrictive.

Cary


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

Re: [Iverilog-devel] Macro expansions, strings and back tick

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

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

> ... snip ...

So you basically agree with what I said. And I agree it would be best to
poll the big-3 to determine the initial polarity of the flag.

> And by the way, how does C/C++ deal with this issue?

I love rhetorical questions! If you are a good C++ programmer you likely
don't need/use macros since there are better alternatives ;-).

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] Macro expansions, strings and back tick

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

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

Cary R. wrote:

> In general I like the idea of macros expanding in strings. It allows you
> to easily display an expanded macro for either documentation or debugging.
> Yes you could look at the output of the preprocessor for the same
> information. It's just not as convenient!
> 
> Since it is already there I think it should be kept, but we should add a
> -g<flag> that can be used to disabled this feature. I also think we should
> enhance the macro expansion to know when it is in a string constant and do
> the right thing with " and \ so we can display the macro exactly as it
> would appear in the output (don't forget backslash at the end of line is
> special).
> 
> If we go this route it is immaterial what others do, it is an enhancement
> that can easily be disabled. Thoughts?

Well sorta. Most Icarus Verilog extensions make legal something
that is otherwise illegal, and don't get in the way of otherwise
valid code. I would call this the definition of an "extension":-)
This feature, however, may be causing otherwise valid code to fail.
In particular, the string is trying to include the back-tick in
the message and can't. If the Big-3 say that the reported code is
valid (and it makes sense that it is) then we'd be hard pressed to
justify our extension as being worth the harm it causes. People
will rightly call it a bug, not a feature.

If it turns out that the consensus is that macros (or directives in
general) do not get expanded in strings, then we can still include
it as an extension, but by default leave that extension OFF. Then
have a -g flag to turn it ON if someone wants to use it. The person
that uses the extension can deal with the consequences. In other
words, leave it out of the "2x" extension set, add a new generation
code for this feature, and by default leave that flag off.

And by the way, how does C/C++ deal with this issue?
- --
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

iD8DBQFH2WP0rPt1Sc2b3ikRAh/WAJ0XsS+0oa7dFh3e/nKWuE0eUZ711wCgkylS
FYM8LfvdUf5iXW08S+SbEds=
=APlJ
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Macro expansions, strings and back tick

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

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

> The Icarus Verilog code explicitly allows it, but I can't for the
> life of me remember my reasoning for that, and I didn't write any
> justification down. This may be a case where we come up with a
> simple test and throw it at the Big 3 and see what happens. If
> we are the only ones that handles it, and it causes problems in
> off-the-shelf Verilog code, then we may have to abandon the whole
> idea and simply ignore macros/directives within strings.
> 
> If we still want the capability as an extension, we can define
> a syntax that forces expansion in strings without getting in the
> way of vendor code. Perhaps a double-` within strings? We'll
> need to be smart about it.
> 
> The first step is to run it past the Big-3 and see what happens.

In general I like the idea of macros expanding in strings. It allows you
to easily display an expanded macro for either documentation or debugging.
Yes you could look at the output of the preprocessor for the same
information. It's just not as convenient!

Since it is already there I think it should be kept, but we should add a
-g<flag> that can be used to disabled this feature. I also think we should
enhance the macro expansion to know when it is in a string constant and do
the right thing with " and \ so we can display the macro exactly as it
would appear in the output (don't forget backslash at the end of line is
special).

If we go this route it is immaterial what others do, it is an enhancement
that can easily be disabled. Thoughts?

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] Macro expansions, strings and back tick

[Uwe B. <bo...@el...>]

>>>>> "Larry" == Larry Doolittle <ldo...@re...> writes:

    Larry> On Wed, Mar 12, 2008 at 09:54:12AM -0700, Cary R. wrote:
    >> --- Uwe Bonnes <bo...@el...> wrote: >
    >> wire [2:0] CL = (mode_reg[6:4] == 3'b110) ? 2.5 : mode_reg[6:4]; Can
    >> some one explain why you would write code like this? To me this looks
    >> like it is written by a person who has no idea how Verilog converts a
    >> real value to an integer value.

    Larry> I won't comment on your value judgement.  To me this smells of
    Larry> someone hacking previously working SDRAM code, and trying to use
    Larry> it for DDR chips.  Now there has to be provision for CAS
    Larry> latencies of half-cycles.

Actually the micron people later used (2*CL+ 1) in all cases. So it really
looks hackish and I wonder what tools are needed to understand the hacks.

    >> > tb.v:483: error: bit/part select dq_in_pos[23:16] is out of range.
    >> 
    >> I have not looked at this, but I'm assuming this should just set the
    >> bits to 'bx. Once this is confirmed as an error you should add a
    >> report for it so it doesn't get lost.

    Larry> If you want to change it from an error to a warning, that's OK.
    Larry> Just don't set the extra bits to 'bx silently.  I hit the error
    Larry> message "all the time", and it's really helpful to find coding
    Larry> errors early in the process.

To actually run vendor/thrird party code, it helps if those misjaps in the
code only cause warning and not error. 

Bye

-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Iverilog-devel] Macro expansions, strings and back tick

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

--- Larry Doolittle <ldo...@re...> wrote:

> On Wed, Mar 12, 2008 at 09:54:12AM -0700, Cary R. wrote:
> > --- Uwe Bonnes <bo...@el...> wrote:
> > > wire [2:0] CL = (mode_reg[6:4] == 3'b110) ? 2.5 : mode_reg[6:4];
> > Can some one explain why you would write code like this? To me this
> looks
> > like it is written by a person who has no idea how Verilog converts a
> real
> > value to an integer value.
> 
> I won't comment on your value judgement.  To me this smells of
> someone hacking previously working SDRAM code, and trying to use
> it for DDR chips.  Now there has to be provision for CAS latencies
> of half-cycles.

OK that makes a little more sense. My only interaction with memory is
plugging it into a computer or a bank of D-FFs holding some control bits.
I still contend using 2.5 is a poor choice (it will always be rounded to
3), but in this context it probably makes sense. My rant is because of
stuff like this code from the altera_mf_6_1.v files provided in a recent
bug report:

// find the number of VCO clock cycles to wait initially before the first
// rising edge of the output clock
function integer counter_initial;
  input tap_phase, m, n;
  integer tap_phase, m, n, phase;
  begin
    if (tap_phase < 0) tap_phase = 0 - tap_phase;
    // adding 0.5 for rounding correction (required in order to round
    // to the nearest integer instead of truncating)
    phase = ((tap_phase * m) / (360 * n)) + 0.5;
    counter_initial = phase;
  end
endfunction

Which leave little doubt that the author of this code does not know the
real value rounding rules!

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] Macro expansions, strings and back tick

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

On Wed, Mar 12, 2008 at 09:54:12AM -0700, Cary R. wrote:
> --- Uwe Bonnes <bo...@el...> wrote:
> > wire [2:0] CL = (mode_reg[6:4] == 3'b110) ? 2.5 : mode_reg[6:4];
> Can some one explain why you would write code like this? To me this looks
> like it is written by a person who has no idea how Verilog converts a real
> value to an integer value.

I won't comment on your value judgement.  To me this smells of
someone hacking previously working SDRAM code, and trying to use
it for DDR chips.  Now there has to be provision for CAS latencies
of half-cycles.

> > tb.v:483: error: bit/part select dq_in_pos[23:16] is out of range.
> 
> I have not looked at this, but I'm assuming this should just set the bits
> to 'bx. Once this is confirmed as an error you should add a report for it
> so it doesn't get lost.

If you want to change it from an error to a warning, that's OK.
Just don't set the extra bits to 'bx silently.  I hit the error
message "all the time", and it's really helpful to find coding
errors early in the process.

   - Larry

Re: [Iverilog-devel] Macro expansions, strings and back tick

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

--- Uwe Bonnes <bo...@el...> wrote:

> wire [2:0] CL = (mode_reg[6:4] == 3'b110) ? 2.5 : mode_reg[6:4];

I have fixed this for procedural assignments I have not had time to get
the continuous assignments fixed. But this brings up a bit of a rant!

Can some one explain why you would write code like this? To me this looks
like it is written by a person who has no idea how Verilog converts a real
value to an integer value. Verilog is not C/C++!! It rounds to the nearest
integer with a half way value going away from zero (think lround()). So
all these *.5 constants or adding 0.5 to a value puts the final value
right at the inflection point! Why not write this as 3? It's fewer
characters and more obvious as to what is really going to happen.

The problem with 2.5 is I say it should be integer three, but what if it
was represented as 2.49999999999? Then you get 2 instead of the 3 that you
are expecting. I realized this all depends on how the real numbers are
implemented, but in general for a truncating conversion you want to add
0.5 to minimize the chance of error. In a rounding system this is already
taken care of so you want to leave things alone. Yes the standard allows
types to be converted as needed, but why do it when it is not needed?
There is an overhead to the conversion.

I have seen this in a number of pieces of code lately from I believe
different vendors so I have to assume they are doing this for a reason,
but the only reason I have been able to figure out so far is that they
don't know what they are doing! Could someone please enlighten me.

> tb.v:483: error: bit/part select dq_in_pos[23:16] is out of range.

I have not looked at this, but I'm assuming this should just set the bits
to 'bx. Once this is confirmed as an error you should add a report for it
so it doesn't get lost.

Cary


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

Re: [Iverilog-devel] Macro expansions, strings and back tick

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

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

Michael Witten wrote:
> Here is the offending line:
> 	$display ("At time %t ERROR: Memory overflow.\n  Write to Address %h  
> with Data %h will be lost.\n  You must increase the part_mem_bits  
> parameter or `define FULL_MEM.", $time, addr, data);
> 
> As you can see, these guys think that string expansion won't occur.
> 
> Possible solution: If a macro is not defined, we leave it unexpanded  
> when
> found in a string. This won't solve all the problems, but I bet it will
> solve most.

Well now it's starting to get hackish. It looks like the other
tools are not expanding macros within strings. I can imagine the
wording of the standard saying that macros just are not expanded
within strings by saying that a macro expansion within a string
is tantamount to breaking up that token.

The Icarus Verilog code explicitly allows it, but I can't for the
life of me remember my reasoning for that, and I didn't write any
justification down. This may be a case where we come up with a
simple test and throw it at the Big 3 and see what happens. If
we are the only ones that handles it, and it causes problems in
off-the-shelf Verilog code, then we may have to abandon the whole
idea and simply ignore macros/directives within strings.

If we still want the capability as an extension, we can define
a syntax that forces expansion in strings without getting in the
way of vendor code. Perhaps a double-` within strings? We'll
need to be smart about it.

The first step is to run it past the Big-3 and see what happens.

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

iD8DBQFH1/MdrPt1Sc2b3ikRAhJuAJsHQrgjxDHPGl1LIdPydkEL68urswCgljJU
D5HrSTrfIcAk8QpKJxFZNy4=
=evXJ
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Macro expansions, strings and back tick

[Michael W. <mfw...@MI...>]

On 11 Mar 2008, at 9:12 PM, Stephen Williams wrote:
> an interesting problem: what if a macro contains a string? To wit:
>
>  `define foo "also"
>
>  "This is `foo a string."
>
> A macro substitution will break the rules in this case, even though
> there is nothing wrong with a macro containing strings.

It seems to me that there is nothing wrong with someone breaking his  
own code.
You can have a macro expand to a lot of stuff that is syntactically  
wrong.


On 12 Mar 2008, at 6:24 AM, Uwe Bonnes wrote:
> ddr.v:332: error: macro names cannot be directive keywords  
> ('`define'); replaced with nothing.


Here is the offending line:
	$display ("At time %t ERROR: Memory overflow.\n  Write to Address %h  
with Data %h will be lost.\n  You must increase the part_mem_bits  
parameter or `define FULL_MEM.", $time, addr, data);

As you can see, these guys think that string expansion won't occur.

Possible solution: If a macro is not defined, we leave it unexpanded  
when
found in a string. This won't solve all the problems, but I bet it will
solve most.

Re: [Iverilog-devel] Macro expansions, strings and back tick

[Uwe B. <bo...@el...>]

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

    Cary> --- Stephen Williams <st...@ic...> wrote:
    >> The 2005 standard does not say anything different, but there is an
    >> interesting problem: what if a macro contains a string? To wit:
    >> 
    >> `define foo "also"
    >> 
    >> "This is `foo a string."
    >> 
    >> A macro substitution will break the rules in this case, even though
    >> there is nothing wrong with a macro containing strings.
    >> 
    >> But then again, I imagine being ably to "stringify" the contents of a
    >> macro can be highly valuable. Hmm... tough choice.
    >> 
    >> How 'bout we take the 1364-200x at its word and allow macros that are
    >> entirely within strings, and add a means to escape the `tic character
    >> within the string as needed.

    Cary> If we wanted to get real fancy we could stringify the macro
    Cary> expansion when the lexor is in a string context (replace " with
    Cary> \"). The big question is do we also want to replace \ with \\?
    Cary> Doing this would give you an as defined display vs an as evaluated
    Cary> (show \n vs giving you a new line). My first thought is that we
    Cary> want to show the \n. I'll submit the \' patch shortly. We can do
    Cary> the other stuff once it is fully defined.

I stumbled about the backtick problem when trying to run the Micron DDR Ram
Verilog files found at e.g.
http://www.micron.com/products/partdetail?part=MT46V32M16P-5B
under "Verilog". 
> iverilog ddr.v   
ddr.v:332: error: macro names cannot be directive keywords ('`define'); replaced with nothing.
The testbench has more problems, which are i.m.h.o. however syntactiacal
problems on the micron side like:


: ddr_parameters.vh-`ifdef x4
: ddr_parameters.vh-    parameter ADDR_BITS        =      13; // Set this parameter to control how many Address bits are used
: ddr_parameters.vh:    parameter DQ_BITS          =       4; // Set this parameter to control how many Data bits are used
: ddr_parameters.vh-    parameter DQS_BITS         =       1; // Set this parameter to control how many DQS bits are used
: ddr_parameters.vh-    parameter DM_BITS          =       1; // Set this parameter to control how many DM bits are used
: --
: : ddr_parameters.vh-`else `ifdef x8
: ddr_parameters.vh-    parameter ADDR_BITS        =      13; // Set this parameter to control how many Address bits are used
: ddr_parameters.vh:    parameter DQ_BITS          =       8; // Set this parameter to control how many Data bits are used
: ddr_parameters.vh-    parameter DQS_BITS         =       1; // Set this parameter to control how many DQS bits are used
: ddr_parameters.vh-    parameter DM_BITS          =       1; // Set this parameter to control how many DM bits are used
: --
: ddr_parameters.vh-`else `define x16
: ddr_parameters.vh-    parameter ADDR_BITS        =      13; // Set this parameter to control how many Address bits are used
: ddr_parameters.vh:    parameter DQ_BITS          =      16; // Set this parameter to control how many Data bits are used
: ddr_parameters.vh-    parameter DQS_BITS         =       2; // Set this parameter to control how many DQS bits are used
: ddr_parameters.vh-    parameter DM_BITS          =       2; // Set this parameter to control how many DM bits are used
...
: $display ("At time %t ERROR: Memory overflow.\n  Write to Address %h with Data %h will be lost.\n  You must increase
:    332  the part_mem_bits parameter or `define FULL_MEM.", $time, addr, data);
..
:     reg         [DQ_BITS-1 : 0] dq_in_pos   ;
..
:     reg         [DQ_BITS-1 : 0] dq_in_pos   ;
:                 0: dq_in_pos[ 7: 0] <= dq_in[ 7: 0];
:                 1: dq_in_pos[15: 8] <= dq_in[15: 8];
:                 2: dq_in_pos[23:16] <= dq_in[23:16];
:                 3: dq_in_pos[31:24] <= dq_in[31:24];
:                 4: dq_in_pos[39:32] <= dq_in[39:32];
:                 5: dq_in_pos[47:40] <= dq_in[47:40];
:                 6: dq_in_pos[55:48] <= dq_in[55:48];
:                 7: dq_in_pos[63:56] <= dq_in[63:56];
:                 4: dq_in_pos[39:32] <= dq_in[39:32];
:                 5: dq_in_pos[47:40] <= dq_in[47:40];
:                 6: dq_in_pos[55:48] <= dq_in[55:48];
:                 7: dq_in_pos[63:56] <= dq_in[63:56];
 
where non existant bits are selected.
or:
:    wire                [2 : 0] CL       = (mode_reg[6:4] == 3'b110) ? 2.5 : mode_reg[6:4]; //CAS Latency

This all results results in (which todays git verilog)
> iverilog tb.v ddr.v
ddr.v:332: error: macro names cannot be directive keywords ('`define'); replaced with nothing.
tb.v:483: error: bit/part select dq_in_pos[23:16] is out of range.
tb.v:484: error: bit/part select dq_in_pos[31:24] is out of range.
tb.v:485: error: bit/part select dq_in_pos[39:32] is out of range.
tb.v:486: error: bit/part select dq_in_pos[47:40] is out of range.
tb.v:487: error: bit/part select dq_in_pos[55:48] is out of range.
tb.v:488: error: bit/part select dq_in_pos[63:56] is out of range.
tb.v:494: error: bit/part select dq_in_neg[23:16] is out of range.
tb.v:495: error: bit/part select dq_in_neg[31:24] is out of range.
tb.v:496: error: bit/part select dq_in_pos[39:32] is out of range.
tb.v:497: error: bit/part select dq_in_pos[47:40] is out of range.
tb.v:498: error: bit/part select dq_in_pos[55:48] is out of range.
tb.v:499: error: bit/part select dq_in_pos[63:56] is out of range.
tb.v:105: error: True and False clauses of ternary expression have different types.
tb.v:105:      : True clause is real, false clause is logic.
tb.v:105: error: Unable to elaborate r-value: ((mode_reg['sb0110:'sb0100])==(3'b110))?(2.5):(mode_reg['sb0110:'sb0100])
14 error(s) during elaboration.

I think only the first issue is half way on the icarus side.

Thanks for
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Iverilog-devel] Macro expansions, strings and back tick

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

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

> The 2005 standard does not say anything different, but there is
> an interesting problem: what if a macro contains a string? To wit:
> 
>   `define foo "also"
> 
>   "This is `foo a string."
> 
> A macro substitution will break the rules in this case, even though
> there is nothing wrong with a macro containing strings.
> 
> But then again, I imagine being ably to "stringify" the contents
> of a macro can be highly valuable. Hmm... tough choice.
> 
> How 'bout we take the 1364-200x at its word and allow macros that
> are entirely within strings, and add a means to escape the `tic
> character within the string as needed.

If we wanted to get real fancy we could stringify the macro expansion when
the lexor is in a string context (replace " with \"). The big question is
do we also want to replace \ with \\? Doing this would give you an as
defined display vs an as evaluated (show \n vs giving you a new line). My
first thought is that we want to show the \n. I'll submit the \' patch
shortly. We can do the other stuff once it is fully defined.

Cary


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

Re: [Iverilog-devel] Macro expansions, strings and back tick

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

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

Cary R. wrote:
> --- Stephen Williams <st...@ic...> wrote:
> 
>> Hmm... I think the Icarus Verilog behavior here is actually wrong.
>> A quoted string would be a token and macros can't be within tokens.
>> The problem is that the preprocessor needs to know about strings
>> if this is to be fixed.
> 
> The preprocessor does know about strings and it has explicit rules and
> comments saying that macros are expanded! It's as trivial to remove this
> functionality as it is to add \' so either way this is an easy fix. In
> 1364-2001 the only restriction I saw regarding strings and macros is that
> macros could not extend across a string boundary (have the starting or
> closing "). No mention that they could not be in a string. Does 2005 say
> something different?

The 2005 standard does not say anything different, but there is
an interesting problem: what if a macro contains a string? To wit:

  `define foo "also"

  "This is `foo a string."

A macro substitution will break the rules in this case, even though
there is nothing wrong with a macro containing strings.

But then again, I imagine being ably to "stringify" the contents
of a macro can be highly valuable. Hmm... tough choice.

How 'bout we take the 1364-200x at its word and allow macros that
are entirely within strings, and add a means to escape the `tic
character within the string as needed.
- --
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

iD8DBQFH1y3hrPt1Sc2b3ikRAslTAKDsE69OVDHtx/wdFK8G5kQ6mL2G4ACfZdUV
+ML5G3t1pGaYvcaeBffjPkw=
=GQfx
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Macro expansions, strings and back tick

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

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

> Hmm... I think the Icarus Verilog behavior here is actually wrong.
> A quoted string would be a token and macros can't be within tokens.
> The problem is that the preprocessor needs to know about strings
> if this is to be fixed.

The preprocessor does know about strings and it has explicit rules and
comments saying that macros are expanded! It's as trivial to remove this
functionality as it is to add \' so either way this is an easy fix. In
1364-2001 the only restriction I saw regarding strings and macros is that
macros could not extend across a string boundary (have the starting or
closing "). No mention that they could not be in a string. Does 2005 say
something different?

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] Macro expansions, strings and back tick

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

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

Cary R. wrote:
> pr1912112 brings up an interesting problem. Icarus is expanding macros in
> a string context, which after looking at the standard appears to not be
> prohibited (`define and string sections). The problem is how do you get a
> ` into a string if you want to have something other than white space after
> it? For example "I want to quote `this`" does not work since it is trying
> to expand "this" as a macro. Adding a back slash ("\'this\'") would be my
> first thought, but the standard does not mention this as an alternative.
> FYI neither gplcver of veriwell expand macros in strings.
> 
> Is this something that is supported by other tools or are we being a bit
> too clever? I do like the functionality so maybe we should just define \'
> in Icarus. I have a trivial patch that adds this if that is the direction
> we choose.

Hmm... I think the Icarus Verilog behavior here is actually wrong.
A quoted string would be a token and macros can't be within tokens.
The problem is that the preprocessor needs to know about strings
if this is to be fixed.
- --
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

iD8DBQFH1ycKrPt1Sc2b3ikRAqL4AJ9bRA/2inylnKJwCAi9aYBdbWQxPACfazZc
Qq2OlOu2xlnZebd9cNWsFdE=
=9CE8
-----END PGP SIGNATURE-----

[Iverilog-devel] Macro expansions, strings and back tick

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

pr1912112 brings up an interesting problem. Icarus is expanding macros in
a string context, which after looking at the standard appears to not be
prohibited (`define and string sections). The problem is how do you get a
` into a string if you want to have something other than white space after
it? For example "I want to quote `this`" does not work since it is trying
to expand "this" as a macro. Adding a back slash ("\'this\'") would be my
first thought, but the standard does not mention this as an alternative.
FYI neither gplcver of veriwell expand macros in strings.

Is this something that is supported by other tools or are we being a bit
too clever? I do like the functionality so maybe we should just define \'
in Icarus. I have a trivial patch that adds this if that is the direction
we choose.

Cary


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