1
Show Posts
This section allows you to view all Show Posts made by this member. Note that you can only see Show Posts made in areas you currently have access to.
Messages - rotdrop
2
Open Bench Logic Sniffer / Re: Channel mask/RLE
3
Open Bench Logic Sniffer / Channel mask/RLE
So my question is: is this functionality already there?
Thanks,
Claus
4
Open Bench Logic Sniffer / Re: Alternative Java client
thanks for this work. I figured out that I probably would have ot use that "maven" to build from source. I tried
mvn package
from the top-level directory after running "git clone". So, before posting error message from the failed build: how do I recompile from source? I have some issues with the run-length encoding, as the current RLE-decoder in the client does not treat repeated RLE-counts properly.
Best regards,
Claus
5
Open Bench Logic Sniffer / Re: Test Release 2.12 - Dynamic Sample Depth
Thanks again,
Claus
6
Open Bench Logic Sniffer / Re: Test Release 2.11 - RLE
An RLE encoding method, that doesn't let you reconstruct the timing is broken.
[/quote]
Well, yes, this was the concern of my first post. The point is that the current implementation of the OLS does not let you reconstruct the timing.
[quote author="whitis"]
When the count reaches 255, you should store a sample.
[/quote]
Or you just repeat the RLE count.
[quote author="whitis"]
This limits you to 255 or 256 times (depending on your count bias) the base sample rate. If you are interleaving RLE and data, instead of adding bits to your word width, then effectively RLE only lets you extend your sample size by up to 127 (or may reduce it by 2 if the bits are busy).
[/quote]
Well, if you have a (boring) constant signal, then the eight-bit RLE (as used in the OLS with 24k8bits layout) lets you increase your sample size by a _factor_ of 256, simply because the number of bits in each word is 9 in this case. But the sample size is not reduced, because of the 9th bit.
[quote author="whitis"]
You can also take advantage of the ram being 9 bits wide instead of 8. 1 bit could indicate if you have a repeat at all, eliminating the repeat count where there is no repeat.
[/quote]
The current 8- and 16-channel firmwares (as in the SVN archive) do this, but they do not emit repeated RLE-counts properly, the reason is the bug mentioned in my previous post (the RLE-source-code implements the RLE-counter as a VHDL signal, but uses it as if it were a VHDL variable).
Cheers,
Claus
7
Open Bench Logic Sniffer / Re: Toolchain for building FPGA firmware
Cheers,
Claus
8
Open Bench Logic Sniffer / Re: Test Release 2.11 - 12k and 24k sample depths and fixed RLE.
Code: [Select]
if (ctr = 0) then
DO SOMETHING
elseif (ctr has overflow) then
DO SOMETHING ELSE
ctr <= (others => '0');
end if;
ctr <= ctr +1;
does no reset the signal ctr, but simply schedules the event to increment the counter. A work-around would be to use a variable, or something like this:
Code: [Select]
if (ctr = 0) thne
DO SOMETHING;
ctr(1) <= '1';
elsif (ctr overflow) then
DO SOMETHING ELSE
ctr <= '1';
elsif
ctr <= ctr + 1;
endif
or something similar, VHDL wizards will know better. Or drop repeated RLE counts altogether, but then it is not necessary to pretend to reset the counter in the RLE code.
Cheers,
Claus
9
Open Bench Logic Sniffer / Re: Toolchain for building FPGA firmware
Cheers,
Claus
10
Open Bench Logic Sniffer / Re: Test Release 2.11 - 12k and 24k sample depths and fixed RLE.
thanks for your reply. However, I think we are talking about different things. The FPGA in the OLS has to capture the data in real-time and has to wait for the signals anyhow. So I guess it should store the data it captures as accurate as possible. The issue your are talking about is rather a feature/problem of the client: it has to decode the RLE data. If it is appropriate, the client can then deicide to truncate RLE counts. Why not. It would be rather easy to add some button or input field to the client GUI to specify a truncation limit for the RLE count.
I was talking about the fact that the FPGA does not store repeated overflowing repeat counts in memory. This is probably never an issue if you use 32 channels, simply because 2^31 is such a big number that overflows probably never (or seldom) occurs. However, when using only 8 channels a single RLE count is just 8 bits, so there will be an overflow after 256 repetitions, which is not very much, at any rate. So lets assume that we try to capture a signal in 8-channel mode, and by chance the signal stays constant at 0x00 for 515 capture-clock-cycles. I would expect that the OLS should generate the following data:
Code: [Select]
0x00000000 [ data ]
0x800000ff [first overflowing repeat count]
0x800000ff [second overflowing repeat count]
0x80000006 [terminating repeat count, 515 - 1 - 255 - 255]
But instead, I get the following:
Code: [Select]
0x00000000 [data byte]
0x800000ff [RLE count, overflowing]
[second overflowing RLE count is missing]
0x80000006 [final RLE count]
So the second (actually: any further) overflowing repeat count is missing.
Is this intentional? Of course, a constant signal is not that interesting, but doing it this way kills the possibility to reconstruct the timing. Of course, if I get many overflowing repeat counts all the time then this probably means that I should adjust the capture clock. Also, if I have large periods of constant data with only small periods of activity, it would be more efficient to use the OLS in 16 or 32 channel mode, simply because repeated RLE counts are not a very efficient way of compressing the data.
Finally, I wonder where in rle_enc.vhd this dropping of repeated RLE-counts happens. Seemingly I misunderstand the VHDL source code, but at first sight it seems that an overflow simply causes
(1 << 31)|0xff
to be written to the BRAM and then resets the RLE counter. So I would expect that a repeatedly overflowing counter would also result in repeated 0x80...ff data written to the BRAM (and occuring in the output stream).
Thanks,
Claus
11
Open Bench Logic Sniffer / Toolchain for building FPGA firmware
Thanks,
Claus
12
Open Bench Logic Sniffer / Re: Test Release 2.11 - 12k and 24k sample depths and fixed RLE.
first of all, the OLS seems to be a great tool for the given moderate price.
A tried the 2.11 test-release in the hope that the run-length encoding might work, and it does _partly_. Everything seems to be well as long as the run-length counter does not overflow. Specifically, I have tested the 24k8bit FPGA firmware with a standard servo-signal (50Hz, impuls width between 0.75 and 1.5 ms) at a sample frequency of 1 MHz with a sample buffer of 1k (tried to have a look at an I2C signal before, but that did not work, therefore the somewhat artificial setup, servo signals are not too interesting in general ...). Still it did not work. Now, what should happen: with the 24k8bit firmware the FPGA has repeat-counts of only 8bits, so there is an overflow after 255 us (given the sample-rate of 1Mhz). The servo signal was connected to channel seven. So the sample-buffer of the FPGA (and the stream transferred to the PC) should look like this (all channel groups activated, would suffice to activate 0 and 3)
Code: [Select]
0x00000080 [servo signal high]
0x800000FF [RLE repeat count, overflowing]
0x800000FF [ more of these until duty cycle of the PWM signal expires]
...
0x800000XX [final RLE count, not overflowing]
0x00000000 [servo signal low, idle cycle of the PWM signal]
0x800000FF [many of these overflowing repeat counts]
0x800000FF
...
0x800000XX [final partial repeat count without overflow]
0x00000080 [ servo channel high]
...
etc.
However, this is not what comes out of the FPGA. Instead, it transmits something like the follwing stream:
Code: [Select]
0x800000ff
0x800000fb
0x00000080
0x800000ff
0x800000d8
0x00000000
0x800000ff
0x80000068
0x00000080
So it appears that the overflowing 8-bit RLE-counts are never repeated. There is also a bug in the Sump version in the OLS svn-repo (or I misinterpret the RLE protocol). I had to change it as follows in order to make it recognize repeated RLE counts. The first line in the "for"-loop was used to get a copy of the run-length EN-coded sample-buffer, i.e. that "System.out.println()"-call
Code: [Select]
Index: org/sump/analyzer/devices/FpgaDevice.java
===================================================================
--- org/sump/analyzer/devices/FpgaDevice.java (revision 265)
+++ org/sump/analyzer/devices/FpgaDevice.java (working copy)
@@ -739,24 +739,32 @@
java.util.ArrayList<Integer> decodedBuffer = new java.util.ArrayList<Integer>();
decodedBuffer.clear();
+ int old = buffer[0];
for (int i = 0; i < samples; i++) {
+ System.out.println(" 0x" + Integer.toHexString(buffer[i]));
if ((buffer[i] & 0x80000000) != 0) { //This is for a 32 channel buffer
//if ((buffer[i] & 0x100) != 0) { //This is for a 9 channel buffer
// This is a "count"
- if (i==0) {
- // If the first sample is count, skip it.
+ if ((old & 0x80000000) != 0) {
+ // Skip the first part of the stream if it is composed from
+ // repeated repeat-counts.
+ old = buffer[i];
continue;
}
+ //if ((buffer[i-1] & 0x80000000) != 0) {
+ // System.out.println("Duplicate count");
+ //}
int count = 0x7FFFFFFF & buffer[i];
//int count = 0xFF & buffer[i];
for (int j = 0; j < count; j++) {
- decodedBuffer.add(buffer[i-1]);
+ decodedBuffer.add(old);
}
} else {
if ((i>=stopCounter-2) && (rleTrigPos == 0)){
rleTrigPos = decodedBuffer.size();
}
decodedBuffer.add(buffer[i]);
+ old = buffer[i];
}
}
// Copy decoded data to buffer.
I also also had a look at the VHDL code but could not find any obvious bug. However, this might be caused by missing experience with VHDL. There are some strange constructs in rle_enc.vhdl where the repeat count is "first" reset to 0 with "ctr <= (others >= '0')" and only "afterwards" it is written to the BRAM, but as this is an FPGA I suppose there is some concurrency w.r.t. to code "execution", so the ordering propably does not matter. BTW, are there free VHDL compilers which could be used to compile the OLS firmware?
I would be quite nice to have the RLE stuff working also with 8 channels, as this would boost the total sampling time considerably. At least for an electronics dummy like me 8 channels will be enough most of the time.
Many thanks for you work and with best regards,
Claus