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

[Jared C. <jar...@gm...>]

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