[quote author="ian"]Is this related - Dogsbody implemented three storage modes that are documented in the wiki:
Quote
Mode Description 0&1 Issue <value> & <rle-count> as pairs. Backwards compatible. 2 Periodic. <values> reissued approximately every 256 <rle-count> fields. 3 Unlimited. <values> can be followed by unlimited numbers of <rle-counts>.
[quote author="markus_b"] ... This a completely new scheme, but much better than a hack to gain a single additional bit.[/quote]
Once you have standardized the RLE output, you can experiment with RLE implementation without worrying whether it would break the client or not.
For 8-bit data, using 32-bits for the counter would not be an issue. If I were going to implement it, at least I don't have to wait for Jawi to update his client to test my changes.
The advantage of the new RLE code is that you have an extra bit for the counter. This doubles the existing RLE storage capacity.
For example, in 8-bit mode the maximum count is 256. This would translate to (24k/2)*256 = 3M samples. In 16-bit: (12k/2)*65536 = 384M samples.
[quote author="dogsbody"]In 8-bit mode the maximum number of samples (even with non-changing data) is (24k/2) * 128 = 1.5M samples. At 100Mhz that fills very quickly (~15msecs).
In 16-bit mode the max is (12k/2) * 32768 = 192Msamples. So about 2 seconds at 100Mhz.[/quote]
But the main advantage is simplifying the protocol.
Yes, the RLE encoder is demux aware. The RLE code was a complete redesign from scratch.
At the moment 8 bit samples will have 8 bit counts, 16 - 16 bit counts, 24 and 32 bit sample both use 32 bit counts. Additional data compression of zero counts using the parity bits are used. I have not implemented the 200Mhz RLE yet.
There is also a "formatter" that inserts zero counts so that the output will always be a data + count pair.
So in demux mode, we just insert a zero count in between the capture word. Thus the client doesn't have to be aware of how the RLE is implemented within the core.
On my VHDL implementation, RLE always return data and count pairs independent of how the RLE is implemented. This way any changes on the core will not affect the client.
[quote author="Richard Sharpe"]the value set up for the SET READ & DELAY COUNT is actually ((samples requested)/4) - 1. [/quote] This is actually a bug on the client side. If the SET READ or DELAY COUNT is less than 4, what gets transmitted is 0xFFFF. The VHDL logic only works with unsigned numbers, so a -1 request translates to 0xFFFF counts.
This problem is evident if you set the "Before/After ratio" to "100/0".
UPDATE:
This has already been fixed on the latest OLS release.
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.
Attached is a cleaned up version of the VHDL code with the following enhancements:
New SPI code, works with the latest PIC firmware (v3.0)
Working Metadata command (not sure if the values returned are correct)
New RLE code; n bit counters for n bit data width (except for 24 bits). Additional compression for cases with zero run lengths. RLE stop command is also implemented
Fixed the spurious triggers due to floating external trigger pin
Resolved timing issues
Also attached is the diff for Device.java that handles the RLE data and the fix for the before/after trigger capture.
Don't forget to regenerate the BRAM core before compiling the project.
