Attached are some images of the program that interfaces to the V1495
module. This let me make a pattern, send it to the V1495, and retrieves
the processed information from the V1495 that would be used for generating
the trigger.
Trigger_Regular is the algorithm as described in the specification
document that I received. It looks at all possible 3x3 windows and
determines if there are more hit towers than the programmed threshold
(here the threshold was set to 4 - there had to be more than 4 hits in a
3x3 window to define a cluster). As you can see 4 clusters were found in
the sample image (the cluster count is also reported by the V1495 unit).
The one in the bottom left has overlapping 3x3 windows that meet the
cluster definition criteria. In this case, some logic could be used to
determine that a neighboring cluster has fewer hits than the other
neighber and so it could supress that report.
Next, I played around a little more and wrote a simple algorithm that just
just ran in my program (on my PC, not the V1495) that took the same data
and caused adjacent hit towers (Up/down/left/right/all diagonals) to
attract to each other. So if more hits were on the left side of a cluster,
that cluster value would hop left if the weight was larger than its own
(or any other direction if the weight were arragned so). I took the same
data set as in the last image, and ran 3 iterations through this algorithm
(fig1 fig2 fig3) and you can see the hits clump together and increase in count when two
hits go to the same cell. The idea here would be to run this algorithm,
and then apply a threshold to each cell to determine if it is a cluster or
not. Anyway, you can see now the bottom left cell clumps together to a
single point where the "center of mass" would have been for those original
hits. So does the upper left. The upper right fails to clump into a single
point because there is not bias to move either way because there is equal
pull in both directions (this would be something that can be overcome by
forcing them to always go a particular direction when pulls are equal).
For the heck of it I sythesized this algorithm on the FPGA and found it
will need about 3 times the available resources (not really a surprise)!
This, or something of similar complexity could work if spread over more
that one board. I've got some ideas for dealing with that if it is of
interest.
Determining the X/Y location of the clusters is actually a bit more
difficult (especially if the latency needs to be kept low). This should be
feasible, but it will take several more, at least, clock cycles beyond
when a trigger has been determined. This is because all 424 potential
clusters will have to be looked at and probably sorted. Just a guess is
that it could take about 40ns beyond the assertion of the ASYNC trigger.
If there is any flexibility here it may be of some use. I'll certainly
find out more when I get around to implementing this feature. Currently,
I'm planning to focus on "properly" finding clusters.
I'm interested in seeing what some real data looks like. There's probably
no need to format it because I can just read it in with some standard file
I/O in c++.
I need clarification on how to deal with adjacent cluster hits (whether to
count them individually or not, or if we need to do further processing).
