oliver wrote:A quick question about RLE mode.
I read that RLE mode works more effectivly when enabeling all groups (-1 bit, 31bits total) as that strangly is more effective/efficient, with a note of ensuring unused bits are nicely grounded. While I haven't looked at the FPGA code, this seems strange to me. Why can't the FPGA figure out that when using only 1 group, the rest of the bits should be interpreted as 0. Its the same as grounding the unwanted bits, sure, but technically much less work (with the default stock OLS that can be quite tricky, no headers pins 16-31, odd jumpers required for pins 8-15 etc). Also the user experience would make more sense. Use 1 group, yielding more sample memory, enable RLE, doing things more efficiently. That internally the FPGA uses all 32 bits and forces the upper 24 bit to 0 shouldn't matter to the user.
Does this make sense at all?
I agree that it is a bit counter-intuitive. There is a side-effect to selecting 32 or 16 channels vs 8 when using RLE and that is that you get proportionally less "event" storage. An "event" is either a change in the state of one or more of the channels being captured, or a timer rollover. In 8 bit mode, timer rollover happens much more often, since the timer only has 7 bits in that case. You do get the maximum number of events stored, but if the data being traced is sparse, most of the events stored will be timer rollovers.
If you choose 16 channels, you will get half as much event storage, but 256x longer between timer rollover events. So, with sparse data, the fewer timer rollover events, results in more of the available event storage getting used for actual channel transition events and more total time covered in the capture.
In 32 channel mode, the event storage drops in half again, but here we get 65536x more time between timer rollover events. This is great for super-sparse data captures. If you have a serial character being sent once per minute, in 8 or 16 channel mode, 99% or more of the event storage will be used up for timer rollover events. In 32 channel mode, you don't get as much total event storage, but far less is wasted on timer rollover events.
Personally, I find that 16 channel mode works pretty well for what I capture typically, though I do have to think about the tradeoffs.
In my day job, I regularly use a Tektronix TLA7012/7BB4 which has 64M x 135 channels at 800 MHz. I occasionally use what Tek calls "transition" mode which is what we're calling RLE mode. The difference there, is that they have completely separate memory for timestamps and there are no timer rollovers, as the timestamps keep the full calendar time/date. Well, I suppose that it would rollover at some point 1000 years from now or something like that. The point is that given enough money (TLA7012/7BB4 is $180K) you can supply enough memory to make it work without the user needing to understand the dirty details of what is going on behind the scenes. With the OBLS, I don't see how to hide this from the user without causing any issue.