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.
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 ;)
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?
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.
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?
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.
Its my first message in this forum. I have purchased the open bench sniffer recently and still it has not arrived but I have decided to take a look on the software.
It is very nice that the advanced triggering support is available in the FPGA! What is the status of the OLS client support of it?