A CSC chamber consists of 6 detector layers. A set of pre-defined patterns are used to detect muons from the 6-layer coincidence in the “comparator” digis. The patterns used for CLCT and ALCT comparator digis during Run-1 & Run-2 are illustrated below. They will be replaced by a new set of patterns in the upcoming Run-3.

The 3rd layer (ly2) is referred to as the key layer, which is like the center of the pattern. One unit represents a halfstrip (for CLCT) or a wire group (for ALCT).

Run-1,2 CLCT

Run-1,2 ALCT

Reference:

• D. Acosta et al., Efficiency of finding muon track trigger primitives in CMS cathode strip chambers, Nucl.Instrum.Meth.A 592 (2008) 26-37.

In EMTF, pattern recognition is done using a set of pre-defined patterns to detect muon trigger primitives from the 4 CSC stations that are consistent with the signatures of a muon. Initially, a set of 9 patterns were used. These patterns have different shapes which separate muons of different p_T and charges. Each pattern is assigned a “straightness” code which is larger for a straighter pattern. Later (around Sept 2016), a smaller set of patterns have been adopted. This new set contains only 5 patterns and does not distinguish the muon charges. The original set of patterns is called “asymmetric”, while the new set is called “symmetric”. One can think of the symmetric patterns as the “OR” of the asymmetric patterns of the same straightness. They are illustrated below.

The second station (ME2) is referred to as the key station, which is like the center of the pattern. One unit represents a double-strip from a 10° CSC chamber (approx 0.5°).

Asymmetric

Symmetric

I’ve started working on a HLS project. Initially, I have heard a lot of good things about HLS, but now I’ve also started to realize some of its problems. This is an unfinished post, and it’s based on my personal experience as someone who is not an expert on FPGA programming.

Pros

• Provide a really good environment for co-development between firmware and software (including test bench).
• Provide the firmware emulation with bitwise accurate results. The emulation can be used outside of Vivado for a lot of studies.
• Allow non-FPGA engineers to collaborate on the algorithm development. This helps physicists to take over some work load, which is useful for projects where the num of physicsts >> num of engineers.
• Facilitate interfacing with C++ and Python. Xilinx has started providing first-class HLS libraries (e.g. Vitis Libraries) to interact with its FPGAs. This helps lowering the barrier to adopt FPGAs.

Cons

• The output Verilog code generated by the Vivado HLS tool is not human readable.
• Due to the above, it’s very hard to figure out how to optimize the algorithm. Maybe an experienced FPGA engineer could do that, but it’s really difficult for me. I have no idea how should I structure a particular for loop, or which pragma directive should I use, or whether a function should be inlined, etc in order to achieve the results that I want, since I couldn’t understand the translation process.
• The Vivado HLS tool is way too slow. It takes several hours (sometimes >3 hours) to compile my codes after a single change.
• A lot of configurations need to be passed as compile-time arguments (e.g. loop bounds), rendering the C++ codes also kind of unreadable. In C++11 (the standard supported by the Vivado HLS tool), the use of constexpr is very restrictive.

If you happen to look into the TensorFlow source codes, you might find functions that belong to gen_math_ops which is imported via:

from tensorflow.python.ops import gen_math_ops

But gen_math_ops.py does not actually exist in the TensorFlow GitHub repo. This is because gen_math_ops.py (or gen_nn_ops.py etc) is generated automatically, thus not included in the repo. But in your local installation, you may find it in <tensorflow-path>/python/ops/gen_math_ops.py, where <tensorflow-path> is the path of tensorflow.__file__. The functions in this automatically generated python code are usually wrappers of the corresponding C++ functions. So if you are interested in understanding how the functions are coded, you won’t find anything useful in here, but must go look at the corresponding C++ functions.

GitHub user lucidBrot has made a nice and concise list of useful GitHub emoji. This is a copy of that with some of my own additions.

meaning	emoji	text
info		:information_source:
note		:memo:
warning		:warning:
tip		:penguin:
hint		:bulb:
pro		:heavy_plus_sign:
con		:heavy_minus_sign:
error		:x:
correct		:heavy_check_mark:
question		:question:
resolved question		:grey_question:
important		:heavy_exclamation_mark:
wip		:construction:
bug		:bug:
careful		:eyes:
heart		:heart:
+1		:+1:
-1		:-1:
well done		:tada: