Dangerous Prototypes

Other projects => Open Bench Logic Sniffer => Topic started by: dogsbody on January 25, 2011, 08:15:05 pm

Title: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Timing
Post by: dogsbody on January 25, 2011, 08:15:05 pm
--  Jan 25 Edit: Release3.  Fixed SPI interface bug causing problems with PIC firmware 2.3. --  Jan 28 Edit: Release4.  Fixed Xilinx XISE to use correct speed grade.  RLE now works!  --  Feb 2 Edit: Release5.  Restored meta data, minor fixes to ensure ram writes what adv-trigger wants captured, & misc logic resets to known state.  Documented the extra RLE-modes.    Also, the verilog port is now on SVN!  --  Feb 8 Edit: Release6.  Removed inclusive-RLE mode, since breaks older clients and is no longer used by Jawi's.  Also fixed 24-bit RLE counts.
--  Feb 23 Edit: Release7.  Fixes problem with demux DDR captures causing bogus glitches, and issue with missed samples when armed.  Also ensures the finish-now command works cleanly, and minor tweaks to the adv-trigger.  Lastly, a full spec at last (see link)!  Note: Please be sure to use Jawi's 0.9.3 release (http://http://dangerousprototypes.com/forum/viewtopic.php?f=57&t=1198) (or newer)!

I've been busy...  A few weeks ago I ported the OLS FPGA into Verilog
(with which I'm more familiar), and started fixing things.

I design fpga's (big one's) for a living, so I quickly saw several areas
where the old design wasn't great.

My version meets timing trivially now.  For fun I threw in a meta ROM &
fixed RLE for all combination's of channels.  Even added that 0x05 command
to disable RLE mode.

I then decided to show you lot exactly what you can do with an fpga.
Too many remarks about difficulty in meeting timing, etc...  :-)

My goal:
  How much of a big HP 16550a timing logic analyzer can it handle?

Answer:
  MOST of it.  Really!


----

My version of the fpga uses 85% of the slices, keeps the legacy triggers,
meets timing easily (at 105Mhz), and adds:

Trigger Terms:
  10 more 32-bit masked value comparisons.
  2 range checks.
  2 edge checks (rising, falling, both, neither).
  2 36-bit timers (10ns to 600sec range).

States:
  16 state FSM
  Each state can use any combination (AND/NAND/OR/NOR/XOR/NXOR) of the
    trigger terms for detecting a "hit" condition, and "else" condition, or
    "capture" condition.
 
  Each state also has a 20-bit hit count that must be reached before a full "hit"
  occurs.  Hit actions include setting trigger(run), starting/stopping timers,
  and advancing to the next state.

  The "else" condition lets you punt to another state.  If neither hit or else
  conditions match, then the state spins.

  The "capture" condition lets you control what gets sampled into RAM,
  until you flip the trigger.

Grab the 16550a user's guide (Google for "HP 16550a" - it's the first hit). 
I think you'll be surprised how much got squeezed in.

The advanced trigger & basic trigger can be used in parallel, though you
lose the advanced trigger conditional "capture".  Arming basic triggers
immediately starts filling the RAM.

----

Commands:
  0x00 = Reset
  0x01 = Arm basic trigger
  0x02 = Query ID
  0x04 = Query Meta Data*
  0x05 = Disable RLE (fifo will fill at normal sampling speed)*
  0x0F = Arm advanced trigger*
  0x9E = Write trigger select*
  0x9F = Write trigger data*

Additional flag register bits:
  Bit 11:  Internal test pattern mode (supplies data internally).
  Bits[15:14]:  RLE-Encoding Mode.

The RLE-Encoding modes are:
0 = Issue <values> & <rle-count> as pairs.  Counts are exclusive of value.  Backwards compatible.
1 = Same as mode 0.
2 = Periodic. <values> reissued approx every 256 <rle-count> fields.
3 = Unlimited. <values> can be followed by unlimited numbers of <rle-counts>.

----

A few details...

I use a low-level FPGA primitive called a LUT-RAM for most of this stuff.
An fpga is a large array of LUT's with a flop (optional) attached.  LUT's
are 16-bit RAM's, and serially configured during bootstrap to describe
combinatorial logic.  Think shift-register.

However...  you can dynamically change the contents of LUT RAM's.  Thus
a single LUT can evaluate 4 bits of indata directly.

I use them for the trigger terms, range checks -- in combination with a
fast-carry-chain primitive -- and edge checks.  I also use them for
combining the results of the trigger terms.

Nothing is entirely free, and configuring this thing is... involved. 
There is something like 10000 config bits.  I've defined two long
commands, for selecting config addresses (0x9E) & writing data to the
trigger (0x9F).  These pump data serially into the LUT RAM's.

As proof of concept, I revamped the legacy/basic triggers to use the
same LUT based logic.  It remains fully client compatible, assuming said
client writes the data & masks for each trigger sequentially.

----

Compiling/Building:

Open "XISEols-verilog.xise" in Xilinx ISE.  Click on "Generate Programming
File", and it should finish within a few minutes easily.  In a tiny fpga like
this, meeting timing at high utilization -should- be easy.

The OLS had combinatorial logic between I/O & the first flops (big no-no in
an fpga), and was using negedge flops at the SRAM interface which cut the
timing budget in half.  There was an asynchronous timing hazard between the
sampled data & core logic.  Also various other places with smaller issues. 
All fixed now.

Verilog Source Code on Gadget Factory SVN (http://http://gadgetforge.gadgetfactory.net/gf/project/butterflylogic/scmsvn/?action=browse&path=%2Ftrunk%2FVerilog_Core%2F)

----

Simulating:

I use Icarus-Verilog to simulate it.  Scripts are provided to launch
simulations & view results in GTK.

----

I've written a full spec (http://http://www.mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.pdf) for this, but in addition "testbench_adv.v" shows the
various options.  The heavy lifter is in "trigger_adv.v"

My next big project is writing a client app to program the triggers.
In the meantime, I hope you like it!  :-)

You can download the FPGA image to OLS using ols_loader (use *.MCS file), or my
Windows GUI Image downloader (use either MCS or BIT file).  Available here:
-- Logic Sniffer Image Loader (http://http://www.mygizmos.org/ols/olswinloader.html) --

Logic Sniffer Specification for Demon Core FPGA available here:
-- Word format (http://http://www.mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.doc) (1.1 MB) --
-- PDF format (http://http://www.mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.pdf) (674 KB)--

Enjoy!
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 25, 2011, 08:52:05 pm
Fantastic! Thank you, this is a major contribution to the world of open source.

Thank you also for the excellent writeup. You make it all sound so easy ;)

I'll take a look at the options in the source and see if I can outline the spec on the protocol wiki page. I've been meaning to make our own version with the other SUMP commands too.

Looks like Jawi will have his hands full adding features to the client ;) (just kidding, kinda)

Quote
Even added that 0x91 command to disable RLE mode.

I think we decided to go with 0x05 because the higher commands are 5byte commands.

Thanks again, I'll post a call for testers, and test it myself first thing tomorrow morning.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 25, 2011, 09:43:36 pm
[quote author="ian"]
I think we decided to go with 0x05 because the higher commands are 5byte commands.
[/quote]

Oops, sorry for missing that.  I'll fix it tonight when I get home.  Cheers!
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jack.gassett on January 26, 2011, 02:44:24 am
Awesome!

I'll take a look at it right now.

Thanks,
Jack.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jack.gassett on January 26, 2011, 03:29:02 am
Ok,

Just to clarify, is this supposed to be backwards compatible with the current clients right now? I just loaded it onto my OLS and it is not working with the client. It looks like the identification code that is being returned is cALS.

On a side note, I've been using your OLS_Winloader app and I like it. I meant to post a message to that effect to the thread were it was announced but never got the time. But I have been using it every day, I've also been looking at using it for another board called the Papilio Overshield. I'll probably include it in the next Installer, my only hold up with it is whether or not it can be made cross platform.

Jack.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jack.gassett on January 26, 2011, 03:38:54 am
Ok,

I just looked at the source code and it should be returning 1ALS not cALS... Maybe there is an issue with different versions of the PIC firmware... I'm going to try and setup an IRC channel if anyone wants to help work through this.

Jack.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jack.gassett on January 26, 2011, 03:55:50 am
I just created a Freenode IRC channel named #GadgetFactory. I'm going to be on the channel for the next several hours while I take a look at this release. Anyone is welcome to join and help out.

Thanks,
Jack.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 26, 2011, 04:08:03 am
Yes, it should be compatible with clients.  I'm heading home now & will see what's going on.

As for making olswinloader cross platform...  It's a native Windows MFC app (written using VC6 - ie: old tech).  Might work under Wine for Linux assuming no USB<->Serial port headaches.  I've had lots of trouble with flaky Java serial port stuff, which was the reason I went native. 
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 26, 2011, 05:33:14 am
Ok, I figured it out.    Two things wrong.  First, I screwed up somewhere copying files between machines & damaged the spi transmitter (rather lost a fix).  Damn I feel stupid.  Spend most of my life looking at sim results & never noticed the query ID was fouled up.

Second...  JAWI's client is incompatible with Meta data.  If the fgpa responds to the meta query, OLS hangs up.  :-(    Last time I tested with OLS I guess I didn't have meta in there.

I've fixed the SPI bug & disabled meta data for now.  New image attached.

Sorry 'bout that folks.    First post updated with latest image.
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 26, 2011, 08:22:02 am
Ok, caution is due.  If you're Logic Sniffer PIC has the 2.3 firmware my release2 fpga won't work.  Jawi's client won't see it.  Jack and I spent a couple hours figuring out it why it worked for me (and another) & not him.

Needs to be 2.1 firmware on the PIC.  I suspect there is a SPI clocking issue.  I'm investigating.  I'll know soon what's up...
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 26, 2011, 08:55:25 am
I just did a diff on the v2.1 and v2.3 to try to find anything that would cause this. As far as i can tell, I tool v2.1 and added the algo for the new Winbond ROM, but that's it. I'm going to load up the different combos now and see if I can figure out the difference.

I popped into IRC but it doesn't look like anyone is there anymore.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 26, 2011, 09:27:14 am
Back when I was doing the 'new-SPI' routed version (changing the SPI to share with the ROM pins so we have more extra connections) I noticed that the UCF didn't actually match the pins connected to the PIC. The CS pin was the wrong FPGA pin, as far as I could tell the old bitstream didn't use it. I did some extensive testing and it worked no matter the pin (coupling?). I'll check this out to see if there was a change I can track it to.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 26, 2011, 09:50:46 am
Code: [Select]
#define TRIS_FPGA_DATAREADY	TRISBbits.TRISB1
#define PIN_FPGA_DATAREADY PORTBbits.RB1

#define TRIS_FPGA_CS TRISAbits.TRISA1
#define PIN_FPGA_CS PORTAbits.RA1

This is the assignment in v2.0-v2.3 (not v2.2)

DATAREADY=B1=FPGA_AUX2=P35=DATAREADY
CS=A1=FLASH_SO=P44=CS

That all checks out, I wonder what the problem I had was. Maybe I assigned something wrong and it worked anyways, I don't recall. Too bad, it would have been an easy fix.

I have a test bench setup and I will test o n my olses now.

Other notes:

SPI speed and settings are the same between versions. I'll look up the exact config and tell you the phase, etc.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jawi on January 26, 2011, 09:54:45 am
Dang, things move fast now!

@dogsbody: That is something really impressive work you've done! I'll load it into my own OLS when I get home;

@all: I've got a couple of spare hours left the next couple of days, will use them to incorporate the changes needed for the new firmware...
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: rsdio on January 26, 2011, 09:57:32 am
First of all, I want to say that this is an awesome contribution!  Learning FPGA is on my to-do list, but everyone here seems to be trying to learn.  Having you come in with your experience is a great boost to the OLS as a tool, and to the community as a learning opportunity.  Thanks!

[quote author="dogsbody"]My version of the fpga uses 85% of the slices, keeps the legacy triggers, meets timing easily (at 105Mhz), and adds:

Trigger Terms:
  10 more 32-bit masked value comparisons.
  2 range checks.
  2 edge checks (rising, falling, both, neither).
  2 36-bit timers (10ns to 600sec range).

States:
  16 state FSM[/quote]Don't lose track of the 200 MHz mode of the OLS.  It drops the maximum channels from 32 to 16 (i.e., it drops from 4 groups to 2 groups), but it is highly useful for systems like the 108 MHz DSP platform that I am developing.  I suppose that since the old FPGA configuration handled 200 MHz at the edge of timing, then your improvements certainly should still handle 200 MHz, but I wanted to mention it here to be sure - in other words, I'd hate to see 200 MHz scrapped in favor of new HP 16550A features.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 26, 2011, 10:08:44 am
Mine has the same error. I am doing a capture on it now.

Test:

Upload verilog bitstream
Upload v2.1 FW
Send 0x02 in Hercules, get 1ALS
Upload v2.3 FW
Send 0x02 in Hercules, get no reply

Verified for good measure.

Test bench is attached.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 26, 2011, 10:37:51 am
rsdio, the fpga never actually runs at 200Mhz.  It performs double-data-rate sampling at 100Mhz to capture 200Msamples/sec.  It actually has a better-than-ever chance of actually doing that now.  :-)

