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 jawi » Mon Jul 23, 2012 2:28 am

You've done some great work, Ian! There's some progress to mention on the support, see my reply in this thread.
User avatar
jawi
Developer
Developer
 
Posts: 596
Joined: Thu May 27, 2010 2:54 am
Location: The Netherlands

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

Postby mrflibble » Sat Jul 28, 2012 7:53 pm

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?
User avatar
mrflibble
Newbie
Newbie
 
Posts: 7
Joined: Sat Jul 21, 2012 8:26 am

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

Postby dogsbody » Sun Jul 29, 2012 6:56 pm

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
Wiki Documentation: http://iverilog.wikia.com
Download Windows version here: http://bleyer.org/icarus

-- 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 mrflibble » Sat Aug 04, 2012 1:44 pm

dogsbody wrote: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! :-)


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.


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


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.
User avatar
mrflibble
Newbie
Newbie
 
Posts: 7
Joined: Sat Jul 21, 2012 8:26 am

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

Postby dpenev » Mon Apr 01, 2013 7:09 pm

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
dpenev
Newbie
Newbie
 
Posts: 10
Joined: Sun Mar 31, 2013 9:25 am

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

Postby alexwhittemore » Mon Apr 01, 2013 7:24 pm

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.
alexwhittemore
Newbie
Newbie
 
Posts: 49
Joined: Sun Feb 06, 2011 4:57 pm
Location: Boston, MA

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

Postby dpenev » Tue Apr 02, 2013 3:20 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

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
dpenev
Newbie
Newbie
 
Posts: 10
Joined: Sun Mar 31, 2013 9:25 am

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

Postby alexwhittemore » Tue Apr 02, 2013 4:07 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.
alexwhittemore
Newbie
Newbie
 
Posts: 49
Joined: Sun Feb 06, 2011 4:57 pm
Location: Boston, MA

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

Postby dogsbody » Tue Apr 02, 2013 6:28 am

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
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 dpenev » Tue Apr 02, 2013 6:37 am

Hi alexwhittemore

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
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
dpenev
Newbie
Newbie
 
Posts: 10
Joined: Sun Mar 31, 2013 9:25 am

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

Postby dpenev » Tue Apr 02, 2013 7:46 am

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
dpenev
Newbie
Newbie
 
Posts: 10
Joined: Sun Mar 31, 2013 9:25 am

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

Postby dpenev » Tue Apr 02, 2013 7:49 am

Of course if some of the terms/states/sums is not using I guess no need to initialize in FPGA.
Dimitar
dpenev
Newbie
Newbie
 
Posts: 10
Joined: Sun Mar 31, 2013 9:25 am

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

Postby dogsbody » Tue Apr 02, 2013 11:58 am

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
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 dpenev » Tue Apr 02, 2013 4:02 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
dpenev
Newbie
Newbie
 
Posts: 10
Joined: Sun Mar 31, 2013 9:25 am

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

Postby jawi » Wed Apr 03, 2013 1:14 am

Just chiming in here: I do have already some limited support for the "demon core" triggers already encapsulated in a small library. 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...
User avatar
jawi
Developer
Developer
 
Posts: 596
Joined: Thu May 27, 2010 2:54 am
Location: The Netherlands

PreviousNext

Return to Open Bench Logic Sniffer