Skip to main content ↑ ↓
Topic: Status of RLE (Read 24619 times) previous topic - next topic

Status of RLE

Can some one tell me what the current status of RLE is?

I'm trying to capture and decode a SPI bus with long periods of idle.  I need RLE or I can't capture enough data.

I've tried bitstream 2.11 and 2.12 with both 0.9.1 and 0.9.2-b2 (built from git) and none of the combinations seems to give me a useful RLE capture.

The forums have various posts about bugs and non-workingness of RLE so I'm not sure its even supposed to work.

Anyone have a working RLE setup?

Re: Status of RLE

Reply #1 –
Hi smithbone,

This page has the feature status for various firmwares and bitstreams:
http://dangerousprototypes.com/docs/Log ... ure_status

RLE should work for 32channel captures in all firmwares, and 8/16/32 channels in 2.11. We have not managed to merge those changes into 2.12, but I've been poking at it with a stick and hopefully get it going soon.

The documentation for the Logic Sniffer is here:
http://dangerousprototypes.com/docs/Ope ... ic_Sniffer
Got a question? Please ask in the forum for the fastest answers.

Re: Status of RLE

Reply #2 –
[quote author="ian"]

This page has the feature status for various firmwares and bitstreams:
http://dangerousprototypes.com/docs/Log ... ure_status

[/quote]

Thanks for the pointers but I've already found that.

Quote
RLE should work for 32channel captures in all firmwares, and 8/16/32 channels in 2.11. We have not managed to merge those changes into 2.12, but I've been poking at it with a stick and hopefully get it going soon.

Dosen't work for me.   Using non-rle I can get a nice waveform of the 1st transaction on the bus.  But then if do nothing else but select rle the output is garbage.

Attached are 2 outputs waveforms showing what I'm talking about.  These are bitstream 2.12 and ols-0.9.1 32 channels.  But I get the same result for other bitstream versions or ols 0.9.2 I built from git.

Re: Status of RLE

Reply #3 –
Hum, I'm sorry, I'm not sure about this. I don't know about v2.12, but I know RLE should work in the FPGA for sure in 2.11 and earlier (with the various constraints).

Here:
http://dangerousprototypes.com/forum/in ... 9#msg13349
Jawi mentions that RLE decoding is one of the lesser tested features. Maybe you can provide him the capture for further testing to rule out a problem with the client.
Got a question? Please ask in the forum for the fastest answers.
 

Re: Status of RLE

Reply #4 –
Ian,

I thought I read that RLE broke when dynamic sample depth was implemented -- instead of needing to install a new bit stream like before.

I think this is discussed in this thread but I could be wrong.


-Eric

Re: Status of RLE

Reply #5 –
[quote author="Eric"]
I think this is discussed in this thread but I could be wrong.
[/quote]

I can duplicate the problem with bitstream 2.11.  In fact thats what I used to generate the files I just posted int the bugs thread.

Re: Status of RLE

Reply #6 –
I have being doing some test of the OLS using  RLE. I have bitstream 2.12 runing on a Windows 7 machine using ols-0.9.1 32 bit capture and have the following comments:-

1 The total capture time is limited by the java client to about 15 million clock periods. After that the client crashes with heap overflow. The number of samples selected does not affect this.
2 The trigger indicator is shown incorrectly. If a 25/75 pretrigger is selected the trigger event is shown at the correct 25% position but the indicator and zero position is shown at 75%.

 Using a 10Mhz clock 1.5 seconds can be captured if a 1khz aux clock is added to an unused input and the signal does not have many transitions.

Re: Status of RLE

Reply #7 –
Has anyone tried the old 0.8.5 version of SUMP from the SUMP project?
Got a question? Please ask in the forum for the fastest answers.

Re: Status of RLE

Reply #8 –
@smithbone, DavidFrancis: the RLE implementation in my client is far from optimal regarding memory consumption; expect it only to work with "small" time-frames. I've got some ideas on how to improve this and will devote my time the next couple of days on this issue...

Regarding the trigger indicator: I've never seen this issue; is this only the case with RLE enabled?
when good software is not an alternative...

Re: Status of RLE

Reply #9 –
It might be a good idea to have an easy way of selecting an internal signal generator in the FPGA as signal source, for debugging purposes.

I read somewhere that there is a built-in self test using the header, but I don't have a good soldering iron lying around and I don't feel like soldering anyway in case I break something.

Re: Status of RLE

Reply #10 –
I seems the trigger indicator problem only occurs when RLE is selected and shows up when there is a regular clock input.
Attached png shows trace 500khz ols clock aux clock 10khz on pin 0 trigger pulse on pin 1 set for 10% before.

Re: Status of RLE

Reply #11 –
Quote
It might be a good idea to have an easy way of selecting an internal signal generator in the FPGA as signal source, for debugging purposes.

You just need to send 0x03 to the serial port, then it goes into signal generator mode which can be bridged from the buffer to the wing header. Probably not as simple as it could be, but it's already there. I believe Jawi's client can send 0x03 to trigger the test, could be wrong though.

The test can also be trigger by a jumper on the UART header, but you can use anything to temporarily connect it at startup - foil, gum wrapper, small piece of wire, etc.
Got a question? Please ask in the forum for the fastest answers.

Re: Status of RLE

Reply #12 –
You're right. You can trigger test mode from Jawi's client. I made a simple hack and turned the outside number scheme into an internal test mode (since I'm not using that numbering scheme anyway).

If anyone else wants to route the test signal internally you can rewrite one of the cases in the process starting on line 215 in logic_sniffer.vhd. For instance:

Code: [Select]
when "01" =>
test_counter <= test_counter + 1;
probeInput <= test_counter(31 downto 0);

It's not very stable unfortunately.

Re: Status of RLE

Reply #13 –
All right, I did a brief test run of a few things with the internal signal generator.

RLE can only work when you include channel group 3 in the capture.

Noise filtering breaks RLE. If you've done a capture with the noise filter you need to perform a capture without channel group 3 (to reset something?) to get it working again (it still only works with noise filtering turned off).

Re: Status of RLE

Reply #14 –
Thanks for the troubleshooting. I added some notes about the specific limitations to the 'what works and what doesn't' wiki page.
Got a question? Please ask in the forum for the fastest answers.