graph TB subgraph Single_Motherboard[Single Motherboard E-ATX / EE-ATX] subgraph Socket0[Socket 0 - NUMA 0] Memory0[Memory A1-A12] end subgraph Socket1[Socket 1 - NUMA 1] Memory1[Memory B1-B12] end subgraph Socket2[Socket 2 - NUMA 2] Memory2[Memory C1-C12] end subgraph Socket3[Socket 3 - NUMA 3] Memory3[Memory D1-D12] end Socket0 ---|UPI| Socket1 Socket1 ---|UPI| Socket2 Socket2 ---|UPI| Socket3 Socket0 --- PCIe0[PCIe Slots from Socket 0
NUMA-local] Socket3 --- PCIe3[PCIe Slots from Socket 3
NUMA-local] end PCIe0 --- PCIeBus["UPI (Ultra Path Interconnect-Serdes) Mesh / Crossbar on PCB"] PCIe3 --- PCIeBus subgraph System[System Infrastructure] BMC[Single BMC / IPMI] BIOS[Single BIOS / UEFI] PSU[Single Power Distribution] OS[Single OS Instance] end Single_Motherboard --- BMC Single_Motherboard --- BIOS Single_Motherboard --- PSU Single_Motherboard --- OS
graph LR subgraph MB[Single Motherboard E-ATX/EE-ATX] S0[Socket 0
NUMA 0
Memory A1-A12] -->|UPI| S1[Socket 1
NUMA 1
Memory B1-B12] S1 -->|UPI| S2[Socket 2
NUMA 2
Memory C1-C12] S2 -->|UPI| S3[Socket 3
NUMA 3
Memory D1-D12] S0 -.-> PCIe0[PCIe Slots
NUMA-local] S3 -.-> PCIe3[PCIe Slots
NUMA-local] Mesh[UPI Mesh / Crossbar] PCIe0 -.-> Mesh PCIe3 -.-> Mesh end subgraph Infra[Infrastructure] BMC[Single BMC/IPMI] BIOS[Single BIOS/UEFI] PWR[Single Power Distribution] OS[Single OS Instance] end MB --- Infra
graph TB subgraph "Server Motherboard" subgraph "Package 0 (Socket 0)" IODie0["IODie
(I/O Die)"] subgraph "Chiplet Complex 0" CCD00["CCD 0"] CCD01["CCD 1"] CCD02["CCD 2"] CCD03["CCD 3"] end IODie0 --> CCD00 IODie0 --> CCD01 IODie0 --> CCD02 IODie0 --> CCD03 UCIe0["UCIe PHY
(Die-Edge)"] IODie0 --- UCIe0 end subgraph "Package 1 (Socket 1)" IODie1["IODie
(I/O Die)"] subgraph "Chiplet Complex 1" CCD10["CCD 0"] CCD11["CCD 1"] CCD12["CCD 2"] CCD13["CCD 3"] end IODie1 --> CCD10 IODie1 --> CCD11 IODie1 --> CCD12 IODie1 --> CCD13 UCIe1["UCIe PHY
(Die-Edge)"] IODie1 --- UCIe1 end %% Interconnects UCIe0 <==>|"UPI Link
(Board-Level, Inches)"| UCIe1 IODie0 <-.->|"UCIe Links
(mm-scale, Inside Package)"| IODie1 end classDef package fill:#bbdefb,stroke:#1565c0,stroke-width:3px classDef die fill:#fff9c4,stroke:#f9a825,stroke-width:2px classDef ccd fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1px classDef phy fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px class Package0,Package1 package class IODie0,IODie1 die class CCD00,CCD01,CCD02,CCD03,CCD10,CCD11,CCD12,CCD13 ccd class UCIe0,UCIe1 phy
graph TB subgraph HOST["πŸ–₯️ HOST SYSTEM"] CPU["CPU Cores
(Risk/Strat)"] RAM["DDR4/5
(Main Memory)"] PCIe["PCIe Root Complex
(Intel VT-d / AMD IOMMU)"] NIC["Network
(10-100G)"] CPU <--> RAM CPU <--> PCIe PCIe <--> NIC end subgraph FPGA["πŸ”² FPGA Card"] FPGA_CORE["FPGA
(Xilinx / Intel)"] DMA["DMA Engine
──► PCIe TLPs"] SCRATCH["On-FPGA HBM/URAM
(Scratchpad)"] FPGA_CORE --> DMA FPGA_CORE --> SCRATCH end CPU -.->|"Control/Config"| FPGA_CORE PCIe <-->|"DMA Transfers"| DMA NIC <-->|"Packet I/O"| FPGA_CORE
graph TB subgraph "TODAY: Electrical Interconnect" subgraph "Socket 0 (Intel)" CPU0["CPU
(Intel)"] end subgraph "Socket 1 (Intel)" CPU1["CPU
(Intel)"] end CPU0 <==>|"UPI/xGMI
Copper Traces
Board-Level"| CPU1 end subgraph "TOMORROW: Optical Interconnect" subgraph "Socket 0 (Next-Gen)" CPU0_Opt["CPU"] subgraph "On-Package Chiplets" EIC0["EIC
(Electrical-to-Optical
Chiplet)"] Optical0["Optical I/O"] end CPU0_Opt --- EIC0 EIC0 --- Optical0 end subgraph "Socket 1 (Next-Gen)" CPU1_Opt["CPU"] subgraph "On-Package Chiplets 1" EIC1["EIC
(Electrical-to-Optical
Chiplet)"] Optical1["Optical I/O"] end CPU1_Opt --- EIC1 EIC1 --- Optical1 end Optical0 <==>|"CXL.io/mem
Optical Fiber / Waveguide
High Bandwidth, Low Latency"| Optical1 end classDef today fill:#ffebee,stroke:#c62828,stroke-width:2px classDef tomorrow fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px classDef chiplet fill:#fff3e0,stroke:#e65100,stroke-width:2px classDef optical fill:#e3f2fd,stroke:#1565c0,stroke-width:2px class CPU0,CPU1 today class CPU0_Opt,CPU1_Opt tomorrow class EIC0,EIC1 chiplet class Optical0,Optical1 optical
graph LR subgraph "ELECTRICAL (Today)" direction TB subgraph "Package 0" CPU0_E["CPU
(Intel)"] PCIe0["PCIe
Controller"] CPU0_E --- PCIe0 end subgraph "Package 1" CPU1_E["CPU
(Intel)"] PCIe1["PCIe
Controller"] CPU1_E --- PCIe1 end PCIe0 <==>|"UPI/xGMI
━━━━━━━━━━━━
β€’ Copper traces
β€’ 32 GT/s
β€’ Board-level
β€’ ~10-20 inches"| PCIe1 end subgraph "OPTICAL (Tomorrow)" direction TB subgraph "Package 0 (Next-Gen)" CPU0_O["CPU"] EIC0_O["EIC Chiplet
(Electrical-to-Optical)"] Optical0_O["Optical Engine"] CPU0_O --- EIC0_O EIC0_O --- Optical0_O end subgraph "Package 1 (Next-Gen)" CPU1_O["CPU"] EIC1_O["EIC Chiplet
(Electrical-to-Optical)"] Optical1_O["Optical Engine"] CPU1_O --- EIC1_O EIC1_O --- Optical1_O end Optical0_O <==>|"CXL.io/mem
━━━━━━━━━━━━
β€’ Optical fiber/waveguide
β€’ 64+ GT/s
β€’ On-package EIC
β€’ mm-scale to km-scale"| Optical1_O end classDef electrical fill:#ffcdd2,stroke:#c62828,stroke-width:2px classDef optical fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px classDef pcie fill:#fff9c4,stroke:#f57f17,stroke-width:1px classDef eic fill:#ffccbc,stroke:#d84315,stroke-width:2px classDef optengine fill:#bbdefb,stroke:#0d47a1,stroke-width:2px class CPU0_E,CPU1_E electrical class CPU0_O,CPU1_O optical class PCIe0,PCIe1 pcie class EIC0_O,EIC1_O eic class Optical0_O,Optical1_O optengine
block-beta columns 3 HOST["HOST SYSTEM"]:3 CPU["CPU Cores
(Risk/Strat)"] --> RAM["DDR4/5
(Main Memory)"] CPU --> PCIe["PCIe Root Complex
(VT-d / IOMMU)"] PCIe --> NIC["Network
(10-100G)"] space:3 FPGA_BOX["FPGA Card"]:3 FPGA_CORE["FPGA
(Xilinx/Intel)"] --> DMA["DMA Engine
PCIe TLPs"] FPGA_CORE --> SCRATCH["HBM/URAM
Scratchpad"] CPU -.->|Control| FPGA_CORE PCIe <-->|DMA| DMA NIC <-->|Packets| FPGA_CORE
flowchart LR subgraph Host CPU RAM["(DDR4/5)"] RC[PCIe Root Complex] NET[10-100G NIC] end subgraph FPGA_Device[FPGA Accelerator] direction TB FP["FPGA Fabric"] DMA["DMA Engine"] HBM["HBM-(High Bandwidth Memory)/URAM (Ultra RAM)"] end CPU <--> RAM CPU <--> RC RC <--> NET RC <==>|"PCIe TLPs"| DMA DMA <--> FP FP <--> HBM NET <-->|"Ethernet"| FP CPU -.->|"Config/Control"| FP %% click HBM "https://arxiv.org/pdf/2510.08137" "High bandwidth Memory" %% click HBM "https://www.simms.co.uk/tech-talk/what-is-hbm-high-bandwidth-memory/" "High Bandwidth memory" %% https://engineering.purdue.edu/~vshriva/courses/papers/mp5_2022.pdf %% https://www.cadence.com/zh_CN/home/explore/ucie-technology.html %% Melalui SMS: kirim pesan dengan format Cek#KTP#NIK ke nomor 0815-3636-9999.
flowchart LR subgraph Developer["πŸ‘¨β€πŸ’» Developer"] PUSH["git push"] PR["Open PR"] end subgraph GitHub["βš™οΈ GitHub"] ACTIONS["GitHub Actions"] WORKFLOWS[".github/workflows/"] end subgraph Display["πŸ“Š Display Methods"] COMMENT["πŸ’¬ PR Comments
β€’ Quick preview
β€’ Stats
β€’ Code blocks"] ARTIFACT["πŸ“¦ Artifacts
β€’ Full download
β€’ All files
β€’ Reports"] PAGES["🌐 GitHub Pages
β€’ API docs
β€’ Website
β€’ Landing page"] LIVE["πŸš€ Live Preview
β€’ Vercel
β€’ Netlify
β€’ Dashboard"] end subgraph Output["πŸ“„ HTML Output"] INDEX["index.html"] DOCS["API Documentation"] COVERAGE["Coverage Reports"] BENCH["Benchmark Results"] DASHBOARD["Performance Dashboard"] end PUSH --> ACTIONS PR --> ACTIONS ACTIONS --> WORKFLOWS WORKFLOWS --> Display COMMENT --> INDEX COMMENT --> STATS["Stats & Badges"] ARTIFACT --> COVERAGE ARTIFACT --> BENCH PAGES --> DOCS PAGES --> INDEX LIVE --> DASHBOARD LIVE --> UI["UI Preview"] style Developer fill:#e1f5fe,stroke:#01579b,stroke-width:2px style GitHub fill:#f3e5f5,stroke:#4a148c,stroke-width:2px style Display fill:#fff3e0,stroke:#e65100,stroke-width:2px style Output fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px
flowchart TD subgraph Input["πŸ“₯ Input"] CODE["Source Code"] HTML["HTML Files"] RUST["Rust Code"] end subgraph Build["πŸ”¨ Build Stage"] COMPILE["cargo build"] DOC["cargo doc"] BENCH["cargo bench"] TEST["cargo test"] end subgraph Generate["πŸ“Š Generate HTML"] COVERAGE[Coverage Report
cargo tarpaulin] DOCS[API Documentation
cargo doc] PERF[Performance Report
cargo bench] CUSTOM[Custom HTML
docs/ directory] end subgraph Workflows["βš™οΈ GitHub Workflows"] CI["CI.yml
- Build
- Test
- Lint"] DOCS_DEPLOY["Deploy Docs
- Build docs
- Deploy to Pages"] COV_DEPLOY["Coverage
- Generate
- Upload"] PREVIEW["Preview
- Deploy to Vercel
- Comment PR"] end subgraph Display["πŸ“Ί Display Methods"] PR_COMMENT["πŸ’¬ PR Comment
Summary + Stats"] ARTIFACTS["πŸ“¦ Artifacts
Full Reports"] PAGES["🌐 GitHub Pages
API Documentation"] LIVE["πŸš€ Live Preview
Vercel/Netlify"] end CODE --> COMPILE HTML --> CUSTOM RUST --> COMPILE COMPILE --> TEST COMPILE --> BENCH COMPILE --> DOC TEST --> COVERAGE DOC --> DOCS BENCH --> PERF COVERAGE --> COV_DEPLOY DOCS --> DOCS_DEPLOY CUSTOM --> PREVIEW PERF --> CI COV_DEPLOY --> ARTIFACTS COV_DEPLOY --> PR_COMMENT DOCS_DEPLOY --> PAGES PREVIEW --> LIVE PREVIEW --> PR_COMMENT CI --> ARTIFACTS CI --> PR_COMMENT PR_COMMENT --> USER["πŸ‘¨β€πŸ’» Developer"] ARTIFACTS --> USER PAGES --> USER LIVE --> USER style Input fill:#e1f5fe,stroke:#01579b,stroke-width:2px style Build fill:#f3e5f5,stroke:#4a148c,stroke-width:2px style Generate fill:#fff3e0,stroke:#e65100,stroke-width:2px style Workflows fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px style Display fill:#fce4ec,stroke:#b71c1c,stroke-width:2px style USER fill:#fff9c4,stroke:#f57f17,stroke-width:2px
graph LR subgraph "Current State" CPU_E["CPU"] Copper["Copper Traces"] Memory["Memory"] CPU_E --- Copper Copper --- Memory end subgraph "Transition Phase" CPU_EIC["CPU"] EIC["EIC Chiplet"] Copper_Opt["Hybrid
Copper/ Optical"] Memory_Opt["Memory"] CPU_EIC --- EIC EIC --- Copper_Opt Copper_Opt --- Memory_Opt end subgraph "Future State" CPU_Opt["CPU"] EIC_Opt["EIC Chiplet"] Fiber["Optical Fiber"] Memory_Opt2["Optical Memory"] CPU_Opt --- EIC_Opt EIC_Opt --- Fiber Fiber --- Memory_Opt2 end CPU_E --> CPU_EIC Copper --> Copper_Opt Memory --> Memory_Opt CPU_EIC --> CPU_Opt Copper_Opt --> Fiber Memory_Opt --> Memory_Opt2 classDef current fill:#ffcdd2,stroke:#c62828,stroke-width:2px classDef transition fill:#fff9c4,stroke:#f57f17,stroke-width:2px classDef future fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px class CPU_E,Copper,Memory current class CPU_EIC,EIC,Copper_Opt,Memory_Opt transition class CPU_Opt,EIC_Opt,Fiber,Memory_Opt2 future
flowchart LR subgraph A [SOC / Chiplet 1] direction LR Core1[CPU Core] Core2[CPU Core] Mem1[Memory] AXIBridge[AXI-to-UCIe
Offload Engine] Core1 --- Mem1 Core2 --- Mem1 Core1 --- AXIBridge Core2 --- AXIBridge end subgraph B [Chiplet 2] direction LR AXIBridge2[AXI-to-UCIe
Offload Engine] Accel[Accelerator] Mem2[Memory] Accel --- Mem2 Accel --- AXIBridge2 end AXIBridge ---|UCIe Interconnect| AXIBridge2
graph TB subgraph "HIL Verification Platform" subgraph "Host System" H1[MATLAB/Simulink
Test Case Generation] H2[Python Scripts
Automation & Analysis] H3[UVM Testbench
Verification Environment] end subgraph "Real-Time Target Machine" R1[PLECS RT Box / Speedgoat
Real-Time Simulator] R2[Analog I/O
ADC/DAC 16-bit, 2Msps] R3[Digital I/O
PWM/GPIO 3.3V/5V] R4[Communication
SPI/I2C/CAN/UART] end subgraph "Device Under Test" D1[FPGA/SoC
DUT Hardware] D2[Analog Front-End
Sensors/Actuators] D3[Digital Core
CPU/MCU] D4[Mixed-Signal
ADC/DAC/PLL] end end %% Connections H1 -->|"Test Vectors"| R1 H2 -->|"Automation"| R1 H3 -->|"Verification"| R1 R1 -->|"Analog Stimulus"| R2 R1 -->|"Digital Stimulus"| R3 R1 -->|"Protocol Commands"| R4 R2 -->|"Analog I/O"| D2 R3 -->|"Digital I/O"| D3 R4 -->|"Serial Comms"| D4 D2 -->|"Sensor Data"| D4 D3 -->|"Control Signals"| D2 D4 -->|"Mixed-Signal"| D1 %% Styles classDef host fill:#e1f5fe,stroke:#01579b,stroke-width:2px classDef target fill:#f3e5f5,stroke:#4a148c,stroke-width:2px classDef dut fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px class H1,H2,H3 host class R1,R2,R3,R4 target class D1,D2,D3,D4 dut
flowchart LR subgraph Host["πŸ–₯️ Host System (MATLAB/Simulink)"] TC[Test Case Generator] VC[Vector Converter] AN[Analysis Engine] DB[Database/Results] end subgraph RTT["⚑ Real-Time Target (PLECS RT Box)"] FS[Frame Scheduler] AI[Analog Input
ADC 16-bit] AO[Analog Output
DAC 16-bit] DI[Digital Input
GPIO] DO[Digital Output
PWM/GPIO] COM[Communication
SPI/I2C/CAN] end subgraph DUT["πŸ”Œ Device Under Test (FPGA/SoC)"] AFE[Analog Front-End
Sensors] ADC[Analog-to-Digital
Converter] DAC[Digital-to-Analog
Converter] CPU[Digital Core
ARM/RISC-V] PMIC[Power Management
IC] end TC --> VC --> FS FS --> AO FS --> DO FS --> COM AO --> AFE DO --> CPU COM --> CPU AFE --> ADC ADC --> AI CPU --> DI CPU --> DAC AI --> AN DI --> AN AN --> DB %% Power-aware verification PMIC -->|"Voltage/Current"| ADC CPU -->|"PMIC Control"| PMIC style Host fill:#e3f2fd style RTT fill:#f3e5f5 style DUT fill:#e8f5e9
graph TB subgraph UVM["UVM Layer"] U1[Sequencer] U2[Driver] U3[Monitor] U4[Scoreboard] U5[Coverage] end subgraph AMS["SystemC-AMS"] S1[Analog Model] S2[Power Model] S3[Real-Number] end subgraph IF["Interface"] I1[Coupler] I2[Signal I/F] I3[Power I/F] end U1 --> U2 U2 --> I2 I2 --> S1 S1 --> I3 I3 --> DUT DUT --> S3 S3 --> I2 I2 --> U3 U3 --> U4 U3 --> U5 I1 <--> U1 I1 <--> S2 style UVM fill:#e1f5fe style AMS fill:#f3e5f5 style IF fill:#e8f5e9
graph TB subgraph UVM["UVM Layer"] U1[Sequencer] U2[Driver] U3[Monitor] U4[Scoreboard] U5[Coverage] end subgraph AMS["SystemC-AMS"] S1[Analog Model] S2[Power Model] S3[Real-Number] end subgraph IF["Interface"] I1[Coupler] I2[Signal I/F] I3[Power I/F] end U1 --> U2 U2 --> I2 I2 --> S1 S1 --> I3 I3 --> DUT DUT --> S3 S3 --> I2 I2 --> U3 U3 --> U4 U3 --> U5 I1 <--> U1 I1 <--> S2 style UVM fill:#e1f5fe style AMS fill:#f3e5f5 style IF fill:#e8f5e9
[cxl.mem](https://cxl.io/mem) https://www.hahwul.com/blog/2025/jekyll-to-zola/ https://crystal-lang.org [UCIe (Universal Chiplet Interconnect Express)](https://www.cadence.com/zh_CN/home/explore/ucie-technology.html) is an emerging standard for chiplet-to-chiplet communication, while PCIe is the established standard for board-level interconnect. In HFT, this matters because: * PCIe is what we use today (FPGA cards plug into PCIe slots) * UCIe is what might replace/augment it for future tightly-coupled FPGA/CPU systems Let me explain the differences and implications for the shared memory region. UCIe (Universal Chiplet Interconnect Express) and PCIe represent two fundamentally different approaches to the Shared Memory Region β€” the former is a die-level interconnect, the latter is a board-level one. This distinction reshapes everything about latency, coherency, and memory ordering in HFT. CXL.mem vs CXL.cache protocol benchmarks? [system verilog design](https://www.systemverilog.io/design/) Current Status (2026) UCIe 1.0/1.1 spec is finalized, but commercial HFT deployments are still PCIe-based because: Intel Agilex / AMD Versal FPGAs use PCIe/CXL, not UCIe chiplets UCIe requires advanced packaging (2.5D interposer or 3D stacking) β€” expensive, thermally challenging CXL.cache (the cache-coherent protocol) is still maturing; most implementations use CXL.io or CXL.mem The near-term reality: CXL (Compute Express Link) over PCIe is the stepping stone. CXL.mem allows the FPGA to access host memory coherently, but still through the PCIe physical layer. True UCIe (on-package) is likely 3-5 years out for HFT. DPDK --- Data Plane vs. Control Plane Logging A critical distinction for high-performance applications like SDR is separating logging for the control plane (configuration, management) from the data plane (the main signal processing and packet forwarding loop). Control Plane Logs: These are typically managed through standard APIs and can be INFO, WARNING, or ERROR level. They are important for system administration but are generally not latency-sensitive. Data Plane Logs (RTE_LOG_DP): Logging inside the data path must be handled with extreme care. DPDK provides special macros like RTE_LOG_DP() and compile-time flags such as RTE_LOG_DP_LEVEL for this purpose. The goal is to ensure that debug logging in this critical path is compiled out by default to avoid any performance penalty. It must be explicitly enabled at compile time, making it a powerful debugging tool for developers that doesn't affect production performance. The vhost library, for instance, explicitly splits its logging into VHOST_LOG_CONFIG and VHOST_LOG_DATA to enforce this separation. πŸ“ Recommended Steps for Your SDR App Define log types for your main SDR components (e.g., RF frontend, baseband processing, network stack). Use RTE_LOG for all non-critical, configuration, and management logging. Use RTE_LOG_DP for any debug logging inside your main packet processing loop. Implement a custom sink using rte_openlog_stream or the experimental rte_log_sink_set() if you need to send logs to a custom location or format them in a specific way. This setup provides robust, performance-aware logging suitable for a complex SDR system, allowing you to monitor and debug effectively without slowing down your data path. UPI (Ultra Path Interconnect) is not a traditional parallel bus with individual control/address/data pins. Like PCIe and Infinity Fabric, it is a SerDes-based serial link β€” the "pins" are differential pairs carrying high-speed serialized data. NUMA socket control vs processor cores pinning --------- Core Pinning: Your Application's "Home Base" Core pinning (or CPU affinity) assigns a specific thread or process to run exclusively on a designated CPU core . Its primary goal is to create a predictable, low-latency execution environment by shielding critical threads from OS and hardware interference. NUMA Socket Control: Managing the Data "Neighborhood" NUMA (Non-Uniform Memory Access) socket control manages the physical topology of the hardware, specifically how CPUs and memory are arranged in multi-socket servers . A key principle is that a CPU socket can access its local memory much faster than memory attached to another socket (remote memory) . NUMA control aims to maximize the probability of local memory access. It involves: Thread Binding: Pinning a thread to a core on a specific socket . Memory Allocation: Ensuring that memory is allocated from the local NUMA node of the pinned thread. For example, an HFT matching engine can be configured to allocate memory on the same NUMA node it runs on . PCIe Device Locality: Placing critical I/O devices like the network interface card (NIC) on the same NUMA node as the processing threads to avoid latency penalties from the data traveling across the CPU interconnect . AXI4 and UCIe are not competing standards, but rather protocols that operate at completely different levels of a computing system. They serve distinct but complementary roles, especially in the context of modern, high-performance multicore designs. The short answer to your question is yes, AXI4 is extremely relevant for multicore systems . Its relevance, however, is not in replacing UCIe, but as the primary internal communication fabric that must connect to external protocols like UCIe. 🎯 AXI4: The Internal Communication Standard AXI4 (Advanced eXtensible Interface) is the de facto standard for on-chip communication within a System-on-Chip (SoC) . It's the protocol that different cores, accelerators, and peripherals inside a single chip use to talk to each other . Purpose: High-performance, high-frequency communication between multiple IP blocks within a single die . Domain: On-chip interconnect (Network-on-Chip or traditional bus). Key Features: Supports multiple outstanding transactions, burst transfers, and separate read/write channels for efficient, parallel data movement . Multicore Relevance: As more cores are integrated onto a single chip, AXI4 becomes the backbone that allows them to efficiently share data and access memory. This is why modern SoCs, including multicore CPUs and GPUs from Arm, rely on it . However, AXI4 has a known limitation for large-scale systems: its strict ordering requirements for transactions with the same ID can become very complex and performance-limiting when scaled across many hops in a large network . 🧩 UCIe: The Chiplet Interconnect Standard UCIe (Universal Chiplet Interconnect Express) is a new standard designed to solve a different problem: how to connect multiple chiplets (smaller dies) within a single package . Purpose: High-speed, low-latency, and energy-efficient communication between chiplets from different vendors inside the same package . Domain: Die-to-Die interconnect (chiplet-to-chiplet). Key Features: Standardized physical layer, protocol stack, and high data rates (up to 64 GT/s in UCIe 3.0) to create an open chiplet ecosystem . Multicore Relevance: As monolithic scaling slows, the industry is moving towards chiplets. UCIe enables you to build a complex, multi-chiplet system by seamlessly connecting cores, memory, and accelerators that are spread across different dies . πŸ”— How They Connect: The "Offload Engine" The key to their coexistence is a "bridging" architecture, often called an Offload Engine, which is the main subject of the provided research papers . This engine sits between the AXI-based internal fabric of a chiplet and the UCIe external link. Its job is to "translate" AXI transactions into UCIe-compatible data packets (called Flits) and vice-versa . This Engine typically performs the following tasks: AXI Interface: Directly connects to the SoC's AXI bus, handling the complex handshakes and transaction management . Protocol Engine (PE): Manages the state of the UCIe link and the Flit Construction/Deconstruction process . Flit Construction/Deconstruction: Serializes data and control signals from the AXI interface into Flits that can be sent over UCIe, and parses incoming Flits back into AXI-compatible transactions . πŸ’Ž Summary To put it simply: AXI4 is the "internal language" of your multicore chip. It's how all the components on the die talk to each other, making it highly relevant for multicore architecture . UCIe is the "universal language" for talking to other chiplets. It's how your chip connects to others in a larger, multi-die system . They are not alternatives; the Offload Engine acts as the translator, bridging the AXI internal network to the UCIe external network and enabling the creation of scalable, heterogeneous multicore systems . This allows designers to build a powerful, multicore SoC using AXI4 internally and then integrate it seamlessly into a larger chiplet-based system using UCIe. If you're designing a chiplet-based system, a well-designed AXI-to-UCIe bridge is a fundamental requirement. [Silicon ](https://leetsilicon.com) [systemverilog](https://www.cl.cam.ac.uk/teaching/2425/ECAD+Arch/exercise-modelsim.html) [riscv ](https://riscv.or.jp/wp-content/uploads/syntacore_riscv_ip.pdf) [The Promise of Atomics](https://codecrash.me/trying-to-understand-atomics) [rust slice](https://codecrash.me/understanding-rust-slices) https://doc.rust-lang.org/std/primitive.slice.html Conceptually, a slice is easy to grasp. Like the documentation states, it allows you to view into a sequence of memory. The power of slices is that you β€œview” into sequences of memories that do not belong to you, like parts of the contents of a Vec 1. Slices are one of the best ways to pass around sequences of data that you might read from or write to, but do not need to own (e.g. you’re creating a copy of it to store somewhere else, etc.). [openGL Preprocessor](https://codecrash.me/an-opengl-preprocessor-for-rust) Tera for rust vs Jinja2 [sukr statics html template](https://sukr.io/getting-started) [seith](https://seite.sh/docs/getting-started) [spring acuator](https://www.digitalocean.com/community/tutorials/spring-boot-actuator-endpoints) [research spring bot](https://www.researchgate.net/publication/383000857_Spring_Boot_Actuator_Monitoring_and_Managing_Production-Ready_Applications) [solace](https://docs.solace.com/Get-Started/get-started-lp.htm) [crunc (in c language) instead of runc(in go language)](https://github.com/containers/crun) podman --runtime /usr/bin/crun run --rm --memory 512k fedora echo it works [pangolin vs tailscale](https://pangolin.net/blog/posts/pangolin-v-tailscale) [setup pangolin](https://deployn.de/blog/setup-pangolin/) [docker firefox](https://deployn.de/blog/neko-install/) [home assistant](https://deployn.de/blog/home-assistant-docker/) [gitea](https://deployn.de/blog/gitea-docker/) [myscale database](https://github.com/myscale/MyScaleDB) MyScaleDB is the SQL vector database that enables developers to build production-ready and scalable AI applications using familiar SQL. It is built on top of ClickHouse and optimized for AI applications and solutions, allowing developers to effectively manage and process massive volumes of data. [Pods instead of Compose-Files](https://www.lackhove.de/blog/selfhosting/) [podlet](https://github.com/containers/podlet?tab=readme-ov-file) For multi-container applications, we can leverage Podman's pods, which basically allow network communication between containers over localhost ports, sparing me the complexity of container networks. Paperless-ngx, for instance, requires a redis container in addition to the application itself. So for this, I have the following container files: https://github.com/afbjorklund/lima-gui [Ai ramalama](https://github.com/containers/ramalama) [Fully Automated Document Management System with Paperless-NGX](https://turalali.com/how-i-built-a-fully-automated-document-management-system-with-paperless-ngx/) https://oneuptime.com/blog/post/2026-03-04-how-to-deploy-a-spring-boot-application-as-a-systemd-service-on-rhel/view [example spring boot actuator](https://oneuptime.com/blog/post/2026-01-25-custom-actuator-endpoints-spring-boot/view) [systemd](https://www.lackhove.de/blog/selfhosting/) [pikvm](https://pikvm.org/) [stirling pdf](# stirling pdf) [stirling config](https://mariushosting.com/how-to-install-stirling-pdf-on-your-ugreen-nas/) ``` podman pull stirlingtools/stirling-pdf:latest mkdir -p ~/StirlingPDF/{trainingData,extraConfigs,customFiles,logs,pipeline} podman run -d \ --name stirling-pdf \ -p 8080:8080 \ -v ~/StirlingPDF/trainingData:/usr/share/tessdata \ -v ~/StirlingPDF/extraConfigs:/configs \ -v ~/StirlingPDF/customFiles:/customFiles/ \ -v ~/StirlingPDF/logs:/logs/ \ -v ~/StirlingPDF/pipeline:/pipeline/ \ -e DOCKER_ENABLE_SECURITY=false \ -e LANGS=en_GB \ stirlingtools/stirling-pdf:latest ``` https://ostechnix.com/stirling-pdf-best-open-source-self-hosted-pdf-manipulation-tool/ https://docs.stirlingpdf.com/Installation/Windows%20Installation/ https://github.com/Stirling-Tools/Stirling-PDF/releases/tag/v2.6.0 container_podman_stirling_pdf ================================ version: '3.3' services: stirling-pdf: image: stirlingtools/stirling-pdf:latest ports: - '8080:8080' volumes: - ~/StirlingPDF/trainingData:/usr/share/tessdata - ~/StirlingPDF/extraConfigs:/configs - ~/StirlingPDF/customFiles:/customFiles/ - ~/StirlingPDF/logs:/logs/ - ~/StirlingPDF/pipeline:/pipeline/ environment: - DOCKER_ENABLE_SECURITY=false - LANGS=en_GB https://greenwebpage.com/community/how-to-use-rsync-to-sync-local-and-remote-files-and-directories-in-ubuntu-22-04/ https://sites.ualberta.ca/~clange/Linux/openSUSE/15.6/instructions/openSUSE156_user.html#remote [zfs, btrfs and e4](https://www.alessioligabue.it/en/blog/btrfs-zfs-ext4-comparison#:~:text=You%20are%20a%20Desktop%2FLaptop,openSUSE)%20use%20it%20by%20default.) - You are a Desktop/Laptop Linux user: Go with ext4 if you want maximum simplicity and compatibility. Choose btrfs if you want system snapshots (for easy rollbacks of updates) and compression. - Many modern distributions (such as Fedora and openSUSE) use it by default. * You are building a home NAS (e.g. Unraid, Proxmox): This is the btrfs vs. zfs battle. * Choose ZFS if absolute integrity of your media and backups is priority #1 and you have enough RAM (minimum 8GB+). * Choose btrfs if you prefer flexibility (e.g., add disks of different sizes) and want a lighter system. [Promox](https://www.alessioligabue.it/en/blog/install-proxmox) [proxmox wihout ehernet](https://dev.to/varungujarathi9/setting-up-proxmox-on-a-laptop-without-an-ethernet-port-28n8) [proxmox -1](https://github.com/retiarylime/proxmox-laptop-wifi) # RAII in rust https://benjamincongdon.me/blog/2025/12/23/RAII-Guards-and-Newtypes-in-Rust/ # [Money Laundering](https://www.ingenique.net/anti-money-laundering-whitepapers/) - Dasseti # [Dynamic array c - stb_ds.h or vector.h](https://lazarusoverlook.com/posts/vector-c-library/) [stb_ds.h](https://nothings.org/stb_ds/) is a public-domain, single-header-file C library that provides high-performance, cache-friendly data structures like dynamic arrays and hash tables. The library itself does not manage a general-purpose "cache" in the sense of a CPU cache (e.g., an LRU cache) but its design leverages principles like data locality to perform efficiently with modern CPU caching. [hashtable map](https://hackmd.io/q9KOSSvlRUG0w9APyqBgEw) [video on hashtable](https://www.youtube.com/watch?v=ncHmEUmJZf4) [hashtable 1](https://codecapsule.com/2013/05/13/implementing-a-key-value-store-part-5-hash-table-implementations/) [hashtale 2](https://attractivechaos.wordpress.com/2018/10/01/advanced-techniques-to-implement-fast-hash-tables/) ``` #define STB_DS_IMPLEMENTATION #include "stb_ds.h" #include #include int main(void) { // Define a hash table (string key, integer value) stbds_hmput(my_cache, "key1", 100); stbds_hmput(my_cache, "key2", 200); // --- Cache Lookup (Retrieval) --- // Use stbds_hmget to retrieve a value. If the key isn't found, it returns the default value for the type (0 for int) int value = stbds_hmget(my_cache, "key1"); printf("Value for key1: %d\n", value); // Check for a non-existent key. int value_missing = stbds_hmget(my_cache, "key3"); // You must verify if a key exists using stbds_hmget or stbds_hmdefaults because 0 is a valid value. if (stbds_hmget(my_cache, "key3")) { // Key exists and value is non-zero } else { // Key not found or value is 0. } // --- Cache Update/Insertion --- // If "key1" exists, it updates the value; otherwise, it inserts a new entry stbds_hmput(my_cache, "key1", 150); // --- Iterating over the cache --- for (int i = 0; i < stbds_hmlen(my_cache); ++i) { printf("Key: %s, Value: %d\n", my_cache[i].key, my_cache[i].value); } // --- Cache Management (Clearing) --- stbds_hmclear(my_cache); return 0; } ``` # [Namespace isolation](https://securitylabs.datadoghq.com/articles/container-security-fundamentals-part-2/) [unshare namespace run in unix](https://linuxconcept.com/commands/unshare) Benefits of Using unshare and Namespaces Process Isolation: Able to run processes independently, preventing interference and providing security. Resource Management: Efficiently manage and allocate resources without affecting the global environment. Testing and Development: Create isolated test environments for development and testing purposes without needing full virtual machines. ``` https://dev.to/ajinkya_singh_2c02bd40423/mount-namespace-practice-guide-4c84 unshare -rn sudo unshare --net bash sudo unshare --mount bash sudo lsns ``` |Command |Description| |---------|-----------| |podman images -f dangling=true |List dangling images| |podman image prune -f |Remove only dangling images| |podman image prune -a -f |Remove all unused images| |podman container prune -f |Remove stopped containers| |podman tag localhost/my-image-old:latest localhost/my-image-new:v1| rename tag| |podman build --rm -t my-image .| remove all the dangling images after build| Automatically Remove Dangling Images After Build If you're building images and want to prevent dangling layers, add --rm when building: podman build --rm -t my-image . 16 xbps-query -f webkit2gtk41-devel | grep javascriptcore 17 pnpm tauri dev 18 ENV PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/share/pkgconfig:/usr/local/lib/pkgconfig 19 xbps-install -S webkit2gtk-devel pkg-config 20 xbps-install -S webkit2gtk4-devel pkg-config 21 xbps-install -S void-repo-nonfree void-repo-multilib void-repo-multilib-nonfree 22 pkg-config --modversion webkit2gtk-4.0 # For GTK4 23 export PKG_CONFIG_PATH=/usr/lib/pkgconfig 24 pkg-config --modversion webkit2gtk-4.0 # For GTK4 25 xbps-query -l | grep gtk+3-devel 26 find /usr -name "gdk-3.0.pc" 27 export PKG_CONFIG_PATH=/usr/lib/pkgconfig 28 pkg-config --modversion gdk-3.0 29 sudo xbps-install -S atk-devel cairo-devel pango-devel gdk-pixbuf-devel 30 xbps-install -S atk-devel cairo-devel pango-devel gdk-pixbuf-devel 31 historypwd To migrate Podman images to another hard drive, you can either permanently change the storage location or create portable copies of your images. Here are the most common and reliable methods. πŸ”„ Method 1: Permanently Relocate Storage (Change graphRoot) This method changes the directory where Podman stores all images and containers. It's best if the new hard drive will be the primary storage location. Step-by-step guide: 1. Find your current storage path with podman info | grep graphRoot . 2. Save all images from the current location to archive files using podman save . 3. Stop and remove all containers and images from Podman's management . 4. Change the configuration to point to the new location on your hard drive by editing the storage configuration file (e.g., ~/.config/containers/storage.conf for a user) and setting the graphroot option to the new path . 5. Reload the images from the archives you saved using podman load . Best for: Making a new hard drive the default, permanent location for all Podman data. πŸ“¦ Method 2: Create Portable Image Archives (Save/Load) This method creates standalone .tar files of your images, which you can copy anywhere. How to do it: Β· Save an image: podman save -o myimage.tar IMAGE_NAME_OR_ID . You can save multiple images to one file. Β· Load an image: podman load -i myimage.tar . Best for: Creating backups, transferring images to offline machines, or sharing images . 🌐 Method 3: Transfer Between Hosts (podman image scp) This command uses SSH to copy images directly between two systems. It works even if the destination is a different user account on the same machine . Example commands: Β· Copy to a remote host: podman image scp myimage username@remote_host:: . Β· Copy between users locally: podman image scp myimage otheruser@localhost:: . Best for: Quickly copying images over a network without creating intermediate files, especially between different user accounts . βš™οΈ Method 4: Extract Image Contents for File Access If you need direct access to the files inside an image (like the root filesystem), you can extract them to a directory. One method is to: 1. Create a temporary container: podman create --name temp_container IMAGE_NAME. 2. Export its filesystem: podman export temp_container | tar -x -C /path/on/new/drive . 3. Remove the container: podman rm temp_container. Best for: Inspecting or using an image's file contents outside of a container. πŸ’‘ Key Considerations Β· Manage Data Separately: These methods primarily move the image layers. For persistent data (like databases), remember to separately backup and migrate any volumes or bind mounts used by your containers . Β· Check Compatibility: When loading or transferring images between different Podman versions or systems, ensure compatibility to avoid errors . πŸ“ Summary of Methods To choose a method, consider your goal: Β· Make a new hard drive the main storage: Use Method 1. Β· Create a backup or offline copy: Use Method 2. Β· Copy an image to another computer quickly: Use Method 3. Β· Get the files inside an image: Use Method 4. If you know which specific method best fits your task or need help with a particular step (like editing the storage.conf file), let me know and I can provide more detailed instructions. # Dioxus [pass paramete on rsx!](https://users.rust-lang.org/t/understanding-dioxus-signals-or-state-management-in-general/111611/4) Seaweed Processing Factory This food brings many health benefits such as supporting * thyroid function, * digestive function and * reducing the risk of cancer, * diabetes, * cardiovascular disease, etc. In addition, seaweed has the ability to speed up wound recovery. Effective brand and a reasonable choice for the menu of people after surgery. Postpartum women often eat seaweed to restore health. Currently, more than 90% of seaweed consumed in Korea comes from seaweed farms. Because natural production is decreasing, seaweed farms have provided large quantities to serve consumer demand. # [container guide](https://documentation.suse.com/container/all/html/Container-guide/index.html) 1. sudo systemctl start containerbuild-regionsrv 2. sudo systemctl enable containerbuild-regionsrv 3. podman build --network host build-directory/ FROM registry.suse.com/suse/sle15 RUN zypper ref && zypper --non-interactive in example ENV BACKUP=/backup RUN mkdir -p $BACKUP COPY configuration_example /etc/example/ ENTRYPOINT ["/etc/bin/example"] [openBSD vs FreeBSD malloc for securiy](https://conclusive.tech/glossary/freebsd-vs-openbsd-which-is-right-for-you/) [Incus](https://blog.hetherington.uk/2025/02/running-unifi-network-application-in-an-incus-container/) # [Qemu on esp32](https://github.com/AryanBhirud/ESP32_on_QEMU) [Mock](https://www.throwtheswitch.org/cmock) [freeRTOS emulation](https://www.freertos.org/Documentation/02-Kernel/03-Supported-devices/04-Demos/03-Emulation-and-simulation/Linux/FreeRTOS-simulator-for-Linux) https://github.com/esp-rs/esp-wifi.git . # Or if you need a specific branch: git clone -b your-branch https://github.com/esp-rs/esp-wifi.git . ``` ``` git clone https://github.com/espressif/qemu brew install libgcrypt ./configure --target-list=xtensa-softmmu \ --enable-gcrypt --enable-debug \ --enable-sanitizers \ --disable-strip --disable-user \ --disable-capstone --disable-vnc \ --disable-sdl --disable-gtk ninja -C build ``` ``` qemu-system-xtensa -nographic -machine esp32 \ -nic user,model=open_eth, id=lo0,hostfwd=tcp::8000-:80 \ -drive file=merged_qemu.bin, if=mtd,format=raw ``` ``` docker build -t esp\_qemu . docker run -it --name esp --rm -p 8000:8000 \ -v $(pwd)/build:/app \ esp-qemu:latest qemu-system-xtensa \ -nographic -machine esp32 \ -nic user,model=open\_eth, id=lo0,hostfwd=tcp::8000-:80 \ -drive file=merged\_qemu.bin, if=mtd,format=raw ``` [esp32 on qemu](https://techknowhow.club/index.php/2025/08/20/esp32-on-qemu/) GrapheneOS creates fresh processes (via exec) when spawning applications instead of using the traditional Zygote spawning model. # C anc CPP ABI - gcc test_c.c -c - g++ test_cpp_c.cpp -S - g++ test_cpp_c.cpp test_c.o * [c++ plus rust](https://www.encodian.com/blog/create-and-insert-a-document-approval-sheet-using-powerautomate-approval-data/) * [embedded template c++ Library](https://www.etlcpp.com/releases.html) * [SAP Ui5 architecture](https://www.tutorialspoint.com/sap_ui5/sap_ui5_architecture.htm) * [SAp U5 hana](https://sapui5.hana.ondemand.com/sdk/#/topic/28b59ca857044a7890a22aec8cf1fee9) * [sap ui5 example](https://openui5.org/) * [sap flori tutorial](https://ui5.sap.com//#/topic/3da5f4be63264db99f2e5b04c5e853db) * [Flori web design](https://experience.sap.com/fiori-design-web/action-placement/) * [shell flori tool bar](https://experience.sap.com/fiori-design-web/flexible-column-layout/) * [sap grid view html](https://experience.sap.com/fiori-design-web/flexible-grid/) * [Dioxus](https://codesandbox.io/p/github/mattdanielbrown/Dioxus-Example-Projects/master?file=%2Fecommerce-site%2Fsrc%2Fmain.rs%3A19%2C26) * [Bookmark](https://www.croftsoft.com/library/tutorials/rust-dioxus-project-setup/) * [docsite dioxus tailwind components](https://github.com/42Angouleme/dioxus-tw-components) [Coral](https://www.kkp.go.id/storage/Berita/kkp-berhasil-tambah-lagi-2-kawasan-konservasi-laut-PjYn.jpg)rus rust containers: struct option struct Result ## json vs jsonl ## Safe C++ 1. A new "safe" context where only a rigorously safe subset of C++ is allowed 2. Borrow checking to prevent use-after-free bugs 3. Initialization analysis for type safety 4. Pattern matching, choice types, and borrowing 5. Thread-safety features similar to Rust's send and sync type traits 6. Explicit mutation for references 7. A model for object relocation Market trends --- The dried air bladders called fish maws are exported mainly to * China and Singapore for the manufacture of isinglass, which is used in beverage and cosmetic industry as well as Chinese traditional medicines (Dutta et al., 2014). The lesser and medium sciaenids are mostly sold in fresh condition at the local markets or iced and transported to distant interior markets of Odisha, West - [x] Write the press release - [ ] Update the website - [ ] Contact the media Comparison: Soil pH vs. Water pH & Soil Salinity vs. Brackish Salinity in Mangroves (Indonesia, Lingga Region) 1. Soil pH vs. Water pH in Mangroves Parameter Soil pH Water pH Typical Range 6.0–8.5 (slightly acidic to alkaline) 6.5–8.5 (varies with tides) Influencing Factors - Organic matter decomposition (acidic)
- Sulfide oxidation (acidic)
- Tidal flushing (neutralizing)
- Mangrove root exudates - Tidal influence (seawater pH ~8.1)
- Freshwater input (lower pH)
- Organic acids from leaf litter Measurement Method - 1:1 soil-water slurry (standard)
- 1:2.5 or saturated paste (more precise) - Direct pH electrode in water sample Expected in Lingga 6.5–7.8 (moderately acidic to neutral due to peat and tidal influence) 7.2–8.2 (brackish influence from Malacca Strait) 2. Soil Salinity vs. Brackish Water Salinity in Mangroves Parameter Soil Salinity Brackish Water Salinity Typical Range 5–30 ppt (hypersaline in dry zones) 5–25 ppt (varies with tides) Influencing Factors - Tidal inundation (salt deposition)
- Evaporation (increases salinity)
- Freshwater seepage (dilutes salt)
- Mangrove salt exclusion (roots filter salt) - Tidal mixing (seawater ~35 ppt + river input)
- Rainfall dilution (monsoon effect)
- Distance from sea (higher upstream) Measurement Method - EC meter (1:5 soil-water extract)
- Saturated paste extract (more accurate) - Salinity refractometer/EC meter
- Lab analysis (chlorinity) Expected in Lingga 10–25 ppt (moderate-high due to tidal influence) 15–25 ppt (brackish, influenced by Malacca Strait & rivers) Key Findings for Lingga Mangroves (Indonesia) pH Dynamics: Soil pH is slightly acidic to neutral (6.5–7.8) due to organic matter and tidal buffering. Water pH is more stable (7.2–8.2) due to seawater influence. Salinity Variations: Soil salinity (10–25 ppt) is influenced by tidal cycles and evaporation. Brackish water (15–25 ppt) reflects a mix of seawater and river inputs. Ecological Implications: Mangrove species (e.g., Rhizophora, Avicennia) adapt to moderate salinity & pH fluctuations. High salinity (>25 ppt) may reduce biodiversity, favoring salt-tolerant species. Recommendations for Study in Lingga Field Measurements: Use pH/EC meters for soil & water samples. Compare dry vs. wet season salinity changes. Lab Analysis: Test soil texture (clay/sand affects salt retention). Analyze porewater salinity for finer gradients. Would you like specific methods for sampling or data analysis in this region? yes Great! Below is a detailed methodology for sampling and analyzing soil pH, water pH, and salinity in the mangrove ecosystems of Lingga, Indonesia, including field and lab techniques. 1. Field Sampling Protocol A. Soil Sampling (for pH & Salinity) Sampling Design: Use stratified random sampling across different zones (seaward, mid, landward). Collect 3–5 replicates per zone for statistical reliability. Depth of Sampling: Surface (0–10 cm) – Most affected by tides & root activity. Subsurface (10–30 cm) – For salt accumulation trends. Tools Required: Stainless steel auger or soil corer. Clean plastic bags (avoid metal/contamination). GPS for location marking. B. Water Sampling (for pH & Salinity) Sampling Points: Tidal creeks (high/low tide). Porewater (from soil pits). Adjacent river/sea (reference). Collection Method: Use sterile bottles (rinsed 3x with sample water). Avoid air bubbles (affects pH). Measure in-situ (pH, EC, temp) with portable meters. 2. Laboratory Analysis A. Soil pH Measurement 1:1 Soil-Water Slurry Method (Standard for Mangroves): Mix 10g dry soil + 10mL distilled water, stir, wait 30 mins. Measure with calibrated pH meter (buffer at 4.01, 7.01, 10.01). Saturated Paste Method (More Precise): Add water until soil glistens, wait 1 hour, extract liquid for pH. B. Soil Salinity (EC – Electrical Conductivity) 1:5 Soil-Water Extract: Mix 20g soil + 100mL distilled water, shake 1 hour, filter. Measure EC (Β΅S/cm) and convert to ppt (β‰ˆ EC Γ— 0.64). Saturated Paste Extract (SPE): More accurate for saline soils (measures "real" porewater salinity). C. Water pH & Salinity pH: Use fresh samples (avoid COβ‚‚ absorption). Salinity: Refractometer (direct reading in ppt). EC Meter (convert using EC Γ— 0.47 β‰ˆ ppt for brackish water). 3. Data Analysis & Interpretation A. Statistical Tools Descriptive Stats: Mean Β± SD for pH/salinity per zone. ANOVA/T-test: Compare zones/seasons. Correlation: pH vs. salinity, soil vs. water. B. Mapping & Trends GIS/Interpolation: Plot spatial salinity gradients. Seasonal Variation: Compare monsoon vs. dry season. 4. Expected Challenges & Solutions Challenge Solution Tidal access limitations Sample at low tide. Electrode drift in saline water Frequent calibration with KCl buffers. Organic matter interference Use SPE method for salinity. 5. Equipment Checklist βœ… Field: pH/EC meter, refractometer, GPS, auger, sample bottles. βœ… Lab: Analytical balance, shaker, filter papers, calibration buffers. Next Steps for Your Study Pilot Sampling: Test methods in 1–2 sites before full survey. Local Collaboration: Engage with Universitas Riau or LIPI for lab access. Climate Data: Obtain rainfall/tide charts for Lingga. Would you like a sample data sheet template or references for mangrove soil studies in SE Asia?