FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Timing

A cheap logic analyzer. Get one for $50, including worldwide shipping. A collaboration between the Gadget Factory and Dangerous Prototypes.

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby jawi » Wed Jan 26, 2011 10:07 am

Did some quick testing on the latest bitstream (v3) on FW2.3 and it works well: the OLS does return test sample data.
However, I don't see any reaction on the metadata command (while the latest BP firmware does react).

Another thing regarding the RLE implementation: how does the encoding for 8 & 16-bit work? Similar as to the firmware of Rasmus, or ...?

edit: did some simple tests on RLE and can confirm 8-bit RLE works, though the count appears to have a off-by-one bug... Will do some additional testing (also for 16-bit and 32-bit) tomorrow...
User avatar
jawi
Developer
Developer
 
Posts: 596
Joined: Thu May 27, 2010 2:54 am
Location: The Netherlands

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby dogsbody » Wed Jan 26, 2011 12:53 pm

Ian wrote: Is it possible that the Verilog version holds MISO low even when CS is high?

Oh dang... Everything makes sense now. There was a problem with the "SLA1" signature getting fouled up, and I discovered I'd lost an edit in spi_transmitter. Then all the problems started, ending with the fix in spi_receiver. So I shot my left foot, trying to fix having shot myself in the right. Nice. Doh!!!

An object lesson in not designing hardware when tired...


jawi wrote: However, I don't see any reaction on the metadata command (while the latest BP firmware does react).

I originally had meta. However, OLS 0.9.2 didn't like it. It wouldn't capture, and displayed "Capture aborted: -1". Got distracted by the SPI bug before I could figure it out, and then needed sleep at 3AM. I did try varying the number of null's at the end to no avail. I wrote my own test program & was able to see that data.

The sequence output is:

Code: Select all
0x01 "Open Logic Sniffer v1.01" 0x00
0x02 "3.00" 0x00
0x21 0x00 0x60 0x00 0x00    // 24K samples
0x23 0x00 0xC2 0xEB 0x0B    // 200Mhz
0x40 0x20   // 32 probes
0x41 0x02   // Protocol 2
0x00


The meta ROM is in "meta.v". To enable the command, the decode in "spi_slave.v" must be uncommented. I've made a test image with meta back for you (see attached).
-- IED
Attachments
ols_verilog_meta.zip
(235.81 KiB) Downloaded 345 times
User avatar
dogsbody
Full Member
Full Member
 
Posts: 181
Joined: Wed Jan 05, 2011 3:17 am
Location: San Jose, California

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby dogsbody » Wed Jan 26, 2011 7:16 pm

jawi wrote:did some simple tests on RLE and can confirm 8-bit RLE works, though the count appears to have a off-by-one bug....

Should work with all combination's of channel groups. Any 8-bit channel, any two channels forming 16-bits, any three for 24-bits, etc...

Are RLE counts too big or too small? I'll check the rle code when I get home & see what I flubbed. It did get a heavy rewrite to simplify things (for timing purposes).
-- IED
User avatar
dogsbody
Full Member
Full Member
 
Posts: 181
Joined: Wed Jan 05, 2011 3:17 am
Location: San Jose, California

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby jawi » Thu Jan 27, 2011 5:12 am

@dogsbody: thanks for the new bitstream! Indeed my client had a bug which was related to this metadata reading. Byte order is still an issue here (little vs big endian). I think we need to "standardize" the way 32-bit values are sent along the line.

Regarding the RLE-count: I need to add one to the obtained RLE-count to get the "correct" count values for 8, 16 and 32 bit RLE encodings. I've tested this with the 1kHz reference signal from my scope.

One observation I see is: when using a sample rate of 500x (e.g. 500kHz) or more the original signal, the RLE encoding seems to introduce a lot more errors. This also seems to depend on the number of sampled channels. Will investigate this further to see whether a pattern can be observed in this...
User avatar
jawi
Developer
Developer
 
Posts: 596
Joined: Thu May 27, 2010 2:54 am
Location: The Netherlands

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby dogsbody » Thu Jan 27, 2011 5:20 am

Ah... RLE counts are too small then. Easy fix.

For meta byte order, I didn't see anything stating how it should be. So I copied the long commands (LSB first). Switching is trivial though, since data is stored in a ROM.

As for noise... is this only with my image, or do you see it on others fpga's also? The reason I ask is the OLS does pickup a lot of junk if there are dangling wiring harness pins. They act like antennas... Any not being used should be grounded.

The Logic Sniffer could probably use 50K pulldown's or something on the 16-bit buffer...
-- IED
User avatar
dogsbody
Full Member
Full Member
 
Posts: 181
Joined: Wed Jan 05, 2011 3:17 am
Location: San Jose, California

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby jawi » Thu Jan 27, 2011 6:01 am

I did some tests a while ago with the 2.12 bitstream and did not observe this behaviour there. But, just to be sure will load up one of the 'original' bitstreams to see if it occurs there as well...
User avatar
jawi
Developer
Developer
 
Posts: 596
Joined: Thu May 27, 2010 2:54 am
Location: The Netherlands

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby dogsbody » Thu Jan 27, 2011 6:32 am

jawi wrote:I did some tests a while ago with the 2.12 bitstream and did not observe this behaviour there. But, just to be sure will load up one of the 'original' bitstreams to see if it occurs there as well...


Loose cables really do pick up lots of junk. I see it all the time on my mine. Try not to change -anything- about your setup between tests, other than the fpga images. Apples-to-apples 'n all that.

Got another test image for you. The rle counts are fixed, and byte order of meta dwords is reversed.

I'm a little puzzled by the rle counts. Not seeing how the vhdl 2.12 version has the "correct" behavior, but my grasp of vhdl isn't great. Probably missing something obvious.

Anyway, enjoy! I'm off to bed now (3:30AM)...
-- IED
Attachments
ols_verilog_meta2.zip
(240.09 KiB) Downloaded 325 times
User avatar
dogsbody
Full Member
Full Member
 
Posts: 181
Joined: Wed Jan 05, 2011 3:17 am
Location: San Jose, California

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby jawi » Thu Jan 27, 2011 9:14 am

dogsbody wrote:Loose cables really do pick up lots of junk. I see it all the time on my mine. Try not to change -anything- about your setup between tests, other than the fpga images. Apples-to-apples 'n all that.


The test setup is simple (and remains untouched): 1kHz signal on channel 0, channels 1..4 are grounded. I've used this for all tests I've done so far.

dogsbody wrote:Got another test image for you. The rle counts are fixed, and byte order of meta dwords is reversed.


Looks good! The RLE count is correct now, and I no longer have to transfor the endianness of the metadata.

dogsbody wrote:I'm a little puzzled by the rle counts. Not seeing how the vhdl 2.12 version has the "correct" behavior, but my grasp of vhdl isn't great. Probably missing something obvious.


The 2.12 version, as far as I can remember, only supports 32-bit RLE count values. And there appears that sometimes one bit of the count is flipped (as David Francis already found out in the forum).

One thing: I think the RLE-count can "overflow" in your version, causing incorrect results. According to my tests, the version made by rasmus does not show this behaviour, or are less influenced by count-overflows...

Keep up the good work (and sleep well ;))! As soon as the RLE is a bit more stabilized, I can start focus on other additions your firmware provides...
User avatar
jawi
Developer
Developer
 
Posts: 596
Joined: Thu May 27, 2010 2:54 am
Location: The Netherlands

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby jack.gassett » Thu Jan 27, 2011 1:16 pm

I was figuring that I would give this another day or so and then I would put together an official Test Release so that more people could check out this new version.

Jack.
jack.gassett
Developer
Developer
 
Posts: 319
Joined: Tue Nov 17, 2009 12:47 pm

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby DavidFrancis » Thu Jan 27, 2011 2:12 pm

I have been testing dogsbody's ols_verilog_meta2 bitstream and finds that it handles rle counter rollover slightly differently to the other bitstreams. the others outputs a data word between count rollovers whereas this one does not. This is not handled correctly in Jawi client as all counts except the last are ignored . This is more noticeable at 8 bit captures as rollover occurs more frequently. I think this new bitstream is this best way though as it allows slightly more samples.
I also found the 24 bit rle to does not output the counter correctly in that it outputs the most significant byte as all zeros so it does not show as a count.
I think this great work and I look forward to testing the advanced trigger option.
DavidFrancis
Newbie
Newbie
 
Posts: 32
Joined: Thu May 06, 2010 9:36 am

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby jawi » Thu Jan 27, 2011 3:13 pm

I've taken the liberty to write up a Wiki page on the RLE implementation and the "issues" they might have (read: the client might have ;)). Maybe we can get to more consensus about the implementation details?

http://dangerousprototypes.com/docs/Logic_Sniffer_RLE
User avatar
jawi
Developer
Developer
 
Posts: 596
Joined: Thu May 27, 2010 2:54 am
Location: The Netherlands

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby dogsbody » Thu Jan 27, 2011 4:13 pm

DavidFrancis wrote:I also found the 24 bit rle to does not output the counter correctly in that it outputs the most significant byte as all zeros so it does not show as a count..

Yes, of course... Obvious. The upper byte isn't output to the client, so no RLE flag. Here I was thinking 30 bit counts on 24-bit data would be cool. Oops. One of the hazards of unit testing. My rle testbench checks -only- the RLE module, so I overlooked this detail. Stupid of me. Sorry 'about that.

As for value/count pairing, I should probably do that also -- even though it wastes space -- for client compatibility more than anything. Perhaps a flag bit to make it optional.

jawi wrote:I've taken the liberty to write up a Wiki page on the RLE implementation and the "issues" they might have

