iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] A va_math issue with $log

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

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

Cary R. wrote:
| --- On Mon, 5/5/08, Stephen Williams <st...@ic...> wrote:
|> I've added to the va_math library a $log10 that's
|> an alias to
|> the $log() function, but we may want to put a warning in
|> the code
|> that says that $log() is deprecated.
|
| Verilog-A defines ln() and log(), so that is what I did for the math
library. It matches Verilog-A with the addition of a $ to turn them into
system functions. Once these are real functions (we drop the $) then we
could add the deprecation warning, but for now it is following the
standard the best it can. It's very unfortunate that the early CS
developers didn't get these name right ;-).
|

Verilog-AMS 2.2 declares log(), Verilog-AMS 2.3draft declares
log() and $log10, and Verilog-2005 declares $log10. The conflict
w/ Verilog-2005 was discovered late and fixed in the 2.3 draft.
It's a minor issue because $log() is not standardized anywhere,
whereas $log10() is standard in -2005 and -AMS2.3. The log()
function is standard in -A and -AMS2.x.

Verilog-AMS 2.3draft has text recommending that new code use the
$FN() forms instead of the Verilog-A FN() forms, although the
"old style" forms are kept for compatibility. The min/max/abs
functions are special, and standardized only in -A and -AMS.

What a Verilog soup!-)

Current git should have support for all these Verilog-AMS builtin
math functions now. The -gverilog-ams flag turns them on. The
min/max/abs functions behave more like operators so they have
to be handled more flexibly and they are in progress.

Note also that there is a verilog-ams branch in the git that
I've merged into the master except for a few commits on the end.
I thought it might make sense to work it that way, it allows me
to push more intermediate stuff out and merge to the master at
more controlled moments. We'll see if this work-style works out.

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

iD8DBQFIH0R8rPt1Sc2b3ikRAvQGAKDNkGKT5SErBlkhksi2bzjwbK/bJACgqHKa
fez9rZEOz67VGP4y9ysJr5g=
=fLZa
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Nifty projects

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

--- On Sun, 5/4/08, al davis <ad...@fr...> wrote:
  
> Really ...  it does make sense, in a different way.  Icarus
> 
> should implement relaxation based "timing"
> simulation.  Perhaps 
> this is what you mean by "basic analog modeling
> natively".  
> There are lots of papers on this from the 80's.  It
> tends to be 
> faster than full analog (Spice-like) simulation for some
> kinds 
> of circuits, but only works for digital-like circuits.  It
> does 
> a good job at analog models of digital devices like buffers
> and 
> gates.  It doesn't work for real analog circuits like
> op-amps.  
> To find out more look for authors Resve Saleh, Jacob White,
> 
> Richard Newton.


Mixed-Mode Simulation and Analog Multilevel Simulation covers two of the three. It has been over a decade since I last looked at this so I need to find some time for review. I would also expect that the patents have expired on most of the early work.

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] A va_math issue with $log

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

--- On Mon, 5/5/08, Stephen Williams <st...@ic...> wrote:

> In turns out that Verilog-2005 and Verilog-AMS define a $ln
> function
> and a $log10 function, where the va_math module defines a
> $log
> function. Oops! The reason it should be $log10 is that the
> C log()
> function is the natural log (like $ln) and so $log() is
> confusing.
> 
> I've added to the va_math library a $log10 that's
> an alias to
> the $log() function, but we may want to put a warning in
> the code
> that says that $log() is deprecated.

Verilog-A defines ln() and log(), so that is what I did for the math library. It matches Verilog-A with the addition of a $ to turn them into system functions. Once these are real functions (we drop the $) then we could add the deprecation warning, but for now it is following the standard the best it can. It's very unfortunate that the early CS developers didn't get these name right ;-).

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] Nifty [system verilog] projects

[Steven W. <st...@in...>]

