diff --git a/backends/dpdk/README.md b/backends/dpdk/README.md
index 26a7858f4f..df47204a94 100644
--- a/backends/dpdk/README.md
+++ b/backends/dpdk/README.md
@@ -68,7 +68,7 @@ To load the 'spec' file in dpdk follow the instructions in the
 - Currently, programs written for DPDK target should limit the functionality in Ingress blocks, in case non empty  Egress blocks are present it will be ignored by default unless Hidden temporary option `--enableEgress` used.  When egress block support gets added to the DPDK target, and compiler can generate separate spec file for non empty ingress and egress blocks then option `--enableEgress` will be removed.
 - DPDK architecture assumes the following signatures for programmable block of PSA. P4C-DPDK converts the input program to this form.
 
-```P4
+``` P4
 parser IngressParser (packet_in buffer, out H parsed_hdr, inout M user_meta);
 
 control Ingress (inout H hdr, inout M user_meta);
diff --git a/backends/ebpf/README.md b/backends/ebpf/README.md
index 0ee14ed370..38db453fe7 100644
--- a/backends/ebpf/README.md
+++ b/backends/ebpf/README.md
@@ -280,7 +280,7 @@ state transition | `goto` statement
 `extract` | load/shift/mask data from packet buffer
 
 #### Translating match-action pipelines
-##
+
 P4 Construct | C Translation
 ----------|------------
 table     | 2 eBPF tables: second one used just for the default action
@@ -385,7 +385,7 @@ The C extern could be also allowed to access packet’s payload, but this featur
 
 The custom C extern function should be explicitly declared in the P4 program making use of that extern. For example:
 
-```C
+```c
 /** Declaration of the C extern function. */
 extern bool verify_ipv4_checksum(in IPv4_h iphdr);
 ```
@@ -425,7 +425,7 @@ clang -O2 -include C-EXTERN-FILE.c -target bpf -c OUTPUT.c -o OUTPUT.o
 
   * BPF maps can be defined inside the C extern function to provide statefulness. BPF map can be defined as follows:
 
-  ```C
+  ```c
   REGISTER_START()
   REGISTER_TABLE(<NAME>, BPF_MAP_TYPE_HASH, <KEY-SIZE>, <VALUE-SIZE>>, <MAX_ENTRIES>)
   REGISTER_END()
diff --git a/backends/ebpf/psa/README.md b/backends/ebpf/psa/README.md
index d45fa482bb..191c7600e9 100644
--- a/backends/ebpf/psa/README.md
+++ b/backends/ebpf/psa/README.md
@@ -106,6 +106,22 @@ The `MAX_RESUBMIT_DEPTH` variable specifies maximum number of resubmit operation
 The `resubmit` flag defines whether the `tc-ingress` program should enter next iteration (resubmit)
 or break the loop. The pseudocode looks as follows:
 
+<!--!
+\code{.c}
+int i = 0;
+int ret = TC_ACT_UNSPEC;
+for (i = 0; i < MAX_RESUBMIT_DEPTH; i++) {
+    out_md.resubmit = 0;
+    ret = ingress(skb, &out_md);
+    if (out_md.resubmit == 0) {
+        break;
+    }
+}
+\endcode
+-->
+<!--!
+\internal
+-->
 ```c
 int i = 0;
 int ret = TC_ACT_UNSPEC;
