On Fri, 19 Jan 2007, Timothy Miller wrote: > On 1/19/07, Trevor & Jenny Williams <[EMAIL PROTECTED]> wrote: > > > I agree that Icarus Verilog could implement a special non-standard feature > > to accommodate this need. Just don't expect other tools to understand that > > the dumped memory elements all come from the same memory. > > It might be of value to get with the developers of GTKWave and Bølge > to see if they're willing to add support for a special extension to > VCD.
Probably the easiest way would be to dump similar to the "b" and "r" items, but add an array row number as an extra field. It wouldn't be hard to support such a thing. Are arrays of reals supported in Verilog? Regardless of the situation, adding array support to gtkwave wouldn't be hard, but I do wonder what a good visualization technique for arrays would be. What do other viewers do? I'm almost thinking of something like the scrollable "memory" window that RiscWatch or any other assembly language debugger uses, but what is shown would also follow the pointer time. (Then there's the issue of possibly bolting on data filters such as disassemblers for instruction caches as somebody out there would want it...) Anyway, dumping out as one long vector sounds like a mistake, given that large arrays would be difficult to find data in. Of course, sparse arrays would be out using the one long bitvector strategy. So what is the current state of Bølge? I stumbled across that project on Open Graphics a while back and did find some humor in the changelog where he was set on writing a strawman viewer in 24 hrs or less of coding time. Has he updated it since then? I'm curious how far he's come with memory consumption issues and what his strategy is/will be. (A couple of months ago I added a new VCD loader for gtkwave that re-encodes and zlib compresses the VCD in memory on the fly in order to reduce memory consumption with VCD so files of several hundred MB should load ok for most users now. That was a huge gripe with the Open Graphics people.) -Tony _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
