FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Timing

[dogsbody]

-- 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 (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 "XISE\ols-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

----

Simulating:

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

----

I've written a full spec 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 --

Logic Sniffer Specification for Demon Core FPGA available here:
-- Word format (1.1 MB) --
-- PDF format (674 KB)--

Enjoy!
-- IED

[ian]

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)

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.

[dogsbody]

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

Oops, sorry for missing that. I'll fix it tonight when I get home. Cheers!
-- IED

[jack.gassett]

Awesome!

I'll take a look at it right now.

Thanks,
Jack.

[jack.gassett]

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.

[jack.gassett]

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.

[jack.gassett]

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.

[dogsbody]

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

[dogsbody]

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

[dogsbody]

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

[ian]

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.

[ian]

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.

[ian]

Code: Select all

#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.

[jawi]

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...

[rsdio]

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!

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

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.