I think something might be up in OLS regarding RLE handling. When I capture data, its looking corrupted. However, on closer examination it appears to be showing rle-count's as data.
I wrote a test program to capture the output from the FPGA. The data capture was correct... exactly as expected. ie: <value><rle-count>(inclusive of the value)<value>(even if same as last value)<rle-count>etc...
It's possible the first sample you get isn't a value. If so, it should be ignored. There is no way to avoid it if the fpga RAM write pointer wraps around capturing, especially when waiting for a trigger.
Also, the Read & Delay Count's must be the same when -not- using a trigger. Otherwise you'll get some undefined data/garbage. There's a cautionary blurb mentioned in the SUMP protocol site.
Assume no trigger & read-count > delay-count. The fpga starts storing when armed. It immediately captures delay-count # of samples, then uploads read-count # of samples. You'll get delay-count of sampled data, and (readcount - delaycount) words of leftover garbage. The garbage could spoof bogus rle-values.
I've written a test program to capture the output from the FPGA. The data capture looks completely clean, on all rle settings. Exactly what I expect, formatted as specified. Values, rle-count (inclusive of the value), then another value (even if same as last value), followed by another rle-count, etc...
So... either I'm formatting RLE count values totally wrong, or Jawi has a bit of work left. -- IED
Looks like the scramble I saw on release3. Targeting the wrong device created timing violations in the rle module, that messed it up. Release 4 seems clean though.
If you capture with just RLE & no trigger, does that work? Is it only the combination? -- IED
I been fooling around changing the meta data. I found OLS 0.9.2 is only sensitive to the LSB first long data (max sample rate & samples). I'd swapped them to MSB a while ago & still had problems with capture aborts.
But now I don't. Um... Hmmm...
I've attached a test release for you to try out. If you think it safe, I'll generally release it for people on 0.9.2. -- IED
[quote author="jawi"]I've uploaded a beta release of 0.9.3 for people to use... [/quote] I'm having a problem getting the 0.9.3-b3 release to work. I'm running WinXP & unzipped it under: C:Program FilesOpenBench Logic SnifferAlternativeLogicSnifferols-0.9.3-b3
Same place as the older versions. File structure under the folder looks the same. Deleted the "C:Program FilesOpenBench Logic Snifferfelix-cache" folder. Edited the OB_Logic_Sniffer.bat file BASEDIR variable, and well... it starts.
If I attempt a capture though, I get a Java exception and it crashes. If I restore the batch file, it works again.
Does this release need a new Java package, or rxtxserial library? My JAVADIR variable is setup with: set JAVADIR=%~dp0jre1.6.0_14-b08bin
Just discovered what I think is the cause of RLE issues...
My Xilinx XISE environment had the -5 speed grade Sparten 3E selected (the high performance flavor). How that happened I've no clue. With the -4 grade timing I needed to change clock constraints back to 100Mhz from 105Mhz (oh well). Compiles clean with no timing violations & RLE appears to work fine now.
Still don't have meta data enabled, since OLS 0.9.2 doesn't like it. New release4 fpga image is available in the first post of this thread. Anyway, enjoy! -- IED
Sounds right. Once the spi_transmitter gets busy it ignores query commands. However, the fpga -is- bidirectional & processes commands. So you can write regs & change things no problem. -- IED
Hmmm... My memory must be mush from working late. I clearly remember big gaps between the bursts of SCLK pulses & could have sworn CS was deasserting.
As for higher speeds, the fpga should handle no problem. I'd say up to 10Mhz easy (3X). The 0x7F is needed though. The fpga's spi_receiver doesn't care about transmit data, so if it sees CS & SCLK, it grabs bits. The 0x7F NOP's it. If you output zeros, you'd reset the fpga.
If you want to avoid 0x7F's, we'd need a separate CS to enable transmit. Wouldn't really be SPI, but who cares? -- IED
I'm going off what I remember when debugging the SPI issue, and capturing query ID reads on my scope. My PIC was running the older firmware at the time (OLSv1_firmware_v2.1). Maybe it was changed for 2.3? -- IED
[quote author="jack.gassett"]I don't want to take any chances that the Wifi module will not support anything other than 8N1 communications.[/quote] Exactly my thinking. I don't think rxtx libraries are guaranteed of being graceful either for non-8N1.
We can compensate for overhead (a little) by tweaking the SPI uplink between fpga & pic. There is a lot of dead time between bytes. In response to "dataready", the PIC writes 0x7F to the fpga, which supplies the SCLK pulses the fpga needs to upload data. The PIC asserts CS, pulses SCLK, deasserts CS, repeats...
If the PIC could handle it, my image can happily output much longer bursts. If the PIC wrote 64 non-stop 0x7F's (no CS gaps) uploads would be much faster. -- IED
[quote author="rsdio"]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.[/quote] Absolutely. There are 4 extra bits available (we've a 6k x 36 bit RAM to play with). So we -could- have 256 counts per 8 bit sample (8 bits + rle-flag), 128k counts per 16 bit sample (16 bits + 1 extra + rle-flag), and 32 Gsamples per 32 bit rle count (32 bits + 3 extra + rle-flag). Over five minutes of non-changing captures per 32-bit word at 100Mhz!! Weeks for 6k samples!!
The upload bitstream would change though. Simple is probably best. Something like:
[quote author="DavidFrancis"]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..[/quote] 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.
[quote author="jawi"]I've taken the liberty to write up a Wiki page on the RLE implementation and the "issues" they might have[/quote] 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.
[quote author="jawi"]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...[/quote]
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
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
[quote author="jawi"]did some simple tests on RLE and can confirm 8-bit RLE works, though the count appears to have a off-by-one bug....[/quote] 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