Think of Interfaces as a bus that can have tasks included.  You may 
define alternate versions of the bus (think master and slave 
descriptions) allowing source and sink of the bus. You can define tasks 
within the interface description that allow it to be an active part of 
the simulation. 

So in one sense it is a very power short-hand method of describing a 
design.  I can define a bus connection source and sink in a define file, 
then include same in the modules that are using it and just connect them 
with a single interface connection between the port lists at the top of 
the design.

Steve

Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Steven Wilson wrote:
> | In the system verilog arena - I would add Interfaces to the descriptions
> | already provided.   I suspect that Interfaces is going to be a more
> | challenging effort than always_ff - so I would put it at a second tier
> | effort, but this in combo with what has already been proposed takes care
> | of most of the things synthesis compatible RTL is going to look like!
>
> I admit to not being entirely clear on how interfaces work. Maybe
> when I or any of the other developers gets a good idea how they
> work, we may better judge how they can be integrated in.
>
> I had put SystemVerilog aside for a while because it seemed to be
> getting out of control, but I get the impression it's settling
> down and there's a sense of a practical subset that may be worth
> looking at. I see for example that extended types of SystemVerilog
> are from the Cadence-style proposal that I've been following for
> the Icarus Verilog extended types, so there's already some overlap
> 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
>
> iD8DBQFIHypyrPt1Sc2b3ikRAnpcAKDm+BaS9BYe8GsHMth4u6aPpf8diQCguZMJ
> ta9Qzds8xZoX3MTTcbC3+Pk=
> =VG9K
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>   

[Iverilog-devel] A va_math issue with $log

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

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


Cary,

In turns out that Verilog-2005 and Verilog-AMS define a $ln function
and a $log10 function, where the va_math module defines a $log
function. Oops! The reason it should be $log10 is that the C log()
function is the natural log (like $ln) and so $log() is confusing.

I've added to the va_math library a $log10 that's an alias to
the $log() function, but we may want to put a warning in the code
that says that $log() is deprecated.

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

iD8DBQFIHytMrPt1Sc2b3ikRAg8nAJ9RJJatpKavtJ4PzGlaIfNPFQbAsgCgseRD
Vc097uP7MmigRTGHu7eQ6yw=
=oPNZ
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Nifty [system verilog] projects

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

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

Steven Wilson wrote:
| In the system verilog arena - I would add Interfaces to the descriptions
| already provided.   I suspect that Interfaces is going to be a more
| challenging effort than always_ff - so I would put it at a second tier
| effort, but this in combo with what has already been proposed takes care
| of most of the things synthesis compatible RTL is going to look like!

I admit to not being entirely clear on how interfaces work. Maybe
when I or any of the other developers gets a good idea how they
work, we may better judge how they can be integrated in.

I had put SystemVerilog aside for a while because it seemed to be
getting out of control, but I get the impression it's settling
down and there's a sense of a practical subset that may be worth
looking at. I see for example that extended types of SystemVerilog
are from the Cadence-style proposal that I've been following for
the Icarus Verilog extended types, so there's already some overlap
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

iD8DBQFIHypyrPt1Sc2b3ikRAnpcAKDm+BaS9BYe8GsHMth4u6aPpf8diQCguZMJ
ta9Qzds8xZoX3MTTcbC3+Pk=
=VG9K
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Nifty projects

[Steven W. <st...@in...>]

In the system verilog arena - I would add Interfaces to the descriptions 
already provided.   I suspect that Interfaces is going to be a more 
challenging effort than always_ff - so I would put it at a second tier 
effort, but this in combo with what has already been proposed takes care 
of most of the things synthesis compatible RTL is going to look like!

Steve Wilson

Re: [Iverilog-devel] Nifty projects

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

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

al davis wrote:
| As to Icarus implementing analog ..  my first impression is that
| if you think all you need to do is re-implement Spice, you are
| grossly underestimating the project.

| [...]

