Is the gtkwave gray code filter broken?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I was trying to convert from gray but the data looks fishy. has anybody else tried that?  

Re: Is the gtkwave gray code filter broken?
On 03/13/2018 04:44 PM, Johann Klammer wrote:
Quoted text here. Click to load it
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...



Re: Is the gtkwave gray code filter broken?
Johann Klammer wrote:
Quoted text here. Click to load it

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

Re: Is the gtkwave gray code filter broken?
On 03/14/2018 10:23 AM, Jeroen Belleman wrote:
Quoted text here. Click to load it
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.



[PATCH] gtkwave gray code filter/HEX/OCT/ASCII broken
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;i<nbits;i+=8)
         {
@@ -453,7 +453,7 @@ else if((flags&TR_HEX)||((flags&(TR_DEC|
     if(GLOBALS->show_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<nbits;i+=4)
         {
@@ -614,7 +614,7 @@ else if(flags&TR_OCT)
     parse=(flags&TR_RJUSTIFY)
         ?(newbuff+((nbits%3)?(nbits%3):3))
         :(newbuff+3);
-    cvt_gray(flags,parse,nbits);
+    cvt_gray(flags,parse,(flags&TR_RJUSTIFY)?(((nbits+2)/3)*3):nbits);
  
     for(i=0;i<nbits;i+=3)
         {
@@ -1117,7 +1117,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;i<nbits;i+=8)
         {
@@ -1156,7 +1156,7 @@ else if((flags&TR_HEX)||((flags&(TR_DEC|
     if(GLOBALS->show_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<nbits;i+=4)
         {
@@ -1317,7 +1317,7 @@ else if(flags&TR_OCT)
     parse=(flags&TR_RJUSTIFY)
         ?(newbuff+((nbits%3)?(nbits%3):3))
         :(newbuff+3);
-    cvt_gray(flags,parse,nbits);
+    cvt_gray(flags,parse,(flags&TR_RJUSTIFY)?(((nbits+2)/3)*3):nbits);
  
     for(i=0;i<nbits;i+=3)
         {



Site Timeline