Menu
▾
▴
iverilog-devel
|
From: <by...@nc...> - 2013-07-20 17:38:39
|
> I know this is not strictly about Icarus Verilog, but since you mentioned > it, there are some other things I would like to see in GTKWave. I will just > make a list, since I do not have time to run tests now. > > 1. to show signals inside the module scope differently then module ports > 2. to show port directions > 3. to show parameters (ModelSim exports parameters to VCD) > 4. hierarchical display of packed structures and arrays > 5. display of interfaces as both instances and ports > 6. display of SystemVerilog classes #1 and #2 have been in gtkwave in SVN for about a week. The only formats that gtkwave can read that currently support it are FST and FSDB. Existing FSDB files from VCS read fine and ports/direction are intact. For FST, I am unaware of any current simulators writing port direction info though I think CVC will be soon to add it. Note that for FST, vcd2fst can work to convert FSDB to FST (with port information intact) provided this line pops out of ./configure: EXTLOAD_CFLAGS : -DEXTLOAD_PATH=\"/pub/fsdb/bin/fsdbdebug\" -DEXTLOAD_SUFFIX=\"fsdb\" -DEXTCONV_PATH=\"/pub/fsdb/bin/fsdb2vcd\" You need to ensure those executables from an nWave install are in path as both are used during conversion. The vcd file alone from fsdb2vcd is not enough as information is missing that is provided by fsdbdebug. For accelerated (not slow via fsdbdebug) reading of FSDB files, and also without using -o (via fsdb2vcd then vcd2fst) if the above EXTLOAD stuff is satisfied, you need these libraries and the accompanying c++ headers: FSDB_CFLAGS : -DFSDB_NSYS_IS_PRESENT -DFSDB_IS_PRESENT -I/pub/FsdbReader FSDB_LDADD : /pub/FsdbReader/libnsys.so /pub/FsdbReader/libnffr.so ...then FSDB looks like any other available filetype. > How much is actually not implemented in Icarus and how much is not > supported by waveform file standards. Is there actually a free waveform > format supporting all this? VCD doesn't support any of the #1-#6 above. What I would need to see is an FSDB file that contains examples of all that stuff so I can (1) see what Verdi does, and (2) see how it is stored internally in the file. I say FSDB because VCS (or whatever) has an established format for doing this already that could provide good guidelines to free solutions. As far as parameters go (#3), isn't that an Icarus dumper thing? For #4, there is hierarchical structure stuff that Bluespec writes to VCD as well as the save files, but I don't remember how it works, simply that it does. > The Verilator teem is also behind here, they only support VCD files, but > they have made some progress supporting SystemVerilog interfaces, so I > could check how are those displayed in GTKWave. > > Regards, > Iztok Jeras I'm not a verification guy currently, so I'm completely ignorant of SV interfaces. Again, I'd need to see an FSDB file that has all this stuff and be pointed to it. -Tony |
|
From: <by...@nc...> - 2013-07-23 17:44:22
|
OK, I grabbed those .sv examples and compiled/ran them in VCS to see how they're stored. datatypes mapped back to existing Verilog ones. Nothing says that Icarus has to do that so we can invent aliases for SV if we want. t_enumerate only stored the values, not the enum names. t_string stored nothing: it was an FSDB file with zero variables. Note that FST can dump strings so this might be a limitation in having variable length records in FSDB. I don't know. For all the array/struct ones, those dumped fine and I'll look at how those can be dumped--mainly by looking at the corresponding API in the FsdbWriter. It's a straightforward iterative/recursive traversal to dump those datatypes like you'd expect. I'd be able to fold them into fstHierType as that's how FSDB does it via fsdbTreeCBType which functions in a similar capacity. The elements of arrays/structs/etc dump as normal vars except they're surrounded by the appropriate begin and end markers to set up the datatype's parameters. So at least from the FST/gtkwave side, SV dumping seems doable. -Tony |
|
From: Jared C. <jar...@gm...> - 2013-07-23 19:00:46
|
On Tue, Jul 23, 2013 at 10:44 AM, <by...@nc...> wrote: > For all the array/struct ones, those dumped fine and I'll look at how those can be dumped--mainly by looking at the corresponding API in the FsdbWriter. It's a straightforward iterative/recursive traversal to dump those datatypes like you'd expect. I'd be able to fold them into fstHierType as that's how FSDB does it via fsdbTreeCBType which functions in a similar capacity. The elements of arrays/structs/etc dump as normal vars except they're surrounded by the appropriate begin and end markers to set up the datatype's parameters. > When looking at this, it'd be nice to look at unpacked net arrays and var arrays (i.e. memories), possibly multi-dimensional. I didn't see those included in the examples that Iztok put up (I may have missed them). Might be slightly different than struct arrays. I'm dealing now with a design that makes extensive use of net arrays. Rather then going through and manually looping through each array and dumping each element as an individual net, I've been planning to go in and implement a $dumpmems parallel and similar to $dumpvars that creates a new scope for each array and puts each element in there. My plan is to just hack something up for myself so my dump files are a little cleaner (and I don't need to manually put in dozens of for loops), then if there is interest I could clean it up and put in a patch. I know previous discussion has decided that $dumpvars should not dump arrays, but I figured it might be nice to have a $dumpmems or something to do so, probably with a little more control so things don't get out of hand. This is similar to one way that vcs does it, they have a $vcdplusmemon function that turns on dumping of memories, it takes a scope, or a specific array and list of dimension bounds to dump. The fsdb dumper takes in an extra argument that indicates that arrays should be included (i.e. "+mda"), but since Icarus uses the standard $dumpvars function names, this doesn't seem like an option. Of course dumping multi-dimensional arrays isn't going to be nice unless/until support for them is extended into vvp and they aren't flattened during code generation. When I took a quick look it seemed like, at least for net arrays, the basic implementation of arrays wouldn't need to change and it could just be a matter of including the information about the dimensions for use by the vpi/dumping routines, which translate between flat indices and multi-dimensional sets of indices (but I didn't put much thought into it). Jared |
|
From: Cary R. <cy...@ya...> - 2013-07-23 21:09:25
|
Hi Jared, Some thoughts: $dumpvars() should probably not dump an array by default for a scope, but I see no reason why it could not be enhanced to dump an array if it is explicitly given. We may want to use the same philosophy for any other large objects. Actually I thought we had something to do that already in Icarus where the code automatically iterated over the array elements. Having a real array type to dump would be even better since you could distinguish between dumping an entire array or individually dumping the elements of an array (e.g. array[0], array[1] could be the entire array or just the first two elements). I'm assuming an array would have some kind of pseudo scope in GTKWave where the array would show something like the following: array -> 0 -> 1 How to correctly handle dynamic objects, classes, etc. need more thought. Unfortunately Icarus development at time suffers from only considering what is needed for correct simulation. This limits what can be done in the runtime without a significant rewrite of the base functionality. A more fundamental issue with the flattened multi-dimensional arrays is that variable selects that should be out of range actually access elements in other dimensions. Pushing the real dimension information that you mentioned may be enough to fix this problem if smarter (multi-dimension array aware) access methods are used for reading or writing the array elements. Cary ________________________________ From: Jared Casper <jar...@gm...> To: Discussions concerning Icarus Verilog development <ive...@li...> Sent: Tuesday, July 23, 2013 12:00 PM Subject: Re: [Iverilog-devel] Generate scope change in vvp and the VPI API for development On Tue, Jul 23, 2013 at 10:44 AM, <by...@nc...> wrote: > For all the array/struct ones, those dumped fine and I'll look at how those can be dumped--mainly by looking at the corresponding API in the FsdbWriter. It's a straightforward iterative/recursive traversal to dump those datatypes like you'd expect. I'd be able to fold them into fstHierType as that's how FSDB does it via fsdbTreeCBType which functions in a similar capacity. The elements of arrays/structs/etc dump as normal vars except they're surrounded by the appropriate begin and end markers to set up the datatype's parameters. > When looking at this, it'd be nice to look at unpacked net arrays and var arrays (i.e. memories), possibly multi-dimensional. I didn't see those included in the examples that Iztok put up (I may have missed them). Might be slightly different than struct arrays. I'm dealing now with a design that makes extensive use of net arrays. Rather then going through and manually looping through each array and dumping each element as an individual net, I've been planning to go in and implement a $dumpmems parallel and similar to $dumpvars that creates a new scope for each array and puts each element in there. My plan is to just hack something up for myself so my dump files are a little cleaner (and I don't need to manually put in dozens of for loops), then if there is interest I could clean it up and put in a patch. I know previous discussion has decided that $dumpvars should not dump arrays, but I figured it might be nice to have a $dumpmems or something to do so, probably with a little more control so things don't get out of hand. This is similar to one way that vcs does it, they have a $vcdplusmemon function that turns on dumping of memories, it takes a scope, or a specific array and list of dimension bounds to dump. The fsdb dumper takes in an extra argument that indicates that arrays should be included (i.e. "+mda"), but since Icarus uses the standard $dumpvars function names, this doesn't seem like an option. Of course dumping multi-dimensional arrays isn't going to be nice unless/until support for them is extended into vvp and they aren't flattened during code generation. When I took a quick look it seemed like, at least for net arrays, the basic implementation of arrays wouldn't need to change and it could just be a matter of including the information about the dimensions for use by the vpi/dumping routines, which translate between flat indices and multi-dimensional sets of indices (but I didn't put much thought into it). Jared ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Iverilog-devel mailing list Ive...@li... https://lists.sourceforge.net/lists/listinfo/iverilog-devel |
|
From: <by...@nc...> - 2013-07-24 19:58:00
|
[All of the adds are in SVN. Nothing is "written in stone" yet.]
I added struct and union scope types to the FST writer/reader. As far as I can tell, you don't really need arrays as the variable name conveys enough information. If I'm wrong, this is an easy add.
Note that even though it's not a part of the VCD "standard", I've also added generate, struct, and union as scope types to the VCD parsers in gtkwave and vcd2fst. fst2vcd will write out such scope types if it encounters them.
As a side note:
void fstWriterSetScope(void *ctx, enum fstScopeType scopetype,
const char *scopename, const char *scopecomp);
...I don't see FSDB supporting it as an element in their "tree types", but for the union/struct, if the simulator fills in the appropriate struct/union type for scopecomp, this will be viewable in gtkwave as well. That is if you have struct t_color and it is called "a", you'll see "a (t_color)" in the SST.
I added struct and union as scope rather than tree types (as FSDB does) as they do generate a level of hierarchy when one descends into the instantiation. It doesn't make a whole lot of sense to me having to define a new tree type when it's more-or-less similar in function to how a scope functions.
I'll add more SV types to FST and gtkwave as I experiment more. I don't use SV on my day job so I'm mostly looking at SV documentation and am massaging the example .sv files I was provided yesterday to see what comes out of VCS+FSDB.
I'll likely hold off on the tarball release of gtkwave for a while longer than usual to add more of these SV features, but it looks like a good excuse finally to bump up the version number up to the 3.4 series.
-Tony
enum fstScopeType {
FST_ST_VCD_MIN = 0,
FST_ST_VCD_MODULE = 0,
FST_ST_VCD_TASK = 1,
FST_ST_VCD_FUNCTION = 2,
FST_ST_VCD_BEGIN = 3,
FST_ST_VCD_FORK = 4,
FST_ST_VCD_GENERATE = 5,
FST_ST_VCD_STRUCT = 6,
FST_ST_VCD_UNION = 7,
FST_ST_VCD_MAX = 7,
FST_ST_MAX = 7,
FST_ST_VCD_SCOPE = 254,
FST_ST_VCD_UPSCOPE = 255
};
|
|
From: Jared C. <jar...@gm...> - 2013-07-24 21:54:05
|
On Wed, Jul 24, 2013 at 12:57 PM, <by...@nc...> wrote: > I added struct and union scope types to the FST writer/reader. As far as I can tell, you don't really need arrays as the variable name conveys enough information. If I'm wrong, this is an easy add. > I think that arrays don't need to be a new scope as long as gtkwave will recognize the array from the name and make it collapsible in the list of signals (which currently is not a hierarchical display, correct?). With dozens of large-ish arrays, I feel like a flat list of all the individual elements in the signal list would quickly become a huge hassle to use. (is this the distinction between a "scope" and a "tree type" in FSDB? A "scope" is a new thing in the SST, and a "tree type" is a hierarchy level in the signal list?) Without a collapsible hierarchy in the signal list, I would probably put arrays into their own scope, in which case a designation for array scopes would be nice. Jared |
|
From: Martin W. <mai...@ma...> - 2013-07-24 20:21:35
|
Jared Casper wrote: > I'm dealing now with a design that makes extensive use of net arrays. > Rather then going through and manually looping through each array and > dumping each element as an individual net, I've been planning to go in > and implement a $dumpmems parallel and similar to $dumpvars that > creates a new scope for each array and puts each element in there. My > plan is to just hack something up for myself so my dump files are a > little cleaner (and I don't need to manually put in dozens of for > loops), then if there is interest I could clean it up and put in a > patch. I know previous discussion has decided that $dumpvars should > not dump arrays, but I figured it might be nice to have a $dumpmems or > something to do so, probably with a little more control so things > don't get out of hand. This is similar to one way that vcs does it, > they have a $vcdplusmemon function that turns on dumping of memories, > it takes a scope, or a specific array and list of dimension bounds to > dump. The fsdb dumper takes in an extra argument that indicates that > arrays should be included (i.e. "+mda"), but since Icarus uses the > standard $dumpvars function names, this doesn't seem like an option. > I'm definitely interested in this - I make extensive use of net arrays. It might be worth mentioning that the default behaviour of NC-Verilog is to dump the elements of a net array when $dumpvars is called. For example, with the declaration wire [7:0] Out[0:1][0:1]; the VCD file contains $var wire 8 ! Out [0][0] $end $var wire 8 " Out [0][1] $end $var wire 8 # Out [1][0] $end $var wire 8 $ Out [1][1] $end Unfortunately this syntax confuses gtkwave! Martin |
|
From: Jared C. <jar...@gm...> - 2013-07-24 22:05:46
|
On Wed, Jul 24, 2013 at 1:21 PM, Martin Whitaker <mai...@ma...> wrote: > I'm definitely interested in this - I make extensive use of net arrays. > I'll hopefully get to it within a week or so and see how far I get... > It might be worth mentioning that the default behaviour of NC-Verilog is to > dump the elements of a net array when $dumpvars is called. For example, with > the declaration > > wire [7:0] Out[0:1][0:1]; > I definitely remember some discussion on this a while back. IIRC the decision was that including memories in $dumpvars by default it would be too easy to dump huge amount of values and slow things down to a halt (among other reasons?). Seems reasonable to me to include net arrays by default but not var arrays (i.e. memories). The standard isn't explicit as far as I can see, it just says $dumpvars should dump "all the variables". For now I'll put things into a $dumpmems but shouldn't be hard to change it later... > the VCD file contains > > $var wire 8 ! Out [0][0] $end > $var wire 8 " Out [0][1] $end > $var wire 8 # Out [1][0] $end > $var wire 8 $ Out [1][1] $end > > Unfortunately this syntax confuses gtkwave! > You might be able to get by with a sed script to escape the identifiers (i.e. "\Out[0][1]"), which gtkwave accepts. Jared |
|
From: Iztok J. <izt...@gm...> - 2013-07-25 09:22:05
|
Hi, Tony
I added 3D packed/unpacked arrays, and a packed union example.
array_unpacked_3d.sv
array_packed_3d.sv
union_packed.sv
I also committed array unpacked I forgot to commit before.
array_unpacked.sv
Some details regarding how to map SystemVerilog data types to VCD are
described in section 21.7.5 of the 1800-2012 standard.
ModelSim while displaying waveforms is using braces {} to represent arrays.
It might make sense to use structure and array literals as described in
section 5 Lexical conventions from the 1800-2012 standard. Subsection 5.10
structure and 5.11 array literals is what I meant, but the definitions for
string and signed number literals might also be useful.
As an example here is the definition of a structure:
typedef struct {int a; shortreal b;} ab;
A short literal would be:
'{0, 0.0}
A verbose literal showing the type name and element names would look like
this:
ab'{a:1, b:1.0}
Regards,
Iztok Jeras
On Tue, Jul 23, 2013 at 11:09 PM, Cary R. <cy...@ya...> wrote:
> Hi Jared,
>
> Some thoughts:
>
> $dumpvars() should probably not dump an array by default for a scope, but
> I see no reason why it could not be enhanced to dump an array if it is
> explicitly given. We may want to use the same philosophy for any other
> large objects. Actually I thought we had something to do that already in
> Icarus where the code automatically iterated over the array elements.
> Having a real array type to dump would be even better since you could
> distinguish between dumping an entire array or individually dumping the
> elements of an array (e.g. array[0], array[1] could be the entire array or
> just the first two elements). I'm assuming an array would have some kind of
> pseudo scope in GTKWave where the array would show something like the
> following:
>
> array -> 0
> -> 1
>
> How to correctly handle dynamic objects, classes, etc. need more thought.
>
> Unfortunately Icarus development at time suffers from only considering
> what is needed for correct simulation. This limits what can be done in the
> runtime without a significant rewrite of the base functionality. A more
> fundamental issue with the flattened multi-dimensional arrays is that
> variable selects that should be out of range actually access elements in
> other dimensions. Pushing the real dimension information that you mentioned
> may be enough to fix this problem if smarter (multi-dimension array aware)
> access methods are used for reading or writing the array elements.
>
> Cary
>
> ------------------------------
> *From:* Jared Casper <jar...@gm...>
> *To:* Discussions concerning Icarus Verilog development <
> ive...@li...>
> *Sent:* Tuesday, July 23, 2013 12:00 PM
>
> *Subject:* Re: [Iverilog-devel] Generate scope change in vvp and the VPI
> API for development
>
> On Tue, Jul 23, 2013 at 10:44 AM, <by...@nc...> wrote:
> > For all the array/struct ones, those dumped fine and I'll look at how
> those can be dumped--mainly by looking at the corresponding API in the
> FsdbWriter. It's a straightforward iterative/recursive traversal to dump
> those datatypes like you'd expect. I'd be able to fold them into
> fstHierType as that's how FSDB does it via fsdbTreeCBType which functions
> in a similar capacity. The elements of arrays/structs/etc dump as normal
> vars except they're surrounded by the appropriate begin and end markers to
> set up the datatype's parameters.
> >
>
> When looking at this, it'd be nice to look at unpacked net arrays and
> var arrays (i.e. memories), possibly multi-dimensional. I didn't see
> those included in the examples that Iztok put up (I may have missed
> them). Might be slightly different than struct arrays.
>
> I'm dealing now with a design that makes extensive use of net arrays.
> Rather then going through and manually looping through each array and
> dumping each element as an individual net, I've been planning to go in
> and implement a $dumpmems parallel and similar to $dumpvars that
> creates a new scope for each array and puts each element in there. My
> plan is to just hack something up for myself so my dump files are a
> little cleaner (and I don't need to manually put in dozens of for
> loops), then if there is interest I could clean it up and put in a
> patch. I know previous discussion has decided that $dumpvars should
> not dump arrays, but I figured it might be nice to have a $dumpmems or
> something to do so, probably with a little more control so things
> don't get out of hand. This is similar to one way that vcs does it,
> they have a $vcdplusmemon function that turns on dumping of memories,
> it takes a scope, or a specific array and list of dimension bounds to
> dump. The fsdb dumper takes in an extra argument that indicates that
> arrays should be included (i.e. "+mda"), but since Icarus uses the
> standard $dumpvars function names, this doesn't seem like an option.
>
> Of course dumping multi-dimensional arrays isn't going to be nice
> unless/until support for them is extended into vvp and they aren't
> flattened during code generation. When I took a quick look it seemed
> like, at least for net arrays, the basic implementation of arrays
> wouldn't need to change and it could just be a matter of including the
> information about the dimensions for use by the vpi/dumping routines,
> which translate between flat indices and multi-dimensional sets of
> indices (but I didn't put much thought into it).
>
> Jared
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
|
|
From: Iztok J. <izt...@gm...> - 2013-07-27 16:55:22
|
Hi Tony, I now added the interface example. The hierarchy is a bit more complex here. The bench part and the RTL parts are separated, and there are no SV interfaces between them, only normal signals. This is because I would like to compile this example in Verilator (it is already passing "verilator --lint-only wav_interface.sv"), and interfaces are kind of not allowed as top level module ports (I do not know what the standard has to say, but tools are reporting issues). Inside the top level RTL module 'wav_interface' there is an instance of the streaming protocol interface 'wav_interface_str'. This interface is then connected to a stream source module 'wav_interface_src' instance and a stream drain module 'wav_interface_drn' instance. The interface contains modports, which are used to specify the direction of signals if the interface is used as a module port. I wrote a source and a drain modport, but it is common to add a passive modport for bus monitors (all signals are inputs into the monitor). Till now I observed interfaces using INCISIVE (the latest) and ModelSim Altera, and I am not satisfied with them. What I would expect, is first for the interface instance being visible similarly to a module, this is done well by both tools. Next I would like to see the interfaces as module ports, including the directions specified in modports, this is not done that well by the mentioned tools. ModelSim seems to show the interface as a module instance inside the module which should have it as s port, and no related port signals are listed. INCISIVE simvision sometimes shows the interface ports properly, but it depends how you specify the simulation environment. I noticed this while playing with large projects containing UVM, so I do not have an easy explanation here. If you are going to work on this, it makes sense to first try and see how other tools handle it. I am curious to see how verilator dumps this example into a VCD file, but I am not experienced enough with verilator to do it quickly. The sources are: bench: wav_interface_tb.sv (top module: wav_interface_tb) RTL: wav_interface.sv (top module: wav_interface) Regards, Iztok Jeras |
|
From: Iztok J. <izt...@gm...> - 2013-07-27 17:37:54
|
Hi, I added a C++ bench wrapper for verilator. The example produces a VCD file, containing the interface visible only as a module. ./wav_interface.verilator.sh gtkwave wav_interface.vcd The same approach could be used by icarus when exporting to VCD. But for FST I would really like to see the interfaces also visible as a ports with directions specified by modports. I must say I am a bit impressed with Verilator support for interfaces. Regards, Iztok Jeras On Sat, Jul 27, 2013 at 6:55 PM, Iztok Jeras <izt...@gm...> wrote: > Hi Tony, > > I now added the interface example. The hierarchy is a bit more complex > here. The bench part and the RTL parts are separated, and there are no SV > interfaces between them, only normal signals. This is because I would like > to compile this example in Verilator (it is already passing "verilator > --lint-only wav_interface.sv"), and interfaces are kind of not allowed as > top level module ports (I do not know what the standard has to say, but > tools are reporting issues). Inside the top level RTL module > 'wav_interface' there is an instance of the streaming protocol interface > 'wav_interface_str'. This interface is then connected to a stream source > module 'wav_interface_src' instance and a stream drain module > 'wav_interface_drn' instance. The interface contains modports, which are > used to specify the direction of signals if the interface is used as a > module port. I wrote a source and a drain modport, but it is common to add > a passive modport for bus monitors (all signals are inputs into the > monitor). > > Till now I observed interfaces using INCISIVE (the latest) and ModelSim > Altera, and I am not satisfied with them. What I would expect, is first for > the interface instance being visible similarly to a module, this is done > well by both tools. Next I would like to see the interfaces as module > ports, including the directions specified in modports, this is not done > that well by the mentioned tools. ModelSim seems to show the interface as a > module instance inside the module which should have it as s port, and no > related port signals are listed. INCISIVE simvision sometimes shows the > interface ports properly, but it depends how you specify the simulation > environment. I noticed this while playing with large projects containing > UVM, so I do not have an easy explanation here. > > If you are going to work on this, it makes sense to first try and see how > other tools handle it. > > I am curious to see how verilator dumps this example into a VCD file, but > I am not experienced enough with verilator to do it quickly. > > The sources are: > bench: wav_interface_tb.sv (top module: wav_interface_tb) > RTL: wav_interface.sv (top module: wav_interface) > > Regards, > Iztok Jeras > |
|
From: Iztok J. <izt...@gm...> - 2013-07-23 14:31:21
|
Hi Tony, I was not able to learn much about the FSDB format, and it seems it is not supported by the tools I have available (INCISIVE, ModelSim Altera). But is you have access to an appropriate simulator, I acreated a few examples which can be used to observepacked/umpacked structures/arrays (unions are missing here). There are 2-state types in datatypes.sv, and strings in t_string.sv. An interesting feature would be to show value names for enumerated data types. https://github.com/jeras/waveform_examples What is missing are unions, interfaces, modports, dynamic arrays, queues, classes, ... I hope this helps, somehow. Regards, Iztok Jeras On Sat, Jul 20, 2013 at 7:38 PM, <by...@nc...> wrote: > > I know this is not strictly about Icarus Verilog, but since you mentioned > > it, there are some other things I would like to see in GTKWave. I will > just > > make a list, since I do not have time to run tests now. > > > > 1. to show signals inside the module scope differently then module ports > > 2. to show port directions > > 3. to show parameters (ModelSim exports parameters to VCD) > > 4. hierarchical display of packed structures and arrays > > 5. display of interfaces as both instances and ports > > 6. display of SystemVerilog classes > > #1 and #2 have been in gtkwave in SVN for about a week. The only formats > that gtkwave can read that currently support it are FST and FSDB. Existing > FSDB files from VCS read fine and ports/direction are intact. For FST, I > am unaware of any current simulators writing port direction info though I > think CVC will be soon to add it. Note that for FST, vcd2fst can work to > convert FSDB to FST (with port information intact) provided this line pops > out of ./configure: > > EXTLOAD_CFLAGS : -DEXTLOAD_PATH=\"/pub/fsdb/bin/fsdbdebug\" > -DEXTLOAD_SUFFIX=\"fsdb\" -DEXTCONV_PATH=\"/pub/fsdb/bin/fsdb2vcd\" > > You need to ensure those executables from an nWave install are in path as > both are used during conversion. The vcd file alone from fsdb2vcd is not > enough as information is missing that is provided by fsdbdebug. > > For accelerated (not slow via fsdbdebug) reading of FSDB files, and also > without using -o (via fsdb2vcd then vcd2fst) if the above EXTLOAD stuff is > satisfied, you need these libraries and the accompanying c++ headers: > > FSDB_CFLAGS : -DFSDB_NSYS_IS_PRESENT -DFSDB_IS_PRESENT > -I/pub/FsdbReader > FSDB_LDADD : /pub/FsdbReader/libnsys.so > /pub/FsdbReader/libnffr.so > > ...then FSDB looks like any other available filetype. > > > > How much is actually not implemented in Icarus and how much is not > > supported by waveform file standards. Is there actually a free waveform > > format supporting all this? > > VCD doesn't support any of the #1-#6 above. What I would need to see is > an FSDB file that contains examples of all that stuff so I can (1) see what > Verdi does, and (2) see how it is stored internally in the file. I say > FSDB because VCS (or whatever) has an established format for doing this > already that could provide good guidelines to free solutions. > > As far as parameters go (#3), isn't that an Icarus dumper thing? > > For #4, there is hierarchical structure stuff that Bluespec writes to VCD > as well as the save files, but I don't remember how it works, simply that > it does. > > > > The Verilator teem is also behind here, they only support VCD files, but > > they have made some progress supporting SystemVerilog interfaces, so I > > could check how are those displayed in GTKWave. > > > > Regards, > > Iztok Jeras > > I'm not a verification guy currently, so I'm completely ignorant of SV > interfaces. Again, I'd need to see an FSDB file that has all this stuff > and be pointed to it. > > -Tony > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X