| If you look at so-called mixed-signal simulators you will see 3
| approaches ...
|
| 1. Big A, little d, single kernel .. the gnucap approach, also
| used by commercial simulators such as those from Berkeley
| Design Automation.  Using Icarus as a model compiler is still
| this approach.  Ultimately, this should replace purely analog
| simulation in professional tools.

And I think the way to handle this is exactly to have a code
generator for Icarus Verilog that generates a simulation (or a
model) for gnucap to run.

| 2. Big D, little a, single kernel  .. the approach proposed by
| Resve Saleh and others, sometimes used by the reduced accuracy
| simulators.  This is what I think you are leading to that
| Icarus should do.  If so, I agree.  Ultimately, this should
| replace purely digital simulation in professional tools.

This is the sort of think I would like to eventually build into
the vvp run-time. It would be nice for the digital people to get
a better picture of what happens on the edges of their design,
and blending some analog support into the Verilog simulator is
a light-weight way to handle it.

BTW, Verilog-AMS expects that an AMS simulator handles multiple
"kernels", although I think there is a jargon issue here. In the
AMS LRM, a "kernel" is a simulated analog circuit. Analog circuits
that are completely separated by discrete logic are called distinct
and are called "kernels" but they may use a single kernel engine.
Or many kernel engines. Or many threads....

| 3. "glued" .. an analog and digital simulator talk to each
| other.  That's the old days.  Today, we should glue a #1 and a
| #2 together.  We can do this with gnucap and icarus-vvp
| communicating with each other.

This can conceivably support multiple-discipline designs by
giving the engineering team both ends of the Da to dA spectrum
in an integrated set of tools. For example, an entire subset,
including some of the digital aspects, can be farmed off to
gnucap this way, and yet Icarus Verilog has enough analog smarts
to interface intelligently with an externally simulated sub-design.

But this may be getting ahead of ourselves.

I would like us to get #1 going as a way to motivate the analog
language elements parsed and elaborated down to the code generator.
Then there is that basis for working on the vvp run time needed
to support #2 and ultimately #3.


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

iD8DBQFIHkRyrPt1Sc2b3ikRAsu1AKDkicRh6k8mPUBPSayV0CRjKsFReACg3qaW
r2pX94UuH9OIl0+LKgzsPfs=
=3yyb
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Nifty projects

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

--- On Sun, 5/4/08, al davis <ad...@fr...> wrote:

> Now that somebody wants to use it, I have an incentive.  I
> will 
> put something on the gnucap wiki http://wiki.gnucap.org and
> let you know.

Thanks.

> 2. Big D, little a, single kernel  .. the approach proposed
> by 
> Resve Saleh and others, sometimes used by the reduced
> accuracy 
> simulators.  This is what I think you are leading to that 
> Icarus should do.  If so, I agree.  Ultimately, this should
> 
> replace purely digital simulation in professional tools.

Yep, Big D, little a, is what I'm thinking about. I want to have a realistic analog model for complex analog functionality that a digital system can control/interact with. I already have access to a complete SPICE/Verilog-A environment so adding this to Icarus is not high on my priority list.

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] Nifty projects

[al d. <ad...@fr...>]

On Saturday 03 May 2008, Cary R. wrote:
> I have been planning to work on this for you at some point
> (in a few months/later this year). If Steve gets to it first
> that's also fine. Right now I'm focusing on cleaning up my
> personal bug list and I need to finish implementing constant
> functions and I want to implement one of the feature
> requests. Something that would help either one of use is a
> pointer to any documentation and source code that would help
> us to implement this. I remember you sending me a link to one
> of the files, but anything you can do to make our job easier
> would be appreciated.

Now that somebody wants to use it, I have an incentive.  I will 
put something on the gnucap wiki http://wiki.gnucap.org and let 
you know.

> As far as a merger that would be fine for the serious mixed
> mode simulations, but I believe Icarus will benefit from
> implementing basic analog modeling natively.