Whatever you guys want I'll provide. Count values as repetitions, my original approach (rle-count of 4 means 5 samples total) has the advantage of allowing two bytes indicate 128 samples versas 127 (in 8 bit mode). Otherwise, no difference.

Repetitions, without value between rle-counts, could pack 3121026 captures of non-changing 8-bit data. Repeat count (rle-count of 4 means 4 samples total), with values per, can record 1560576 captures. About half. However, if the RAM capture wraps around you lose the initial value - a bad thing. Perhaps a mode where the value is output once every 256 bytes? That could pack 3109056 captures -- or 3076670 if we lose the first value.

btw, any chance of getting a data capture of the "noise" you see? Also an example of the overflow. Might help me narrow down what's going on... Raw capture data from the serial port would be preference, along with value written to the "flags" register.

Thanks!
-- IED
User avatar
dogsbody
Full Member
Full Member
 
Posts: 181
Joined: Wed Jan 05, 2011 3:17 am
Location: San Jose, California

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby jawi » Thu Jan 27, 2011 6:14 pm

dogsbody wrote:
jawi wrote:I've taken the liberty to write up a Wiki page on the RLE implementation and the "issues" they might have

Whatever you guys want I'll provide. Count values as repetitions, my original approach (rle-count of 4 means 5 samples total) has the advantage of allowing two bytes indicate 128 samples versas 127 (in 8 bit mode). Otherwise, no difference.

Repetitions, without value between rle-counts, could pack 3121026 captures of non-changing 8-bit data. Repeat count (rle-count of 4 means 4 samples total), with values per, can record 1560576 captures. About half. However, if the RAM capture wraps around you lose the initial value - a bad thing. Perhaps a mode where the value is output once every 256 bytes? That could pack 3109056 captures -- or 3076670 if we lose the first value.

btw, any chance of getting a data capture of the "noise" you see? Also an example of the overflow. Might help me narrow down what's going on... Raw capture data from the serial port would be preference, along with value written to the "flags" register.


What I already posted in another thread, the RLE-count of 4 meaning 5 is no problem to me. If multiple consecutive RLE-counts can occur (which should be added to get the 'real' RLE-count) that is also fine, as long as it is a bit consistent among the various firmwares.

I'll redo the tests I've done today to see if I can provide you the noisy signals in some way. Now it's time for me to go to bed... ;)
User avatar
jawi
Developer
Developer
 
Posts: 596
Joined: Thu May 27, 2010 2:54 am
Location: The Netherlands

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby rsdio » Thu Jan 27, 2011 6:22 pm

DavidFrancis wrote:I have been testing dogsbody's ols_verilog_meta2 bitstream and finds that it handles rle counter rollover slightly differently to the other bitstreams. the others outputs a data word between count rollovers whereas this one does not. This is not handled correctly in Jawi client as all counts except the last are ignored . This is more noticeable at 8 bit captures as rollover occurs more frequently. I think this new bitstream is this best way though as it allows slightly more samples.
I agree with your assessment that the bitstream should be as efficient as possible. Since the count words have a bit to flag them as not being a data word, it should not be confusing to skip the data word between count words.
User avatar
rsdio
Developer
Developer
 
Posts: 1407
Joined: Sun Feb 28, 2010 10:53 pm
Location: Seattle

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Postby rsdio » Thu Jan 27, 2011 6:31 pm

dogsbody wrote:Whatever you guys want I'll provide. Count values as repetitions, my original approach (rle-count of 4 means 5 samples total) has the advantage of allowing two bytes indicate 128 samples versas 127 (in 8 bit mode). Otherwise, no difference.
Jack - the originator of the OLS design, I believe - was looking into using the spare bits of the 18-bit BRAM as the RLE flag. Thus, 8-bit mode would have 8-channel data words and 8-bit count words, so we're talking about allowing 256 or 257 samples versus 255 (see my other post, here).

But using the 18-bit BRAM for out-of-band RLE flags calls up a question about the stream design. USB is an 8-bit transport, and so is the CDC serial layer (although I suppose you could set 7-bit, 8-bit, or 9-bit with serial).

I'm asking: What do we do about 32-bit mode if the RLE flag is a 33rd bit? 16-bit mode with RLE flag as a 17th bit? 8-bit mode with RLE as a 9th bit? These bitstreams match the logic analyzer inputs more conveniently, but they make the RLE-encoded data more tricky to transport. Any ideas?

I'm assuming that dogsbody can handle accessing the extra 2 bits of the BRAM in the FPGA as Jack was planning. This seems like a good way to get the maximum use out of the FPGA, and might even simplify things by placing the RLE flag in a consistent location. There's even the potential for a 2nd flag, although I can't imagine a use for that just yet.
User avatar
rsdio
Developer
Developer
 
Posts: 1407
Joined: Sun Feb 28, 2010 10:53 pm
Location: Seattle

PreviousNext

Return to Open Bench Logic Sniffer