Ian, I've hooked a scope & the only difference I see is on MOSI.  With the dynamic_depth bitfile, MOSI behaves differently than with my bitfile.  MOSI is the output from the PIC, so something is up there.

Assuming the client is trying to write 0x02 (the Query ID) command, with dynamic-depth.bit, MOSI is initially high & is left high afterwards:
Code: [Select]
 SCLK:  0000000011100011100011100011100011100011100011100011100000000
 CS:    1110000000000000000000000000000000000000000000000000000000111
 MOSI:  1111110000000000000000000000000000000000011111100000011111111
With my bitfile, MOSI is initially -low-, and remains low afterwards:
Code: [Select]
 SCLK:  0000000011100011100011100011100011100011100011100011100000000
 CS:    1110000000000000000000000000000000000000000000000000000000111
 MOSI:  0000000000000000000000000000000000000000011111100000000000000

Under simulation, my fpga immediately asserts "dataReady".  Nothing happens here.
It's almost as if the fpga is stuck in reset, or the dataReady pin is being held down. 

I'm going to make a test image to pulse one of the LED's at a slow rate.  A sign
of life heartbeat next...

-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 26, 2011, 10:42:41 am
Tied it up to a LA, and sure enough the PIC sends properly but never gets a dataready reply.

Questions:
1. Is dataready ok - is it setup and an  input on the PIC? (seems like yes)
2. Is the ROM held in reset (yes, did a logic check)
3. Is it something during the setup phase - does the PIC engage the pins differently. I'll get these captures now.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 26, 2011, 10:49:53 am
Looks like we posted at the same time. I'll capture the dynamic one now for comparison
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 26, 2011, 10:54:48 am
I'm posting this for comparison. This is v2.3 firmware with 2.12 bitstream. I'll try with v2.1 now too.

The MISO is high at beginning and end.

MOSI stays high between 0x02 and reading the data too.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 26, 2011, 11:07:43 am
Found it.  Problem in my spi_receiver.  Something about the 2.3 firmware was managing to confuse it.  It's more robust now, and works!!!

Whew!  Must be something to that "third-times-the-charm".

Is there any way to go back & edit the first posting to use this attachment?  The old board used to allow editing, but this one doesn't.

-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 26, 2011, 11:10:45 am
Fantastic! I still wonder what the difference is. When you have a new synthesis I'd like to give it a spin under debug.

-------------
I attached teh v2.1-dynamic above. Here si what I can tell:
1. Dynamic bitstream always has MISO high at start and finish. Both verilog tests always have MISO low (at start and finish).
2. Dynamic bitstream always has MOSI high between writing and the next read. The verilog version has it low in both cases.

I guess the question is - who is holding what high when, and to whom does it matter. I'll runt he PIC under debug and check the registers to be sure.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 26, 2011, 11:11:31 am
Thanks for letting me know about the edit issue, everyone should be able to edit their posts. I'm still getting it figured out.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: rsdio on January 26, 2011, 11:14:46 am
[quote author="dogsbody"]rsdio, the fpga never actually runs at 100Mhz.  It performs double-data-rate sampling to capture at 200Mhz.  It actually has a better-than-ever chance of actually doing that now.  :-)[/quote]I was aware of that, thanks to the excellent hardware documentation of the OLS from Jack and Ian.  However, I didn't realize that you were talking about the clock frequency of the FPGA as opposed to the sample rate of the OLS function.  Now that I think about it, you're saying that your new FPGA configuration is so efficient that you could overclock the chip to 105 MHz and it would still work (meaning the 200 MHz sampling would be running at 210 MHz).  Fantastic!

(P.S. I wrote Fantastic! before Ian's post came through...)
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 26, 2011, 11:16:44 am
The edits should be fixed. I see you attached a new version - sorry, I'm one step behind. The 'new message' warning didn't show that there was a file attached. I'll test now.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 26, 2011, 11:29:11 am
Verilog v3 + v2.3 is attached. It looks just like the successful verilog before (unlike dynamic nothing is high)

On reflection - while I'm very confused about the difference between v2.1 and v2.3 caused the issues, I do remember a 'problem' with the (FPGA) SPI module. I was using SUMP core in another project and I had to ensure that MOSI (?) was high in idle or there were various problems (no data, dataready stuck with, etc). That does not seem to be the case here.

I have one more idea for a test to try.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 26, 2011, 11:30:01 am
[quote author="rsdio"]you're saying that your new FPGA configuration is so efficient that you could overclock the chip to 105 MHz and it would still work (meaning the 200 MHz sampling would be running at 210 MHz).  Fantastic![/quote]
Thanks, and Yes! 

It's actually even better than that...  I'm forcing the tool to assume clock jitter of 1ns, in addition to requiring the 105Mhz.  Without the jitter setting, it'd hit 120Mhz easy.  Not a good idea though to remove the jitter constraint.

btw, without the advanced trigger the fpga would hit 150Mhz easy (or 300 DDR Msamples/sec).

All that logic does slow thing down...  <sigh>  :-)
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 26, 2011, 11:51:43 am
I ran some tests without the FPGA in the loop. I booted as normal, test the 0x02 reply, then placed a jumper over PGM to hold the FPGA in reset. I attached dataready to ground through a 1K resistor to stop random data.

I did two tests:
1. I connected the MOSI and MISO pins to ground with a 1K resistor. The Saleae stays high when a pin is floating, so I wanted to tell the difference between floating and ground. Here you can see that MISO stay low before/after EDIT: MOSI is high before and low after...
2. Left all pins floating. Here MISO (floating) is high as expected. What is strange is that MOSI is also high at the end of the 0x02 write. Since it is low with the resistor, I have to guess the PIC is floating MOSI between bytes. That doesn't make any sense though.

Is there any kind of bus keep or pullx on your pins?
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 26, 2011, 12:19:42 pm
[quote author="ian"]Is there any kind of bus keep or pullx on your pins?[/quote]
Not to my knowledge.  I avoided changing the I/O's, except for the addition of timing constraints. 

I'm off to bed now.  Shall pick this up tomorrow.  Cheers!
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 26, 2011, 12:44:27 pm
I made a new firmware with the SPI LAT pins being set instead of the PORT pins. Technically writes to PORT are supposed to go to LAT, but sometimes the compiler is stupid.

No, during setup, the SPI outputs are configured through LAT instead of PORT. The PPS is supposed to handle all of that when it is configured.

That seems to fix it with the Verilog 2.

I loaded the v2.12 bitstream to test that, it seems to be compatible. You can see in the LA output attached that it still doesn't match the Verilog version.

Is it possible that the Verilog version holds MISO low even when CS is high?

I can't explain MOSI being high between 0x02 and reads on one and low on the other.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jawi on January 26, 2011, 04:07:45 pm
Did some quick testing on the latest bitstream (v3) on FW2.3 and it works well: the OLS does return test sample data.
However, I don't see any reaction on the metadata command (while the latest BP firmware does react).

[s:]Another thing regarding the RLE implementation: how does the encoding for 8 & 16-bit work? Similar as to the firmware of Rasmus, or ...?[/s:]

edit: did some simple tests on RLE and can confirm 8-bit RLE works, though the count appears to have a off-by-one bug... Will do some additional testing (also for 16-bit and 32-bit) tomorrow...
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 26, 2011, 06:53:26 pm
Quote
Ian wrote: Is it possible that the Verilog version holds MISO low even when CS is high?
Oh dang...  Everything makes sense now.  There was a problem with the "SLA1" signature getting fouled up, and I discovered I'd lost an edit in spi_transmitter.  Then all the problems started, ending with the fix in spi_receiver.    So I shot my left foot, trying to fix having shot myself in the right.  Nice.  Doh!!!