I didn't really mean to merge the projects, any more than 
cooperating, and informally agreeing which goes where.

As to Icarus implementing analog ..  my first impression is that 
if you think all you need to do is re-implement Spice, you are 
grossly underestimating the project.

Really ...  it does make sense, in a different way.  Icarus 
should implement relaxation based "timing" simulation.  Perhaps 
this is what you mean by "basic analog modeling natively".  
There are lots of papers on this from the 80's.  It tends to be 
faster than full analog (Spice-like) simulation for some kinds 
of circuits, but only works for digital-like circuits.  It does 
a good job at analog models of digital devices like buffers and 
gates.  It doesn't work for real analog circuits like op-amps.  
To find out more look for authors Resve Saleh, Jacob White, 
Richard Newton.

If you look at so-called mixed-signal simulators you will see 3 
approaches ...

1. Big A, little d, single kernel .. the gnucap approach, also 
used by commercial simulators such as those from Berkeley 
Design Automation.  Using Icarus as a model compiler is still 
this approach.  Ultimately, this should replace purely analog 
simulation in professional tools.

2. Big D, little a, single kernel  .. the approach proposed by 
Resve Saleh and others, sometimes used by the reduced accuracy 
simulators.  This is what I think you are leading to that 
Icarus should do.  If so, I agree.  Ultimately, this should 
replace purely digital simulation in professional tools.

3. "glued" .. an analog and digital simulator talk to each 
other.  That's the old days.  Today, we should glue a #1 and a 
#2 together.  We can do this with gnucap and icarus-vvp 
communicating with each other.

Each of the 3 has advantages.  The thought that jointly we can 
have all 3 is really great.

Re: [Iverilog-devel] Nifty projects

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

--- On Sat, 5/3/08, al davis <ad...@fr...> wrote:

> So, the first step to do Verilog-AMS, on the Icarus side,
> is to 
> make Icarus generate gnucap plugins.  After that works, add 
> analog capability, still with the focus on gnucap plugins.

Al,

I have been planning to work on this for you at some point (in a few months/later this year). If Steve gets to it first that's also fine. Right now I'm focusing on cleaning up my personal bug list and I need to finish implementing constant functions and I want to implement one of the feature requests. Something that would help either one of use is a pointer to any documentation and source code that would help us to implement this. I remember you sending me a link to one of the files, but anything you can do to make our job easier would be appreciated.

As far as a merger that would be fine for the serious mixed mode simulations, but I believe Icarus will benefit from implementing basic analog modeling natively.

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] Nifty projects

[Udi F. <ic...@ud...>]

On Sat, May 3, 2008 at 10:25 PM, Trevor Williams <pha...@gm...>
wrote:

> Steve et al,
>
> As a user of IV, I would be interested in seeing some of the lower
> hanging fruit of SystemVerilog be handled (i.e., increment, decrement,
> do..while, final, always_ff, always_latch, always_comb, data types,
> etc.)  These don't fit into the three categories that you suggested,
> but may be worth tackling at some point (I wouldn't think that most of
> these would be that difficult to add to the existing code structure).


I second that.

I would also like to see integration with compiled simulators like
Verilator.

So far I haven't used IV or Verilator much, but I intend to use them
massively with the next few months, and merging a fast simulator for the
synthesizable code with a full Verilog simulator for the test bench would be
great.

Udi

Re: [Iverilog-devel] Nifty projects

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

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

Cary R. wrote:
| --- On Sat, 5/3/08, Stephen Williams <st...@ic...> wrote:
|
|> I'm probably going to start on Item 1, but I'd like
|> to hear what
|> most excites people.
|
| Anything to make analog modeling better is fine with me, but having
reasonable string processing would also be handy.
|
| Could you provide more details on what functions and any limitations
you expect for the functions. For this new analog modeling are you also
planning to work on an adaptive event scheduler for the continuous
functions? That would allow us to get away from what is effectively an
analog clock to keep the functions output looking continuous.