@@ -117,6 +133,9 @@ for (i = 0; i < MAX_RESUBMIT_DEPTH; i++) {
     }
 }
 ```
+<!--!
+\endinternal
+-->
 
 The same mechanism for RESUBMIT is used in the TC-based and XDP-based design.
 
@@ -286,6 +305,63 @@ the best match is overwritten. The algorithm exists when there is no more tuples
 
 The snippet below shows the C code generated by the PSA-eBPF compiler for a lookup into a ternary table. The steps are explained below.
 
+
+<!--!
+\code{.c}
+struct ingress_tbl_ternary_1_key key = {};
+key.field0 = hdr->ipv4.dstAddr;
+key.field1 = hdr->ipv4.diffserv;
+struct ingress_tbl_ternary_1_value *value = NULL;
+struct ingress_tbl_ternary_1_key_mask head = {0};
+struct ingress_tbl_ternary_1_value_mask *val = BPF_MAP_LOOKUP_ELEM(ingress_tbl_ternary_1_prefixes, &head);
+if (val && val->has_next != 0) {
+    struct ingress_tbl_ternary_1_key_mask next = val->next_tuple_mask;
+    #pragma clang loop unroll(disable)
+    for (int i = 0; i < MAX_INGRESS_TBL_TERNARY_1_KEY_MASKS; i++) {  // (1)
+        struct ingress_tbl_ternary_1_value_mask *v = BPF_MAP_LOOKUP_ELEM(ingress_tbl_ternary_1_prefixes, &next);
+        if (!v) {
+            break;
+        }
+        // (2)
+        struct ingress_tbl_ternary_1_key k = {};
+        __u32 *chunk = ((__u32 *) &k);
+        __u32 *mask = ((__u32 *) &next);
+        #pragma clang loop unroll(disable)
+        for (int i = 0; i < sizeof(struct ingress_tbl_ternary_1_key_mask) / 4; i++) {
+            chunk[i] = ((__u32 *) &key)[i] & mask[i];
+        }
+        __u32 tuple_id = v->tuple_id;
+        next = v->next_tuple_mask;
+        // (3)
+        struct bpf_elf_map *tuple = BPF_MAP_LOOKUP_ELEM(ingress_tbl_ternary_1_tuples_map, &tuple_id);
+        if (!tuple) {
+            break;
+        }
+        
+        // (4)
+        struct ingress_tbl_ternary_1_value *tuple_entry = bpf_map_lookup_elem(tuple, &k);
+        if (!tuple_entry) {
+            if (v->has_next == 0) {
+                break;
+            }
+            continue;
+        }
+        // (5)
+        if (value == NULL || tuple_entry->priority > value->priority) {
+            value = tuple_entry;
+        }
+        if (v->has_next == 0) {
+            break;
+        }
+    }
+}
+
+// (6): go to default action if value == NULL
+\endcode
+-->
+<!--!
+\internal
+-->
 ```c
 struct ingress_tbl_ternary_1_key key = {};
 key.field0 = hdr->ipv4.dstAddr;
