Menu
▾
▴
iverilog-devel
|
From: Stephen W. <st...@ic...> - 2008-05-03 16:11:58
|
-----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----- |
|
From: Cary R. <cy...@ya...> - 2008-05-03 20:44:28
|
--- 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
|
|
From: Stephen W. <st...@ic...> - 2008-05-03 21:45:51
|
-----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----- |
|
From: Stephen W. <st...@ic...> - 2008-05-03 21:59:04
|
-----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----- |
|
From: al d. <ad...@fr...> - 2008-05-03 17:08:22
|
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 |
|
From: Stephen W. <st...@ic...> - 2008-05-03 21:55:02
|
-----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----- |
|
From: Cary R. <cy...@ya...> - 2008-05-04 01:27:39
|
--- 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
|
|
From: al d. <ad...@fr...> - 2008-05-04 16:48:23
|
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. |
|
From: Cary R. <cy...@ya...> - 2008-05-04 22:09:44
|
--- 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 |
|
From: Stephen W. <st...@ic...> - 2008-05-04 23:19:11
|
-----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----- |
|
From: Cary R. <cy...@ya...> - 2008-05-05 17:02:20
|
--- 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
|
|
From: al d. <ad...@fr...> - 2008-05-05 19:50:12
|
On Monday 05 May 2008, Cary R. wrote: > 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. Don't be intimidated by patents, other than to avoid looking at them. There is plenty of prior art. Most of the early work was done at universities and published, some with code. It might be a good idea to change the license to GPL-3. Gnucap is GPL-3. If you do run into patent issues, maybe someone will try to hire you, possibly as an expert witness. |
|
From: Trevor W. <pha...@gm...> - 2008-05-03 19:25:53
|
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 |
|
From: Udi F. <ic...@ud...> - 2008-05-03 23:43:01
|
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 |
|
From: Steven W. <st...@in...> - 2008-05-05 14:05:35
|
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 |
|
From: Stephen W. <st...@ic...> - 2008-05-05 15:40:31
|
-----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----- |
|
From: Steven W. <st...@in...> - 2008-05-05 16:06:55
|
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 > |
|
From: Trevor W. <pha...@gm...> - 2008-05-05 21:23:20
|
In addition to supporting interfaces, adding struct/union, enum and typedef support would also be nice. I would consider their inclusion to this task list to be a lower priority as I don't believe that their implementation is quite as simple as increment, decrement, etc. (i.e., I don't believe them to be "low hanging fruit" at this point in IV's development). Trevor On May 5, 2008, at 11:06 AM, Steven Wilson wrote: > 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 >> > > > ------------------------------------------------------------------------- > 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 |
Thanks for helping keep SourceForge clean.
X