sigrok-devel

[Iztok J. <izt...@gm...>]

Hi,

The last weekend I was working on the triggering code.

First I would like to describe how the current LogicSniffer is optimizing
logic consumption for triggers, and how this is probably not portable to
other FPGA platforms.

The easiest way to write generic logic, is to write a lookup table. This is
an asynchronous memory with logic inputs as address and logic outputs as
read data. The size of the memory grows exponentially with the number of
inputs (WI) and linearly with the number of outputs (WO). The number of
memory bits is SIZE=2^WI*WO.

Xilinx allows the creation of small (as small as 16bits) memories from LUT
(LookUp Table) which are hard coded (loaded at power-up) on Altera and
probably Lattice. So on Altera the same logic requires more FPGA resources.
This optimization is only an advantage when writing generic code, so on the
scale of the whole chip this advantage  of Xilinx devices is not as
important.

In practice this means it will not be possible to write the same code for
both Altera and Xilinx devices while using this feature offered by Xilinx.
So Xilinx devices will not be as optimal as they could be. I am not sure
what will this amount to, but I will try to measure it.

The other question is regarding the capabilities of the trigger module. Let
me list a few examples with growing trigger complexity. My descriptions are
only approximately accurate, but should be good enough to make a point,
feel free to correct them.
1. FX2 based streaming LA
Triggering is possible only on value or edge, there are no timers, and no
state machine.
2. Original SUMP trigger
The 32bit input is masked and compared to a reference value, edges can also
be detected. There are 4 stages of such comparators, which makes it a 4
state state machine. Transitions between states are very limited limited.
3. Advanced OLS triggers based on HP 16500/16550
There are 10 comparators, 2 edge detectors, 2 range checkers, 2
timers/counters, all this are event sources. The state machine has 16
states, programmable combinations of events can cause state transitions,
but as I understand it a limited number of transitions (arrows in a state
diagram) is supported. There are also extra counters for events, so the
system is more complex and functional.
4. Contemporary professional LA, like Tektronix - TLA7000 Series
There are 16 comparators, 16 edge detectors, 4 range checkers, 2
counter/timers generating events. This events are applied to a 16 state
state machine, the number of transitions from a state to any other is
limited to 16, and driven by up to 8 event sources. So even modern LA do
not have a totally generic transition space.

To achieve a generic transition space a LUT would be required. The LUT size
is growing exponentially with the number of events. I can give details
later.

It is possible to combine comparators and edge detectors into a single
module, I have already written the RTL, I will have to add some comments.

I think range detectors do not have to support both limits (uper lower).
Two edge detectors can be used instead, one configured for the upper and
the other for the lower limit.

The main question here is what would be the best set of compromises. I will
try to make the first version very generic, from the GUI user/developer
point of view, a generic state machine should be easier to use, since there
would be less feature specific GUI elements to use/design.

For now my target was:
4 comparators/edge detectos, 2 range detectors, 4 timers/counters (also
used to measure the sample stream length). 4bit (16 state) state machine,
with every possible transition allowed, implemented as a LUT. 2bits in the
LUT memory would be used to control the storage memory (write, trigger,
abort, end). Such a LUT would have to be 6bit x 2^14locations (96kbits).

Regards,
Iztok Jeras