An object lesson in not designing hardware when tired...


Quote
jawi wrote:  However, I don't see any reaction on the metadata command (while the latest BP firmware does react).
I originally had meta.  However, OLS 0.9.2 didn't like it.  It wouldn't capture, and displayed "Capture aborted: -1".  Got distracted by the SPI bug before I could figure it out, and then needed sleep at 3AM.  I did try varying the number of null's at the end to no avail.    I wrote my own test program & was able to see that data.   

The sequence output is:

Code: [Select]
0x01 "Open Logic Sniffer v1.01" 0x00
0x02 "3.00" 0x00
0x21 0x00 0x60 0x00 0x00    // 24K samples
0x23 0x00 0xC2 0xEB 0x0B    // 200Mhz
0x40 0x20  // 32 probes
0x41 0x02  // Protocol 2
0x00

The meta ROM is in "meta.v".    To enable the command, the decode in "spi_slave.v" must be uncommented.  I've made a test image with meta back for you (see attached).
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 27, 2011, 01:16:46 am
[quote author="jawi"]did some simple tests on RLE and can confirm 8-bit RLE works, though the count appears to have a off-by-one bug....[/quote]
Should work with all combination's of channel groups.  Any 8-bit channel, any two channels forming 16-bits, any three for 24-bits, etc...

Are RLE counts too big or too small?    I'll check the rle code when I get home & see what I flubbed.  It did get a heavy rewrite to simplify things (for timing purposes).
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jawi on January 27, 2011, 11:12:30 am
@dogsbody: thanks for the new bitstream! Indeed my client had a bug which was related to this metadata reading. Byte order is still an issue here (little vs big endian). I think we need to "standardize" the way 32-bit values are sent along the line.

Regarding the RLE-count: I need to add one to the obtained RLE-count to get the "correct" count values for 8, 16 and 32 bit RLE encodings. I've tested this with the 1kHz reference signal from my scope.

One observation I see is: when using a sample rate of 500x (e.g. 500kHz) or more the original signal, the RLE encoding seems to introduce a lot more errors. This also seems to depend on the number of sampled channels. Will investigate this further to see whether a pattern can be observed in this...
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 27, 2011, 11:20:44 am
Ah...  RLE counts are too small then.  Easy fix.

For meta byte order, I didn't see anything stating how it should be.  So I copied the long commands (LSB first).  Switching is trivial though, since data is stored in a ROM.

As for noise... is this only with my image, or do you see it on others fpga's also?    The reason I ask is the OLS does pickup a lot of junk if there are dangling wiring harness pins.  They act like antennas...  Any not being used should be grounded. 

The Logic Sniffer could probably use 50K pulldown's or something on the 16-bit buffer...
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jawi on January 27, 2011, 12:01:49 pm
I did some tests a while ago with the 2.12 bitstream and did not observe this behaviour there. But, just to be sure will load up one of the 'original' bitstreams to see if it occurs there as well...
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 27, 2011, 12:32:14 pm
[quote author="jawi"]I did some tests a while ago with the 2.12 bitstream and did not observe this behaviour there. But, just to be sure will load up one of the 'original' bitstreams to see if it occurs there as well...[/quote]

Loose cables really do pick up lots of junk.  I see it all the time on my mine.  Try not to change -anything- about your setup between tests, other than the fpga images.    Apples-to-apples 'n all that.

Got another test image for you.  The rle counts are fixed, and byte order of meta dwords is reversed. 

I'm a little puzzled by the rle counts.  Not seeing how the vhdl 2.12 version has the "correct" behavior, but my grasp of vhdl isn't great.  Probably missing something obvious. 

Anyway, enjoy!  I'm off to bed now (3:30AM)...
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jawi on January 27, 2011, 03:14:23 pm
[quote author="dogsbody"]
Loose cables really do pick up lots of junk.  I see it all the time on my mine.  Try not to change -anything- about your setup between tests, other than the fpga images.    Apples-to-apples 'n all that.
[/quote]

The test setup is simple (and remains untouched): 1kHz signal on channel 0, channels 1..4 are grounded. I've used this for all tests I've done so far.

[quote author="dogsbody"]
Got another test image for you.  The rle counts are fixed, and byte order of meta dwords is reversed. 
[/quote]

Looks good! The RLE count is correct now, and I no longer have to transfor the endianness of the metadata.

[quote author="dogsbody"]
I'm a little puzzled by the rle counts.  Not seeing how the vhdl 2.12 version has the "correct" behavior, but my grasp of vhdl isn't great.  Probably missing something obvious. 
[/quote]

The 2.12 version, as far as I can remember, only supports 32-bit RLE count values. And there appears that sometimes one bit of the count is flipped (as David Francis already found out in the forum).

One thing: I think the RLE-count can "overflow" in your version, causing incorrect results. According to my tests, the version made by rasmus does not show this behaviour, or are less influenced by count-overflows...

Keep up the good work (and sleep well ;))! As soon as the RLE is a bit more stabilized, I can start focus on other additions your firmware provides...
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jack.gassett on January 27, 2011, 07:16:29 pm
I was figuring that I would give this another day or so and then I would put together an official Test Release so that more people could check out this new version.

Jack.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: DavidFrancis on January 27, 2011, 08:12:19 pm
I have been testing dogsbody's ols_verilog_meta2 bitstream and finds that it handles rle counter rollover slightly differently to the other bitstreams. the others  outputs a data word between count rollovers whereas this one does not. This is not handled correctly in Jawi client as all counts except the last  are ignored . This is more noticeable at 8 bit captures as rollover occurs more frequently. I think this new bitstream is this best way though as it allows slightly more samples.
I also found the 24 bit rle to does not output the counter correctly in that it outputs the most significant byte as all zeros so it does not show as a count.
I think this great work and I look forward to testing the advanced trigger option.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jawi on January 27, 2011, 09:13:12 pm
I've taken the liberty to write up a Wiki page on the RLE implementation and the "issues" they might have (read: the client might have ;)). Maybe we can get to more consensus about the implementation details?

http://dangerousprototypes.com/docs/Logic_Sniffer_RLE (http://dangerousprototypes.com/docs/Logic_Sniffer_RLE)
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 27, 2011, 10:13:08 pm
[quote author="DavidFrancis"]I also found the 24 bit rle to does not output the counter correctly in that it outputs the most significant byte as all zeros so it does not show as a count..[/quote]
Yes, of course...  Obvious.  The upper byte isn't output to the client, so no RLE flag.  Here I was thinking 30 bit counts on 24-bit data would be cool.    Oops.    One of the hazards of unit testing.  My rle testbench checks -only- the RLE module, so I overlooked this detail.  Stupid of me.  Sorry 'about that.

As for value/count pairing, I should probably do that also -- even though it wastes space -- for client compatibility more than anything.  Perhaps a flag bit to make it optional.

[quote author="jawi"]I've taken the liberty to write up a Wiki page on the RLE implementation and the "issues" they might have[/quote]
Whatever you guys want I'll provide.    Count values as repetitions, my original approach (rle-count of 4 means 5 samples total) has the advantage of allowing two bytes indicate 128 samples versas 127 (in 8 bit mode).  Otherwise, no difference. 

Repetitions, without value between rle-counts, could pack 3121026 captures of non-changing 8-bit data.  Repeat count (rle-count of 4 means 4 samples total), with values per, can record 1560576 captures.  About half.  However, if the RAM capture wraps around you lose the initial value - a bad thing.  Perhaps a mode where the value is output once every 256 bytes?  That could pack 3109056 captures -- or 3076670 if we lose the first value.

btw, any chance of getting a data capture of the "noise" you see?  Also an example of the overflow.  Might help me narrow down what's going on...  Raw capture data from the serial port would be preference, along with value written to the "flags" register.

Thanks!
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jawi on January 28, 2011, 12:14:21 am
[quote author="dogsbody"]
[quote author="jawi"]I've taken the liberty to write up a Wiki page on the RLE implementation and the "issues" they might have[/quote]
Whatever you guys want I'll provide.    Count values as repetitions, my original approach (rle-count of 4 means 5 samples total) has the advantage of allowing two bytes indicate 128 samples versas 127 (in 8 bit mode).  Otherwise, no difference. 

Repetitions, without value between rle-counts, could pack 3121026 captures of non-changing 8-bit data.  Repeat count (rle-count of 4 means 4 samples total), with values per, can record 1560576 captures.  About half.  However, if the RAM capture wraps around you lose the initial value - a bad thing.  Perhaps a mode where the value is output once every 256 bytes?  That could pack 3109056 captures -- or 3076670 if we lose the first value.

btw, any chance of getting a data capture of the "noise" you see?  Also an example of the overflow.  Might help me narrow down what's going on...  Raw capture data from the serial port would be preference, along with value written to the "flags" register.[/quote]

