Attached is the VHDL code for continuous sampling mode.
Continuous mode is enabled by issuing 0x10 command. The ARM led will blink slowly once data transfer has begun. If there is data overrun, the rate of blinking will increase and the TRIG led will lit up.
Note that triggering is ignored and RLE is not supported.
On my netbook with version 3.0 of the PIC firmware, the system can only achieve a maximum sample rate of 10kHz for 8 bit samples. Currently, the bottleneck is the PIC USB transfer rate.
Included is a test SUMP client to demonstrate this new capability. Select Test Mode and memory depth of 256K. Test mode outputs the contents of a 32 bit counter incremented by the sample rate clock.
Very cool, I will test it today.
Kinsa,
I just wanted to put out a quick message that this has not been forgotten. Your VHDL cleanup and continuous sampling mode contributions are greatly appreciated.
Right now I'm putting all of my effort into the new automated build/release system and the new OLS information portal at http://gadgetfactory.net/logicsniffer (http://gadgetfactory.net/logicsniffer). Once these tasks are done I intend to check this out and get an experimental release put together so everyone can give this a try.
Thank you for your contribution and please bear with us for a little longer.
Thanks,
Jack.
I don't have the OBLS logic sniffer (yet), but I'm just curious about the possibilities here.
I assume this mode is a 10 kHz analyzer (0.1 millisecond time resolution), is that right? Now, let's say I have two input signals that have very infrequent logic transitions, like only 1 per second, but I would like to measure the edges with high accuracy (eg 10 ns resolution) on a continuous basis forever. Is this something that could be done with the continuous mode, or could it be developed? In other words, the board's FPGA would sample inputs at 100 MHz but it would select out the (rare) transitions and just send a few 32-bit timer values every second over the USB connection, so there shouldn't be a USB bandwidth issue there. This would be using the sniffer as a continuous-running TIC (time interval counter) with 10 ns resolution. Is it possible?
Hello Jack, this is just a proof of concept and I'm learning VHDL through your great little device. No worries :)
jbeale, I think you need continuous mode RLE. Needs to be implemented though.
Even with RLE enabled in continuous mode, you probably wont make it.
I'm not sure about this but I think that even with all the signals grounded, at 100Mhz the ram will just fill up faster than you can send it to the PC.
I'm not saying that what you are asking for isn't possible with this hardware, just (probably) not within the SUMP specification.
Thanks for the replies. Yes, what I'm looking for is different from a standard logic analyzer. I guess it would need a circular RAM buffer in the FPGA (?) so that the signal is always captured at (say) 100 MHz and it overwrites old data as it wraps around; meanwhile a separate RLE process is scanning through the RAM and sending only the compressed data out to the PIC. The RLE process has to process samples at the input sample rate or else it will eventually fall behind and loose data. So, since would need to work at the sample rate, you should not need a large RAM buffer, in fact maybe you don't need a buffer at all. Or maybe it's not even possible, I don't know enough about FPGAs.
I was thinking about something slightly different. As you're really only interested in the changes, you could just initialize a say 32 bit counter and everytime a change occurs, send out the value of the counter, and initialize a new counter 32bits ahead. I'm not entirely sure how this would be implemented in an FPGA, but I do think something along these lines would be possible.
RLE of 10kHz signal at 100MHz sampling would, in worst case, generate twice the amount of data than normal sampling.
This can be easily handled once the PIC usb code is optimized.
[quote author="jbeale"]I guess it would need a circular RAM buffer in the FPGA (?) so that the signal is always captured at (say) 100 MHz and it overwrites old data as it wraps around; meanwhile a separate RLE process is scanning through the RAM and sending only the compressed data out to the PIC. The RLE process has to process samples at the input sample rate or else it will eventually fall behind and loose data. So, since would need to work at the sample rate, you should not need a large RAM buffer, in fact maybe you don't need a buffer at all.[/quote]
I think you have it backwards. No matter how much RAM you have, it's going to be better to handle RLE first, then fill the circular buffer, then transmit to the PIC. RLE will typically fill up memory much slower. kinsa is correct that the worst case will fill memory twice as fast as non-RLE, but the average case will be much, much better than the worst case. After you have reduced the data, it will be far easier for the PIC and USB to keep up.
I think that the only glitch would be when the circular buffer erases old data and you're left with a starting repeat count with no known data to repeat. But discarding that one glitch should be fairly easy with the out-of-band RLE flag bit (stored in one of the extra two bits of the 16-bit/18-bit SRAM inside the FPGA).
I don't think RLE is as bad as you think. It should never be worse than the original sample rate.
If every sample is different, all it stores are values. ie:
<1><2><1><2><1><2> => <1><2><1><2><1><2>
If there are duplicates, only then do you get counts. ie:
<1><1><2><1><1><2> => <1><count=1><2><1><count=1><2>
A 10Khz signal sampled at 100Mhz in non-rle mode would store 10000 samples per 10Khz pulse. In 16 bit or 32 bit rle-mode, it consumes only 4 samples per pulse: <1><count=4999><0><count=4999> repeat... In 8 bit mode, the same 10KHz signal burns 158 samples per pulse (counters are too small).
Assuming 32-bit mode, jbeale's one event per second sampled at 100Mhz is very doable. That is only three or four samples per second. The 31-bit rle-counter can handle over 20 seconds of nothing. A single buffer full represents hours of captures at that rate.
-- IED
My current RLE code always sends the counts irrespective of the RLE bit implementation. This was meant to standardize the interface to the client.
So in worst case scenario, a 10kHz signal would generate 20k samples/second.
[quote author="dogsbody"]"..."[/quote]
Doh! I forgot that with 16/32 channels, the RLE counter is also 16/32 bits!
[quote author="kinsa"]My current RLE code always sends the counts irrespective of the RLE bit implementation. This was meant to standardize the interface to the client.
So in worst case scenario, a 10kHz signal would generate 20k samples/second.[/quote]
That probably doesn't matter for jbeale's scenario, as it only makes a difference when changes are only 10ns apart, which, from my understanding, won't be very often.