Is the gtkwave gray code filter broken?

there's also sthg fishy with the hex+oct conv... in baseconvert.c nevermind.. there have been changes to the baseconvert.c... its prolly fixed.. may have2 rebuild...

Gtkwave's docs are a fine example of narrow focus. I couldn't figure out from the descriptions that it was a tool to visualize timing diagrams of logic signals. Only the screenshot finally made that clear.

Jeroen Belleman

It's a rather well known program...

the HEX output seems still broken.. may have to do with the vector's size not being a multiple of 4.. also not sure if/how they handle endianness. they do have a bit reverse tho... the filters really should be stackable except for the string formatters.

I'm posting this here, since interactions with sourceforges mailinglists are usually unsatisfactory. The patch was generated against gtkwave-code-1246 (off the sourceforge svn browser)

cvt_gray this gets 10 bits ctr[9:0] the array looks like this: [0] [9] XXXXXXXXXX MSB LSB

newbuff is nbits+6 so adding three is kewl

newbuf/parse is (without rjustify)

000YYYYYYYYYY000 newbuf XXXXXXXXXX?? parse | | | | gets segmented into 3 nibbles, the lowest partially undefined

with rjustify

000YYYYYYYYYY000 newbuf XXXXXXXXXX?? parse | | | |

are the spare fields initialized yes xfwd[0]?

but cvt_gray converts too little.. needs nbits rounded up to multiple of 4

--

--- ./gtkwave3/src/baseconvert.c.orig	2017-06-22 22:50:48.000000000 +0200 
+++ ./gtkwave3/src/baseconvert.c	2018-03-15 15:47:39.000000000 +0100 
@@ -413,7 +413,7 @@ if(flags&TR_ASCII) 
 	if(GLOBALS->show_base) { *(pnt++)='"'; } 
  
 	parse=(flags&TR_RJUSTIFY)?(newbuff+((nbits+7)&7)):(newbuff+7); 
-	cvt_gray(flags,parse,nbits); 
+	cvt_gray(flags,parse,(flags&TR_RJUSTIFY)?((nbits+7)&~7):nbits); 
  
 	for(i=0;ishow_base) { *(pnt++)='$'; } 
  
 	parse=(flags&TR_RJUSTIFY)?(newbuff+((nbits+3)&3)):(newbuff+3); 
-	cvt_gray(flags,parse,nbits); 
+	cvt_gray(flags,parse,(flags&TR_RJUSTIFY)?((nbits+3)&~3):nbits); 
  
 	for(i=0;i