Re: [Iverilog-devel] Generate scope change in vvp and the VPI API for development

[Iztok J. <izt...@gm...>]

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