@@ -337,6 +413,9 @@ if (val && val->has_next != 0) {
 
 // (6): go to default action if value == NULL
 ```
+<!--!
+\endinternal
+-->
 
 The description of annotated lines:
 1. The algorithm starts to iterate over the ternary masks map. The loop is bounded by the `MAX_INGRESS_TBL_TERNARY_1_KEY_MASKS` which is configured by `--max-ternary-masks` compiler option (defaults to 128).
@@ -378,6 +457,61 @@ or member.
 
 Before action execution, following source code will be generated (and some additional comments to it) for table lookup,
 which has implementation `ActionSelector`:
+<!--!
+\code{.c}
+struct ingress_as_value * as_value = NULL;  // pointer to an action data
+u32 as_action_ref = value->ingress_as_ref;  // value->ingress_as_ref is entry from table (reference)
+u8 as_group_state = 0;                      // which map contains action data
+if (value->ingress_as_is_group_ref != 0) {  // (1)
+    bpf_trace_message("ActionSelector: group reference %u\n", as_action_ref);
+    void * as_group_map = BPF_MAP_LOOKUP_ELEM(ingress_as_groups, &as_action_ref);  // get group map
+    if (as_group_map != NULL) {
+        u32 * num_of_members = bpf_map_lookup_elem(as_group_map, &ebpf_zero);      // (2)
+        if (num_of_members != NULL) {
+            if (*num_of_members != 0) {
+                u32 ingress_as_hash_reg = 0xffffffff;  // start calculation of hash
+                {
+                    u8 ingress_as_hash_tmp = 0;
+                    crc32_update(&ingress_as_hash_reg, (u8 *) &(hdr->ethernet.etherType), 2, 3988292384);
+                    bpf_trace_message("CRC: checksum state: %llx\n", (u64) ingress_as_hash_reg);
+                    bpf_trace_message("CRC: final checksum: %llx\n", (u64) crc32_finalize(ingress_as_hash_reg));
+                }
+                u64 as_checksum_val = crc32_finalize(ingress_as_hash_reg) & 0xffff;     // (3)
+                as_action_ref = 1 + (as_checksum_val % (*num_of_members));              // (4)
+                bpf_trace_message("ActionSelector: selected action %u from group\n", as_action_ref);
+                u32 * as_map_entry = bpf_map_lookup_elem(as_group_map, &as_action_ref); // (5)
+                if (as_map_entry != NULL) {
+                    as_action_ref = *as_map_entry;
+                } else {
+                    /* Not found, probably bug. Skip further execution of the extern. */
+                    bpf_trace_message("ActionSelector: Entry with action reference was not found, dropping packet. Bug?\n");
+                    return TC_ACT_SHOT;
+                }
+            } else {
+                bpf_trace_message("ActionSelector: empty group, going to default action\n");
+                as_group_state = 1;
+            }
+        } else {
+            bpf_trace_message("ActionSelector: entry with number of elements not found, dropping packet. Bug?\n");
+            return TC_ACT_SHOT;
+        }
+    } else {
+        bpf_trace_message("ActionSelector: group map was not found, dropping packet. Bug?\n");
+        return TC_ACT_SHOT;
+    }
+}
+if (as_group_state == 0) {
+    bpf_trace_message("ActionSelector: member reference %u\n", as_action_ref);
+    as_value = BPF_MAP_LOOKUP_ELEM(ingress_as_actions, &as_action_ref);         // (6)
+} else if (as_group_state == 1) {
+    bpf_trace_message("ActionSelector: empty group, executing default group action\n");
+    as_value = BPF_MAP_LOOKUP_ELEM(ingress_as_defaultActionGroup, &ebpf_zero);  // (7)
+}
+\endcode
+-->
+<!--!
+\internal
+-->
 ```c
 struct ingress_as_value * as_value = NULL;  // pointer to an action data
 u32 as_action_ref = value->ingress_as_ref;  // value->ingress_as_ref is entry from table (reference)
@@ -428,6 +562,9 @@ if (as_group_state == 0) {
     as_value = BPF_MAP_LOOKUP_ELEM(ingress_as_defaultActionGroup, &ebpf_zero);  // (7)
 }
 ```
+<!--!
+\endinternal
+-->
 Description of marked lines:
 1. Detect if a reference is a group reference. When the `_is_group_ref` field is non-zero, the reference is assumed to be
    a group reference.
@@ -496,33 +633,74 @@ The PSA implemented for eBPF backend is verified to work with the kernel version
 Moreover, make sure that the BPF filesystem is mounted under `/sys/fs/bpf`.
 
 Also, make sure you have the following packages installed:
-
+<!--!
+\code{.sh}
+$ sudo apt install -y clang llvm libelf-dev
+\endcode
+-->
+<!--!
+\internal
+-->
 ```bash
 $ sudo apt install -y clang llvm libelf-dev
 ```
-
+<!--!
+\endinternal
+-->
 You should also install a static `libbpf` library. Run the following commands:
-
+<!--!
+\code{.sh}
+$ python3 backends/ebpf/build_libbpf
+\endcode
+-->
+<!--!
+\internal
+-->
 ```bash
 $ python3 backends/ebpf/build_libbpf
 ```
-
+<!--!
+\endinternal
+-->
 ### Compilation
 
 You can compile a P4-16 PSA program for eBPF in a single step using:
+<!--!
+\code{.sh}
+make -f backends/ebpf/runtime/kernel.mk BPFOBJ=out.o P4FILE=<P4-PROGRAM>.p4 P4C=p4c-ebpf psa
+\endcode
+-->
 
+<!--!
+\internal
+-->
 ```bash
 make -f backends/ebpf/runtime/kernel.mk BPFOBJ=out.o P4FILE=<P4-PROGRAM>.p4 P4C=p4c-ebpf psa
 ```
+<!--!
+\endinternal
+-->
 
 You can also perform compilation step by step:
 
+<!--!
+\code{.sh}
+$ p4c-ebpf --arch psa --target kernel -o out.c <program>.p4
+$ clang -Ibackends/ebpf/runtime -Ibackends/ebpf/runtime/usr/include -O2 -g -c -emit-llvm -o out.bc out.c
+$ llc -march=bpf -mcpu=generic -filetype=obj -o out.o out.bc
+\endcode
+-->
+<!--!
+\internal
+-->
 ```
 $ p4c-ebpf --arch psa --target kernel -o out.c <program>.p4
 $ clang -Ibackends/ebpf/runtime -Ibackends/ebpf/runtime/usr/include -O2 -g -c -emit-llvm -o out.bc out.c
 $ llc -march=bpf -mcpu=generic -filetype=obj -o out.o out.bc
 ```
-
+<!--!
+\endinternal
+-->
 Note that you can use `-mcpu` flag to define the eBPF instruction set. Visit [this blog post](https://pchaigno.github.io/bpf/2021/10/20/ebpf-instruction-sets.html) to learn more about eBPF instruction sets.
 
 The above steps generate `out.o` BPF object file that can be loaded to the kernel. 
@@ -531,9 +709,20 @@ The above steps generate `out.o` BPF object file that can be loaded to the kerne
 
 Supposing we want to use a packet recirculation we have to specify the `PSA_PORT_RECIRCULATE` port.
 We can use `-DPSA_PORT_RECIRCULATE=<RECIRCULATE_PORT_IDX>` Clang flag via `kernel.mk`
+<!--!
+\code{.sh}
+make -f backends/ebpf/runtime/kernel.mk BPFOBJ=out.o ARGS="-DPSA_PORT_RECIRCULATE=<RECIRCULATE_PORT_IDX>" P4FILE=<P4-PROGRAM>.p4 P4C=p4c-ebpf psa
+\endcode
+-->
+<!--!
+\internal
+-->
 ```bash
 make -f backends/ebpf/runtime/kernel.mk BPFOBJ=out.o ARGS="-DPSA_PORT_RECIRCULATE=<RECIRCULATE_PORT_IDX>" P4FILE=<P4-PROGRAM>.p4 P4C=p4c-ebpf psa
 ```
+<!--!
+\endinternal
+-->
 or directly:
 `clang ... -DPSA_PORT_RECIRCULATE=<RECIRCULATE_PORT_IDX> ...`,  
 where `RECIRCULATE_PORT_IDX` is a number of a `psa_recirc` interface (this number can be obtained from `ip -n switch link`).
@@ -549,17 +738,36 @@ To install the CLI tool, follow the guide in [the NIKSS repository](https://gith
 (e.g., default actions) will only work when using `nikss-ctl`.
 
 To load eBPF programs generated by P4-eBPF compiler run:
-
+<!--!
+\code{.sh}
+nikss-ctl pipeline load id <PIPELINE-ID> out.o
+\endcode
+-->
+<!--!
+\internal
+-->
 ```bash
 nikss-ctl pipeline load id <PIPELINE-ID> out.o
 ```
-
+<!--!
+\endinternal
+-->
 `PIPELINE-ID` is a user-defined value used to uniquely identify PSA-eBPF pipeline (we are going to support for multiple PSA-eBPF pipelines running in parallel).
 In the next step, for each interface that should be attached to PSA-eBPF run:
-
+<!--!
+\code{.sh}
+nikss-ctl add-port pipe <PIPELINE-ID> dev <INTF>
+\endcode
+-->
+<!--!
+\internal
+-->
 ```bash
 nikss-ctl add-port pipe <PIPELINE-ID> dev <INTF>
 ```
+<!--!
+\endinternal
+-->
 
 ## Running PTF tests
 
@@ -567,23 +775,51 @@ PSA implementation for eBPF backend is covered by a set of PTF tests that verify
 The test scripts, PTF test cases and test P4 programs are located under `backends/ebpf/tests`. The tests must be executed from this directory.
 
 To run all PTF tests:
-
+<!--!
+\code{.sh}
+sudo ./test.sh
+\endcode
+-->
+<!--!
+\internal
+-->
 ```
 sudo ./test.sh
 ```
+<!--!
+\endinternal
+-->
 
 You can also specify a single PTF test to run:
-
+<!--!
+\code{.sh}
+sudo ./test.sh test.BridgedMetadataPSATest
+\endcode
+-->
+<!--!
+\internal
+-->
 ```
 sudo ./test.sh test.BridgedMetadataPSATest
 ```
-
+<!--!
+\endinternal
+-->
 It might be also useful to enable tracing for troubleshooting with `bpftool prog tracelog`:
-
+<!--!
+\code{.sh}
+sudo ./test.sh --trace=on
+\endcode
+-->
+<!--!
+\internal
+-->
 ```
 sudo ./test.sh --trace=on
 ```
-
+<!--!
+\endinternal
+-->
 ## Troubleshooting
 
 The PSA implementation for eBPF backend generates standard BPF objects that can be inspected using `bpftool`.
@@ -591,7 +827,21 @@ The PSA implementation for eBPF backend generates standard BPF objects that can
 To troubleshoot PSA-eBPF program you will probably need `bpftool`. Follow the steps below to install it.
 
 You should be able to see `bpftool help`:
-
+<!--!
+\code{.sh}
+$ bpftool help
+  Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
+         bpftool batch file FILE
+         bpftool version
+         
+         OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
+         OPTIONS := { {-j|--json} [{-p|--pretty}] | {-f|--bpffs} |
+                      {-m|--mapcompat} | {-n|--nomount} }
+\endcode
+-->
+<!--!
+\internal
+-->
 ```bash
 $ bpftool help
   Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
@@ -602,6 +852,9 @@ $ bpftool help
          OPTIONS := { {-j|--json} [{-p|--pretty}] | {-f|--bpffs} |
                       {-m|--mapcompat} | {-n|--nomount} }
 ```
+<!--!
+\endinternal
+-->
 
 Refer to [the bpftool guide](https://manpages.ubuntu.com/manpages/focal/man8/bpftool-prog.8.html) for more examples how to use it.
 
diff --git a/backends/p4tools/modules/testgen/README.md b/backends/p4tools/modules/testgen/README.md
index 2c7390abb5..d1709749d1 100644
--- a/backends/p4tools/modules/testgen/README.md
+++ b/backends/p4tools/modules/testgen/README.md
@@ -114,7 +114,8 @@ P4Testgen supports the use of custom externs to restrict the breadth of possible
 
 #### Restricted Tests
 `testgen_assume(expr)` will add `expr` as a necessary path constraints to all subsequent execution. For example, for the following snippet
-```p4
+``` P4
+
 state parse_ethernet {
     packet.extract(headers.ethernet);
     testgen_assume(headers.ethernet.ether_type == 0x800);
@@ -130,7 +131,8 @@ only inputs which have `0x800` as Ethertype will be generated. This mode is enab
 #### Finding Assertion Violations
 Conversely, `testgen_assert(expr)` can be used to find violations in a particular P4 program. By default, `testgen_assert` behaves like `testgen_assume`. If the flag `--assertion-mode` is enabled, P4Testgen will only generate tests that will cause `expr` to be false and, hence, violate the assertion.
 For example, for
-```p4
+``` P4
+
 state parse_ethernet {
     packet.extract(headers.ethernet);
     transition select(headers.ethernet.ether_type) {
diff --git a/backends/tofino/bf-p4c/phv/slicing/README.md b/backends/tofino/bf-p4c/phv/slicing/README.md
index 17e63129bb..8639cb5ae1 100644
--- a/backends/tofino/bf-p4c/phv/slicing/README.md
+++ b/backends/tofino/bf-p4c/phv/slicing/README.md
@@ -72,7 +72,7 @@ split. The algorithm is as follows:
    3. Restore the state by removing *head* from result and *tail* from header.
 
 Pseudo codes of the DFS:
-```c++
+```cpp
 // global states
 Headers = [A, B, C, D];
 Result = []
@@ -397,7 +397,7 @@ enhancing our after-split constraint. Previously, an after-split constraint can
 the 'exact' requirement. We introduce a less restricted form of after-split constraint, which
 specifies a minimum size of the list that a metadata resides in.
 
-```c++
+```cpp
 struct AfterSplitConstraint {
     enum class ConstraintType {
         EXACT = 0,  // must be placed in container of the size.
diff --git a/backends/tofino/bf-p4c/phv/solver/README.md b/backends/tofino/bf-p4c/phv/solver/README.md
index 2ad5b37643..53fac0d52a 100644
--- a/backends/tofino/bf-p4c/phv/solver/README.md
+++ b/backends/tofino/bf-p4c/phv/solver/README.md
@@ -9,7 +9,7 @@ check and generate instruction based on the PHV allocation.
 ## Example of using Z3
 an example of using z3 to validate deposit field. Unfortunately it's about 20ms per invocation,
 which is too slow for us.
-``` c++
+```cpp
 boost::optional<Error> ActionMoveSolver::run_deposit_field_z3_solver(
     const ContainerID dest, const std::vector<Assign>& src1,
     const std::vector<Assign>& src2) const {
diff --git a/docs/CodingStandardPhilosophy.md b/docs/CodingStandardPhilosophy.md
index 4c2562a0f2..8f2bb25bda 100644
--- a/docs/CodingStandardPhilosophy.md
+++ b/docs/CodingStandardPhilosophy.md
@@ -138,7 +138,7 @@ the `boost::format` for the format argument, which has some
 compatibility for `printf` arguments.  These functions handle IR and
 SourceInfo objects smartly.  Here is an example:
 
-```C++
+```cpp
 IR::NamedRef *ref;
 error(ErrorType::ERR_INVALID,
       "%1%: No header or metadata named '%2%'", ref->srcInfo, ref->name);
diff --git a/docs/IR.md b/docs/IR.md
index c83dc2b94c..4ea87e3eac 100644
--- a/docs/IR.md
+++ b/docs/IR.md
@@ -72,7 +72,7 @@ IR tree and accumulates information about the tree but does not modify
 it, while a Transform pass visits every node, possibly modifying the
 node or replacing it with some other node
 
-```C++
+```cpp
     /* pseudo-code for basic Transform visitor */
     visit(node, context=ROOT, visited={}) {
 	if (node in visited) {
@@ -152,7 +152,7 @@ As an example for how these are used in the IR visitor routines, the IR::If clas
 three children to visit -- a predicate and two consequents, with the value of the
 predicate deciding which consequent to execute.  The child visitor for `IR::If` is
 
-```C++
+```cpp
     visitor.visit(predicate);
     clone = visitor.flow_clone();
     visitor.visit(ifTrue);