Re: gEDA: Iverilog and GTKwave

[Anthony J Bybell <netracurse-at-NOSPAMnc_dot_rr_dot_com>]

On Fri, 22 Nov 2002, Stephen Williams wrote:

> I wonder also if there may be a problem with the atexit function,
> which the lxt dumper uses to close the file. If something is amiss
> here, you might see these sorts of difficulties.

This point is *very* important.  I've never used cygwin before (hey, if I
want to run a unixoid OS I use Linux or AIX), but if you ctrl-c or some
other thing to kill a sim run, depending on how atexit() under cygwin
works, you may be botching things.

The important thing is that the very last byte in the file is 0xb4.  If
it's not that, the LXT dumper will throw its hands up and die in defeat as
that byte is used to determine if a file's been closed out properly via
lt_close().  LXT (unlike VCD) is a database.  As such, it isn't simply
read front->back and needs to exhibit some kind of properties which ensure
that it's "correct", "finalized", or whatever you want to call it.  Let's
look at the source in lxt.c:

| if(get_byte(f_len-1)!=LT_TRLID)
|        {
|        fprintf(stderr, "LXT '%s' is truncated, exiting.\n", fname);
|        exit(255);
|        }

...this is the code firing on you.

http://linux-workshop.com/bybell/ver/wave/LXT_Explained.html has all the
gory details, but I hate to say I'm probably the only person alive who
fully understands this document so I suppose you can safely ignore it.  =)


Important Stuff (tm):
---------------------
(1) Is the lxt file closed out properly?  Look at the last byte with od or
some other program like a hex editor.  If it's 0xb4, you can probably say
with a reasonable amount of certainty that the atexit() handler was called
properly and that everything's fine.  If not, you can ask, "What
happened to kill the simulator prematurely?!?"  If you're really paranoid,
add some sort of printf() to lt_close in lxt_write.c and make sure that
that function is called!

(2) Is your lxt file >=2GB?  If so, all bets are off due to how mmap() (or
MapViewOfFile() in win32 which is what cygwin probably xlates it to)
handles extremely large files.  Within the past two days or so, there has
been some discussion on AMULET's gtkwave mailing list with respect to the
max size of lxt files...unless your file size is in the 2+GB range, you're
probably fine.  I'm no windows programmer so I have no idea what the max
size is for a memory mapped file (or if I've messed up and the code
isn't >31-bit clean...I must review it).

(3) Have you tried using the version of gtkwave at
http://linux-workshop.com/bybell/ver/wave/gtkwave9x.html ...does it
complain about truncation also?  It's a VC++ compiled binary and I
explicitly call native win32 functions as necessary.

(4) Have you tried the Linux version?  I realize you're using cygwin for a
reason, but considering that gtkwave was developed primarily under
linux/unix/osx, those are the only OSs I can say it truly works for.
e.g., I routinely debug SoC sim runs with LXT+GTKWave and by no stretch of
the imagination are those models toys.  LXT does require less space than a
corresponding VCD file, but it still does require a lot of PTEs/TLB
entries if the LXT file is huge.  If you run out of swap, the result is
indeterminate.  Make sure you have swap file space turned *way* up in your
control panel.

Hope this helps,
-t