All the functions that you implemented in va_math can be associated
with their true VAMS keywords and handled "natively" by elaboration.
They would work in any of the discrete domain that Icarus Verilog
already handles.

String data type support would be a matter of giving a way to declare
string variables, track string types of expressions, and pass strings
through nets and behavioral processes. The string support would be
what is described both in SystemVerilog and Verilog-AMS 2.3.

| I may have more comments after I have had sometime to think on this a
bit more.


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

iD8DBQFIHOAvrPt1Sc2b3ikRAqIfAJ0eAZt8JyN/wtuaYGG3Gzzh4cUO8gCgxQ8f
QpSJodmBIKi61D3JrewHqV4=
=ycga
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Nifty projects

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

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

al davis wrote:
| How about a merger between Icarus Verilog and Gnucap :-)
|
| Seriously ..   Gnucap is an interactive simulator, with analog
| and mixed-signal kernel.  Icarus Verilog is (as far as I know)
| a non-interactive compiler.
|
| Gnucap has a model compiler, that seriously needs updating, or
| maybe complete replacement.  I have been considering building
| on Icarus......
|
| So, the first step to do Verilog-AMS, on the Icarus side, is to
| make Icarus generate gnucap plugins.  After that works, add
| analog capability, still with the focus on gnucap plugins.

I'm specifically interested in this, yes. That would at the worst
give me an opportunity to get the parsing/elaboration of Verilog-A
worked out by using a code generator that generates gnucap
plugins. That would be good for you (gnucap gets a plug-in devel
tool) and for Icarus Verilog. So even if the Icarus Verilog run
time never gets analog support, there is use for the analog
syntax.

It might also be interesting for the vvp run time to farm off
handling of analog kernels to gnucap, if vvp can get back from
gnucap information about analog events that it needs to feed the
vvp scheduler. I haven't settled on whether that would be better,
or if it would be better to keep the analog kernel processing
in threads of the vvp process itself. Lots of thought yet to be
done here.

| After this, I see an opportunity for analog synthesis.  I
| started to do some work on this about 20 years ago, but didn't
| go very far.

Now this is getting pretty fancy.

| There is a gnucap developers email list:
| http://lists.gnu.org/mailman/listinfo/gnucap-devel


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

iD8DBQFIHN87rPt1Sc2b3ikRAoc+AJ9yJHQ1lRtd6Oix4i49ZvcygsvqxgCg1S5m
pmuerriAPp+SicZZ0MG5eZ8=
=in0+
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Nifty projects

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

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

Cary R. wrote:
| --- On Sat, 5/3/08, Stephen Williams <st...@ic...> wrote:
|
|> I'm probably going to start on Item 1, but I'd like
|> to hear what
|> most excites people.
|
| Anything to make analog modeling better is fine with me, but having
reasonable string processing would also be handy.
|
| Could you provide more details on what functions and any limitations
you expect for the functions. For this new analog modeling are you also
planning to work on an adaptive event scheduler for the continuous
functions? That would allow us to get away from what is effectively an
analog clock to keep the functions output looking continuous.

Well, in the long term everything that is Verilog-A (which should
roughly include all/most the capabilities of a typical SPICE) will
be blended in. That is what Verilog-A/MS is about.

I'm thinking at the moment about some of the lower hanging fruit
that can get the ball rolling.

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

iD8DBQFIHN0UrPt1Sc2b3ikRAoiqAJ4rs2M1g/TUc4yKNHUsGHQ6wezaMgCdGZrZ
zp6z3JvuyAkpOCOvMiIn9FA=
=Gbof
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Nifty projects

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

--- On Sat, 5/3/08, Stephen Williams <st...@ic...> wrote:
 
> I'm probably going to start on Item 1, but I'd like
> to hear what
> most excites people.

Anything to make analog modeling better is fine with me, but having reasonable string processing would also be handy.

Could you provide more details on what functions and any limitations you expect for the functions. For this new analog modeling are you also planning to work on an adaptive event scheduler for the continuous functions? That would allow us to get away from what is effectively an analog clock to keep the functions output looking continuous.

I may have more comments after I have had sometime to think on this a bit more.

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] Automatically creating parameters.

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

--- On Sat, 5/3/08, Stephen Williams <st...@ic...> wrote:
 
> I *think* my intent was to ignore (with a warning)
> defparams to
> non-existent parameters because there are many cases where
> this
> happens in existing code. I think this may be of some use
> if you
> have a multi-file design and you sometimes replace
> implementations.
> For example, you may be defparam-ing debugging off in a
> module,
> but you substitute a synthesized version of your module
> which
> would not have the debugging at all. It would continue to
> work
> as is, if with a warning.
> 
> Currently, the defparam is actually creating the not-found
> parameter,
> which can't possibly be right. I think the right thing
> is to
> ignore with a warning defparams to non-existent parameters.

Good because this is how I have things coded at the moment. There is still something that is making valgrind complain that I need to track down and it looks like the parameter replacement needs to be recoded to match the standard. It's not always just replace the expression with a new one. This is all intertwined with (found when working on) a patch to add parameter file/line number support.

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] Nifty projects

[Trevor W. <pha...@gm...>]

Steve et al,

As a user of IV, I would be interested in seeing some of the lower  
hanging fruit of SystemVerilog be handled (i.e., increment, decrement,  
do..while, final, always_ff, always_latch, always_comb, data types,  
etc.)  These don't fit into the three categories that you suggested,  
but may be worth tackling at some point (I wouldn't think that most of  
these would be that difficult to add to the existing code structure).

Trevor Williams



On May 3, 2008, at 11:12 AM, Stephen Williams wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> I'm looking to push further into Verilog-AMS and SystemVerilog
> for a little while and I have a couple of items I'd like to guage
> interest in.
>
> Item 1: I'd like to add all the various trancendental functions
> of Verilog-AMS at least to behavioral expressions. With the va_math
> module added in, I can implement them as implicit calls to the
> parallel function in that module, so there is no additional run-
> time support needed.
>
> Item 2: Verilog-AMS and SystemVerilog have build-in "string" and
> long types. I'd like to add these. The vvp run-time has some
> support for "long" types already, so this won't be too hard. The
> "string" type will need a little vvp work, but I've always found
> carrying strings in vvp_vector4_t objects wasteful and think it's
> potentially useful. (BTW GTKWAVE supports strings, so it might
> be a fun debugging aid to users, too.)
>
> Item 3: This is harder. I'd like to start working on the infra-
> structure for analog kernels in vvp. I think the scaffolding can
> be useful in Verilog-1364 as a way to implement [r]tran[if]
> gates, a nagging hole in baseline Verilog.
>
> I'm probably going to start on Item 1, but I'd like to hear what
> most excites people.
>
> - --
> 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
>
> iD8DBQFIHI7UrPt1Sc2b3ikRAs1rAJ9DjzVR/ffyn3Sh8buqJ9rLmrP87ACgxEN7
> 5l8Duv0KphnrGY6v2dPxCeU=
> =yJ5g
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] Nifty projects

[al d. <ad...@fr...>]

On Saturday 03 May 2008, Stephen Williams wrote:
> I'm looking to push further into Verilog-AMS and
> SystemVerilog for a little while and I have a couple of items
> I'd like to guage interest in.
>
> Item 1: I'd like to add all the various trancendental
> functions of Verilog-AMS at least to behavioral expressions.
> With the va_math module added in, I can implement them as
> implicit calls to the parallel function in that module, so
> there is no additional run- time support needed.
>
> Item 2: Verilog-AMS and SystemVerilog have build-in "string"
> and long types. I'd like to add these. The vvp run-time has
> some support for "long" types already, so this won't be too
> hard. The "string" type will need a little vvp work, but I've
> always found carrying strings in vvp_vector4_t objects
> wasteful and think it's potentially useful. (BTW GTKWAVE
> supports strings, so it might be a fun debugging aid to
> users, too.)
>
> Item 3: This is harder. I'd like to start working on the
> infra- structure for analog kernels in vvp. I think the
> scaffolding can be useful in Verilog-1364 as a way to
> implement [r]tran[if] gates, a nagging hole in baseline
> Verilog.
>
> I'm probably going to start on Item 1, but I'd like to hear
> what most excites people.

How about a merger between Icarus Verilog and Gnucap :-)

Seriously ..   Gnucap is an interactive simulator, with analog 
and mixed-signal kernel.  Icarus Verilog is (as far as I know) 
a non-interactive compiler.

Gnucap has a model compiler, that seriously needs updating, or 
maybe complete replacement.  I have been considering building 
on Icarus......

So, the first step to do Verilog-AMS, on the Icarus side, is to 
make Icarus generate gnucap plugins.  After that works, add 
analog capability, still with the focus on gnucap plugins.

After this, I see an opportunity for analog synthesis.  I 
started to do some work on this about 20 years ago, but didn't 
go very far.  

There is a gnucap developers email list:
http://lists.gnu.org/mailman/listinfo/gnucap-devel

[Iverilog-devel] Nifty projects

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

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


I'm looking to push further into Verilog-AMS and SystemVerilog
for a little while and I have a couple of items I'd like to guage
interest in.

Item 1: I'd like to add all the various trancendental functions
of Verilog-AMS at least to behavioral expressions. With the va_math
module added in, I can implement them as implicit calls to the
parallel function in that module, so there is no additional run-
time support needed.

Item 2: Verilog-AMS and SystemVerilog have build-in "string" and
long types. I'd like to add these. The vvp run-time has some
support for "long" types already, so this won't be too hard. The
"string" type will need a little vvp work, but I've always found
carrying strings in vvp_vector4_t objects wasteful and think it's
potentially useful. (BTW GTKWAVE supports strings, so it might
be a fun debugging aid to users, too.)

Item 3: This is harder. I'd like to start working on the infra-
structure for analog kernels in vvp. I think the scaffolding can
be useful in Verilog-1364 as a way to implement [r]tran[if]
gates, a nagging hole in baseline Verilog.

I'm probably going to start on Item 1, but I'd like to hear what
most excites people.

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

iD8DBQFIHI7UrPt1Sc2b3ikRAs1rAJ9DjzVR/ffyn3Sh8buqJ9rLmrP87ACgxEN7
5l8Duv0KphnrGY6v2dPxCeU=
=yJ5g
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Automatically creating parameters.

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

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

Cary R. wrote:
| It appears that the compiler automatically creates parameters when
they are overridden (defparam, etc.). It does issue a warning, but I
believe this should be an error. It makes no sense to create a parameter
that did not exist in the original definition. The standard (1364-2001
section 12.2) says that there are only two ways to create parameters: as
a module item or as a module parameter port list.
|
| So the question is should a parameter replacement of a nonexistent
parameter be an error? Doing this would more forcefully catch the
mistyping of a parameter name in a defparam or named parameter
assignment. pr498.v from the test suite show that the warning was
deliberate.

Hmm, I wonder what I was thinking when I did that. I actually went
back to pr498 in the old bug tracker to see what I was smoking, and
it's still not clear. The original problem was that the reporter
wanted an error message other then "Core dumped".

I *think* my intent was to ignore (with a warning) defparams to
non-existent parameters because there are many cases where this
happens in existing code. I think this may be of some use if you
have a multi-file design and you sometimes replace implementations.
For example, you may be defparam-ing debugging off in a module,
but you substitute a synthesized version of your module which
would not have the debugging at all. It would continue to work
as is, if with a warning.

