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 |