Hi, My proposal for a general purpose trigger specification, is to use a combination of algebraic and regular expressions to describe any trigger condition. The application of this expressions to a specific device with specific limitations would be implemented by mapping the user specified configuration onto the available machine. This proposal does not provide the final syntax or mapping algorithms, but I think it is enough to start a discussion.
Algebraic expressions: Usually logic analyzers perform algebraic/logic operations on the whole width of the bus, with an additional mask. It would be much easier to force the user to write equations for the whole bus, but the user would prefer to be able to separate the bus into various named signals and write equations for them. VAR_0=0 VAR_1=1 VAR_2=2:5 Algebraic expressions could be any equation, but the return value of the expression is only interpreted as TRUE or FALSE. The next examples show some common equations that are usually present in logic analyzers: EQUATION_0 = (BUS ~^ CONST) & MASK; // bit-wise bus comparison against a constant with a mask EQUATION_1 = (VAR == CONST); // looking for a specific variable value EQUATION_2 = (MIN <= VAR <= CONST); // looking for a variable in a range Regular expressions: Regular expressions are computationally equivalent to FSM (finite state machines). So they can be used to describe any sequence of events. Here regular expressions would not be used to process text strings but to process equations or events, where only two values are available (true/false). The next regular expression operators are available: 1) concatenation Just list the input events in the required order, with comma as a separator: EVENT_0, EVENT_1, EVENT_2 2) repetition (counters, timers) Three repetition options are available: exact, range, unlimited EVENT[n] exact EVENT[n,m] range EVENT[*] unlimited EVENT[+] one or more EVENT[?] one or none 3) alternation (one OR the other paths) EVENT_0 | EVENT_1 | EVENT_2 Example A: How to describe 'Open Bench Logic Sniffer' triggers with this syntax. http://dangerousprototypes.com/docs/Logic_Sniffer_102 There are parallel and serial triggers available. The example will focus on parallel triggers, since serial triggers are similar to what is currently available for software triggers in sigrok. There is a version of the FPGA which supports more complex triggers. This features would also be supported by the described syntax, but are not described in this example. http://dangerousprototypes.com/docs/SUMP_logic_analyzer_Verilog_Demon_core_documentation Supported algebraic expressions E (events) are a simple comparison of a variable V (the whole 32bit bus) against a constant C with a mask M. Four comparators are available: E0 = (V0 ~^ C0) & M0; E1 = (V1 ~^ C1) & M1; E2 = (V2 ~^ C2) & M2; E3 = (V3 ~^ C3) & M3; Supported regular expressions are any combination of the four event using only concatenation and alternation operators. Counters are not available in this example. Few examples: E0, E1, E2, E3 E0 | E1 | E2 | E3 (E0 | E1), (E2 | E3) E0, ( E1 | E2 ) E0 | E1 E0 Serial event syntax: Serial events can be described as a regular expression. A concatenation of 1 to 32 bits (0/1) I am not sure if the dot (any value) operator is supported by having a hole in the mask. Example B: I had a look at the current trigger implementation in "libsigrok/hardware/fx2lafw/fx2lafw.c" only simple sequences are supported, this would be equivalent to a regular expression, where only the concatenation operator is supported. One way to implement all the features listed above, while being able to process fast enough, would be to generate C code and compile it at run time. Algebraic expressions would be translated directly to C code and a modified parser generator (re2c.org for example) would be used to translate the regular expression into a C automaton. Mapping the trigger specification onto a hardware implementation: This is probably the hardest part to implement. The simplest option would be to use fixed forms for each hardware, this would mean a separate implementation (GUI, configuration file parser) for each hardware. Another option is to have a tree based mapper. Each expression (algebraic or regular) can be expressed as a tree. The parser could check if the configuration is compatible with the hardware by checking the shape of the tree (available operators) and counting the number of nodes (number of comparator engines). Regards, Iztok Jeras On Thu, Aug 9, 2012 at 1:23 AM, Iztok Jeras <[email protected]> wrote: > Hi, > > I saw there are some plans for a generalized trigger specification. > http://sigrok.org/wiki/New_trigger_specification > > The most general approach which would still make sense (from my point > of view), are finite automata (this is an option in professional logic > analyzers). The input symbol into the automaton would be a single bit > or a vector. Since finite automata are equivalent to regular > expressions, they could be used for syntax. > > It should also be possible to separate signals into groups, apply an > automaton/regex to each group and then apply logic functions between > groups. For example for SDRAM, a sequence on control signals (WE, CAS, > RAS) AND a specific address. > > Regarding an implementation we would have to find or write a fast > streaming regex implementation, which would tell if the current > character is the last character of a matching word or not. I will look > further into it in the next weeks. > > Regards, > Iztok Jeras ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
