Skip to main content ↑ ↓

Messages

This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.

Messages - dogsbody

166
Open Bench Logic Sniffer / Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
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
168
Open Bench Logic Sniffer / Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
[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
169
Open Bench Logic Sniffer / Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
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
170
Open Bench Logic Sniffer / Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
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
171
Open Bench Logic Sniffer / Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
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
172
Open Bench Logic Sniffer / Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
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
173
Open Bench Logic Sniffer / Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi
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
175
Open Bench Logic Sniffer / FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Timing
--  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 "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

----

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
179
Open Bench Logic Sniffer / Re: New Windows OLS FPGA image loader...
[quote author="ian"]
There are a couple new rom additions for the v1.04 boards...[/quote]

No problem.   If it's ok, a short post here would probably be easier.   I made some changes to the original code, to return error codes instead printing error messages.

Also, I've attached source now (in first message).   It includes a revised ols_loader that uses the new plumbing if your interested. 

Cheers!
-- IED
180
Open Bench Logic Sniffer / New Windows OLS FPGA (& PIC firmware!) image loader...
[-- Edit Jan 9th - Added source code], [-- Edit Jan 10th - Added github repository], [-- Edit Feb 6th - Added support for programming PIC firmware], [ -- Edit Feb 8th - Added flexibility for PIC firmware variations & now detects if OLS already in bootloader mode when starting.], [ -- Edit Feb 9th - Removed complaint about 8 byte difference in 2.6 firmware.  Fixed stupid build problem with 2.01], [ -- Edit Mar 14th - Fixed Logic Sniffer detection for Windows Vista & 7.]
[ -- Edit May 14th, 2012 - Updated Flash ROM Table.]

Hi,
Since I've been busy on fpga tweaking I decided to make myself a
polished Windows GUI OLS loader. 

I've attached screen images & a ZIP with the EXE.   Supports HEX,
MCS (same as HEX), BIN (binary), -and- Xilinx native BIT files.

It can update either the FPGA ROM file, or the PIC firmware.  Simply pick the
image file, and olswinloader handles the rest.  No knobs, or extra checkbox
required!

Source is available below and on Github:  https://github.com/ied/olswinloader

Enjoy! 
-- IED

( ! ) Fatal error: Uncaught exception 'Elk_Exception' with message 'Please try again. If you come back to this error screen, report the error to an administrator.' in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
( ! ) Elk_Exception: Please try again. If you come back to this error screen, report the error to an administrator. in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
Call Stack
#TimeMemoryFunctionLocation
10.01812462392session_write_close ( )...(null):0
20.01852594016ElkArte\sources\subs\SessionHandler\DatabaseHandler->write( )...(null):0
30.01852594792Database_MySQL->query( ).../DatabaseHandler.php:119
40.06692733552Database_MySQL->error( ).../Db-mysql.class.php:273