What I already posted in another thread (http://http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=1473&p=16661#p16654), the RLE-count of 4 meaning 5 is no problem to me. If multiple consecutive RLE-counts can occur (which should be added to get the 'real' RLE-count) that is also fine, as long as it is a bit consistent among the various firmwares.

I'll redo the tests I've done today to see if I can provide you the noisy signals in some way. Now it's time for me to go to bed... ;)
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: rsdio on January 28, 2011, 12:22:07 am
[quote author="DavidFrancis"]I have been testing dogsbody's ols_verilog_meta2 bitstream and finds that it handles rle counter rollover slightly differently to the other bitstreams. the others  outputs a data word between count rollovers whereas this one does not. This is not handled correctly in Jawi client as all counts except the last  are ignored . This is more noticeable at 8 bit captures as rollover occurs more frequently. I think this new bitstream is this best way though as it allows slightly more samples.[/quote]I agree with your assessment that the bitstream should be as efficient as possible.  Since the count words have a bit to flag them as not being a data word, it should not be confusing to skip the data word between count words.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: rsdio on January 28, 2011, 12:31:49 am
[quote author="dogsbody"]Whatever you guys want I'll provide.    Count values as repetitions, my original approach (rle-count of 4 means 5 samples total) has the advantage of allowing two bytes indicate 128 samples versas 127 (in 8 bit mode).  Otherwise, no difference.[/quote]Jack - the originator of the OLS design, I believe - was looking into using the spare bits of the 18-bit BRAM as the RLE flag.  Thus, 8-bit mode would have 8-channel data words and 8-bit count words, so we're talking about allowing 256 or 257 samples versus 255 (see my other post, here (http://http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=1473&start=90#p16680)).

But using the 18-bit BRAM for out-of-band RLE flags calls up a question about the stream design.  USB is an 8-bit transport, and so is the CDC serial layer (although I suppose you could set 7-bit, 8-bit, or 9-bit with serial).

I'm asking: What do we do about 32-bit mode if the RLE flag is a 33rd bit?  16-bit mode with RLE flag as a 17th bit?  8-bit mode with RLE as a 9th bit?  These bitstreams match the logic analyzer inputs more conveniently, but they make the RLE-encoded data more tricky to transport.  Any ideas?

I'm assuming that dogsbody can handle accessing the extra 2 bits of the BRAM in the FPGA as Jack was planning.  This seems like a good way to get the maximum use out of the FPGA, and might even simplify things by placing the RLE flag in a consistent location.  There's even the potential for a 2nd flag, although I can't imagine a use for that just yet.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 28, 2011, 12:48:48 am
[quote author="rsdio"]I'm assuming that dogsbody can handle accessing the extra 2 bits of the BRAM in the FPGA as Jack was planning.  This seems like a good way to get the maximum use out of the FPGA, and might even simplify things by placing the RLE flag in a consistent location.  There's even the potential for a 2nd flag, although I can't imagine a use for that just yet.[/quote]
Absolutely.  There are 4 extra bits available (we've a 6k x 36 bit RAM to play with).  So we -could- have 256 counts per 8 bit sample (8 bits + rle-flag), 128k counts per 16 bit sample (16 bits + 1 extra + rle-flag), and 32 Gsamples per 32 bit rle count (32 bits + 3 extra + rle-flag).    Over five minutes of non-changing captures per 32-bit word at 100Mhz!!  Weeks for 6k samples!!

The upload bitstream would change though.  Simple is probably best.  Something like:   

8-bit:  <value><rle-count>
16-bit:  <value-b0><value-b1><rle-count0><rle-count1><rle-count2>
32-bit:  <value-b0><value-b1><value-b2><value-b3><rle-count0><count1><count2><count3><count4>

[ -- edit:  just realized my rle-count sizes were off for 16-bit & 32-bit -- ]

All samples would have counts following.  Very doable.
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jack.gassett on January 28, 2011, 02:41:20 am
Quote
The upload bitstream would change though. Simple is probably best. Something like:

8-bit: <value><rle-count>
16-bit: <value-b0><value-b1><rle-countlo><rle-counthi>
32-bit: <value-b0><value-b1><value-b2><value-b3><rle-countlo><rle-counthi>

All samples would have counts following. Very doable.

I was just struggling with this very issue, thank you for bringing it up rsdio. Before dogsbody posted his code I had the rle bit setup to roll along with the rest of the memory and had everything routed to the necessary modules. It gave me pause once I realized that the only good way to do this was to add another RLE byte. I was planning on coordinating with Jawi to make it happen when dogsbody came out of nowhere with this awesome contribution!

I like the idea of making the serial bitstream longer, it seems more elegant. But I think we should play it safe and go with additional RLE bytes like dogsbody outlined. Keep in mind that I intend to develop a wireless Wifi option and I don't want to take any chances that the Wifi module will not support anything other than 8N1 communications. I don't think we will notice the extra bytes very much anyways and they are not time critical so the worst thing that will happen is having to wait a little longer for a capture.

Jack.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 28, 2011, 03:00:17 am
[quote author="jack.gassett"]I don't want to take any chances that the Wifi module will not support anything other than 8N1 communications.[/quote]
Exactly my thinking.  I don't think rxtx libraries are guaranteed of being graceful either for non-8N1.

We can compensate for overhead (a little) by tweaking the SPI uplink between fpga & pic.  There is a lot of dead time between bytes.    In response to "dataready", the PIC writes 0x7F to the fpga, which supplies the SCLK pulses the fpga needs to upload data.    The PIC asserts CS, pulses SCLK, deasserts CS, repeats...

If the PIC could handle it, my image can happily output much longer bursts.    If the PIC wrote 64 non-stop 0x7F's (no CS gaps) uploads would be much faster.
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 28, 2011, 08:02:44 am
Quote
If the PIC could handle it, my image can happily output much longer bursts. If the PIC wrote 64 non-stop 0x7F's (no CS gaps) uploads would be much faster.

It should be doing that now.

Code: [Select]
			//give preference to bulk transfers from the FPGA to the USB for best speed
if((PIN_FPGA_DATAREADY==1)){//test for bytes to send from FPGA to USB
if((uartincnt<USB_OUT_BUF)){//test for free buffer space
//get SPI to buf
PIN_FPGA_CS=0;
PIN_LED=1;

//continue to fill the USB output buffer while
// there's free space and the data pin is high
while( (PIN_FPGA_DATAREADY==1) && (uartincnt<USB_OUT_BUF) ){
//FPGA buffer is NOT bidirectional! This does not work (yet)
//if we have data waiting to go, send it with this read
//if(usbbufgetbyte(&inbuf)==0){
// inbuf=0x7f; //send no command to FPGA
//}

buf[uartincnt] = spi(0x7f); //spi(inbuf);
++uartincnt;
Nop(); //if the FPGA needs time to raise/lower the read flag, need to see a logic capture to be sure
Nop();
}

PIN_LED=0;
PIN_FPGA_CS=1;
}//end buffer check

}else{

It is supposed to loop as long as the dataready flag is high and there is room in the USB buffer (up to 64 bytes).

I can connect a logic analyzer and see what is going on.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 28, 2011, 08:08:48 am
I'm going off what I remember when debugging the SPI issue, and capturing query ID reads on my scope.  My PIC was running the older firmware at the time (OLSv1_firmware_v2.1).  Maybe it was changed for 2.3?
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 28, 2011, 08:52:28 am
The loop was a define in v2.1, but we have used it as the default since v2 at least.

These captures show v2.1 and v2.3, they both seem to keep CS high for the entire ID command (doesn't say anything about the data though):
viewtopic.php?f=23&t=1711&start=15#p16560 (http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=1711&start=15#p16560)

Will your new SPI module handle higher speeds? I think in the past we had to run the PIC SPI at a fairly low speed or we had problems. Is the 0x7F also needed anymore? I recall it was required in the VHDL version or it wouldn't spit out data.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 28, 2011, 09:05:07 am
Hmmm...  My memory must be mush from working late.  I clearly remember big gaps between the bursts of SCLK pulses & could have sworn CS was deasserting. 

As for higher speeds, the fpga should handle no problem.  I'd say up to 10Mhz easy (3X).  The 0x7F is needed  though.  The fpga's spi_receiver doesn't care about transmit data, so if it sees CS & SCLK, it grabs bits.  The 0x7F NOP's it.  If you output zeros, you'd reset the fpga. 

If you want to avoid 0x7F's, we'd need a separate CS to enable transmit.  Wouldn't really be SPI, but who cares?
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 28, 2011, 09:20:32 am
There's no reason to avoid 0x7F. I didn't know that the FPGA did anything with the data that is clocked in while the dataready flag is high, that makes sense. In the beginning I did some tests to see if it was truly bi-directional (try to get a second 1ALS by sending a second 0x02 while the first 1als is being clocked out), but it didn't work (not that it needs to or should, I just like to poke at things).
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 28, 2011, 09:33:14 am
Sounds right.  Once the spi_transmitter gets busy it ignores query commands.  However, the fpga -is- bidirectional & processes commands.  So you can write regs & change things no problem.
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 28, 2011, 10:43:30 am
Just discovered what I think is the cause of RLE issues... 

My Xilinx XISE environment had the -5 speed grade Sparten 3E selected (the high performance flavor).  How that happened I've no clue.  With the -4 grade timing I needed to change clock constraints back to 100Mhz from 105Mhz (oh well).  Compiles clean with no timing violations & RLE appears to work fine now.

Still don't have meta data enabled, since OLS 0.9.2 doesn't like it.    New release4 fpga image is available in the first post of this thread.  Anyway, enjoy!
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jawi on January 28, 2011, 11:15:29 am
@dogsbody: I'll do a quick test with release 4, and then make a beta of 0.9.3 which should work a lot better with both the RLE and metadata commands... I'll keep you posted.

edit: I've uploaded a beta of the 0.9.3 release for everybody interested, see the client topic (http://http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=1198) for the download link(s)...
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: kandos on January 29, 2011, 06:26:04 am
I have upgraded my ols to the new ver4 and thought i would use it  to debug a Playstation2 game controller to usb converter i built with a pic 18f4550.(I know i could buy one real cheap but i have some spare pic's and i learn more if i build things myself ).

Found the problem i was having and the controller is now functioning in windows,The Pic code (asm) i use  for the controller is software spi with a 9 byte packet LSB.

configuration is 
         0x01 0x43 0x00 0x01 0x00 0x00 0x00 0x00 0x00
          0x01 0x44 0x00 0x01 0x03 0x00 0x00 0x00 0x00

it then just loops sending 0x01 0x42 0x00 0x00 0x00 0x00 0x00 0x00 0x00 to "read" the controller.
If i do a capture without RLE and trigger on c/s low i can get the first 2 packets as seen here.
[attachment=1]
It is possible to see "read" packets if i just do a random capture with no trigger, but I was trying to see a few more packets from the start so i thought i could use the RLE and trigger on c/s low , but i can not seem to get a good outcome
as seen here.
[attachment=0]
I have tried various settings to no avail and do not know if there is something wrong with the RLE ,or if i am missing some vital point as to its use.Can anyone give me some advice?
 
I am using the FPGA ver4 and OLS ver0.9.2 (Can not seem to get 0.9.3 working yet).

Nick

P.S To Dogsbody & Jack sorry i left the conversation abruptly the other night but my modem seems to have developed a heat related fault and only works for short periods.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 29, 2011, 07:27:24 am
Looks like the scramble I saw on release3.  Targeting the wrong device created timing violations in the rle module, that messed it up.  Release 4 seems clean though.

If you capture with just RLE & no trigger, does that work?    Is it only the combination?
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: kandos on January 29, 2011, 07:56:25 am
Sorry should have said it is not the combination of RLE & trigger  only happens when RLE is on ,triggered or not.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 29, 2011, 11:51:48 am
In OLS 0.9.2 I'm seeing garbage also.  However...

I've written a test program to capture the output from the FPGA.  The data capture looks completely clean, on all rle settings.  Exactly what I expect, formatted as specified.  Values, rle-count (inclusive of the value), then another value (even if same as last value), followed by another rle-count, etc...

So...  either I'm formatting RLE count values totally wrong, or Jawi has a bit of work left.
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 30, 2011, 04:57:59 pm
I loaded the v2.4 firmware from another thread and the latest Verilog 4 bitstream. I ran the beta 4 Jawi client, and ran portmon to get a look at the activity. In this particular capture it looks like there is no reply to the 0x04 query. I'll do some manual probing now.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 30, 2011, 06:56:10 pm
Query was disabled in release4, because I wasent sure if it'd crash OLS or not.    I subsequently found it was the MSB ordered long data that caused the problem (I think).

Anyway, I uploaded meta3 for Jawi to evaluate:

viewtopic.php?f=57&t=1198&start=30#p16745 (http://dangerousprototypes.com/forum/viewtopic.php?f=57&t=1198&start=30#p16745)

However, that's when all the problems started.    I'm running XP SP3.  Can't understand why 0.9.2 works perfectly & 0.9.3 dies on capture, with an exception in the rxtxserial.dll library.  I've tried updating the system Java to the latest release.  I've flushed the Java caches & felix-caches.  Tried installing under the root directory.  Dunno what else to try.  Ideas?
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 31, 2011, 06:16:42 am
Update!    OLS 0.9.3 works, along with RLE & Meta data, but is -sensitive- to high COM port numbers.  If your Logic Sniffer appears on port COM10 or higher, it will fail. 

On Windows, go into the device manager.  Select Ports (COM & LPT).  Open properties on port the Logic Sniffer currently resides (ie: COM11).  Click on "Port Settings" tab.  Click "Advanced..." button.  On bottom of dialog is "COM Port Number".  Choose one less than 10.  Click OK, and OK again.  Open 0.9.3, select the new COM port and it should work!

Windows might say the new COM is in "use", but likely just reserved it for another unplugged USB COM port device.  In other words, it's safe to ignore the warning.

Hopefully Jawi can now fix the bug properly to avoid anguish among the newbies.  :-)
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 31, 2011, 08:30:00 am
Great news, I'm glad you got it going! That frees up my morning for some other debugging :)
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jawi on January 31, 2011, 11:53:58 am
I've uploaded a new beta (6) which should solve the COM-port bug on Windows platforms. See this post on the client releases topic (http://http://dangerousprototypes.com/forum/viewtopic.php?f=57&p=16850#p16850) for details.

Now on with all other issues I came across recently... ;)
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on January 31, 2011, 12:37:16 pm
I tried it on XP-SP3 with both meta3 and verilog4 bitstreams, it seems to work ok (no crashing).
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jack.gassett on January 31, 2011, 07:09:45 pm
It looks like things are starting to solidify, I would like to get the code officially checked into svn and make an official Test Release.

@dogsbody
Are you ok with svn? If you create an account at gadgetforge.gadgetfactory.net I will add you as a developer on the OLS project so you can check in code.
If you have concerns or prefer something else just let me know, I should be online in the #GadgetForge IRC channel on Freenode all day.

Jack.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 31, 2011, 07:29:01 pm
[quote author="jack.gassett"]Are you ok with svn?[/quote]
If I need to use SVN, I'll use SVN.  :-)    I think I've got it installed in a VM somewhere.  The flavor I have "helpfully" plugs itself into Windows Explorer, so I relegated it. 

I'll upload the source when I get home tonight.
--IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: jack.gassett on January 31, 2011, 07:36:30 pm
@dogsbody

I use TortoiseSVN under Windows, it is a nice interface. I can get the initial code checked into svn so you don't have to worry about all of that hassle.

Jack.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on January 31, 2011, 07:50:03 pm
Sure, that's fine.  There are some minor tweaks I've made since release 4, but sounds like a good starting point. 

In my earlier quest to get RLE & OLS working (before I discovered the speed grade thing), I disabled meta & added some synthesis directives to the BRAM instances that can foul up the first output sample.

I've also registered as "dogsbody" on your site now.  Cheers!
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on February 02, 2011, 10:50:57 am
I've just posted Release 5 (see first post in thread (http://http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=1711)). 

This image restores meta data, and has minor fixes to ensure the ram captures what the advanced trigger wants captured (not the cycle before or after).    Also ensures rle-encoder and sram interfaces reset properly to known state, and undoes some unnecessary changes made during early rle debug.

I've documented some "extra" RLE-modes that have been lurking for a while.  If used by the client, they can nearly double the storage of non-changing data.  Not bad for a couple extra lines of verilog.

Lastly, the verilog port is now on the Gadget Factory Official SVN (http://http://gadgetforge.gadgetfactory.net/gf/project/butterflylogic/scmsvn/?action=browse&path=%2Ftrunk%2FVerilog_Core%2F)!  Thanks to Jack for hand holding me through the process!   

Note: Please be sure to use Jawi's 0.9.3-b6 release (http://http://dangerousprototypes.com/forum/viewtopic.php?f=57&t=1198) (or newer)!  Solid RLE support & all Windows issues vanquished!
 
Enjoy!
--IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on February 02, 2011, 01:16:20 pm
Here's the bitstreams in a .zip for anyone following without SVN mojo.
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: dogsbody on February 02, 2011, 06:25:14 pm
Good idea!  Although my release zips have the bitstreams, many people would probably prefer not wading through the source files.  I've attached your Verilog-5 zip to the first post.  Also tossed in a couple comments for newbies.  Cheers!
-- IED
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on February 02, 2011, 06:47:53 pm
I forgot to try the first post :) I followed the link to SVN and the download link dumped everything in my browser as text. It seems like several people are following and testing, so I thought that might help someone else out and score a few extra testers. I'll stay quiet and just check the first post from now on :)
Title: Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
Post by: ian on February 07, 2011, 06:22:33 pm
This firmware (v2.6) has a faster PIC->FPGA SPI clock to take advantage of the increased abilities of the new core. This will be buggy with the old core, though I have not seen issues with the new core:

viewtopic.php?f=23&t=1802 (http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=1802)
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dogsbody on February 08, 2011, 06:43:32 pm
I've just posted Release 6 (see first post (http://http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=1711) in thread).

I've removed inclusive-RLE mode, since it breaks older clients and is no longer used by Jawi's.  There was some confusion early on about how rle-counts should work, and now the last vestige of that is gone. 

This image also fixes an issue with 24-bit rle-counts found by David Francis.  So cudo's to him.

Note: Please be sure to use Jawi's 0.9.3 release (http://http://dangerousprototypes.com/forum/viewtopic.php?f=57&t=1198) (or newer)! 

Enjoy!
--IED
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dogsbody on February 23, 2011, 12:11:04 pm
I've just posted Release 7 (see first post (http://http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=1711) in thread).

Fixes problems found by miro with demux DDR captures causing bogus glitches, and issue with missed samples when armed.  Many thanks to him for putting up with my thickheadedness.   

New image also ensures the finish-now command works cleanly.  Once the rle-mode was disabled, normal capture data could spoof rle-flags & foul up the client display.  Also a couple minor tweaks to the advanced trigger to make it easier to use.

Oh... and finally!  A full spec at last!

Logic Sniffer Specification for Demon Core FPGA available here:
-- Word format (http://http://www.mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.doc) (1.1 MB) --
-- PDF format (http://http://www.mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.pdf) (674 KB) --

Note: Please be sure to use Jawi's 0.9.3 release (http://http://dangerousprototypes.com/forum/viewtopic.php?f=57&t=1198) (or newer)!

Enjoy!
--IED
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: jawi on February 23, 2011, 12:52:23 pm
Good work, Ian! And thanks for the detailed specification! I was meaning to contact you about this already, but that is no longer needed! :)
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: pppd on February 23, 2011, 01:05:29 pm
[quote author="dogsbody"]Oh... and finally!  A full spec at last!

Logic Sniffer Specification for Demon Core FPGA available here:
-- Word format (http://http://www.mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.doc) (1.1 MB) --
-- PDF format (http://http://www.mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.pdf) (674 KB) --[/quote]

That's truly awesome! It will surely help me work on a little "secret" project of mine :)
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: ian on February 23, 2011, 01:47:02 pm
fantastic, thanks dogsbody. A wiki version is going up now here:
http://dangerousprototypes.com/docs/SUM ... umentation (http://dangerousprototypes.com/docs/SUMP_logic_analyzer_Verilog_Demon_core_documentation)
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: alexwhittemore on February 23, 2011, 02:56:36 pm
Holy crap! That document is glorious!
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: kandos on February 23, 2011, 06:48:40 pm
[quote author="alexwhittemore"]Holy crap! That document is glorious![/quote]

I agree looks fantastic , a big thankyou to Ian i am at work now but look forward to reading in full when i get home.
Nick
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: ian on February 23, 2011, 07:40:59 pm
Here is a v3 firmware for the PIC:
viewtopic.php?f=23&t=1915 (http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=1915)

I also did a complete refresh of the wiki software reference:
http://dangerousprototypes.com/docs/Ope ... r#Software (http://dangerousprototypes.com/docs/Open_Bench_Logic_Sniffer#Software)

Please let me know if you have any issues. Not a big update, so not too much should change.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: Randy on February 24, 2011, 02:52:04 am
The documentation by dogsbody is superb, great job!
Looks like Verilog-7 fixed the RLE problems I was having.  Before, I was unable to make it work with 8 channels, now it works great.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dogsbody on February 24, 2011, 03:45:49 am
Thanks everyone!  Feels like writing the spec took longer than the fpga sometimes.  Glad it's done!  :-)
-- IED
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: rsdio on February 24, 2011, 07:32:30 am
I agree with the several comments that the "Demon Core" documentation looks great!
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: flubberlab on May 07, 2011, 11:42:42 am
The Demon Core spec is so nice that I thought it deserved some interface details that I think would be especially useful to client developers.  I have attached a revised spec (Track Changes is on). Two operational details that I ran across but have not verified in other docs are
1. Need Reset after capture to make sure next trigger works correctly, and
2. Need basic trigger mask and values copied to upper groups for Demux mode

I found that if I did not reissue a Reset command after a capture, then sometimes the OLS would hang in an armed state on the next capture.

Can someone verify whether or not my revisions to the spec are valid?

One question: Is RLE compatible with Demux mode?

Thanks.


EDIT: Well, it looks like the file is too big to upload. If there is interest in the Word doc, where mayI put it?
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: ian on May 07, 2011, 11:51:33 am
Is it too big if you zip it up? You can also email it to me at ian@ this site and I'll post it up for you.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dogsbody on May 08, 2011, 01:03:17 am
Yup, the spec is definitely on the large size.  It's why I host the spec on my site & provide links in the above postings.

If you email your update to "dogsbody<at>mygizmos.org", I'll update the source where the said links point.  :-)
-- IED
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: flubberlab on May 08, 2011, 06:25:37 am
@ian^2
Thanks. (Can't believe I didn't think about zipping it! But it's still over the 400KB limit.)
I sent it to dogsbody, since it's his baby.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dogsbody on May 08, 2011, 08:24:25 am
Updated spec with flubberlab's changes is now posted. 

I cleaned up the formatting & tweaked a couple things also.  You we're definitely right about it needing a little extra clarity in there. 

Same links as before, but I'll repeat them here:
-- Word format (http://http://www.mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.doc) (1.1 MB) --
-- PDF format (http://http://www.mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.pdf) (674 KB) --

Cheers!
-- IED
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: flubberlab on May 09, 2011, 11:21:57 am
Beautiful. Thanks.

How about another little interface revision: The device returns (readCount + 1) * 4 bytes, so perhaps
"The read-count specifies the number of samples (read_count = (num_samples/4) - 1) to be returned to the client on your PC (one byte per each enabled input channel group). The delay-count specifies the number of samples (delay_count = (num_samples/4) - 1) to capture -after- the basic or advanced trigger fires."
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dogsbody on May 10, 2011, 06:55:55 am
Hmm...  # bytes returned certainly is (readcount+1)*4. 

However, the number of -samples- depends on demux mode if I remember right.  If you're expecting "x" samples, you need to divide by 4 or 8 depending on demux mode since it samples at 2x rate.  Ug.

I'm torn between keeping an relatively easy to understand description for the curious & gory details for developers. 

Maybe another appendix would be better.  Something with example code...
-- IED
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: flubberlab on May 10, 2011, 11:20:14 am
I know what you mean.

I guess the desired content depends on who the spec is written for. I have considered it first and foremost as an interface spec that targets software developers that need to know precisely what the OLS can do and how to make it do it. Perhaps a useful thought is something like this: if it has a command description that includes the numeric opcode and parameter bitmap, then why not go ahead and describe as precisely and completely as possible what the effect of the command is?

I think the fact that it is such a sweet document tempts one to use it as a user guide as well. In an ideal world, I think there would exist both a programmer's guide (your spec) and a user guide.

The way I look at it is I can probably figure out how to use something with only a programmer's guide, but I can't write software to run it with only a user guide. I'd have to reverse-engineer the thing to do that (i.e. create my own programmer's guide).

Thanks for listening.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: flubberlab on May 10, 2011, 11:47:54 am
I noticed something unexpected with the 3.07 Basic/Legacy trigger operation that I think is a good candidate to be described in the spec/guide.

I observed that a trigger stage increments the trigger level even though all of its inputs are masked off. Is this the intended behavior? I expected that the level would not be bumped by the stage configured as such.

This lead me to the question "How do you disable one or more stages?" A workaround I used was to arm the unused stages at a level greater than or equal to the arm level of the capture stage/s with the highest arm level.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dogsbody on May 11, 2011, 11:12:16 am
A masked off bit is basically always a "match".  So if you mask off all bits, then they all match.  Thus the trigger stage trips.  Not a good way to disable a stage.

There is no explicit way of disabling legacy trigger stages.  Setting the start level to 3 is one way of disabling a trigger though.

Another way is not even trying.  Simply configure all stages identically on your first trigger.  Need a second trigger?  Then pick a stage (any stage) & configure it.

The basic trigger isn't a state machine.  Any stage can trigger any other.  The only thing which matters is the trigger "level", and the level increments whenever any of the stages trips.  If one or more trip at the same time, the level only increments once.

This is off the top of my head.  To be honest, I don't use the basic trigger much so haven't given this a lot of thought. 

If it works, let me know & I'll write it up.
-- IED
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: flubberlab on May 12, 2011, 02:36:34 am
@dogsbody,

Thanks for your description; it really corrects my false assumptions about how the trigger works (and gives me the luxury of slacking on learning Verilog or VHDL!).  I can see why masking off bits is exactly opposite the "right" approach to disable a stage.

Here is what I have learned:
--- The mask and value combine to form the classic (on the analyzers I have used) "0, 1, don't care (X)" pattern choices (pattern 0/1/X = mask:value 1:0/1:1/0:?).
--- All stages are permanently active. Each stage either initiates a capture (if configured to do so) or increments the trigger level regardless of its mask.
--- If multiple stages have duplicate masks/values, the group acts together as if it were a single stage, and increments the trigger level only once. If any stage in a group of duplicate stages is configured to initiate a capture, then a capture will be initiated exactly once.

I think your idea of duplicating stages is clearly sound, whereas my idea of relying on setting the arm levels "out of range", is not (to me) obviously--without further analysis--effective for all possible cases.

Duplicating the triggers as you describe works in this simple application I tried. Here are some examples (capture on low to high edge) that illustrate what works and does not:

Stage Level Pattern Capture?
  1    0      0      No   
  2    1      1      Yes   
  3    3      X      No   
  4    3      X      No   
Does work, since desired trigger occurs before "unused" stages 2 and 3 are armed.

Stage Level Pattern Capture?
  1    0      0      No   
  2    1      1      Yes   
  3    0      0      No   
  4    0      0      No   
Does work, since duplicate stages 1, 3, and 4 act together as a single stage.

Stage Level Pattern Capture?
  1    0      0      No   
  2    1      1      Yes   
  3    1      1      No   
  4    0      0      No
Does work, since duplicate stages 1 and 4 act together as a single stage, and stages 2 and 3 act together with stage 2's "yes"-capture overriding stage 3's "no"-capture.

Stage Level Pattern Capture?
  1    0      0      No   
  2    1      1      Yes   
  3    0      X      No   
  4    0      X      No   
Does not work, since "unused" stages 2 and 3 bump level too soon, overriding stage 1. The trigger is effectively "match level 1".

Stage Level Pattern Capture?
  1    0      0      No   
  2    1      0      No   
  3    2      1      Yes   
  4    2      X      No   
Does work.

After some reflection, I guess I blindly jumped into this topic in which to post these functional details because your spec has me thinking what a great single-point source it is to put it all. Maybe the Wiki where ian duplicated your spec is more appropriate, and maybe I could contribute there instead of dropping little crumbs here...  Thanks for having taking on here the deails that are SUMP-common, especially since I understand that your main goal was to do the HP16550.
Walt.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dogsbody on May 12, 2011, 11:04:23 am
Nice.  Glad it worked!

Regarding the spec, I'd also like to have a single-point source (as you say).  Originally the spec just covered the advanced trigger, but I quickly realized a more complete fpga spec would be better.

I also wanted to make it approachable.  Hopefully to interest more people in fpga's if possible.  Thus the background sections, drawings, etc... and my dilemma between gory detail & glazed-over eyeballs.  :-) 

Please feel free to post here (and/or in the wiki as you like) with any comments/nuggets of info!

I'm definitely leaning towards pushing details into an Appendix though.  A programming section covering trigger setup, buffer thresholds, parsing returned buffer data, etc...
-- IED
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: flubberlab on May 12, 2011, 01:50:28 pm
I think the modular format is a good idea also (same as code and hardware). AsI think you mentioned before, the documentation can seem more involved than the implementation--a design in its own right.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: hlipka on May 26, 2011, 09:43:23 pm
[quote author="flubberlab"]I guess the desired content depends on who the spec is written for. I have considered it first and foremost as an interface spec that targets software developers that need to know precisely what the OLS can do and how to make it do it.[/quote]

I recently used a SUMP client to drive a  project I build (sorry, as a new user I'm not allowed to post a link here - you can only google for "a combination of 2-channel oscilloscope" :-) - it was just easier than writing my own client. I found the existing protocol documentation sparse, and in may places unclear and vague. I just had a quick glance at this document, and yet I know that it would have saved me several hours of trial and error... I really understood how the original OLS works (and I'm sure I will understand how the new core works).

Thanks for this great work!
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: ian on May 27, 2011, 08:24:05 am
Sorry about the spam filter. You project sounds interesting. I googled it, but no luck finding it.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: hlipka on May 28, 2011, 08:46:00 pm
[quote author="MickM"]Hi;
is this it?
[/quote]
Yes :) But the referenced project is not the final one - this can be found here: here (http://http://hendriklipka.de/misc/adm_scope_20110421.zip). It contains some bug fixes, several enhancements (e.g. being able to run standalone) and a little bit more documentation.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: chautygorcy on April 26, 2012, 08:42:37 am
I'll take a look at the options in the source and see if I can outline the spec on the protocol wiki page. I've been meaning to make our own version with the other SUMP commands too.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: mrflibble on July 21, 2012, 04:11:49 pm
Are the extra triggering features supported in the current client software?

Reason I ask is I'd like to run it on a nexys2 board, add a few features, and then make sure it'll also run on OLS hardware selectable by synthesis parameter. But for usage of demon core to make sense (over the older SUMP) the extra triggers actually being configurable from the client would be a big plus. ;) Well, aside from my personal preference of using verilog over vhdl.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dogsbody on July 23, 2012, 04:24:00 am
Not that I'm aware of.  Been over a year now with no sign so I'm not hopeful anymore. 
-- IED
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: jawi on July 23, 2012, 09:28:57 am
You've done some great work, Ian! There's some progress to mention on the support, see my reply in this thread (http://http://dangerousprototypes.com/forum/viewtopic.php?f=57&t=4342&p=42715#p42715).
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: mrflibble on July 29, 2012, 02:53:29 am
I've been trying to get it to work on a nexys2 but so far only partial success. I did some rearranging of the modules and I think something got lost in translation... Which leads me to the following question for dogsbody: was there any specific reason to keep the same decoder structure? By which I mean: decoder.v does all of the long opcodes and some of the short opcodes. And the other opcodes are handled directly in spi_slave (or one of it's submodules). When I noticed this structure in the older VHDL version I had one of those wtf moments. But then I see you used the exact same structure in the verilog rewrite. Any specific reason? Or just trying to keep it as close to the original as possible in the first go?

No right or wrong here, more of a bemused "why?". If there's a good design reason for it 1) I don't see it and 2) I'd love to hear about it so I can improve my HDL skills. If it's just "well that's how they did it in the original" then I understand that as well. :P

Reason I bring that up, it may actually be why my current nexys2 version is not working. I tried (and failed) to move all the decoding to decoder.v, and make a more 8-bit + handshake interface between spi/uart/usb/whatever and the decoder. The motivation for that is obvious (well from my egotistical viewpoint anyways :P ). I need to change it anyways to have it work with an uart instead of the current SPI interface. And since I plan to move it to usb after I get that working, the more generic interface made sense. But right now it doesn't work for reasons unknown. So if I don't get it working after one more debugging session I may just chicken out and do a simple spi-to-uart bridge. I know, super lame, but hey if it works it works. :P Right now I want something that works, and not something that wins a design award.

Oh and on that note, in the verilog code there is a `define for using the original rx/tx interface. But as far as I can see that's not exactly functional anymore. Is that correct or did I miss something obvious?
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dogsbody on July 30, 2012, 01:56:10 am
The demon core didn't just happen all in one go.  Originally I just translated OLS to verilog & fixed a few timing problems.  There were more than one "huh?" moments.

Later I connected the thoughts of "HP 16550" and LUT cells and felt the light bulb go on.    There was a lot of rewriting after that point, but vestiges of the old are still there. 
 
In short, no particular reason.  If you feel refactoring would make things easier to update/understand go for it!  :-)

I doubt the presence of decoding in one file or another is the problem though.  The UART code was very broken in the original OLS vhdl I translated.  They had moved onto SPI by that point.    Might explain a thing or two?

I'd suggest setting a simulation.  Send in some data, see what the decoder is capturing.  I used Icarus verilog on my home machine, which is free & includes the GTK waveform viewer. 
    Offical site:  http://www.icarus.com/eda/verilog (http://www.icarus.com/eda/verilog)
    Wiki Documentation:  http://iverilog.wikia.com (http://iverilog.wikia.com)
    Download Windows version here:  http://bleyer.org/icarus (http://bleyer.org/icarus)

-- IED
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: mrflibble on August 04, 2012, 08:44:44 pm
[quote author="dogsbody"]The demon core didn't just happen all in one go.  Originally I just translated OLS to verilog & fixed a few timing problems.  There were more than one "huh?" moments.

Later I connected the thoughts of "HP 16550" and LUT cells and felt the light bulb go on.    There was a lot of rewriting after that point, but vestiges of the old are still there. 
 
In short, no particular reason.  If you feel refactoring would make things easier to update/understand go for it!  :-)
[/quote]

Heheh, understood. It´s more like a different structure to begin with would have helped (me). But my attempt at doing 2 things all in 1 go (impatience and all that) failed horribly. So for next time when I get around to it (hopefully next week) the plan is to take a fresh repo checkout and just add a lame spi/uart bridge. Less optimal, but more transparent.


Quote
I doubt the presence of decoding in one file or another is the problem though.  The UART code was very broken in the original OLS vhdl I translated.  They had moved onto SPI by that point.    Might explain a thing or two?

Oh no doubt the problem is some mistake I made, no mysteries there. :P It was more like that the current structure didn´t really help...


Quote
I'd suggest setting a simulation.  Send in some data, see what the decoder is capturing.  I used Icarus verilog on my home machine, which is free & includes the GTK waveform viewer. 

Yeah, I actually did a simulation after fixing a few synth/sim mismatches. The simulation was pretty basic, but the results all looked okay. Right states in the FSM, right response on the UART. So I optimistically flashed that bit file, but no luck with the client. And then the chirp chirp birds outside notified me it was THAT LATE, so zzzZZZzzz. And no fpga tinkering events since then.

Anyways, the plan now is to keep everything as is and logic hot glue said spi/uart bridge on it in a big ugly blob. Then check with testbench and client. If that works ... make simple tool to configure some triggers. If that works ... refactor as I tried and failed right now.

... or something.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dpenev on April 02, 2013, 02:09:54 am
Hi Guys,

I have purchased the open bench logic sniffer and i got excited about the possibility for the advanced triggers.
It is a pity that it is not supported by the java client and in this respect i have a question.
Please don't get me wrong. It is not a criticism.  I just would like to understand the complexity of this.

So I see the task like this. I don't have any idea about Java and making GUI with it so I see the advanced trigger menu
as few edit controls in which the user will be able to enter expressions. (It may be acceptable for the first release?) 

For example 

Trigger terms
A=(Input XOR Target_value ) AND Mask_value

Range Detectors
B=lower-limit <= sample <= upper-limit

 Edge Detectors (r - rising, f - falling, b - both, c - constant)
C=input * rfbcrfbcrfbcrfbcrfbcrfbcrfbcrfbc

Timers
D=timer_value

Trigger Sums
R=A OR B OR NOT(C) ...

Trigger Sequence States
Seems to be more complex so lets discuss later.
 
Each of those expressions can be parsed with very primitive parser and the result can be mapped in the FPGA
configuration as explained in the Demon Core  PDF document. Even C code provide there.
Each of the expression above can be parsed by a custom parser tailored to the particular expression.     

All this doesn't look as very complex to me.
Trigger Sequence States will bring some more complexity but still not that complex I think.
 
Is there something I miss in the picture?

Best Regards
Dimitar
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: alexwhittemore on April 02, 2013, 02:24:14 am
It doesn't *seem* very complex, but that doesn't mean it isn't.

Those kinds of triggers aren't difficult for a generic processor to handle, but the issue is (as you seem to be aware) translating it to FPGA hardware. Yes, you could write a parser that boiled a given expression down to verilog, but even if you did (which isn't trivial as it seems), you'd still have to flash a new FPGA bitstream every time you changed the trigger, which is a bit silly. Without automated tools, it'd look like design trigger>open xilinx ISE>implement HDL>synthesize>place+route>flash>use. You can imagine that, even if you automated those steps, it's not like it'd be as quick as change trigger>restart capture.

Of course, you could implement some kind of generic logic in the FPGA to handle complex triggers, then simply *configure* that logic at runtime when you make a complex trigger, in much the same way demon core + Jawi's OLS client do now, but the resources on the 250k gate Spartan 3E are already pretty much maxed. And it took talent even to get there.

The problem boils down to: every trigger statement you can think of has to be evaluated for every sample taken by the OLS, meaning it has to not only be done in combinational logic (and not some kind of post processing), but it also has to meet the timing requirements for the given speed you're operating at (which can be up to 200MSPS for 4ch, I think).

Not to say it's impossible by any stretch. But it's not EASY, and it might be impossible given the current limitation of 250k gate Spartan 3E hardware in production now.

Now, I've also been away from this project for quite a while, so perhaps there have been some changes I'm not aware of. But it looks like the current sparkfun OLS is still using the same xilinx part, so I don't think I'm too out of date on this answer.

Brutal thread resurrection, by the way.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dpenev on April 02, 2013, 10:20:56 am
Hi alexwhittemore,

Thank you for the comment. Well I am very new to this project and probably I am missing something indeed but have you check the great demon core documentation at http://www.mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.pdf (http://www.mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.pdf)
 
As far as I understand the programming of the FPGA is done on the fly indeed by sending individual programing serial chain for the different LUT's (supporting different advanced triggering options) In general it doesn't seems very complex. In this document two commands are defined , one for selection of the programing chain and another to send actual serial data. (and alexwhittemore all seems to fit in the current FPGA )
A C code is defined there to explain how the bit stream can be created. Probably this code can be used as is after some C to java conversion?

If the FPGA timing specification will met the particular LA configurations is a topic which probably dogsbody can answer
and can define some restrictions if any. 

So I actually thought that the complexity is in the client GUI around the advanced triggers selection.
Please confirm if I got confused?

Best Regards
Dimitar
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: alexwhittemore on April 02, 2013, 11:07:15 am
No, actually you are more right than I thought, I hadn't realized the core used direct runtime LUT modification. But the point remains that the mechanics of trigger string to LUT config compilation remain to be worked out, and there's no guarantee that more advanced triggers can fit into just the LUTs currently allotted.

Anyway more advanced triggers as you suggest would be a real boon anyway, so a more serious FPGA developer than I should look into it in more depth.
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dogsbody on April 02, 2013, 01:28:19 pm
The advanced triggers are fully implemented.  No additional LUT's / design changes are required.  Example C code for programming them is even provided in the spec.  Trigger configuration is handled entirely through the standard SUMP interface.

It's definitely non trivial to configure though.  I pushed all complexity (of configuration) onto the client, since it simply wouldn't fit in the fpga.

The original simple trigger terms are bound to a given state, and the state can only increment upwards.

The advanced trigger terms are decoupled from states,  so they can be reused.  There is a new layer for combining multiple trigger terms algorithmically (and/or/xor/etc) which can differ by state.  Finally there is the expanded state machine which supports sixteen states each supporting if-then-else clauses with arbitrary jumping (on the else case).

Best approach to implementing something is probably small incremental adds.    ie:  Start by implementing the current simple GUI using the complex trigger.  Next, expand it to 10 states since there are ten normal trigger terms.  Then add support for converting states to be range or edge checks.  The if-then-else states, with trigger sums, etc... can wait for later.

Jawi claims to be working on it, but I suspect his time is limited these days.

-- IED
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dpenev on April 02, 2013, 01:37:49 pm
Hi alexwhittemore

Quote
But the point remains that the mechanics of trigger string to LUT config compilation remain to be worked out, and there's no guarantee that more advanced triggers can fit into just the LUTs currently allotted.

Can you please check the http://www.mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.pdf (http://www.mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.pdf)
chapter 3.2 Example (Trigger Term Initialization).
Trigger string -> LUT seems to be already developed and I guess the person wrote this document already have this code working.

Is it not possible we agree on some lexical/text specification of the advanced triggers?
I am not this type of programmer but I could spent some time and try parsing this and generating a LTU configuration data 
If the java client developers are given with the LTU configuration chain data they probably can do the rest easily.

Having an advanced trigger configuration file as an import for the java client  will be both useful
and at the same time a great motivating factor to complete the GUI part.

Best Regards
Dimitar
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dpenev on April 02, 2013, 02:46:54 pm
Hello,

To be sure I have understood. What about this text example about the specification of the advance trigger

//Terms specification =================================================================================
a=(Data XOR Target_value_a ) AND Mask_value_a
b=(Data XOR Target_value_b ) AND Mask_value_b
c=(Data XOR Target_value_c ) AND Mask_value_c
d=(Data XOR Target_value_d ) AND Mask_value_d
e=(Data XOR Target_value_e ) AND Mask_value_e
f=(Data XOR Target_value_f ) AND Mask_value_f
g=(Data XOR Target_value_g ) AND Mask_value_g
h=(Data XOR Target_value_h ) AND Mask_value_h
i=(Data XOR Target_value_i ) AND Mask_value_i
j=(Data XOR Target_value_j ) AND Mask_value_j
inrange1=lower_limit_1 <= Data <= upper_limit_1
inrange2=lower_limit_2 <= Data <= upper_limit_2
edge1= Data EDGE edge1  //edge1/2 are a 32 bits in quad number system, rise, fall, both, no change
edge2= Data EDGE edge2
timer1=Value1
timer2=Value2

//State specification ===================================================================================
//State1 definition
sum_capture_1=a OR c OR NOT(inrange1) OR h
sum_Hit_1=a OR j OR edge1
sum_Else_1=a OR d OR timer1 OR NOT(timer2)
state1_= state(sum_capture_1, sum_Hit_1, sum_Else_1, Occurrence_Count_1, Elase_State_1, Timer_Control_Flags_1 , Trigger_Flag_1)

//State2 definition
sum_capture_2=a OR c OR NOT(inrange1)
sum_Hit_2=a OR f OR edge2
sum_Else_2=a OR d OR timer1
state1_= state(sum_capture_2, sum_Hit_2, sum_Else_2, Occurrence_Count_2, Elase_State_2, Timer_Contro_Flags_2 , Trigger_Flag_2)

...

//State16 definition
sum_capture_16=a OR c OR NOT(inrange1)
sum_Hit_16=a OR f OR edge1
sum_Else_16=a OR d OR timer2
state1_= state(sum_capture_16, sum_Hit_16, sum_Else_16, Occurrence_Count_16, Elase_State_16, Timer_Control_Flags_16 , Trigger_Flag_16)

==============================================
The client should parse this and sends it to the FPGA at once using the defined bit stream C implementations in the Almanah document. The amount of bit streams need to be sent are equal to the amount of the lines in the description above?
Did I understood or still missing something?

Best Regards
Dimitar
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dpenev on April 02, 2013, 02:49:14 pm
Of course if some of the terms/states/sums is not using I guess no need to initialize in FPGA. 
Dimitar
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dogsbody on April 02, 2013, 06:58:55 pm
Dimitar, yes, your example could be handled.  Each of the sum_capture / sum_hit / sum_else could be different though (a/b/c/d/e/f/range/edge/timer/etc...), combined logically however you like.

Only those states, the corresponding capture/hit/else sums, and any trigger terms enabled by said trigger sums need be programmed.
-- IED
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dpenev on April 02, 2013, 11:02:26 pm
Hi dogsbody,

OK nice that I am getting the main idea.

Guys do you think that having a text specification like the one above (as intermediate implementation step)
is beneficial for the project? If yes I would like we discuss it and define it.
I have something pretty restricted in mind. Most of the acceptable syntax should be pretty fixed. 
After that I could try implementing a simple parser for this. First in C which I am familiar in
and later I can try porting to java or someone else can help me with this.

It makes sense of course  if the client guys are willing to integrate this text file in the software.
It make sense only if the final GUI interface is far from being implemented of course.

Sorry if I am making to much noise in this forum. I just get exited from the fact the demon core is so capable ;)

Best Regards
Dimitar
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: jawi on April 03, 2013, 08:14:23 am
Just chiming in here: I do have already some limited support for the "demon core" triggers already encapsulated in a small library (http://https://github.com/jawi/libtdl). Initial tests looked very promising, and I'm busy with some basic frontend for editing those triggers.

However, at the moment, my day job and personal life take so much time that I've had little time to work at finalising the UI for the "nearly" complete 0.9.7 release of my client. I hope the next couple of weeks I do find the time to work at finalising the new release...
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dpenev on April 03, 2013, 10:00:37 am
Hi Jawi,

Thank you for the report and for your work.

If you think that you can get help from a C/firmware/Matlab programmer please let me know.

If you also can generate a beta version of what you already have I am more then willing to invest
some time to test and report  issues if any.

Please keep up the work moreover you seems to be very close.

Best regards
Dimitar
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dpenev on April 24, 2013, 08:28:43 pm
Hi Jawi,

I just got my logic sniffer. I am eager to test the advanced triggering
If you have some better version already I am willing to test and provide feedback.

Thank you
Dimitar
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: jadew on May 20, 2013, 04:17:43 am
Hi dogsbody,

I'd like to implement advanced triggers in my client as well, but I'm having issues understanding the bigger picture so I figured a few questions might be in order:


1) The the range detectors, timers and edge detectors are limited to a number of two. Correct?

2) Can the trigger order be configured? Say, I want to do normal match first and then an edge match, is that doable?

3) If the answer to question nr. 2 is Yes, how does that affect the trigger sums? Maybe I'm not understanding them properly, but at the first sight they seem like they operate on the current state of all the enabled triggers. Is that the case or should I re-read the docs?

4) Related to nr. 3, can we do something like this: if ( (trigger1 AND trigger2) OR trigger 3 (at this very moment)) then advance to the next section and wait for trigger4. When trigger 4 hits, go to next section where we wait for at least x seconds since trigger4 and see if trigger5 matches after that. Is this a possibility?

5) You said something about implementing complex triggers and then using 10 of them, after that try to convert them into range triggers and all that. Does that imply that the advanced triggers overlap complex triggers? Does that also mean that we can have 10 complex triggers instead of 4, with out actually implementing any advanced triggering?


Now a little request, could you please provide some mockup code that would exemplify setting up a simple advanced trigger and then a more complex one (doesn't have to be real code, it can be just english, as long as it hits the important set up ideas). The problem is I got a bit confused by the terminology in the documentation, since I'm not familiar with FPGAs (for example I have no idea how LUTs work or what exactly they are, even tho you explained it there, therefore all the code related to them is lost by me, because I don't know its purpose) so the lamest the terms you'd use, the better.


Hope I'm not asking for too much,
Thank you
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dogsbody on May 20, 2013, 07:33:05 pm
Trigger Sources:  There are two range detectors, two timers, two edge detectors, 10 pattern matchers.

Trigger Sums:  The above trigger sources are combined using trigger sum's.    What I call a complex trigger is anything that combines two or more trigger sources into a single sum.  A simple trigger would be a single trigger source only.

Trigger States:  Each trigger sequence state (trigger state machine) can use different trigger sum's for storing, matching, or else conditions.  Each trigger sequence state can also have a totally different set of trigger sum's from any other state. 

In other words, any state, can use any trigger source, in any supported combination, in any order.  Trigger sources can also be reused in any/all trigger-sums in any/all trigger-states. 

So yes, your example in #4 is totally doable.  ie:

State0 :  Set match-sum = (trigger1 AND trigger2) OR trigger3.  If hit, advance to next state.
State1 :  Set match-sum = (trigger4).  If hit, start timer1 & advance to next state.
State2 :  Set match-sum = (timer1-trigger AND trigger5).  If hit, advance to next state.

The trigger could be more complex.  You can also use trigger sum's to control what gets sampled, or use the "else" state to jump backwards.

For example, a decoder looking for a specific value on a serial line:

Configure Edge1 to trigger on rising or falling edge of clock input.
Configure Trigger1 to match 0 on data input.
Configure Trigger2 to match 1 on data input.

State0 : 
  Set capture-sum = Edge1.  If capture-hit, store inputs.
  Set match-sum = (Edge1 AND Trigger1).  If match-hit, advance to next state.
State1: 
  Set capture-sum = Edge1.  If capture-hit, store inputs.
  Set match-sum = (Edge1 AND Trigger2).  If match-hit, advance to next state.
  Set else-sum = (Edge1 AND Trigger1).  If else-hit, goto state 0.
State2 : 
  Set capture-sum = Edge1.  If capture-hit, store inputs.
  Set match-sum = (Edge1 AND Trigger1).  If match-hit, advance to next state.
  Set else-sum = (Edge1 AND Trigger2).  If else-hit, goto state 0.
State3: 
  Set capture-sum = Edge1.  If capture-hit, store inputs.
  Set match-sum = (Edge1 AND Trigger2).  If match-hit, start timer1, advance to next state.
  Set else-sum = (Edge1 AND Trigger1).  If else-hit, goto state 0.
State4:
  Set capture-sum = Edge1.  If capture-hit, store inputs.
  Set match-sum = none.
  Set else-sum = Timer1.  If else-hit, goto state0.

The above trigger looks for a "0101" pattern on the data input, and only evaluates the data on a clock rise/fall.  It also only captures data on the clock edge.  After finding the pattern, it continues capturing on clock edges until the timer elapses.

Hope this helps.
-- IED
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: jadew on May 20, 2013, 08:54:39 pm
Awesome, that answers most of the important questions I had.

Thank you
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: GHOVA0 on July 29, 2014, 03:34:28 am
I would like to see the verilog code (and if possible a Xilinx ISE project for same).  I don't know verilog but have some familiarity with VHDL and would like to study the design.  I've just joined the forum and am probably doing this wrong!
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: dogsbody on August 01, 2014, 12:53:52 pm
See attachments to the first post in this thread.  Latest source is there. 
Can also grab from http://mygizmos.org/ols/fpga.html (http://mygizmos.org/ols/fpga.html)

Cheers!
-- IED
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: GHOVA0 on August 14, 2014, 03:29:43 pm
Ian,
My initial thought was that source for all SUMP descendents was in a central repository, and I was baffled that no one every mentioned where it was :).  Anyway, I finally stumbled onto mygizmos.org which, I assume, is the home of the latest dope on the Demon Core version.

I have an Intronix LA which has been my faithful companion for some years, but it cost 8X as much.  With the triggering features you have added, OLS is way out in front.  OLS can count itself lucky to have attracted the attention of such high-powered talent.

Thanks a lot!
George
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: oliver on September 29, 2014, 09:30:09 am
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?
Title: Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti
Post by: Qwlciguk on September 29, 2014, 05:54:12 pm
[quote author="oliver"]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?[/quote]

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.