Currently, the defparam is actually creating the not-found parameter,
which can't possibly be right. I think the right thing is to
ignore with a warning defparams to non-existent parameters.

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

iD8DBQFIHH/IrPt1Sc2b3ikRAg+fAJ9cvXsAlErMzTlNYHZQzPaVsk5rMACeOWDj
pjeFKa+AykBltkVW+rppkxg=
=6SGt
-----END PGP SIGNATURE-----

[Iverilog-devel] Automatically creating parameters.

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

It appears that the compiler automatically creates parameters when they are overridden (defparam, etc.). It does issue a warning, but I believe this should be an error. It makes no sense to create a parameter that did not exist in the original definition. The standard (1364-2001 section 12.2) says that there are only two ways to create parameters: as a module item or as a module parameter port list.

So the question is should a parameter replacement of a nonexistent parameter be an error? Doing this would more forcefully catch the mistyping of a parameter name in a defparam or named parameter assignment. pr498.v from the test suite show that the warning was deliberate.

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] new defines for native bit width and OS.

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

--- On Fri, 5/2/08, Stephen Williams <st...@ic...> wrote:

> In any case making a preprocessor macro that carries the
> information
> would be of no use to you at all, because you may run
> iverilog on
> one system and vvp on another, and they may easily have
> different
> word sizes. You need something at run-time.

With this restriction we would need to craft/recraft the tests very carefully.

> I suggest a system function. Maybe something like
> $ivl_cpu_wordsize
> that simply returns 8*sizeof(long)? That'll actually
> get you the
> information that you're after.

Yes that is exactly what I was after. I will need to check if having this information available only at runtime is enough.

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] new defines for native bit width and OS.

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

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

Cary R. wrote:
| Does it make sense to have two defines that can be used to report the
native bit width and possibly the underlying OS?
|
| I'm not certain the general user would need this, but the test suite
would benefit from having this functionality. Especially the bit width
since there  are tests that fail on 32 bit system, but pass on 64 bit
systems. They are looking explicitly at 32 bit problems. If we had this
flag we could force the check to be a 64 bit problem on 64 bit machines.
|
| Something like ICARUS_BITS and ICARUS_OS. The bits definition is
fairly straight forward, but should the OS be massaged or do we just
report the same result as uname -o? We will have a lot more results to
deal with if we don't massage the results.

If you are talking about the width of "integer" variables in
Verilog, you can use the $bits() system function to a variable
declared as an integer and get the width of that variable.

But I think you really mean the width of the underlying CPU word
width. I doubt we want to encourage people to access that information,
but I certainly see your point for the test suite.

In any case making a preprocessor macro that carries the information
would be of no use to you at all, because you may run iverilog on
one system and vvp on another, and they may easily have different
word sizes. You need something at run-time.

I suggest a system function. Maybe something like $ivl_cpu_wordsize
that simply returns 8*sizeof(long)? That'll actually get you the
information that you're after.


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

iD8DBQFIG3w8rPt1Sc2b3ikRAnwCAJ4hoi1ZsF7DavtuN0j2JPrz5RYLyQCgx/3y
YtLhvEhxw87CkPy+1zzGUDU=
=f1EY
-----END PGP SIGNATURE-----

[Iverilog-devel] new defines for native bit width and OS.

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

Does it make sense to have two defines that can be used to report the native bit width and possibly the underlying OS?

I'm not certain the general user would need this, but the test suite would benefit from having this functionality. Especially the bit width since there  are tests that fail on 32 bit system, but pass on 64 bit systems. They are looking explicitly at 32 bit problems. If we had this flag we could force the check to be a 64 bit problem on 64 bit machines.

Something like ICARUS_BITS and ICARUS_OS. The bits definition is fairly straight forward, but should the OS be massaged or do we just report the same result as uname -o? We will have a lot more results to deal with if we don't massage the results.

Cary


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