gEDA-dev: Re: Icarus verilog question

[Stephen Williams <steve-at-NOSPAMicarus_dot_com>]

Anthony J Bybell wrote:
> On Fri, 19 Jan 2007, Timothy Miller wrote:
> 
>> On 1/19/07, Trevor & Jenny Williams <trevorw@charter.net> 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?

Arrays of reals are not supported in Verilog, but *I* intend to support
them. So any array support you add should include support for reals.

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

laying out memories would be utterly useless. I can think of two ways:
Treat arrays like scopes, and allow the user to select words to display,
or simply treat array words like any other displayable item. Mostly
the issue here would be the signal browser and not the display.

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


-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."



_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev