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

A cheap logic analyzer. Get one for $50, including worldwide shipping. A collaboration between the Gadget Factory and Dangerous Prototypes.

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby dpenev » Wed Apr 03, 2013 3:00 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
dpenev
Newbie
Newbie
 
Posts: 10
Joined: Sun Mar 31, 2013 9:25 am

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby dpenev » Wed Apr 24, 2013 1:28 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
dpenev
Newbie
Newbie
 
Posts: 10
Joined: Sun Mar 31, 2013 9:25 am

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby jadew » Sun May 19, 2013 9:17 pm

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
jadew
Newbie
Newbie
 
Posts: 44
Joined: Sat Oct 20, 2012 1:49 am

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby dogsbody » Mon May 20, 2013 12:33 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
User avatar
dogsbody
Full Member
Full Member
 
Posts: 181
Joined: Wed Jan 05, 2011 3:17 am
Location: San Jose, California

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby jadew » Mon May 20, 2013 1:54 pm

Awesome, that answers most of the important questions I had.

Thank you
jadew
Newbie
Newbie
 
Posts: 44
Joined: Sat Oct 20, 2012 1:49 am

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby GHOVA0 » Mon Jul 28, 2014 8:34 pm

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!
GHOVA0
Newbie
Newbie
 
Posts: 4
Joined: Mon Jul 28, 2014 6:41 pm

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby dogsbody » Fri Aug 01, 2014 5:53 am

See attachments to the first post in this thread. Latest source is there.
Can also grab from http://mygizmos.org/ols/fpga.html

Cheers!
-- IED
User avatar
dogsbody
Full Member
Full Member
 
Posts: 181
Joined: Wed Jan 05, 2011 3:17 am
Location: San Jose, California

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby GHOVA0 » Thu Aug 14, 2014 8:29 am

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
GHOVA0
Newbie
Newbie
 
Posts: 4
Joined: Mon Jul 28, 2014 6:41 pm

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby oliver » Mon Sep 29, 2014 2:30 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?
oliver
Newbie
Newbie
 
Posts: 47
Joined: Mon Jan 16, 2012 6:49 am

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby Qwlciguk » Mon Sep 29, 2014 10:54 am

oliver wrote: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?


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.
Qwlciguk
Full Member
Full Member
 
Posts: 111
Joined: Sat Nov 19, 2011 7:48 pm

Previous

Return to Open Bench Logic Sniffer

cron