Lizard-Spock

SoC Article 06: Interconnects and Bus Protocols - AXI, AHB, and APB

2026-04-09T00:00:00+01:00

Series: Introduction to SoC Design | Article 6 of 11

Introduction

Every block on a SoC -- CPUs, DMA engines, memory controllers, peripherals -- must communicate with every other block. The internal communication fabric that makes this possible is called the interconnect or bus. Choosing and designing the interconnect is one of the most consequential architectural decisions in SoC design: it determines bandwidth, latency, arbitration, and overall system throughput.

This article introduces the major bus standards used in modern SoCs, with emphasis on ARM's AMBA (Advanced Microcontroller Bus Architecture) family, which is the dominant standard in the industry.

Why a Standard Bus Matters

Without a standard interface, every IP block would need a custom interface to every other block -- an impractical explosion of design effort. A standard bus protocol defines:

Signal names and widths -- both sides know how to connect
Handshake mechanism -- how a master requests and a slave responds
Transaction semantics -- what "read", "write", and "burst" mean
Timing requirements -- setup times, hold times, latency bounds

IP vendors design their blocks to be plug-compatible with the standard, so a UART controller from one vendor and a DMA engine from another can both connect to the same ARM CoreLink interconnect without any custom glue logic.

The AMBA Family

ARM's AMBA specification, first published in 1996 and evolving through multiple generations, defines a family of bus protocols at different performance tiers:

The family spans from simple, low-power APB peripherals on the right through pipelined AHB, high-performance AXI4, all the way to cache-coherent ACE/CHI protocols used in multi-core processor clusters on the left.

APB -- Advanced Peripheral Bus

APB is the simplest AMBA protocol, designed for low-bandwidth, low-power peripheral registers. It is a synchronous, non-pipelined bus with no burst mode -- every transfer takes a minimum of two clock cycles.

APB Signals

Key APB signals:

PCLK -- Clock
PRESETn -- Active-low reset
PADDR -- Address (12-32 bit)
PSEL -- Select: asserted to indicate target peripheral
PENABLE -- Enable: on second cycle of every transfer
PWRITE -- Direction: high = write, low = read
PWDATA -- Write data
PRDATA -- Read data (from slave)
PREADY -- Slave extends transfer if not ready
PSLVERR -- Slave error response

APB Write Timing

An APB write transaction takes place over two phases: Setup and Access:

In the Setup phase, PSEL is asserted and the address and write data are presented. In the Access phase, PENABLE goes high confirming the transfer. PREADY allows a slow peripheral to extend the access phase by holding it low.

APB is ideal for: UART, SPI, I2C, GPIO, timer, and watchdog registers -- anything that does not require high data throughput.

AHB -- Advanced High-performance Bus

AHB sits in the middle tier. It is a pipelined, higher-bandwidth protocol supporting burst transfers. AHB separates the address phase and data phase, allowing the next address to be issued while the current data transfer is in progress.

Key AHB Signals

HCLK, HRESETn -- Clock and reset
HADDR -- Address (32-bit)
HTRANS -- Transfer type: IDLE / BUSY / NONSEQ / SEQ
HWRITE -- Direction
HSIZE -- Transfer size (8, 16, 32, 64... bit)
HBURST -- Burst type (SINGLE, INCR, WRAP4, INCR4...)
HWDATA / HRDATA -- Write and read data
HREADY -- Transfer complete / extend
HRESP -- Response (OKAY / ERROR)

AHB Pipelined Burst Read

The key insight: while the data for A0 is being returned, the address A1 is already being presented. This pipeline overlap hides address-to-data latency and improves throughput.

AHB Arbitration

When multiple masters (CPU, DMA) contend for the AHB, an arbiter decides who gets access using a bus grant / bus request protocol. Masters assert HBUSREQx when they want the bus; the arbiter asserts HGRANTx to indicate the winner. This round-robin or priority-based arbitration introduces a form of time-division multiplexing onto the shared bus.

AXI -- Advanced eXtensible Interface

AXI4 is the highest-performance AMBA protocol, used to connect CPUs, memory controllers, DMA engines, GPUs, and other high-bandwidth masters and slaves. It is the backbone of most modern SoCs.

AXI4's key innovation is independent channels: read and write transactions are completely separate, and multiple transactions can be in flight simultaneously.

The Five AXI Channels

The five channels are:

AW (Write Address) -- master sends the address and burst parameters for a write
W (Write Data) -- master sends the data beats with byte strobes and WLAST flag
B (Write Response) -- slave confirms the write completed (or reports an error)
AR (Read Address) -- master sends the address and burst parameters for a read
R (Read Data) -- slave returns data beats with RLAST flag

Valid/Ready Handshake

Every AXI channel uses the same valid/ready handshake protocol. The sender asserts VALID when it has data to transfer. The receiver asserts READY when it can accept data. The transfer completes on the rising clock edge when both are high:

This decoupled handshake is powerful: the master can issue addresses continuously; the slave can stall when its internal buffers are full, without requiring the master to back off.

AXI Burst Transfers

Rather than issuing many single transactions, AXI supports burst transfers -- a single address phase followed by multiple data beats. This dramatically improves efficiency for sequential memory access.

Key burst parameters:

AWLEN / ARLEN -- number of data beats (0=1 beat, 255=256 beats for AXI4)
AWSIZE / ARSIZE -- bytes per beat (1, 2, 4, 8, 16, 32, 64, 128)
AWBURST / ARBURST -- burst type:
FIXED -- same address repeated (useful for FIFOs)
INCR -- address increments each beat (normal memory access)
WRAP -- like INCR but wraps at a boundary (useful for cache lines)

AXI IDs and Out-of-Order Transactions

AXI assigns each transaction an ID (AWID / ARID). A slave may respond to transactions out of order as long as responses within the same ID are in order. This allows a memory controller to optimise DRAM access patterns rather than being forced to respond in the exact order of requests.

The Interconnect: From Bus to Crossbar

A simple shared bus forces all masters to share a single data path -- only one master can use it at a time. This creates a bottleneck in systems with multiple high-bandwidth masters.

The solution is an AXI crossbar (also called a switch matrix): it provides dedicated paths between every master-slave pair, allowing multiple simultaneous transfers as long as they target different slaves.

ARM's CoreLink NIC-400 and CoreLink CCI-550 are examples of AXI interconnect IP used in real SoCs. RISC-V SoCs commonly use TileLink or AXI crossbars built with open-source IP.

QoS: Quality of Service in Interconnects

Not all traffic is equal. A display engine reading pixel data must deliver frames at a guaranteed rate, or the screen will tear. A background DMA transfer moving log data is not time-critical. AXI4 supports QoS signalling (ARQOS / AWQOS) -- a 4-bit priority tag attached to every transaction.

The interconnect uses these tags to arbitrate between competing masters, ensuring that time-sensitive traffic is served first without starvation of low-priority traffic.

AXI4-Lite: The Simplified Register Interface

Full AXI4 has substantial complexity -- burst management, ID tracking, out-of-order responses. For accessing peripheral register banks (where individual 32-bit reads and writes are all that is needed), AXI4-Lite offers a simplified subset:

No burst support (single transfers only)
No transaction IDs
No out-of-order support
Simple 32-bit or 64-bit data width

AXI4-Lite is extremely common for connecting peripheral IP blocks to the system bus, where its simplicity makes it easy to implement correctly.

APB Bridge: Connecting the Bus Tiers

Because APB is simpler and lower power, slow peripherals are typically attached to an APB bus rather than directly to the AXI/AHB backbone. An AXI-to-APB bridge converts between the protocols:

The bridge runs the APB at a lower, slower clock (e.g., 100 MHz) while the AXI backbone runs at 500 MHz or more, reducing dynamic power in the peripherals.

Network-on-Chip (NoC)

In the largest, most complex SoCs -- server processors, AI accelerators -- even an AXI crossbar becomes a bottleneck. The solution is a Network-on-Chip (NoC): a switched packet network embedded on the die, with routers at each node and links between them.

NoCs provide:

Scalability -- adding more processing tiles does not require redesigning the interconnect
Bandwidth -- multiple simultaneous transfers across different links
Modularity -- standard router IP can be assembled in different topologies

This is an advanced topic covered in the advanced article series.

Summary

SoC interconnects form the communication backbone that links every functional block. The AMBA protocol family provides a hierarchy of protocols: APB for simple peripherals, AHB for mid-range transfers, and AXI for high-performance connections. AXI's independent channel architecture and valid/ready handshake enable high-throughput, pipelined, out-of-order transfers. Crossbar interconnects replace shared buses to allow simultaneous transfers between different master-slave pairs. Understanding these protocols is essential for designing IP blocks that plug into an SoC and for debugging system-level performance issues.

SoC Article 05: Memory Architecture - Caches, DRAM, and On-chip Storage

2026-04-04T00:00:00+01:00

Series: Introduction to SoC Design | Article 5 of 11

Introduction

Of all the factors that determine a SoC's real-world performance, memory is often the most important and the most overlooked by beginners. A modern CPU core can theoretically execute billions of operations per second, but most of that potential is wasted if data cannot be delivered fast enough.

The art of SoC memory architecture is bridging the massive speed gap between the processor (which wants data in nanoseconds) and the external DRAM (which takes tens of nanoseconds to respond) in the most energy-efficient way possible.

The Memory Speed Gap

The problem starts with a fundamental mismatch in technology:

Notice the gap: a CPU register delivers data in under a nanosecond, while external DRAM takes 50-70 ns - roughly 100x slower. Without a caching strategy, the CPU would spend most of its time waiting for memory.

The Memory Hierarchy

The solution is a hierarchy of storage technologies, organised by speed, cost, and distance from the processor:

The hierarchy works because of locality - the observation that most programs access the same data repeatedly over a short period (temporal locality) and access data at adjacent addresses in sequence (spatial locality). Caches exploit both properties.

How Caches Work

A cache is a small, fast SRAM that stores copies of recently-used data from slower memory. When the CPU reads an address, it first checks the cache:

Cache hit - the data is in the cache; it is returned immediately (low latency)
Cache miss - the data is not in the cache; it must be fetched from a slower level

Cache Organisation

A cache is organised into lines (also called blocks) - the minimum unit of transfer between memory levels. A typical cache line is 64 bytes.

Three important cache parameters:

Capacity - total amount of data the cache can hold.

Associativity - how many possible cache locations a given memory address can map to. A direct-mapped cache is simplest: each address maps to exactly one line. A fully-associative cache can hold any address in any line. A 4-way set-associative cache is a compromise: each address maps to a set of 4 lines.

Write policy - what happens when the CPU writes to a cached address:

Write-through: simultaneously update both cache and memory (simple, but uses memory bandwidth)
Write-back: update only the cache, mark the line "dirty", and write to memory only when the line is evicted (more efficient)

Static RAM (SRAM): The Cache Technology

Caches are built from SRAM (Static RAM). Each bit is stored in a six-transistor cell (6T SRAM) - two cross-coupled inverters and two access transistors.

SRAM retains data as long as power is applied (it is volatile). It is fast (sub-nanosecond access) but uses significant area - roughly 100-150 F per bit (where F is the minimum feature size). This is why caches are small relative to DRAM.

DRAM: The Main Memory Technology

External DRAM uses a one-transistor, one-capacitor (1T1C) cell. The charge on a capacitor represents the bit value.

The 1T1C cell is much smaller than a 6T SRAM cell, enabling much higher density - today's DRAM stores tens of gigabits per die. However, the capacitor leaks charge over time, so each cell must be refreshed (read and rewritten) thousands of times per second. This refresh activity consumes power and introduces brief periods where the memory cannot be accessed.

DRAM Organisation

DRAM is organised into banks, rows, and columns. Accessing data requires:

Activate (open) a row - copies the row into a row buffer (sense amplifiers)
Read/Write column - access the desired column from the row buffer
Precharge - close the row (prepare for the next row activation)

Key timing parameters:

tRCD - Row-to-Column Delay (time after ACT before a column can be accessed)
CL - CAS Latency (time after READ command before data appears)
tRP - Row Precharge time (time to precharge before next ACT)
tRAS - Row Active time (minimum time row must be open)

On-chip SRAM (Tightly Coupled Memory)

In addition to caches, many SoCs include blocks of Tightly Coupled Memory (TCM) - SRAM directly connected to the processor core, accessed through a dedicated bus rather than through the cache hierarchy. TCM provides:

Guaranteed latency - always one cycle, no possibility of a cache miss
Deterministic behaviour - essential for real-time systems
DMA-accessible storage - used for buffers shared with peripherals

This is particularly common in ARM Cortex-M microcontrollers, where code critical for interrupt service routines may be placed in ITCM (Instruction TCM) to ensure it always executes at maximum speed.

The DRAM Controller

Between the SoC's system bus and the DRAM package sits the DRAM controller - a complex piece of hardware that:

Translates read/write requests from the bus into DRAM-specific command sequences (ACT, RD, WR, PRE, REF)
Schedules requests to maximise row-buffer hit rate and memory bandwidth
Issues periodic refresh commands to prevent data loss
Manages multiple banks and ranks for parallel access
Implements QoS (Quality of Service) to ensure latency-sensitive initiators (e.g., display engines) get priority

Non-Volatile Storage

Beyond volatile DRAM, SoCs interface with non-volatile storage where data must persist after power-off:

eMMC (embedded MultiMediaCard) - flash memory in a BGA package, soldered to the board. Used in mid-range phones and single-board computers.

UFS (Universal Flash Storage) - faster, lower-latency serial protocol with command queuing. Used in high-end smartphones.

NOR Flash - byte-addressable, execute-in-place (XIP) capable. Often used for bootloaders on embedded systems.

NAND Flash - high density, page/block-based access. Requires a flash translation layer (FTL) to manage wear levelling.

The SoC connects to these through dedicated controller IP blocks: eMMC controller on AHB/APB, UFS controller on AXI, QSPI controller on APB for NOR flash, and NAND controller on AHB.

Memory Mapping: The Software View

From software's perspective, all memory - SRAM, DRAM, memory-mapped registers, flash - appears as a flat address space. The processor simply reads and writes to 32-bit or 64-bit addresses; the hardware decides which memory or peripheral handles each range.

The memory map is one of the first things a firmware developer consults when writing code for a new SoC. It is typically documented in the SoC's Technical Reference Manual (TRM).

Cache Coherency: The Multi-Core Problem

When multiple CPU cores share a memory system, a challenge arises: what happens if two cores have different cached copies of the same address?

This is the cache coherency problem. If Core 0 writes to address A and Core 1 has a stale cached copy of A, Core 1 will read incorrect data.

Hardware cache coherency protocols solve this. The most common is MESI (Modified, Exclusive, Shared, Invalid):

Each cache line has a state tag (M, E, S, or I) that determines how it may be used. A bus snooping mechanism or directory protocol ensures all cores agree on the current state.

Memory Management Unit (MMU)

The MMU translates virtual addresses (used by software) into physical addresses (used by hardware). This translation enables:

Process isolation - each process has its own virtual address space
Memory protection - preventing processes from accessing each other's memory
Virtual memory - presenting more memory than is physically available

Translation is performed via a page table hierarchy stored in DRAM. To avoid the latency of a full table walk for every access, the CPU caches recent translations in the TLB (Translation Lookaside Buffer):

The ARM SMMU (System Memory Management Unit) extends this concept to non-CPU masters (DMA engines, GPU), ensuring that peripheral DMA transfers are also constrained to authorised memory regions.

Summary

The SoC memory architecture is a carefully designed hierarchy that bridges the speed gap between fast-but-small on-chip SRAM and slow-but-large external DRAM. Caches exploit locality to keep frequently-used data close to the processor. DRAM controllers manage the complex command sequencing needed to drive modern LPDDR memory. The MMU virtualises the address space to enable protection and isolation. Together, these components are often the primary determinant of real-world SoC performance.

Intermediate Articles This Topic Connects To

Cache Coherency Protocols - MESI, MOESI, directory-based coherency in detail
DRAM Subsystem Timing (Advanced) - tRCD, tCL, CWL, refresh, power states, LPDDR5
Memory-Mapped I/O and Linux Device Drivers - How software talks to hardware registers

Previous: SoC Article 04 - Processor Cores

SoC Article 04: Processor Cores - CPU, DSP, GPU and Hardware Accelerators

2026-03-27T00:00:00+00:00

Series: Introduction to SoC Design | Article 4 of 11

Introduction

The processor is the heart of any SoC. But "processor" is a broad term that covers a remarkably diverse family of designs, each optimised for a different class of computation. A modern smartphone SoC may contain a dozen or more distinct processing engines - general-purpose CPUs, a graphics processor, a signal processing cluster, a neural network accelerator, and several smaller microcontrollers managing power and connectivity.

This article surveys the main classes of processor used in SoCs, explains what makes each suited to its domain, and introduces the key architectural concepts every SoC designer needs to understand.

The Processing Landscape

Different computational tasks have different shapes. Some are sequential and unpredictable (parsing a web page). Others are massively parallel and regular (multiplying a matrix). Still others require precisely timed, low-latency responses (handling a radio frame). These different "shapes" of computation call for different processor architectures.

General-Purpose CPU Cores

Architecture Fundamentals

A CPU core executes a sequential stream of instructions: fetch, decode, execute, access memory, write back. The efficiency of this loop determines performance.

Modern CPU cores in SoCs are overwhelmingly RISC (Reduced Instruction Set Computer) designs. The dominant ISA is ARM, with RISC-V growing rapidly in open-source and embedded applications.

The key subsystems inside a CPU core are:

Pipeline Stages

A five-stage pipeline is the canonical teaching model:

The Big-Little Concept

For power-sensitive SoCs (smartphones, wearables), ARM developed the big.LITTLE architecture, which pairs high-performance "big" cores with energy-efficient "little" cores on the same die:

The OS scheduler assigns heavy tasks (video decoding, gaming) to the big cores, and lightweight tasks (receiving notifications, idle polling) to the little cores. This can reduce energy consumption by 10x or more compared to running everything on the big cores.

Key Performance Metrics

IPC (Instructions Per Cycle) - how much useful work a core does per clock cycle
Clock frequency - cycles per second (GHz)
Performance = IPC x Frequency
CPI (Cycles Per Instruction) = 1/IPC; lower is better

Modern high-performance cores achieve IPC values of 4-8 by executing multiple instructions simultaneously (superscalar) and speculatively executing future instructions.

Soft vs Hard CPU Cores

An important distinction for SoC designers is between soft and hard processor cores:

Hard cores are transistor-level implementations physically embedded in the silicon - you cannot change them. They are highly optimised for performance and area. The ARM Cortex-A cores in a smartphone SoC are hard cores licensed from ARM.

Soft cores are RTL descriptions that you synthesise yourself onto the target process or onto FPGA fabric. They are portable and configurable but less efficient. Examples include: - ARM Cortex-M0 (available as soft core for ASIC/FPGA) - RISC-V cores (PicoRV32, VexRiscv, BOOM, Rocket) - MicroBlaze (Xilinx/AMD FPGA soft core) - Nios II (Altera/Intel FPGA soft core)

SoC designers on FPGAs (see Article 09) almost always use soft cores since they are placing logic into reconfigurable fabric.

Digital Signal Processors (DSPs)

A DSP is a processor specialised for signal processing algorithms. Its architecture is tuned for two operations that appear constantly in such algorithms: multiply-accumulate (MAC) and data movement.

The MAC Operation

The core of almost all digital signal processing is the dot product: multiply pairs of numbers and sum the results. This appears in: - FIR filters: y[n] = h[0]x[n] + h[1]x[n-1] + ... + h[N]x[n-N] - FFT (Fast Fourier Transform) - Convolution in image processing and neural networks

A MAC operation computes: Accumulator += A x B in a single cycle.

DSP Architecture Features

DSPs include hardware features that a general-purpose CPU lacks:

Hardware loopers - zero-overhead loops without branch penalty
Dual-MAC units - two multiply-accumulate operations per cycle
Circular addressing - automatic modulo addressing for filter delay lines
Bit-reverse addressing - essential for FFT butterfly operations
SIMD instructions - Single Instruction Multiple Data, processing several samples simultaneously

DSPs are commonly found in SoCs handling audio codecs, cellular modem baseband processing, image signal processing (ISPs), and radar systems.

Graphics Processing Units (GPUs)

A GPU is architected around massive parallelism. Instead of a few powerful, complex cores, a GPU contains hundreds or thousands of simple shader cores that execute in lockstep on large datasets.

The programming model is based on the observation that rendering a 3D scene, applying a filter to an image, or training a neural network involves applying the same operation to many different data points independently.

In mobile SoCs, GPUs are used for: - 3D gaming and UI rendering - Video encode/decode - Computer vision and augmented reality - Machine learning inference (alongside or instead of dedicated NPUs)

Common mobile GPU families include ARM Mali, Qualcomm Adreno, and Apple's own GPU (unnamed, integrated in A-series chips).

Hardware Accelerators

As compute-intensive AI workloads have become dominant, SoC vendors have added dedicated hardware accelerators - fixed-function silicon blocks that execute one type of computation extremely efficiently.

Neural Processing Unit (NPU / Neural Engine)

An NPU accelerates neural network inference - the process of running a trained model on new input data. The core operation is matrix-vector multiplication (essentially a large MAC array).

In a systolic array, data flows through the processing elements rhythmically (like blood through a heart - hence "systolic"). Weights are pre-loaded; activations and partial sums flow through, with each PE performing one MAC per cycle. This achieves very high utilisation of the multiplication hardware.

Video Codec Engine

Encoding and decoding H.264/H.265/AV1 video in software is extremely CPU-intensive. A dedicated hardware codec can process 4K video at 30+ frames per second while drawing milliwatts, compared to watts for a software implementation. Modern SoCs include fixed-function codec blocks that implement the specific algorithms of each video standard.

Cryptographic Accelerator

AES encryption, SHA hashing, RSA/ECC public-key operations, and True Random Number Generation (TRNG) are all candidates for hardware acceleration. Performing AES-128 in hardware can be 50-100x more energy-efficient than software.

Image Signal Processor (ISP)

The camera pipeline - demosaicing, noise reduction, white balance, tone mapping, HDR merging - runs in a dedicated ISP. This is a DSP-like block hardwired to the specific algorithms of computational photography.

The Processor Cluster: Putting It Together

A high-end mobile SoC might contain the following processing elements:

Processor State Machine: A Simplified View

Every processor can be modelled as a state machine. Here is a simplified view of a CPU's states in a typical embedded SoC context:

Choosing the Right Processor for Your SoC

The processor choice depends critically on the application:

Application	Primary Processor	Rationale
IoT sensor node	Cortex-M0+ (soft/hard)	Ultra-low power, simple code
RTOS control system	Cortex-M4 / M7	Real-time response, DSP extensions
Automotive ADAS	Cortex-A + DSP cluster	Linux needed + CV workloads
Smartphone	big.LITTLE Cortex-A	Variable load, battery priority
Edge AI inference	ARM + NPU	Dominates workload
5G baseband	Multi-DSP cluster	Fixed-point signal processing
FPGA prototyping	RISC-V soft core	Open, configurable, no licence fee

Summary

SoC processing subsystems are not monolithic: they combine CPUs for general-purpose code, DSPs for signal processing, GPUs for parallel/graphics workloads, and hardware accelerators for specific high-demand functions like AI inference, video coding, and cryptography. Each architecture is optimised for its domain. The RISC philosophy underpins most modern SoC CPUs, while the systolic array and SIMD principles dominate accelerators. Understanding the trade-offs between these options is one of the core competencies of SoC architecture.

Intermediate Articles This Topic Connects To

Pipeline Design and Hazards - Data, structural, and control hazards; forwarding networks
Cache Coherency Protocols - How multiple CPU cores agree on the state of shared memory
AI Accelerator Architecture (Advanced) - Dataflow, weight stationarity, memory bandwidth

Previous: Article 03 - The SoC Design Stack

SoC Article 03: The SoC Design Stack - From Transistors to Software

2026-03-21T00:00:00+00:00

Series: Introduction to SoC Design | Article 3 of 11

Introduction

In the previous article we looked at what a SoC is. Now we need to understand how it is described, designed, and built. The answer is not a single language or a single tool - it is a stack of abstraction layers, each hiding complexity from the layer above it.

This concept of layered abstraction is one of the most powerful ideas in all of engineering, and it is particularly rich in SoC design, where the stack spans from quantum mechanics at the silicon level all the way up to the C programs and operating systems that run on the finished chip.

The Abstraction Hierarchy

Think of SoC design as a series of nested boxes. Each layer can be understood and reasoned about independently, so long as it respects the contracts defined by the layers around it.

Engineers who work in SoC design typically specialise in one or two adjacent layers. A physical design engineer thinks in terms of polygons and resistance; a firmware engineer thinks in terms of memory-mapped registers and interrupt vectors. The stack is the shared vocabulary that lets them collaborate.

The Gajski-Kuhn Y-Chart

A classic way to visualise the design space is the Y-chart, introduced by Daniel Gajski and Robert Kuhn in 1983. It organises design descriptions along three axes (or "domains"), each of which can be examined at multiple levels of abstraction:

The key insight of the Y-chart is that every design activity maps a description from one domain into another at the same level of abstraction. Synthesis maps a behavioural RTL description into a structural gate-level netlist. Place-and-route maps a structural netlist into a physical layout.

Layer 1: Devices and Transistors

At the very bottom of the stack sits the transistor - the fundamental switch of digital electronics. Modern SoCs are built using CMOS (Complementary Metal-Oxide-Semiconductor) technology, which uses two complementary transistor types: nMOS (conducts when gate is high) and pMOS (conducts when gate is low).

A single CMOS inverter (NOT gate) uses one nMOS and one pMOS transistor. This pairing is elegant: it ensures that when the output is stable, no DC path exists from power to ground, so the circuit draws near-zero static power.

The process of manufacturing transistors is described by the technology node - a number like 5 nm, 7 nm, or 28 nm. This roughly corresponds to the minimum feature size achievable. Smaller nodes pack more transistors into the same area but require more expensive processes.

Layer 2: Logic Gates

Transistors are combined to form logic gates - circuits that implement boolean operations. Gates are the building blocks of all digital logic.

In practice, NAND and NOR gates are the most fundamental - any other gate can be built from them (they are "universal"). Standard cell libraries contain dozens to hundreds of gate variants with different drive strengths, optimised for speed or area.

Layer 3: Register Transfer Level (RTL)

Above the gate level sits the Register Transfer Level (RTL), the primary working abstraction for SoC designers. RTL describes a circuit in terms of:

Registers - collections of flip-flops that hold state
Combinational logic - the boolean functions that compute new values from current state and inputs
Data transfers - moving values between registers, through functional units (ALUs, multiplexers)

RTL is described using a Hardware Description Language (HDL) - either Verilog/SystemVerilog or VHDL. Here is a simple 4-bit counter in both:

// SystemVerilog -- 4-bit synchronous counter with enable
module counter #(parameter WIDTH = 4) (
    input  logic             clk,
    input  logic             rst_n,   // active-low reset
    input  logic             en,
    output logic [WIDTH-1:0] count
);
    always_ff @(posedge clk or negedge rst_n) begin
        if (!rst_n)
            count <= '0;
        else if (en)
            count <= count + 1'b1;
    end
endmodule

-- VHDL -- equivalent 4-bit synchronous counter
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity counter is
    generic (WIDTH : integer := 4);
    port (
        clk   : in  std_logic;
        rst_n : in  std_logic;
        en    : in  std_logic;
        count : out std_logic_vector(WIDTH-1 downto 0)
    );
end entity;

architecture rtl of counter is
    signal cnt : unsigned(WIDTH-1 downto 0);
begin
    process(clk, rst_n)
    begin
        if rst_n = '0' then
            cnt <= (others => '0');
        elsif rising_edge(clk) then
            if en = '1' then
                cnt <= cnt + 1;
            end if;
        end if;
    end process;
    count <= std_logic_vector(cnt);
end architecture;

The behaviour of this counter over time is shown in the timing diagram below:

Layer 4: The Instruction Set Architecture (ISA)

The ISA is the contract between hardware and software. It defines:

The programmer-visible registers (e.g., x0-x31 in RISC-V)
The instruction set - the opcodes and their semantics
Memory addressing modes - how addresses are formed
Exception and interrupt behaviour
Privilege levels - user, supervisor, machine mode

The ISA is intentionally a stable interface. A program compiled for RISC-V will run correctly on any RISC-V implementation, regardless of how many pipeline stages it has, how large its caches are, or whether it executes instructions out of order. The microarchitecture can change entirely as long as it correctly implements the ISA.

There are two broad architectural philosophies:

Attribute	CISC	RISC
Philosophy	Complex instructions doing more work	Simple, fast instructions
Instruction size	Variable (1-15 bytes on x86)	Fixed (4 bytes in RISC-V, ARM)
Register count	Historically few	Many (16-32+)
Examples	x86 / x86-64	ARM, RISC-V, MIPS
Common in SoCs	Desktop/server	Mobile, embedded, IoT

Most modern SoCs use RISC-based ISAs (particularly ARM) because their simpler, more regular instruction encodings are easier to implement efficiently in hardware.

Layer 5: Microarchitecture

The microarchitecture is the implementation of the ISA - the actual pipeline, caches, branch predictors, and functional units that execute instructions. It is typically described at RTL level.

A simple five-stage pipeline illustrates the key idea:

Multiple instructions are in-flight simultaneously, improving throughput. The art of microarchitecture is managing the interactions between them - particularly hazards where one instruction depends on the result of a previous one that hasn't finished yet.

IP Cores: Pre-Built Design Blocks

One of the most important concepts in SoC design is the Intellectual Property (IP) core - a pre-designed, pre-verified block that can be reused in a new design. IP reuse is what makes SoC development tractable: instead of designing every block from scratch, engineers assemble proven components.

IP cores come in three forms:

ARM's Cortex-M series are delivered as soft IP - you receive the RTL description and synthesise it yourself. ARM's Cortex-A series in advanced processes often comes as hard IP - the physical layout is fixed for a particular foundry process.

Common IP blocks found in SoCs:

CPU cores - ARM Cortex-A/M/R, RISC-V cores
GPU IP - ARM Mali, Imagination PowerVR
USB PHY and controller - Synopsys DesignWare
PCIe controller - Synopsys, Cadence
Memory controllers - DDR PHY from specialised vendors
Ethernet MAC/PHY - various vendors
Cryptography engines - AES, SHA, PKA implementations

The Design Flow Overview

Taking an SoC from concept to fabricated silicon follows a structured sequence of steps, each with its own tools and verification checkpoints:

Article 09 in this series covers the design flow in detail. For now, the important point is that design is not a linear process - it is iterative. Problems discovered during synthesis or place-and-route often require revisiting the RTL, and sometimes the architecture.

Modelling Languages: Choosing the Right Abstraction

Different languages are suited to different levels of the design stack:

Language	Level	Primary Use
SystemC	Architecture / TLM	System-level modelling, HW/SW co-design
SystemVerilog	RTL / Gate	Hardware design, simulation, formal
VHDL	RTL / Gate	Hardware design (historically in Europe/defence)
Verilog	RTL / Gate	Older HDL, still widely used
C/C++	Algorithm / Firmware	SW design, hardware test benches
Python	Verification / Tools	Test automation, tooling, cocotb test benches

Summary

SoC design is organised as a stack of abstraction layers, from quantum-mechanical effects in transistors at the bottom to application software at the top. Each layer hides complexity from the layer above it, enabling teams of specialists to collaborate without needing to understand every detail. The key levels are: device/transistor, logic gate, RTL, ISA, microarchitecture, and software. IP reuse is the mechanism that makes modern SoC development tractable. The design flow moves from specification through RTL, synthesis, physical design, and sign-off before tape-out.

Intermediate Articles This Topic Connects To

RTL Synthesis and Timing Closure - How EDA tools map RTL to gates and meet timing
SoC Verification with UVM - Proving the RTL is correct before committing to silicon
Formal Verification Methods - Using mathematics to prove hardware correctness

Previous: Article 02 - What is a System on Chip? Next: Article 04 - Processor Cores: CPU, DSP, GPU and Hardware Accelerators

SoC Article 02: What is a System on Chip? - Anatomy and Motivation

2026-03-15T00:00:00+00:00

Series: Introduction to SoC Design | Article 2 of 11

Introduction

In the previous article we traced the seventy-year journey from room-sized mainframes to silicon-level integration, arriving at the System on Chip - a complete computer system fabricated on a single piece of silicon. Now it is time to look inside one: what blocks does it contain, how do they relate, and why does integration deliver such dramatic benefits?

The Board-to-Silicon Transition

In traditional electronics, a "system" was a circuit board populated with many separate chips, each performing one role: a CPU chip, a separate memory controller, a graphics processor, communication peripheral chips, and a power management IC, all connected by copper traces on the PCB.

A System on Chip collapses most or all of those components onto a single piece of silicon. The processor, memory interfaces, graphics engine, USB controller, cryptographic accelerator, radio interface, and many other functional blocks are fabricated together in one integrated circuit.

The term "SoC" emerged formally in the mid-1990s when transistor densities crossed roughly 100 million per chip - the threshold at which integrating a complete system became both technically practical and economically compelling. Today, modern SoCs routinely contain tens of billions of transistors.

Why Does Integration Matter?

Putting everything on one die is not just about convenience. It delivers fundamental advantages across every dimension that matters.

Speed

On-chip wires are nanometres wide and micrometres long. Signals cross them in fractions of a nanosecond. Signals crossing a PCB encounter far greater inductance and capacitance, longer paths, and the need for high-drive output buffers - all of which introduce significant delay. An on-chip memory access takes 1-5 ns; an off-chip access might take 60-100 ns for the same data.

Power Efficiency

Driving a signal off-chip requires pumping it up to a voltage level and current that the PCB can handle reliably - this is fundamentally wasteful. On-chip signalling operates at much lower voltages (as little as 0.4 V for the fastest paths) and does not need the drive strength of an off-chip interface. Every chip-to-chip boundary eliminated saves power directly.

Area and Cost

Fewer chips means a smaller PCB, which means a smaller, lighter product. At the volumes of the smartphone market (billions of units per year), even a 5 mm² reduction in PCB area translates into substantial savings. One complex SoC may cost less to manufacture and assemble than the collection of chips it replaces.

Reliability

Solder joints and connectors are the most common failure points in electronic assemblies. Fewer chips mean fewer joints, longer mean time between failures, and better suitability for vibration-prone environments (automotive, industrial, aerospace).

The Anatomy of a Generic SoC

While no two SoCs are identical, most share a recognisable set of functional blocks:

Each block has its own dedicated article later in the series. Here is a brief map of what each does:

Processing Subsystem

The "brains" of the SoC. One or more CPU cores execute general-purpose software. Alongside them are specialised processors - DSPs for signal processing, GPUs for graphics and parallel computation, and dedicated hardware accelerators for AI inference, video coding, and cryptography. (Article 04)

Memory Subsystem

On-chip SRAM provides fast, low-latency storage close to the processors. DRAM controllers connect to external memory for the large working set. A cache hierarchy sits between the two. (Article 05)

System Interconnect

The internal "highway" connecting all blocks. High-bandwidth connections use AXI; lower-bandwidth peripheral connections use AHB or APB. (Article 06)

DMA Engine

Direct Memory Access allows peripherals to move blocks of data to/from memory without involving the CPU - essential for high-throughput peripherals like USB, Ethernet, and cameras. (Article 08)

Peripherals

The interfaces that connect the chip to the external world: UART, SPI, I2C, GPIO, USB, Ethernet, and many others. (Article 08)

Clock and Reset

A PLL generates the precise, stable frequencies each subsystem requires. The reset subsystem places all flip-flops in a known initial state after power-up. (Article 07)

Power Management

The PMU selectively powers down idle blocks, runs the CPU at lower voltage when full speed is not needed, and manages battery charging in portable devices. (Article 07)

Security Engine

Dedicated hardware for encryption, secure boot, key storage, and access control. ARM TrustZone partitions the chip into secure and non-secure domains. (Article 11)

SoC Examples in the Real World

SoC	Application	Notable Features
Apple A18 (iPhone 16)	Smartphone	6-core CPU, 6-core GPU, Neural Engine, 16 B transistors
Qualcomm Snapdragon 8 Gen 3	Android phone	big.LITTLE cluster, Hexagon DSP, integrated 5G modem
NVIDIA Orin	Autonomous vehicles	12-core ARM, Ampere GPU, deep learning accelerator
Raspberry Pi RP2040	Hobbyist MCU	Dual Cortex-M0+, PIO state machines, 264 KB SRAM
Nordic nRF5340	IoT / BLE	Dual ARM cores, Bluetooth 5.3 radio integrated on-chip
Xilinx Zynq UltraScale+	FPGA SoC	ARM quad-core + FPGA fabric + GPU + DSP slices

The range here is important. An SoC is not just a smartphone chip. The same integration principle applies from a $0.50 microcontroller running a light switch to a $200 chip managing an autonomous vehicle.

The Complexity Challenge

Integration delivers benefits, but it raises design complexity to a different level entirely. A modern SoC is designed by teams of hundreds of engineers over one to three years. The design must:

Meet timing requirements across all operating conditions (voltage, temperature, process variation)
Be verified correct before manufacture - a bug in silicon costs millions to fix
Balance the competing bandwidth demands of many simultaneous data flows
Boot reliably from cold power-off and recover gracefully from faults
Meet strict power and thermal budgets across wildly different workloads

Managing this complexity is the central discipline of SoC design, and it is the reason for the structured methodologies this series explores.

HW/SW Duality

A crucial insight for SoC design is that hardware and software are both valid ways to implement any function. The choice between them is a trade-off, and it shapes the entire architecture:

Attribute	Hardware	Software
Performance	Very high (parallel, GHz)	Lower (sequential execution)
Flexibility	Fixed after tape-out	Updateable/patchable
Energy efficiency	Excellent for specific tasks	Lower for the same task
Development time	Long, expensive	Shorter, cheaper
Debugging difficulty	Very high post-silicon	Much easier

Most SoCs exploit this duality deliberately - placing performance-critical, stable functions in hardware, and flexible or complex control logic in software. Understanding where to draw that line is one of the core skills in SoC architecture and is the subject of Article 11.

Summary

A System on Chip integrates what was once a board full of discrete chips - processors, memory controllers, communication interfaces, and more - onto a single piece of silicon. Integration delivers speed (proximity), power efficiency (no off-chip driving), smaller area (fewer chips), and higher reliability (fewer solder joints). Every SoC shares a recognisable anatomy: processing subsystem, memory subsystem, system interconnect, DMA engine, peripherals, clock/reset, power management, and security. The following articles examine each of these in turn.

Intermediate Articles This Topic Connects To

AXI4 Protocol Deep Dive - The interconnect in detail
SoC Power Management Techniques - DVFS, power gating, retention
Heterogeneous SoC Partitioning (Advanced) - Formal HW/SW co-exploration

Previous: Article 01 - From Room to Silicon Next: Article 03 - The SoC Design Stack: From Transistors to Software

Managing Dotfiles with Stow and Git

2026-03-07T00:00:00+00:00

Configuration files (dotfiles) for tools like Zsh, Vim, tmux, and Git tend to accumulate across machines over time. Without a strategy, they diverge: one machine has tuned aliases, another has an old vimrc, and a new machine starts from scratch. Keeping dotfiles in a single Git repository solves this. Clone once, link into place, and every machine stays consistent.

My dotfiles are on GitHub at morganp/dotfiles.

Why Centralise Dotfiles

A single source of truth for all shell and tool configuration.
Version history lets you see what changed and roll back if something breaks.
Setting up a new machine reduces to cloning the repo and running a handful of commands.
Sharing config across macOS and Linux with minimal platform-specific branching.

Cloning the Repo

git clone https://github.com/morganp/dotfiles.git ~/dotfiles

Linking Config Files

There are two approaches depending on the tool.

Sourcing (Zsh and Vim)

Some tools are simplest to handle by having the home directory config file source the dotfiles version directly.

Zsh -- add to ~/.zshrc:

source ~/dotfiles/config/shell/dot-zshrc

Vim -- add to ~/.vimrc:

so ~/dotfiles/config/vim/dot-vimrc_clean

GNU Stow (Everything Else)

GNU Stow manages symlinks. It takes a package directory and creates symlinks in a target directory that mirror the structure. With the --dotfiles flag, files named dot-foo are linked as .foo in the target, keeping the repo free of files that would be hidden by default.

Install Stow and other packages via Homebrew:

brew bundle install --file=~/dotfiles/config/brew

Then link the remaining configs:

cd ~/dotfiles/config
stow git --dotfiles -t ~/
stow input --dotfiles -t ~/
stow screen --dotfiles -t ~/

A run_stow script in the repo automates this.

Tmux

Tmux looks for its config via the $XDG_CONFIG_HOME variable, set in config/shell/dot-profile:

$XDG_CONFIG_HOME/tmux/tmux.conf

For the tmux plugin manager, clone TPM separately:

git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm

Shell Features

The dotfiles configure the following shell aliases across Bash and Zsh:

Alias	Description
`ls`	File list with colour
`ll`	Long list with human-readable sizes and colour
`la`	As `ll` but includes hidden files
`lt`	Directory tree view
`..`	Up one directory

Other configurations included:

Screen: Virtual tabs across the bottom in standard colours.
Inputrc: Case-insensitive tab completion, including hidden files.

Emotional Intelligence in the Workplace

2026-03-07T00:00:00+00:00

Emotional intelligence (EQ) is the ability to recognise, understand, and manage your own emotions, as well as the emotions of those around you. In professional settings, EQ significantly influences how individuals lead, collaborate, and navigate difficult situations.

High EQ: What It Looks Like

Leaders and employees that demonstrate high EQ:

Navigate not just motivating and empowering employees and team members, but also navigate complex and challenging decision making with the mastery of emotional response.
Are realistic but not negative and overcome with their emotions.
Are enthusiastic and confident in themselves and the team.
Demonstrate trust and respect.
Are communicative and cooperative.
Volunteer for assignments and decisions.
Include and engage others as much as possible.
Share openly with the team.
Demonstrate empathy.
Actively listen.
Are flexible.
Develop their teams.

Low EQ: Warning Signs

Low EQ may show up as:

Emotional outbursts, typically out of proportion to the situation at hand.
Not listening to others.
Becoming argumentative.
Blaming others.
Believing that others are overly sensitive, because the person with low EQ cannot understand how others feel.
Difficulty maintaining friendships and other relationships.
Stonewalling, or refusing to see other points of view.

Why It Matters

High EQ is not about suppressing emotion -- it is about channelling emotion constructively. Teams led by high-EQ individuals tend to communicate more openly, recover from setbacks more quickly, and make better collective decisions. Recognising low EQ behaviours early, in yourself and others, is the first step toward building a healthier team culture.

MakerWorld Parametric Models with OpenSCAD

2026-03-07T00:00:00+00:00

MakerWorld listings with a "Customize" button let users tweak model parameters, preview changes live, and download a ready-to-print file. Under the hood, these are OpenSCAD scripts. MakerWorld runs the script inside their Parametric Model Maker app and presents the configurable variables as a UI for the end user.

If you can write an OpenSCAD script that generates your model and expose the key dimensions as variables, MakerWorld handles the rest: a polished customizer UI and a downloadable 3mf file.

OpenSCAD is a free, code-based CAD tool. Rather than clicking tools and dragging dimensions, you describe geometry as code. For example, instead of drawing a sphere and setting its diameter to 20mm, you write:

sphere(d = 20);

Think of it as scripting the feature timeline you would normally follow in Fusion 360 or Onshape.

Getting Started with OpenSCAD

Learning resources:

YouTube tutorials are the quickest way to get a feel for what OpenSCAD can do.
The official OpenSCAD documentation and cheatsheet are available online.
LLMs like ChatGPT are surprisingly effective: describe the object you want, ask for an OpenSCAD script, and iterate from there.

Testing your script:

Run it locally in OpenSCAD on your own machine as you develop.
Or use MakerWorld's Parametric Model Maker directly in your browser without installing anything.

Which version of OpenSCAD does MakerWorld support?

MakerWorld is compatible with the 2021 official release. The project has daily development builds with additional features, but stick with the stable 2021 release to ensure compatibility.

Publishing to MakerWorld

To add a Customize button to your listing, create a new MakerWorld listing and upload the .scad file instead of a .3mf file. MakerWorld will automatically detect it and enable the customizer. You also earn MakerWorld points when users download via the Customize button.

Controlling the Customizer UI

Any variable declared at the top of your script appears as an editable field in the UI automatically. To control the widget type (slider, dropdown, colour picker, help text), use comments following the OpenSCAD Customiser standard. The easiest way to explore the options is to click the "Sample Code" icon in the bottom-left of the Parametric Model Maker. It loads example code demonstrating all available widgets.

Example: dropdown with named options

// Select which size you want
Box_Size = 10; // [10:Large, 5:Medium, 1:Small]

Font selector:

Label_Font = "Arial"; // font

Available fonts are those pre-loaded by MakerWorld, which includes most of Google Fonts. The full list is in the Parametric Model Maker under the "Book" icon then "Third-party fonts".

Libraries

MakerWorld supports a curated set of OpenSCAD libraries:

Library	Purpose
BOSL2	General-purpose functions and geometry
UB	Miscellaneous utilities
KeyV2	Keyboard keycap generation
gridfinity-rebuilt-openscad	Gridfinity bin generation
threads-scad	Threaded parts
Getriebe	Gear generation
knurledFinishLib_v2	Knurled surface textures

Largely based on this Reddit post in r/BambuLab.

OpenSCAD on Apple Silicon

2026-03-07T00:00:00+00:00

OpenSCAD is a script-based 3D CAD modeller, well suited to parametric and printable part design. The snapshot release has native Apple Silicon support.

Install Homebrew

If Homebrew is not already installed, run the following in Terminal:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Install OpenSCAD

The snapshot cask provides the latest development build with native ARM support:

brew install --cask openscad@snapshot

Once installed, OpenSCAD will be available in /Applications and can be launched from Spotlight or the Applications folder.

reMarkable: Local File Transfer Without the Cloud

2026-03-07T00:00:00+00:00

The reMarkable tablet is excellent for reading and annotating PDFs, but by default it routes everything through reMarkable's cloud. If you prefer to keep files local -- for privacy, or simply because you do not want a subscription -- you can unpair the device and use the built-in USB file server instead.

Unpairing from the Cloud
Enabling the USB Web Interface
Transferring Files via http://10.11.99.1/
Tips and Limitations

1. Unpairing from the Cloud

Unpairing stops the device from syncing to reMarkable's servers. Your existing documents remain on the device; they are simply no longer backed up or accessible from the reMarkable apps on other devices.

On the tablet:

Open Settings (gear icon, bottom-left of the home screen)
Go to Storage
Tap Unpair device
Confirm when prompted

Once unpaired, the tablet no longer requires a reMarkable account or internet connection for normal use. The cloud sync icon will disappear from the top bar.

Note: Unpairing is reversible. You can re-pair the device at any time from the same Settings screen by signing back in to your reMarkable account.

2. Enabling the USB Web Interface

The reMarkable has a built-in HTTP file server that becomes accessible over USB. When enabled, the tablet presents itself as a USB network adapter and serves files at http://10.11.99.1/.

On the tablet:

Open Settings
Go to Storage
Enable USB transfer (the toggle may be labelled "USB web interface" depending on firmware version)

Connect the tablet to your computer using the supplied USB-C cable. The tablet will appear as a network device (USB Ethernet adapter) rather than a mass storage drive.

On Linux the interface typically appears as usb0 or enp0s20u1 and receives an address in the 10.11.99.0/24 subnet automatically via DHCP from the tablet.

Verify connectivity:

ping 10.11.99.1

3. Transferring Files

Open a browser and navigate to:

http://10.11.99.1/

The web interface shows all documents and notebooks currently on the device, organised in folders matching the tablet's home screen layout.

Uploading PDFs

Click Import (or the upload button, top-right)
Select one or more PDF files from your computer
The files appear on the tablet home screen immediately -- no restart required

Supported formats: PDF and EPUB.

Downloading annotated files

Click on any document in the web interface
Select Download to save the annotated PDF to your computer

The downloaded file includes all pencil annotations, highlights, and notes made on the tablet.

Command-line upload with curl

For scripting or batch uploads:

curl -X POST http://10.11.99.1/documents/ \
  -F "file=@/path/to/document.pdf"

To upload into a specific folder, first find the folder UUID from the web interface URL, then:

curl -X POST "http://10.11.99.1/documents/{folder-uuid}" \
  -F "file=@/path/to/document.pdf"

4. Tips and Limitations

No Wi-Fi required. The USB file server works entirely over the USB cable with no network connection needed.
Cable must stay connected. The web interface is only available while the tablet is plugged in. Unplugging immediately drops the 10.11.99.1 address.
One client at a time. The built-in server is minimal; avoid opening multiple browser tabs uploading simultaneously.
Folder structure is flat internally. The reMarkable stores documents with UUIDs internally; the folder hierarchy you see in the web interface is a virtual view maintained by the device.
Firmware updates still work offline. Updates are downloaded over Wi-Fi separately from the cloud sync; unpairing does not block firmware updates if Wi-Fi is available.
Annotations on existing PDFs are exported as a new annotated PDF -- the original on- device file is not modified.

SoC Article 01: From Room to Silicon — The Story of the Computer System

2026-03-07T00:00:00+00:00

Series: Introduction to SoC Design | Article 1 of 11

Introduction

There is a photograph from 1964 that captures the scale of computing at the time. It shows two engineers installing an IBM System/360 Model 50. They are not sitting at desks. They are standing in a large, air-conditioned room, surrounded by cabinets the size of wardrobe closets, connected by thick bundles of cabling snaking under a raised false floor. The computer weighs approximately two tonnes. It required specialist riggers with cranes and fork trucks to move into the building. It draws 30 kilowatts of power — enough to heat several homes.

That machine cost around $3.5 million in 1964 dollars. It performed roughly 500,000 operations per second.

The phone in your pocket performs about 15 trillion operations per second - thirty million times more — on a sliver of silicon roughly 100 mm² in area, weighing a fraction of a gram, drawing less than three watts. It fits comfortably in a jacket pocket.

This article is the story of how we got from there to here. It is not just a history lesson. Understanding the shape of that journey — what drove miniaturisation at each step, and what trade-offs were made along the way — is essential context for understanding why modern SoC design is structured the way it is.

What is a "System"?

Before discussing a System on Chip, we should understand what the word "system" means in this context.

In engineering, a system is a collection of components that work together to perform a function greater than any single component could achieve alone. A computer system, in the classical sense, means all the hardware necessary to store, retrieve, and process information:

processor — the arithmetic and logic engine
Memory — where programs and data live
Storage - where data persists when power is off
Input/Output — keyboards, displays, printers, serial ports
Interconnect — the buses and cables that tie it all together
Power supply — the electrical infrastructure

For decades, each of these was a separate physical unit, often made by different vendors, assembled on a raised floor in a dedicated machine room. The history of computing is largely the story of these components shrinking, converging, and ultimately merging.

Era 1: The Room-Sized Machine (1950s–1960s)

Valves and Racks

The earliest electronic computers used vacuum tubes (valves) as their switching elements. A vacuum tube is roughly the size of a light bulb. A computer that needs hundreds of thousands of switching elements built from vacuum tubes fills a building.

ENIAC (1945) is the canonical example: 17,468 vacuum tubes, 70,000 resistors, 10,000 capacitors, filling a room 2.4 m × 1.8 m × 30 m. It consumed 150 kilowatts of power and broke down regularly — with so many valves, a failure every few hours was normal. Operators spent more time repairing it than computing with it.

The Manchester Baby (1948), while tiny by comparison, still occupied a substantial rack of equipment and required skilled operators to program it using switches and plugboards.

Approximate Physical Scale — 1950s Computer Systems

  ┌──────────────────────────────────────────────────────────────────┐
  │                                                                  │
  │  ENIAC (1945)                                                    │
  │                                                                  │
  │  [██████████████████████████████████████████████████████████]    │  ← 30 metres
  │  [█ Accumulator █][█ Multiplier █][█ Divider █][█ I/O █][█...█]  │
  │                                                                  │
  │  Weight: ~27 tonnes   Power: 150 kW   Speed: 5,000 ADD/sec       │
  │                                                                  │
  └──────────────────────────────────────────────────────────────────┘

The Transistor Changes Everything

In 1947, Bell Labs invented the transistor. It did the same job as a vacuum tube — acting as an electronic switch — but was smaller, faster, cooler, more reliable, and consumed far less power. By the late 1950s, computers began to be built from transistors instead.

IBM System/360 (1964) was a landmark: the first family of computers with a common instruction set, so that programs written for one model would run on any other. But it was still a room-scale machine. The System/360 Model 50 filled multiple cabinets, required dedicated air conditioning, and had to be craned into the computer room through specially widened doorways or lowered through the roof.

The economics were equally extreme: only universities, large corporations, government agencies, and national laboratories could afford to own one. Everyone else bought time-shares, submitting jobs on punched cards and waiting hours for results.

Era 2: The Minicomputer (1965–1975)

Thinking Small

The minicomputer was not called "mini" because it was small by today's standards. It was called mini because it was dramatically smaller than the mainframes it accompanied — small enough to fit in a single large cabinet, deliverable in a standard lift, operable without a dedicated air-conditioned room.

Digital Equipment Corporation (DEC) pioneered this category. Their PDP-8 (1965) was a 12-bit machine that cost $18,000 — expensive, but accessible to a laboratory, university department, or medium-sized company without a dedicated data centre.

The PDP-11 (1970) is one of the most important computers ever designed. It was a 16-bit machine that fit in a single rack about the size of a tall filing cabinet. It had a clean, elegant instruction set that influenced virtually every processor architecture that followed — including Unix, which was first developed on a PDP-7 and PDP-11.

DEC PDP-11 (1970) — Physical Footprint:

  ┌─────────────────────┐
  │  ┌───────────────┐  │
  │  │  Backplane    │  │  ← Processor and memory cards slot in here
  │  │  (UNIBUS)     │  │
  │  │               │  │
  │  │  CPU card     │  │  ← A single card, 30 cm × 25 cm
  │  │  Memory cards │  │
  │  │  I/O cards    │  │
  │  └───────────────┘  │
  │  Power supply       │
  └─────────────────────┘
    ~ 60 cm × 45 cm × 60 cm
    Weight: ~30 kg
    Power: ~300 W
    Speed: ~1 million ops/sec
    Cost: ~$10,000 (1970)

The PDP-11 introduced several ideas that persist in modern SoC design: memory-mapped I/O (where peripherals appear as addresses in the memory map), a bus standard (UNIBUS), and the concept of a clean separation between the processor and the rest of the system through a well-defined bus interface.

The Minicomputer Era's Legacy

The minicomputer era produced ideas that underpin every SoC today:

Bus standards — the UNIBUS, Multibus, and S-100 buses established the principle that components from different vendors could interoperate on a common bus
Operating systems — Unix was born on the PDP-11; its model of processes, file descriptors, and device drivers lives on in Linux running on modern SoCs
Modular architecture — CPU, memory, and I/O were separate cards in the same backplane, a precursor to the IP block model

Era 3: The Microprocessor (1971–1980)

Everything on One Chip

In 1971, Intel introduced the 4004 — the first microprocessor. It placed the entire CPU — arithmetic unit, registers, control logic — onto a single chip about 12 mm². It ran at 740 kHz and processed 4-bit numbers.

This was a revolutionary idea: previously, a "CPU" was a cabinet full of boards. Now it was a package you could hold between your fingers.

The 8080 (Intel, 1974), 6502 (MOS Technology, 1975), and Z80 (Zilog, 1976) followed in rapid succession. These 8-bit processors became the engines of the personal computer revolution.

The Intel 8086 (1978) and Motorola 68000 (1979) raised the bar to 16-bit, with the 68000 in particular earning a reputation for elegance and performance that made it the choice for the Apple Macintosh, the Amiga, the Atari ST, and countless workstations.

But the microprocessor alone was just the CPU. Everything else — memory, storage, I/O — was still provided by separate chips on a board. The "system" was still a board, just a smaller one.

Era 4: The Personal Computer (1977–1990)

The Desktop System

The first personal computers were kits for hobbyists. The Altair 8800 (1975) was an 8080-based machine with no keyboard, no display, and no software beyond a bootloader — users programmed it by toggling switches on the front panel.

Within a few years, Apple, Commodore, and Tandy produced complete personal computers: CPU, RAM, ROM, keyboard, display output, and storage on a single motherboard in a desktop enclosure. The Apple II (1977) sold as a complete system you could put on a desk.

Apple II Motherboard (1977) — A Complete Computer System on One Board:

  ┌────────────────────────────────────────────────────────────────┐
  │                       Apple II Motherboard                     │
  │                                                                │
  │  [6502 CPU]  [RAM chips × 8]  [ROM chips × 2]  [Video chip]    │
  │                                                                │
  │  [Keyboard encoder]  [Cassette I/O]  [Speaker driver]          │
  │                                                                │
  │  ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐       │
  │  │Slot│ │Slot│ │Slot│ │Slot│ │Slot│ │Slot│ │Slot│ │Slot│       │
  │  │  1 │ │  2 │ │  3 │ │  4 │ │  5 │ │  6 │ │  7 │ │  8 │       │
  │  └────┘ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘       │
  │                (expansion cards for disk, serial, etc.)        │
  │                                                                │
  │  Board size: ~30 cm × 25 cm    Number of chips: ~66            │
  │  System power: ~25 W           Speed: 1 MHz                    │
  └────────────────────────────────────────────────────────────────┘

The IBM PC (1981) standardised the desktop architecture that dominated computing for three decades: a processor, a chipset handling memory and I/O, expansion slots for peripherals, and a shared bus (first ISA, later PCI). By the late 1980s, a PC could sit on a desk, consume 50–200 W, and perform millions of operations per second for a few thousand dollars.

The chip count had fallen from thousands (mainframe) to hundreds (minicomputer) to dozens on a single motherboard. But a PC motherboard was still a system assembled from many chips: CPU, north bridge, south bridge, graphics chip, sound chip, network chip, storage controller, and many more.

Era 5: The Laptop — Mobile Demands Integration

Batteries Change Everything

The first truly portable computers appeared around 1981. The Grid Compass (1982) was used by NASA and the US military — it was functional but cost $8,000 and ran for barely four hours on battery. The Compaq LTE (1987) was the first laptop to use a 3.5" hard drive and internal battery in a genuinely portable form factor.

Mobile computing imposed a constraint that desktop design had never faced: batteries. A desktop computer plugged into the wall can draw as much power as needed. A laptop must run for hours on a battery with finite energy.

Power Budget — Desktop vs. Laptop (late 1980s):

  Desktop PC (1988):         Compaq LTE (1987):
  Power: ~150 W              Power: ~8 W
  Battery: none              Battery: NiCd, ~2 hr life
  Weight: ~10 kg             Weight: ~3 kg
  Size: tower case           Size: 28 cm × 22 cm × 4 cm

  Problem: the same chips designed for desktop
  drew 150 W — far too much for a battery.
  A new approach to chip design was needed.

Power pressure drove two responses:

Low-voltage CMOS — designers switched from bipolar logic (powerful but power-hungry) to CMOS (Complementary Metal-Oxide-Semiconductor), which consumes power only when transistors switch, not when they are idle. This dramatically reduced both active and standby power.

Integration — every chip-to-chip interface wastes energy driving signals off-chip and back. Merging two chips into one removes those interfaces. The laptop era was the first time integration was driven primarily by power rather than just performance.

Era 6: The Mobile Phone and the ARM Architecture

An Architecture Built for Efficiency

In 1983, Acorn Computers in Cambridge designed their own processor: the Acorn RISC Machine, or ARM. It was a 32-bit RISC processor designed to be simple, low-power, and fast enough for interactive computing in an inexpensive product. The original ARM1 ran at 6 MHz and consumed a fraction of a watt — remarkable for 1985.

Acorn spun off Advanced RISC Machines Ltd in 1990 as a joint venture with Apple and VLSI Technology. Rather than manufacturing chips itself, ARM licenced its architecture to other companies — a business model that would eventually see ARM cores inside virtually every mobile device on the planet.

The first mobile phones were large, power-hungry, and limited. As GSM digital mobile telephony spread in the 1990s, phones needed to perform signal processing (decoding the radio channel), handle the telephone UI, and manage a small battery. They could afford perhaps 200 mW of sustained power.

A phone of the early 2000s had several separate chips: a baseband processor (running the radio protocols), an application processor (running the UI and apps), a power management IC, a display controller, and various analog front-ends for audio and radio. These chips communicated over a shared PCB — the "system" was a small board inside a plastic case.

This was the moment before SoC. All the pieces existed — they just were not yet on the same die.

Era 7: The System on Chip (1995–present)

Integration Crosses a Threshold

As process technology advanced through the 1990s — from 350 nm to 250 nm to 180 nm — the number of transistors that could be fabricated reliably on a single die crossed 100 million. That is enough transistors to implement not just a CPU, but everything around it: memory controllers, DSPs, display engines, USB, audio, and power management.

The Texas Instruments OMAP series (early 2000s) was among the first true smartphone SoCs: ARM application processor, DSP, camera interface, display controller, and power management all on one die. This appeared in early Nokia smartphones and PDAs.

Apple's acquisition of PA Semi in 2008 and its launch of the A4 SoC in 2010 (the first iPhone 4 chip) signalled that the world's most valuable consumer electronics company was betting everything on the SoC model. Qualcomm, Samsung, MediaTek, and HiSilicon followed with their own vertical SoC programmes.

The convergence was complete:

The Integration Journey — Same Computational Power, Shrinking Footprint:

  Year   System                      Physical Size       Power    Transistors
  ─────────────────────────────────────────────────────────────────────────
  1964   IBM System/360 Model 50     2 rooms, 2 tonnes   30 kW    ~500,000
  1970   DEC PDP-11/20               Filing cabinet      300 W    ~20,000 *
  1977   Apple II (full system)      Desk (30×25 cm PCB) 25 W     ~100,000 *
  1982   Intel 80286 CPU alone       28-pin DIP package  3 W      134,000
  1993   Intel Pentium               273-pin PGA chip    15 W     3.1 M
  2003   Nokia 6600 (5 chips total)  PCB inside a phone  200 mW   ~50 M total
  2010   Apple A4 SoC                12 mm × 12 mm die   ~1 W     ~300 M
  2020   Apple A14 SoC               88 mm² die          ~3 W     11.8 B
  2024   Apple A18 SoC               90 mm² die          ~3 W     ~16 B
  ─────────────────────────────────────────────────────────────────────────
  * Approximate, counting discrete transistors and SSI/MSI chips

Moore's Law: The Engine of Miniaturisation

No account of this journey is complete without Moore's Law. In 1965, Gordon Moore (co-founder of Intel) observed that the number of transistors on a commercially practical integrated circuit doubled approximately every two years. This was an empirical observation about the economics of the semiconductor industry, but it became a self-fulfilling prophecy: the industry organised itself to deliver that doubling, and did so for more than fifty years.

Each doubling meant that the same design could be shrunk to half the area (reducing cost), or that twice as much logic could fit in the same area (enabling integration). Both drove the SoC story.

Moore's Law has slowed in recent years — physical limits make further miniaturisation increasingly difficult and expensive below 3 nm. The industry is responding with new techniques: 3D stacking (chips stacked vertically), chiplets (multiple dies in one package), and new materials. But the principle — relentless pressure toward more integration per unit cost — continues.

What "System" Means Now

Return to where we started: the IBM System/360, craned into a dedicated machine room, requiring a team of operators and a purpose-built building to run.

Today's SoC is a more capable system — more memory, faster clock, more peripherals, better networking — occupying an area smaller than a fingernail, drawing power measurable in milliwatts, costing a few dollars to manufacture at scale.

But it is still a system: processor, memory controller, interconnect, peripherals, power management, security hardware. The same logical building blocks exist. They have simply been reimplemented in silicon, brought together on a single die, separated by wires measured in nanometres rather than copper cables measured in metres.

Understanding that lineage — why the blocks exist, what problems they solve, where the trade-offs come from — is the context for everything that follows in this series.

Summary

Computer systems began as room-filling collections of vacuum tubes. The transistor enabled the minicomputer — a cabinet-scale machine accessible to laboratories and companies. The microprocessor collapsed the CPU onto a single chip and made the personal computer possible. Mobile computing added battery constraints that drove integration for power efficiency. The System on Chip emerged when transistor densities crossed the threshold that made fitting an entire system — CPU, memory, peripherals, and more — onto a single die both technically feasible and economically compelling. Moore's Law underpinned the entire journey, doubling integration density roughly every two years for five decades.

Series Roadmap

Article	Topic
01	From Room to Silicon — History of the Computer System (this article)
02	What is a System on Chip? — Anatomy and Motivation
03	The SoC Design Stack: From Transistors to Software
04	Processor Cores: CPU, DSP, GPU and Hardware Accelerators
05	Memory Architecture: Caches, DRAM, and On-chip Storage
06	Interconnects and Bus Protocols: AXI, AHB, and APB
07	Clocking, Reset, and Power Domains
08	Peripherals and I/O: Connecting the SoC to the World
09	Hardware Description Languages and RTL Design
10	The SoC Design Flow: From Specification to Silicon
11	HW/SW Co-Design: Bridging Software and Silicon

Next: Article 02 - What is a System on Chip? Anatomy and Motivation

Requirements Writing

2026-03-06T18:00:00+00:00

Good requirements engineering is fundamental to delivering products that meet customer needs within cost and schedule. A well-formed requirement identifies a specific user or stakeholder, defines a positive end result, and states a measurable success criterion -- for example: "The internet user shall be able to access their current account balance in less than 5 seconds." Requirements must be unambiguous, singular (one requirement per statement), and free of escape clauses such as "unless", "except", or "if possible". They should avoid designing the solution, speculating about future needs, or using vague qualitative terms like "user-friendly" or "flexible" that cannot be verified. The normative terms shall, should, and may carry specific and distinct meanings -- using them precisely is critical to a traceable and verifiable requirement set.

Note: The IBM Requirements Writing Training document uses 'shall' or 'will' interchangeably to signal a mandatory requirement. The IEEE Standards Style Manual (also referenced below) deprecates the use of 'will' for mandatory requirements, reserving it for statements of fact only. The IEEE definition is the preferred usage.

Normative Terms

Normative requirements are normally phrased using one of the three terms below: shall, should, or may. All normative elements that are requirements (shall) are to be followed in all cases in order to be in conformity.

Term	Priority	Description
'Shall'	High	'Must-have' for minimum viable product (MVP)
'Should'	Medium	'Desirable' in product and to be considered for phase 1, including any impact
'May'	Low	'Nice-to-have' and could be included if no impact to key metrics. Should log decision.

Use of Special Terms (from IEEE Standards Style Manual)

The word shall is used to indicate mandatory requirements strictly to be followed in order to conform to the Specification and from which no deviation is permitted (shall equals is required to).

The use of the word must is deprecated and shall not be used when stating mandatory requirements; must is used only to describe unavoidable situations.

The use of the word will is deprecated and shall not be used when stating mandatory requirements; will is only used in statements of fact.

The word should is used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited (should equals is recommended that).

The word may is used to indicate a course of action permissible within the limits of the Specification (may equals is permitted to).

The word can is used for statements of possibility and capability, whether material, physical, or causal (can equals is able to).

All sections are normative, unless they are explicitly indicated to be informative.

Requirement Categories

The following categories reflect a common industry classification used in semiconductor product development.

Category	Definition	Owner
CR	Customer Requirement -- A customer need that the product needs to meet. Gathered from customer interaction, field channels or market research. May not be possible to meet all CRs on a product due to risk or resources.	Marketing, Systems
SR	System Requirement -- Describes the required black-box behaviour of the device. Customer visible SRs are the primary basis for the datasheet. Often, an SR translates a CR into the plan-of-record for a product. Captures the negotiated attribute. May not fully meet the ideal CR.	Systems
DR	Design Requirement -- Result of distillation of SR, driven by implementation choices that do not affect the black-box behaviour but need to be defined for the design or verification team. Capture constraints required to implement the SRs.	Design
VR	Verification Requirement -- Description of what needs to be done to ensure an SR and/or DR is implemented correctly. Linked to at least one SR and/or DR. Checks and coverage information is recorded in VRs.	Verification
VAR	Validation Requirement -- A concise description of how an SR or DR of any requirement type will be covered with a test case during the emulation or post-silicon phase of development. Validation requirements check whether we implemented the right thing through means of functional testing or parametric silicon measurements. Test conditions are recorded in a VAR. Linked to at least one SR.	Validation

Requirement Types

Type	Definition
Functional	Normative functional requirements that can be verified and/or validated.
Parametric	Normative parametric requirements that can be verified and/or validated.
Register Field	Normative register field requirements.
Informative	Informative requirement content, not actionable, but provides context for better interpretation of normative requirements. Informative elements are illustrations, examples, or suggestions that explain the meaning and implications of requirements, as well as case studies on their application. May include diagrams and other attachments which are not to be treated as normative.
Use Case	System-level use cases. Commonly captured as diagrams and set context (informative) but can require verification and distillation into further requirements (normative).

Resources

Scotland Outdoor Routes

2026-03-06T12:00:00+00:00

Misc

Historic Scotland (Family £106/year includes entry to Edinburgh Castle): https://www.historicenvironment.scot/

Site Map (PDF)

Mapping


Memory Map (£25/year)	https://memory-map.com/maps/uk-os-topo-maps/
Bing Maps, switch from Road to Ordnance Survey (free)	https://www.bing.com/maps
Ordnance Survey Maps (7 day free trial, £24/year)	https://osmaps.ordnancesurvey.co.uk/
Rucksack Readers for long distance routes (~£15 per map)	https://www.rucsacs.com/book-category/scotland/
Spokes Cycle Maps (~£7 per map)	http://www.spokes.org.uk/spokes-maps/
Urban Nature Maps (Edinburgh & Glasgow, £10 each)	edinburgh-urban-nature-map
Scots Ways	https://scotways.com/maps-and-leaflets/

All Scotland

Edinburgh

Seven Hills

Castle Rock
Calton Hill
Arthur's Seat
Blackford Hill
Braid Hills
Corstorphine Hill
Craiglockhart Hills

Midlothian

Pentland Hills

East Lothian

Core Paths Map links

Map	Area
Map A	Gullane, Aberlady and surrounding area
Map B	North Berwick and surrounding area
Map C	Whitekirk and surrounding area
Map D	Musselburgh North
Map E	Prestonpans, Port Seton, Tranent North
Map F	Longniddry and Haddington West
Map G	Haddington East and surrounding area
Map H	East Linton, Stenton and surrounding area
Map J	Dunbar and surrounding area
Map K	Innerwick and surrounding area
Map L	Musselburgh South and Whitecraig
Map M	Tranent South, Macmerry, Ormiston
Map N	Pencaitland and East Saltoun
Map O	Gifford and surrounding area
Map P	Garvald and surrounding area
Map Q	East Lammermuir Hills
Map R	Oldhamstocks and surrounding area
Map S	Glenkinchie and South West area
Map T	Humbie and surrounding area
Map U	Western Lammermuir Hills
Map V	Central Lammermuir Hills
Map W	Whiteadder and South East Lammermuir Hills

Aviemore

https://www.cairngormmountain.co.uk/

Rothiemurchus

https://rothiemurchus.net/outdoor-activities-at-aviemore/

Loch-an-Eilein: https://rothiemurchus.net/visit/loch-an-eilein/

Laggan Wolftrax

Insh Marshes Nature Reserve

North Ayrshire

Arran

Aberdeenshire

Tarland Trails

tmux Training Manual: Ghostty, xterm and PVE LXC Terminals

2026-02-27T12:00:00+00:00

tmux is a terminal multiplexer: it lets you run multiple terminal sessions inside a single window, split panes side by side, and crucially, keep sessions alive after you disconnect. For headless Proxmox VE (PVE) LXC containers accessed over SSH, this is essential. If your SSH connection drops mid-task, tmux keeps the job running and lets you reattach exactly where you left off. This manual walks through tmux in practical exercises, covering Ghostty on macOS, xterm, and terminal sessions inside PVE LXC containers.

Getting Back to a Known State

This section comes first because it is the most important concept to internalise. Just as pressing Escape repeatedly in vim returns you to a safe state, tmux has equivalent recovery paths. Learn these before anything else.

The Prefix Key

Every tmux command starts with the prefix key, which is Ctrl+b by default. You press Ctrl+b, release both keys, then press the command key. Nothing happens if you just hold Ctrl+b without following up.

If you press Ctrl+b and then the wrong key, tmux usually just ignores it. You are not stuck.

Exiting Any Mode

Situation	How to exit
Stuck in copy mode	Press `q` or `Escape`
Stuck in command mode (`:` prompt)	Press `Escape` or `Ctrl+c`
Pane running something	Press `Ctrl+c` to interrupt it
Everything looks wrong	Detach with `Ctrl+b d` and reattach fresh

Emergency Exit Sequences

Detach from session (session keeps running):

Ctrl+b d

List all sessions from outside tmux:

tmux ls

Reattach to a named session:

tmux attach -t <session-name>

Reattach to the most recent session:

tmux attach

Kill a specific pane (with confirmation prompt):

Ctrl+b x

Kill a specific window (with confirmation prompt):

Ctrl+b &

Kill a session entirely from the command line:

tmux kill-session -t <session-name>

Kill all tmux sessions:

tmux kill-server

The pattern to remember: Ctrl+b d detaches safely, tmux ls shows what is running, and tmux attach -t <name> gets you back. These three commands will rescue you from almost any situation.

Installation

Debian and Ubuntu LXC Containers

sudo apt update
sudo apt install tmux

macOS (Ghostty Host)

brew install tmux

Verify Installation

tmux -V

Expected output: tmux 3.x (version 3.3a or later is common as of 2026).

Terminal Compatibility Notes

Ghostty

Ghostty works excellently with tmux. It supports true colour, full mouse reporting, and passes modifier keys correctly. No special configuration is needed.

If colours look wrong inside tmux running in Ghostty, set this in your shell profile:

export TERM=xterm-256color

Or add this to ~/.tmux.conf to force 256 colour mode:

set -g default-terminal "screen-256color"

xterm

xterm is a reliable fallback. It handles tmux correctly but defaults to a limited colour palette. Set the terminal type explicitly if you see rendering artefacts:

TERM=xterm-256color tmux

Or add to your shell profile permanently:

export TERM=xterm-256color

PVE LXC Console: noVNC vs SSH

PVE's web console (noVNC) can cause key capture problems with tmux. The Ctrl+b prefix may not pass through correctly because the browser intercepts some key combinations. In practice, Ctrl+b often works, but scrolling, mouse support, and certain modifier combinations behave inconsistently.

Recommendation: always use SSH into the LXC for tmux work.

ssh user@<lxc-ip>

SSH gives you a proper PTY, correct terminal type negotiation, and reliable key forwarding. noVNC is fine for quick root access or emergency recovery, but not for regular tmux sessions.

If you must use the PVE noVNC console with tmux, set a longer escape time to reduce timeout frustration:

set -sg escape-time 50

Exercise 1: First Session

This exercise covers starting, using, detaching, and reattaching to a named session.

Start a Named Session

tmux new -s training

You are now inside a tmux session called training. The green (or coloured) bar at the bottom is the status bar.

Reading the Status Bar

The status bar shows:

Left side: session name in brackets, e.g. [training], followed by window index and name, e.g. 0:bash
Right side: hostname and time (depending on your config)
An asterisk * next to the current window name

Run a Command

top

Watch it run. Now detach without killing it.

Detach from the Session

Ctrl+b d

You are back at your normal shell prompt. The top command is still running inside tmux.

Verify the Session is Still Running

tmux ls

Output:

training: 1 windows (created Thu Feb 27 12:00:00 2026)

Reattach to the Session

tmux attach -t training

You are back inside the session. top is still running. Press q to quit top.

Recovery Notes for Exercise 1

If you lose track of session names, tmux ls always shows what is running. If tmux ls shows nothing, there are no sessions and you start fresh with tmux new -s <name>.

Exercise 2: Windows

Windows in tmux are like browser tabs. Each window fills the full terminal area and can run a different program.

Create a New Window

Ctrl+b c

A new window appears. The status bar now shows two windows: 0:bash and 1:bash.

Name the Current Window

Ctrl+b ,

A rename prompt appears at the bottom. Type a name, for example logs, then press Enter.

Switch Between Windows

Switch to window by number:

Ctrl+b 0
Ctrl+b 1

Switch to next window:

Ctrl+b n

Switch to previous window:

Ctrl+b p

List All Windows (Known State Check)

Ctrl+b w

An interactive list of all windows appears. Use arrow keys to navigate and Enter to select. Press Escape to cancel without switching. This gives you a clear view of what is open.

Close a Window

The cleanest way is to exit the shell:

exit

Or force close the current window (with confirmation):

Ctrl+b &

Type y to confirm. If you have multiple windows, tmux moves you to the next one. If it was the last window, the session ends.

Recovery Notes for Exercise 2

If you are confused about which window you are in, Ctrl+b w shows the full list. If a window is running something stuck, Ctrl+b & closes it after confirmation.

Exercise 3: Panes

Panes split a single window into multiple terminal areas visible at the same time.

Split Horizontally (Left and Right)

Ctrl+b %

The window is now split into two vertical columns (left pane and right pane).

Split Vertically (Top and Bottom)

Ctrl+b "

The current pane is split into two horizontal rows.

Navigate Between Panes

Use the prefix followed by an arrow key:

Ctrl+b <arrow key>

For example, Ctrl+b then the right arrow moves focus to the right pane.

Show Pane Numbers (Known State Check)

Ctrl+b q

Large numbers appear briefly over each pane. Press the number while it is visible to jump to that pane directly.

Resize a Pane

Hold the prefix and then repeatedly press arrow keys. In most terminals:

Ctrl+b :resize-pane -D 5

This resizes the current pane down by 5 rows. Directions: -U (up), -D (down), -L (left), -R (right).

Alternatively, if mouse mode is enabled (covered in the config section), you can drag pane borders.

Zoom a Pane to Full Screen

Ctrl+b z

The current pane expands to fill the entire window. Press Ctrl+b z again to return to the split layout. The status bar shows [Z] when a pane is zoomed.

Close a Pane

The cleanest way:

exit

Or force close with confirmation:

Ctrl+b x

Type y to confirm. If it is the last pane in the window, the window closes too.

Recovery Notes for Exercise 3

Ctrl+b q shows pane numbers so you can see where you are. Ctrl+b z is useful if you accidentally zoomed and the layout looks wrong: toggle it again to return to the split view.

Exercise 4: Copy Mode (and How to Exit It)

Copy mode lets you scroll back through terminal output and copy text. Knowing how to exit it reliably is as important as knowing how to enter it.

Enter Copy Mode

Ctrl+b [

The status bar shows [Copy] in the top right corner. You are now in copy mode.

Navigate in Copy Mode

Key	Action
Arrow keys	Move cursor one line/column
`PgUp` / `PgDn`	Scroll up or down a page
`g`	Go to the top of the scrollback buffer
`G`	Go to the bottom (current output)
`/`	Search forward
`?`	Search backward
`n`	Next search match
`N`	Previous search match

Exit Copy Mode

Press q or Escape.

This is the key thing to remember. If you are in copy mode and the terminal seems unresponsive to normal commands, you are still in copy mode. Press q or Escape to return to normal mode.

Copy Text

Enter copy mode: Ctrl+b [
Navigate to the start of the text you want
Press Space to begin selection
Move to the end of the text
Press Enter to copy and exit copy mode

Paste Copied Text

Ctrl+b ]

This pastes the tmux clipboard into the current pane at the cursor position.

Recovery Notes for Exercise 4

If your keyboard input is being swallowed and commands are not running, the most likely cause is that you are in copy mode. Press q first, then Escape if q did not work.

Exercise 5: PVE LXC Workflow

This exercise demonstrates the core use case for tmux in a Proxmox VE environment: running long tasks in an LXC container and safely reconnecting after a disconnect.

Step 1: SSH into the LXC Container

From your workstation (Ghostty or any terminal):

ssh user@<lxc-ip>

Replace <lxc-ip> with the IP address of your LXC container. You can find this in the PVE web interface under the container's Network tab, or by running ip a inside the container.

Step 2: Start a Persistent Session

tmux new -s work

Step 3: Run a Long Job

sudo apt upgrade

This may take several minutes. Let it run.

Step 4: Detach and Close SSH

Ctrl+b d

You are back at the container's shell prompt (outside tmux). Now close the SSH connection entirely:

exit

Or close the terminal window. The apt upgrade is still running inside the tmux session on the LXC container.

Step 5: Reconnect and Reattach

Open a new terminal and SSH back in:

ssh user@<lxc-ip>

List running sessions:

tmux ls

Output:

work: 1 windows (created Thu Feb 27 12:05:00 2026)

Reattach:

tmux attach -t work

You are back watching apt upgrade complete, exactly as you left it.

Why tmux Beats GNU Screen for LXC Work

Both tmux and screen provide session persistence, but tmux has clearer defaults, better pane support, and easier scripting. The tmux ls command gives a clean session overview. Pane splitting is built in without workarounds. Configuration via ~/.tmux.conf is straightforward. For new setups, start with tmux.

Quick Reference Table

Action	Key or Command	Notes
New named session	`tmux new -s <name>`	Run from shell
List sessions	`tmux ls`	Run from shell
Attach to session	`tmux attach -t <name>`	Run from shell
Detach from session	`Ctrl+b d`	Session keeps running
New window	`Ctrl+b c`
Rename window	`Ctrl+b ,`
Switch to window N	`Ctrl+b <N>`	0-9
Next window	`Ctrl+b n`
Previous window	`Ctrl+b p`
List windows	`Ctrl+b w`	Interactive picker
Close window	`Ctrl+b &`	Confirmation required
Split pane left/right	`Ctrl+b %`
Split pane top/bottom	`Ctrl+b "`
Navigate panes	`Ctrl+b <arrow>`
Show pane numbers	`Ctrl+b q`
Zoom pane toggle	`Ctrl+b z`	Status bar shows [Z]
Close pane	`Ctrl+b x`	Confirmation required
Enter copy mode	`Ctrl+b [`
Exit copy mode	`q` or `Escape`
Start selection	`Space`	While in copy mode
Copy selection	`Enter`	While in copy mode
Paste	`Ctrl+b ]`
Reload config	`Ctrl+b :source-file ~/.tmux.conf`
Kill session	`tmux kill-session -t <name>`	Run from shell

Config Tweaks

tmux reads ~/.tmux.conf on startup. Create or edit this file to customise behaviour. Changes take effect in new sessions, or you can reload without restarting.

Location

~/.tmux.conf

Change the Prefix Key to Ctrl+a

Many users prefer Ctrl+a because it is easier to reach and was the screen default:

unbind C-b
set -g prefix C-a
bind C-a send-prefix

After this, all commands use Ctrl+a instead of Ctrl+b. The bind C-a send-prefix line lets you type a literal Ctrl+a in programs like bash by pressing the prefix twice.

Enable Mouse Support

set -g mouse on

With mouse enabled, you can click to select panes, drag borders to resize, and scroll with the mouse wheel. Scroll wheel enters copy mode automatically. To exit copy mode after scrolling, press q.

Increase Scrollback Buffer

The default scrollback is 2000 lines, which fills up quickly. Increase it:

set -g history-limit 10000

Reduce Escape Time (Useful for PVE noVNC)

set -sg escape-time 50

This reduces the delay tmux waits after pressing Escape before deciding it is not a prefix sequence. Lower values make Escape feel more responsive in vim and other tools inside tmux.

Start Window and Pane Index at 1

By default windows are numbered from 0. Starting at 1 maps better to the number keys:

set -g base-index 1
setw -g pane-base-index 1

Reload Config Without Restarting

After editing ~/.tmux.conf, reload it inside a running tmux session:

Ctrl+b :source-file ~/.tmux.conf

Or add a keybinding for this in ~/.tmux.conf:

bind r source-file ~/.tmux.conf \; display-message "Config reloaded"

Then use Ctrl+b r (or Ctrl+a r if you changed the prefix) to reload.

Minimal Recommended Config

# Change prefix to Ctrl+a
unbind C-b
set -g prefix C-a
bind C-a send-prefix

# Enable mouse
set -g mouse on

# Increase scrollback
set -g history-limit 10000

# Reduce escape time
set -sg escape-time 50

# Start numbering from 1
set -g base-index 1
setw -g pane-base-index 1

# Reload config
bind r source-file ~/.tmux.conf \; display-message "Config reloaded"

Known State Cheatsheet

Bookmark this section. When something goes wrong, work through it from top to bottom.

1. Exit any mode:

In copy mode: press q, then Escape if needed
In command mode: press Escape
Program stuck: press Ctrl+c

2. Check what windows and panes are open:

Ctrl+b w    (list windows)
Ctrl+b q    (show pane numbers)

3. Detach safely (session keeps running):

Ctrl+b d

4. From the shell, list all sessions:

tmux ls

5. Reattach to a session:

tmux attach -t <name>
tmux attach          # most recent session

6. Kill a stuck pane:

Ctrl+b x    (confirmation prompt, then y)

7. Kill a stuck window:

Ctrl+b &    (confirmation prompt, then y)

8. Kill a session entirely:

tmux kill-session -t <name>

9. Nuclear option: kill all tmux sessions:

tmux kill-server

10. Start fresh:

tmux new -s main

Following this list top to bottom will resolve the vast majority of situations where tmux feels stuck or confusing. The core principle: Ctrl+b d gets you out, tmux ls shows what is there, and tmux attach gets you back in.

Installing Homebrew on a Debian 13 (Trixie) LXC Container

2026-02-25T00:00:00+00:00

This tutorial documents a working, verified installation of Homebrew (Linuxbrew) on a Debian 13 "trixie" LXC container. Every step reflects what was actually done on this system; nothing has been invented or copied from generic guides without verification.

Tested environment: - Debian GNU/Linux 13 (trixie), amd64 - LXC unprivileged container - Homebrew 5.0.15 - Primary non-root user: morgan (uid=1000)

Prerequisites
Installation Steps
Per-User Shell Setup
Verification
Adding Future Users
Troubleshooting

1. Prerequisites

System packages

The Homebrew installer requires these packages. Install them as root before running the installer:

apt-get update
apt-get install -y build-essential git curl file procps

Verify all five are present:

ii  build-essential 12.12              amd64  Informational list of build-essential packages
ii  curl            8.14.1-2+deb13u2   amd64  command line tool for transferring data with URL syntax
ii  file            1:5.46-5           amd64  Recognize the type of data in a file using "magic" numbers
ii  git             1:2.47.3-0+deb13u1 amd64  fast, scalable, distributed revision control system
ii  procps          2:4.0.4-9          amd64  /proc file system utilities

PATH gotcha: /usr/sbin must be in root's PATH

On Debian 13, /usr/sbin is not automatically in the PATH of non-login shells (including those invoked by su without -l). The installer calls useradd, which lives at /usr/sbin/useradd. If /usr/sbin is missing from your PATH the installer will fail with a confusing "command not found" error.

Before running the installer, confirm your PATH includes /usr/sbin:

echo $PATH

If it does not, prepend it for the session:

export PATH="/usr/sbin:$PATH"

Or simply run the installer from a full login shell (su - rather than su).

2. Installation Steps

All steps in this section are run as root.

Step 1 — Create the dedicated `linuxbrew` group

Homebrew on Linux uses a shared group so that multiple users can write to the installation prefix. Create it before the installer runs so you control its GID:

groupadd linuxbrew

Step 2 — Pre-create the Homebrew prefix directory

The Homebrew installer expects to own /home/linuxbrew/.linuxbrew. In an LXC container the installer sometimes cannot create /home/linuxbrew itself due to ownership constraints on /home. Pre-create it and set the correct ownership before running the installer:

mkdir -p /home/linuxbrew/.linuxbrew
chown -R morgan:linuxbrew /home/linuxbrew
chmod 2775 /home/linuxbrew
chmod 2775 /home/linuxbrew/.linuxbrew

The 2775 mode sets the setgid bit (s) on the directory. This causes all files and subdirectories created inside to inherit the linuxbrew group automatically, which is what allows multiple users to install and update packages.

After this step, ls -la /home/linuxbrew/ should show:

drwxrwxr-x  3 morgan linuxbrew 4096 Feb 25 15:31 .
drwxr-xr-x  4 root   root      4096 Feb 25 15:31 ..
drwxrwsr-x 14 morgan linuxbrew 4096 Feb 25 15:31 .linuxbrew

And stat /home/linuxbrew/.linuxbrew confirms the setgid bit:

Access: (2775/drwxrwsr-x)  Uid: ( 1000/  morgan)   Gid: ( 1001/linuxbrew)

Step 3 — Add the primary user to the linuxbrew group

usermod -aG linuxbrew morgan

The -a flag is critical — without it usermod -G replaces all supplementary groups instead of appending to them.

Step 4 — Run the Homebrew installer as the primary user

Switch to the non-root user and run the official installer. Do not run it as root:

su - morgan
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Because the prefix directory already exists and is writable by the linuxbrew group (and morgan is a member), the installer will populate it without needing to create it or change system-level ownership.

Step 5 — Create the system-wide profile.d script

To activate Homebrew automatically for every user who logs in, create a shell script in /etc/profile.d/ as root:

cat > /etc/profile.d/homebrew.sh << 'EOF'
#!/bin/bash
if [ -d "/home/linuxbrew/.linuxbrew" ]; then
    eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
fi
EOF
chmod +x /etc/profile.d/homebrew.sh

This is exactly the file present on this system:

# /etc/profile.d/homebrew.sh
#!/bin/bash
if [ -d "/home/linuxbrew/.linuxbrew" ]; then
    eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
fi

The if guard makes the script safe on systems where the prefix does not exist (e.g., before installation, or if the directory is removed).

3. Per-User Shell Setup

The /etc/profile.d/homebrew.sh script runs automatically for login shells. This covers su - username, SSH logins, and console logins.

For interactive non-login shells (e.g., a new terminal tab that sources ~/.bashrc instead of ~/.bash_profile), a user may need to add the following to their ~/.bashrc:

# Homebrew (Linuxbrew)
if [ -d "/home/linuxbrew/.linuxbrew" ]; then
    eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
fi

brew shellenv sets these environment variables:

Variable	Value
`HOMEBREW_PREFIX`	`/home/linuxbrew/.linuxbrew`
`HOMEBREW_CELLAR`	`/home/linuxbrew/.linuxbrew/Cellar`
`HOMEBREW_REPOSITORY`	`/home/linuxbrew/.linuxbrew/Homebrew`
`PATH`	prepends `/home/linuxbrew/.linuxbrew/bin` and `.../sbin`
`MANPATH`	prepends `.../share/man`
`INFOPATH`	prepends `.../share/info`

4. Verification

Confirm the installation prefix layout

ls -la /home/linuxbrew/.linuxbrew/

Expected output (all entries owned by morgan:linuxbrew, setgid s visible):

total 56
drwxrwsr-x 14 morgan linuxbrew 4096 Feb 25 15:31 .
drwxrwxr-x  3 morgan linuxbrew 4096 Feb 25 15:31 ..
drwxrwsr-x  2 morgan linuxbrew 4096 Feb 25 15:31 Caskroom
drwxrwsr-x  2 morgan linuxbrew 4096 Feb 25 15:31 Cellar
drwxrwsr-x  2 morgan linuxbrew 4096 Feb 25 15:31 Frameworks
drwxrwsr-x 15 morgan linuxbrew 4096 Feb 25 15:31 Homebrew
drwxrwsr-x  2 morgan linuxbrew 4096 Feb 25 15:31 bin
drwxrwsr-x  3 morgan linuxbrew 4096 Feb 25 15:32 etc
drwxrwsr-x  2 morgan linuxbrew 4096 Feb 25 15:31 include
drwxrwsr-x  2 morgan linuxbrew 4096 Feb 25 15:31 lib
drwxrwsr-x  2 morgan linuxbrew 4096 Feb 25 15:31 opt
drwxrwsr-x  2 morgan linuxbrew 4096 Feb 25 15:31 sbin
drwxrwsr-x  6 morgan linuxbrew 4096 Feb 25 15:32 share
drwxrwsr-x  3 morgan linuxbrew 4096 Feb 25 15:31 var

Check the Homebrew version

su - morgan -c 'brew --version'

Homebrew 5.0.15

Run brew doctor

su - morgan -c 'brew doctor'

Your system is ready to brew.

Confirm group membership

getent group linuxbrew
# linuxbrew:x:1001:morgan

id morgan
# uid=1000(morgan) gid=1000(morgan) groups=1000(morgan),100(users),1001(linuxbrew)

Test installing a package (dry run)

su - morgan -c 'brew install --dry-run hello'

==> Would install 1 formula:
hello

5. Adding Future Users

When a new user needs Homebrew access:

# As root — add the new user to the linuxbrew group
usermod -aG linuxbrew newuser

The user must log out and back in (or start a new login shell) for the group change to take effect. The /etc/profile.d/homebrew.sh script will activate brew for them automatically on their next login. No other changes are needed.

To verify the new user can reach Homebrew:

su - newuser -c 'brew --version'

6. Troubleshooting

`brew: command not found` in a non-login shell

The /etc/profile.d/homebrew.sh script only runs in login shells. In a non-login shell (typical terminal emulators, su username without the -), Homebrew will not be on the PATH.

Fix: source the script manually, or add the eval line to ~/.bashrc as shown in Section 3.

Quick test — if this works but brew does not:

/home/linuxbrew/.linuxbrew/bin/brew --version

then the issue is purely PATH/environment, not the installation.

`useradd: command not found` during installation

useradd lives at /usr/sbin/useradd. On Debian 13, /usr/sbin is not in the PATH of non-login root shells. Run the installer from a full login shell:

su -        # note the hyphen — this gives a login shell with /usr/sbin in PATH

Or prepend it explicitly before running the installer:

export PATH="/usr/sbin:$PATH"

Installer fails to create `/home/linuxbrew`

In LXC containers, the installer may not be able to create the prefix directory itself because /home is owned by root:root with mode 755. The installer does not have write access to /home when running as a non-root user.

Solution: pre-create the directory as root before running the installer (see Step 2).

Permission denied errors when running `brew install`

The user must be in the linuxbrew group and must have started a new session after being added. Check:

id          # linuxbrew should appear in the groups list

If linuxbrew is absent, either the usermod -aG linuxbrew username step was skipped, or the user has not logged out and back in since being added.

`brew doctor` reports warnings about `/usr/local`

On Linux, Homebrew uses /home/linuxbrew/.linuxbrew as its prefix, not /usr/local. Warnings about /usr/local being absent or not owned by the current user are normal and harmless on a Linux installation.

Quick-Reference: Full Root-Side Install Sequence

# 1. Install dependencies
apt-get update && apt-get install -y build-essential git curl file procps

# 2. Ensure /usr/sbin is in PATH (run as login shell or set manually)
export PATH="/usr/sbin:$PATH"

# 3. Create the linuxbrew group
groupadd linuxbrew

# 4. Pre-create the prefix and set ownership/permissions
mkdir -p /home/linuxbrew/.linuxbrew
chown -R morgan:linuxbrew /home/linuxbrew
chmod 2775 /home/linuxbrew
chmod 2775 /home/linuxbrew/.linuxbrew

# 5. Add the primary user to the group
usermod -aG linuxbrew morgan

# 6. Run the installer as the non-root user
su - morgan -c '/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"'

# 7. Install the system-wide profile.d activation script
cat > /etc/profile.d/homebrew.sh << 'EOF'
#!/bin/bash
if [ -d "/home/linuxbrew/.linuxbrew" ]; then
    eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
fi
EOF
chmod +x /etc/profile.d/homebrew.sh

# 8. Verify
su - morgan -c 'brew --version && brew doctor'

FSM Diagrams in Pelican and Claude Code

2026-02-22T18:00:00+00:00

Finite state machines turn up everywhere: protocol implementations, hardware controllers, UI flows, parsers. Drawing them well is useful but tedious. This post covers two tools I've built: a Pelican plugin that renders FSM diagrams at build time so they appear as images in published posts, and a Claude Code skill that generates diagrams from plain-English descriptions.

The pattern is identical to the WaveDrom plugin and skill: describe what you want, get a fenced code block, paste it into a post, and the build renders it to SVG automatically.

The Pelican plugin

The plugin is at github.com/morganp/pelican-fsm, cloned to ~/Code/pelican-fsm (a sibling directory to the blog repo). It intercepts fenced ```mermaid ``` and ```dot ``` code blocks before Pelican's standard Markdown processing, renders each one to an SVG using the appropriate CLI tool, caches the result by content hash in content/images/fsm/, and replaces the block with a standard image reference. Pelican then copies the SVG to output/images/fsm/ as a static asset.

SVGs are cached across builds, so only diagrams whose source has changed are re-rendered.

Requirements

Mermaid CLI for mermaid blocks:

npm install -g @mermaid-js/mermaid-cli

Graphviz for dot blocks:

brew install graphviz      # macOS
sudo apt install graphviz  # Debian/Ubuntu

Both tools are optional. If one is missing, blocks for that type fall back gracefully to a fenced text block without failing the build.

Installation

Clone the plugin alongside your Pelican project and install it into the Pelican virtualenv in editable mode:

git clone https://github.com/morganp/pelican-fsm ../pelican-fsm
source venv/bin/activate
pip install -e ../pelican-fsm --config-settings editable_mode=compat

The editable_mode=compat flag is required. Without it, modern setuptools editable installs use a path-hook mechanism that prevents Pelican's namespace plugin auto-discovery from finding the plugin.

Pelican 4.5+ auto-discovers namespace plugins, so no changes to pelicanconf.py are needed.

Optional config

If mmdc or dot are not on your PATH during the build, set their full paths in pelicanconf.py:

FSM_MERMAID_CLI = '/opt/homebrew/bin/mmdc'
FSM_DOT_CLI = '/opt/homebrew/bin/dot'

Using it in a post

Write a fenced code block with the language set to mermaid or dot:

```mermaid
stateDiagram-v2
    [*] --> Idle
    Idle --> Running : start
    Running --> Idle : stop
    Running --> Error : fault
    Error --> Idle : reset
```

At build time this becomes an SVG embedded in the page:

Graphviz DOT works the same way, and is a better fit for hardware and RTL documentation where the compact box-and-arrow style is conventional:

If the CLI is not found or rendering fails, the block falls back to fenced text — the post still builds, you just see the raw source instead of a diagram.

The Claude Code skill

The skill lives at github.com/morganp/dotfiles/tree/main/config/claude/skills/fsm. Claude Code auto-discovers skills from ~/.claude/skills/ and loads them on demand.

The skill triggers automatically when you describe anything involving states, transitions, or control flow: protocol implementations, UI flows, hardware FSMs, parsers, game logic. You describe the system in plain English and Claude generates the diagram.

The skill knows:

Full Mermaid stateDiagram-v2 syntax: plain states, display labels, transitions with events/guards/actions, composite (nested) states, choice pseudostates, fork/join for parallel regions, concurrent regions (--), notes, direction, and classDef styling
Graphviz DOT FSM conventions: Moore vs Mealy annotation, initial pseudostate arrow, accepting states as double circles
When to prefer each format: Mermaid for software/web docs, DOT for hardware/RTL

Example workflow

Describe the system:

"Draw the states for a TCP connection"

Claude produces:

Because the skill outputs a mermaid fenced block, you can paste it directly into a blog post and the Pelican plugin renders it automatically.

Installing the skill

mkdir -p ~/.claude/skills/fsm
curl -o ~/.claude/skills/fsm/SKILL.md \
  https://raw.githubusercontent.com/morganp/dotfiles/main/config/claude/skills/fsm/SKILL.md

Or clone the dotfiles repo and symlink:

git clone https://github.com/morganp/dotfiles ~/dotfiles
ln -s ~/dotfiles/config/claude/skills/fsm ~/.claude/skills/fsm

Syntax quick reference

Both formats can express the same FSM concepts, but use different syntax. The table below maps them side by side.

Concept	Mermaid `stateDiagram-v2`	Graphviz DOT
Graph declaration	`stateDiagram-v2`	`digraph FSM { ... }`
Default node style	automatic	`node [shape=circle]`
Left-to-right layout	`direction LR`	`rankdir=LR`
Comment	`%% comment`	`// comment`
Plain state	`StateName`	`StateName`
State with display label	`state "Label" as Name`	`Name [label="Label"]`
Initial pseudostate	`[*] --> State`	`__start [shape=point width=0.2]` + `__start -> State`
Final/accepting state	`State --> [*]`	`State [shape=doublecircle]`
Transition	`A --> B`	`A -> B`
Transition with event	`A --> B : event`	`A -> B [label="event"]`
Transition with action	`A --> B : event / action()`	`A -> B [label="event / action()"]`
Guarded transition	`A --> B : [guard]`	`A -> B [label="[guard]"]`
Composite (nested) state	`state S { ... }`	`subgraph cluster_S { ... }`
Choice pseudostate	`state C <<choice>>`	`C [shape=diamond]`
Fork pseudostate	`state F <<fork>>`	invisible node + multiple outgoing edges
Join pseudostate	`state J <<join>>`	invisible node + multiple incoming edges
Concurrent regions	`--` inside composite	parallel `subgraph` blocks

Project structure

~/Code/
├── morganp.github.io/              # blog source (main branch)
│   └── content/images/fsm/         # SVG cache (persists across make clean)
└── pelican-fsm/                    # github.com/morganp/pelican-fsm
    └── pelican/plugins/fsm_renderer/
        ├── __init__.py             # plugin entry point, signal registration
        └── preprocessor.py        # Markdown extension + preprocessor

~/.claude/skills/
└── fsm/
    └── SKILL.md                    # Claude Code skill definition

The combination is useful for any documentation that involves control flow: describe the behaviour, get the diagram from Claude, drop it into a post, and the plugin renders it at build time. No manual editing of diagram syntax, no copy-pasting between browser tabs.

Verilog Lint Skill for Claude Code

2026-02-22T12:00:00+00:00

I've been using Claude Code for RTL generation lately, and the missing piece was a tight feedback loop between code generation and linting. Writing Verilog by hand is tedious; having Claude generate it and immediately validate it with real tools closes that gap nicely.

What it does

The skill connects two open-source linters into an agentic write → lint → fix → re-lint loop:

Verilator (--lint-only -Wall) catches semantic errors: undeclared signals, bit-width mismatches, blocking assignments in always_ff blocks, multi-driven nets
Verible (verible-verilog-lint) enforces style: naming conventions, whitespace, port alignment, always_ff/always_comb discipline

When Claude generates RTL, the skill automatically:

Writes the code to a temp file
Runs both linters
Parses error messages with line numbers
Applies fixes and re-lints — up to 3 times
Reports clean status or surfaces a diagnostic table if errors remain

Why two tools

They complement each other. Verilator thinks like a synthesizer — it catches things that will fail elaboration or produce incorrect silicon. Verible doesn't simulate; it reads the source and checks against Google's SystemVerilog style guide. Together they cover both "will this work" and "is this readable".

Both are free and open source

Verilator: brew install verilator / apt install verilator
Verible: brew tap chipsalliance/verible && brew install verible (macOS), or grab a binary from the GitHub releases page

RTL patterns baked in

The skill includes reference patterns for mistake-free SystemVerilog: synchronous-reset flip-flops, always_comb combinational blocks, parameterized FSMs with typedef enum. Claude defaults to these when generating new modules, which avoids most of the common lint warnings before the first pass even runs.

Same pattern as WaveDrom

This follows the same skill format as the WaveDrom timing diagram skill — a SKILL.md file that gives Claude structured instructions, reference tables, and workflow steps. Both skills live in ~/.claude/skills/ and are picked up automatically by Claude Code.

The combination is handy for hardware work: describe a protocol, get a timing diagram, then generate and lint the RTL that implements it.

WaveDrom Timing Diagrams in Pelican with Claude Code

2026-02-20T12:00:00+00:00

WaveDrom is a JavaScript library that renders digital timing diagrams from a simple JSON-based format called WaveJSON. It's widely used in hardware documentation — you describe signal transitions in a compact string notation, and WaveDrom draws the waveform. This post covers two tools I've built around it: a Pelican plugin that renders diagrams at build time, and a Claude Code skill that generates WaveJSON from plain English.

The Pelican plugin

The plugin is at github.com/morganp/pelican-wavedrom, cloned to ~/Code/pelican-wavedrom — a sibling directory to the blog repo. It intercepts fenced ```wavedrom ``` code blocks before Pelican's standard Markdown processing, renders each one to an SVG using wavedrom-cli, caches the result by content hash in content/images/wavedrom/, and replaces the block with a standard image reference. Pelican then copies the SVG to output/images/wavedrom/ as a static asset.

SVGs are cached across builds — only diagrams whose source has changed are re-rendered.

Installation

The plugin requires wavedrom-cli globally via npm:

npm install -g wavedrom-cli

Then clone the plugin alongside your blog repo and install it into the Pelican virtualenv in editable mode:

git clone https://github.com/morganp/pelican-wavedrom ../pelican-wavedrom
source venv/bin/activate
pip install -e ../pelican-wavedrom --config-settings editable_mode=compat

The editable_mode=compat flag is required. Without it, modern setuptools editable installs use a path-hook mechanism that prevents Pelican's namespace plugin auto-discovery from finding the plugin.

Pelican 4.5+ auto-discovers namespace plugins — no changes to pelicanconf.py are needed.

Optional config

If wavedrom-cli is not on your PATH during the build (e.g. in a CI environment), set its full path in pelicanconf.py:

WAVEDROM_CLI = '/opt/homebrew/bin/wavedrom-cli'

Using it in a post

Write a fenced code block with the language set to wavedrom:

```wavedrom
{ "signal": [
  { "name": "CLK",     "wave": "p.....|..." },
  { "name": "Data",    "wave": "x.345x|=.x", "data": ["head", "body", "tail", "data"] },
  { "name": "Request", "wave": "0.1..0|1.0" }
]}
```

At build time (make html or make github) this becomes an SVG embedded in the page:

If wavedrom-cli is not found or rendering fails, the block falls back to a fenced json block — the post still builds, you just see the raw JSON instead of a diagram.

The Claude Code skill

The skill lives at ~/.claude/skills/wavedrom/SKILL.md. Claude Code auto-discovers skills from ~/.claude/skills/ and loads them on demand.

The skill triggers automatically when you describe anything related to timing diagrams, waveforms, or digital protocols — SPI, I2C, UART, AXI handshakes, clock enables, request/acknowledge patterns. You describe the signals in plain English; Claude generates the WaveJSON.

The skill includes:

The full WaveJSON wave-character reference (p, n, 0, 1, x, z, ., =, 2–9, |)
Signal properties (phase, period, node)
Top-level properties (edge, config, head, foot)
Group and spacer syntax
Edge annotation syntax for timing arrows between signals
Common patterns: SPI transactions, request/acknowledge handshakes, clock-with-enable, grouped signals

Example workflow

Describe the protocol:

"Draw an I2C start condition followed by a 7-bit address byte with ACK"

Claude generates the WaveJSON and explains the timing. Because the skill outputs a wavedrom fenced block (not just JSON), you can paste it directly into a blog post and the Pelican plugin renders it automatically.

WaveJSON quick reference

The wave string for each signal is a sequence of characters:

Char	Meaning
`p` / `n`	Positive / negative clock (with tick mark)
`0` / `1`	Logic low / high
`x`	Unknown / undefined
`z`	High impedance
`.`	Continue previous state
`=`	Multi-bit data (label from `data` array)
`2`–`9`	Coloured data states
`\\|`	Gap / break in time axis

A minimal diagram:

An SPI transaction with chip select:

A request/acknowledge handshake with an edge annotation showing propagation delay:

Project structure

~/Code/
├── morganp.github.io/          # blog source (main branch)
│   └── content/images/wavedrom/  # SVG cache (persists across make clean)
└── pelican-wavedrom/           # github.com/morganp/pelican-wavedrom
    └── pelican/plugins/wavedrom_generator/
        ├── __init__.py         # plugin entry point, signal registration
        └── preprocessor.py    # Markdown extension + preprocessor

~/.claude/skills/
└── wavedrom/
    └── SKILL.md                # Claude Code skill definition

The combination is useful for hardware documentation: describe a protocol in English, get WaveJSON from Claude, drop the block into a post, and the plugin renders it at build time. No manual JSON editing, no copy-pasting between browser tabs.

The same skill format is used by the Verilog lint skill — describe a module, get generated RTL, and the lint loop validates it automatically.

Top Museums for Families

2025-12-05T15:06:00+00:00

Beamish

Life Science Centre

Eureka: Children’s Museum Eureka: Science Museum

Eden Camp

Dynamic Earth

Reduce Rack Drum Kit Size

2025-12-05T14:50:00+00:00

For the Yamaha DTX8 the cymbals mount on to the horizontal drum rack tubes. A more compact setup can be achieved if the cymbal mounts are onto of the vertical tubes. Some drum racks already have this setup, typically on the lower end as it requires less harder to be supplied. It seems like a great way to save space if trying to fit a drum kit into your home!  Gibraltar have this clamp, to convert other drum racks with (1.5”) 38.1mm tubing.

Expanding Yamaha DTX8 Drum Kit

2025-12-05T14:43:00+00:00

TOM

Parts Required for adding 4th Tom (second floor tom) to a Yamaha DTX8 kit.

Mounting bracket for rack: Yamaha TPCL500 Tom Holder. UK supplier.

10” tom, on the DTX8 they are all 10”: Yamaha XP125T M.   Note are the Mesh heads(M), not the (X) heads.  UK supplier.

eBay might also be a good source for used components.

Adding a Cymbal

Cable splitting tom1 for tom1 single zone and a single zone splash cymbal.

Yamaha PCY10010-inch cymbal pad
Yamaha CYAT500 Cymbal Attachment  Splash £180 UK Supplier.

Alternatively for another crash or simply larger 13” pad a Yamaha PCY135A pad could be used.

Crash £200 UK Supplier.

Yamaha Drum App

2025-12-05T14:38:00+00:00

For Yamaha electronic drum kits (DTX) there is a ‘DTX Touch app’ for iPhone, iPad, Android that lets you more easily manage the kit sounds.

Command Line Disk Usage

2025-09-06T13:19:00+01:00

NCurses Disk Usage

A useful Command Line Iterface (CLI) for exploring disk usage:

ncdu

Example output.

ncdu 2.9.1 ~ Use the arrow keys to navigate, press ? for help
--- ... github.io --------------------------
  115.6 MiB [##################] /venv
   59.7 MiB [#########         ] /output
   47.6 MiB [#######           ] /.git
   46.1 MiB [#######           ] /content
    8.0 KiB [                  ]  .DS_Store
    8.0 KiB [                  ]  tasks.py
    8.0 KiB [                  ] /__pycache__
    4.0 KiB [                  ]  Makefile
    4.0 KiB [                  ]  readme.md
    4.0 KiB [                  ]  pelicanconf.py
    4.0 KiB [                  ]  python_search_category.py
    4.0 KiB [                  ]  python_search_and_replace.py
    4.0 KiB [                  ]  create_new_post.py
    4.0 KiB [                  ]  publishconf.py
    4.0 KiB [                  ]  .gitignore
    4.0 KiB [                  ]  CNAME

If you are using MacOS then brew can be used to install:

brew install ncdu

Disk Usage

The disk usage tool du is a simpler non interactive way of listing file sizes.

du -h -d 1
  60M   ./output
  46M   ./content
 8.0K   ./__pycache__
 116M   ./venv
  48M   ./.git
 313M   .

The -h gives human readable output, ie sizes in k, M, G TBytes.
thr -d 1 on MacOS limits listing to 1 directory deep. -scan be used to summarise the requested directory.

Tree

Another alternative is to use tree to list folde contents with the -hoption to give human readable file sizes.

tree -L 1 -h
[ 608]  .
├── [ 128]  __pycache__
├── [  19]  CNAME
├── [ 224]  content
├── [1.2K]  create_new_post.py
├── [2.8K]  Makefile
├── [ 28K]  output
├── [2.1K]  pelicanconf.py
├── [ 528]  publishconf.py
├── [1.3K]  python_search_and_replace.py
├── [1.7K]  python_search_category.py
├── [2.2K]  readme.md
├── [4.1K]  tasks.py
├── [ 224]  venv
└── [ 224]  venv_old

MacOS install tree with brew:

brew install tree

Book: Mastering the command line

2025-05-31T10:11:00+01:00

Mastering the command line like a hacker by Xiaodong Xu

The book focuses on bash and zsh, which is great since I use both of those shells.

The useful sections from the book include:

Zsh Completion

# ~/.zshrc
autoload -U compinit
compinit -i

source ~/dotfiles/zsh-autosuggestions/zsh-autosuggestions.zsh

The zsh-autosuggestions.zsh needs to be installed/downloaded from Github, adding as a seperate depo or adding as a submodule to your dotfiles depo.

History

BASH History

# ~/.bashrc
# Save 5000 lins of history, with the same scroll back in the terminal
HISTFILESIZE=5000
HISTSIZE=5000

# Do not save duplicate commands, ignore commands starting with a space
HISTCONTROL='erasedups:ignorespace'

ZSH History

# ~/.zshrc 
# Save 5000 lins of history, with the same scroll back in the terminal
SAVEHIST=5000
HISTSIZE=5000

# Do not save duplicate commands, ignore commands starting with a space
setopt HIST_IGNORE_ALL_DUPS
setopt HIST_IGNORE_SPACE

Using History

View the last 5 commands

# Bash
$ history 5
# Zsh
$ history -5

For zsh we can see the last time the command was run and the time taken with :

history -i -D

Alternative command to history:

fc

Searching History

The most common way is piping history through grep to search.

$ history | grep 'cmd'

Ctrl+r is another option which starts a reverse search through the history.

Ctrl+p and Ctrl+n can be used to scroll forwards and backwards through previous commands. Although for me the up down cursors workk mor enaturally.

Repeating Commands

Repeat the last command used (Bang Bang)

!!

great example is when you run a command but it fails because of require Superuser access.

$ cmd_that_needs_root
> fail
$ sudo !!
> yay!

Execute command 2 back.

!-2
#Note
!! => !-1

Execute command 100 from history

!100

Last Argument

!$ recalls the last Argument. typicall usage could be with mkdir and cd:

$ mkdir notes
$ cd !$

Better Python Iterators

2025-03-01T12:24:00+00:00

Pyhton can convert most (all) lists/collections into iterator objects, this is done by calling iter() ie

num_list = [1, 2, 3] 
num_iter = iter(num_list)  # Returns Iterator

Python in the background is calling the objects __iter__() method.

A typical method for returning an Iterator is using a for loop to compile/create the elements. However the draw back to this is that the for loop can not begin executing until the full iterator is created.
This could make it the program look like it has stalled while it compiles long and or complex iterator objects.

Generator Functions

Generator function allow an optimisation that it allows the use of the iterator after each element has been created. Generator functions return elemnts using yield instead of return on the complete list. The a benefit of this approach is that the full iterator never has to be held in memory at the same time, allowing much larger data sets to be analysed.

Generator Example

def my_generator(n):

    # initialize counter
    value = 0

    # loop until counter is less than n
    while value < n:

        # produce the current value of the counter
        yield value

        # increment the counter
        value += 1

Non-Generator Example

def my_nongenerator(n):

    # initialize counter
    value = 0
    this_list = list()
    # loop until counter is less than n
    while value < n:

        # produce the current value of the counter
        this_list.append( value )

        # increment the counter
        value += 1
    return this_list

Packaging Python Projects

2025-02-28T15:22:00+00:00

How to package a pythin script or project for distribution. Offical Docs are [here][python_package]. Packaging for pip requires use of a [build backend][], [Hatchling][] is the default for this example.

This run through uses the testPyPI.

Summary

Initialise Python project area: note: the build process also uses the gitignore to excluded the venv folder.

mkdir packaging_tutorial
cd packagin_tutorial
python3 -m venv venv
source venv/bin/activate
curl --output .gitignore "https://raw.githubusercontent.com/github/gitignore/refs/heads/main/Python.gitignore"

Create the folder structure:

packaging_tutorial/
├── LICENSE
├── pyproject.toml
├── README.md
├── src/
│   └── example_package_YOUR_USERNAME_HERE/
│       ├── __init__.py
│       └── example.py
└── tests/

__init__.py can be empty, but allows project to be imported in standard way.

pyproject.toml - directs pip how to build the project

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[project]
name = "example_package_YOUR_USERNAME_HERE"
version = "0.0.1"
authors = [
  { name="Example Author", email="author@example.com" },
]
description = "A small example package"
readme = "README.md"
requires-python = ">=3.8"
classifiers = [
    "Programming Language :: Python :: 3",
    "Operating System :: OS Independent",
]
license = "MIT"
license-files = ["LICEN[CS]E*"]

[project.urls]
Homepage = "https://github.com/pypa/sampleproject"
Issues = "https://github.com/pypa/sampleproject/issues"


[python_package]: https://packaging.python.org/en/latest/tutorials/packaging-projects/
[build backend]: https://packaging.python.org/en/latest/glossary/#term-Build-Backend
[Hatchling]: https://hatch.pypa.io/latest/

Generate Distrubution Archive

Update build

pip install --upgrade build

Build:

python3 -m build

This should create

dist/
├── example_package_YOUR_USERNAME_HERE-0.0.1-py3-none-any.whl (Built Distribution)
└── example_package_YOUR_USERNAME_HERE-0.0.1.tar.gz (Source Distibution)

Upload!

Create and store API token. Create Token, set scope to entire account.

Update twine

pip install --upgrade twine

Upload the files in dist

python3 -m twine upload --repository testpypi dist/*

Once Complete the uploaded package can be viewed here:

https://test.pypi.org/project/example_package_YOUR_USERNAME_HERE.

Test install

python3 -m pip install --index-url https://test.pypi.org/simple/ --no-deps example-package-YOUR-USERNAME-HERE

Pelican New Post script

2025-01-03T16:44:00+00:00

In the aim of keeping the navigation of the Blog posts clean, I have limited my self to a few general categories, but remeberign them while editing in vim and not creating typos is a pain. Therefore I have added the category selection to my pyhton script for creating the new markdown files.

When running this file from the command line, top level of my pelican project, it first prompts for a category selection then requests The title of the post. The new file is created and correctly formated for a Pelican markdown post.

#!/usr/bin/python3
# coding=utf-8

# CLI for creating a new markdown post

import html

from datetime import datetime

# datetime object containing current date and time
now = datetime.now()

# dd/mm/YY H:M
dt_string = now.strftime("%Y-%m-%d %H:%M")
dt_string_simple = now.strftime("%Y-%m-%d")

# Create dictionary of categories, ask for user selection.
cat_dict = {1:"Cooking", 2:"Engineering", 3:"Home", 4:"Outdoor", 5:"Photography", 6:"Tech"}
print( cat_dict )
post_cat = input("Enter Post Category :")
post_cat = int(post_cat)

#Request title of blog post
post_title = input("Enter Post Title : ")

post_title = html.escape(post_title) # sanitize
post_title_safe = post_title.replace(' ', '_')

new_post_name = dt_string_simple + '_' + post_title_safe

this_file_name = "./content/posts/"+new_post_name+".md"

with open(this_file_name, "w") as file:
    file.write("Title: " + post_title + "\n")
    file.write("Date: %s \n" % dt_string)
    file.write("Category: %s\n" % cat_dict[post_cat])
    file.write("Tags: python\n")
    file.write("Author: morganp\n")
    file.write("Status: draft\n")
    file.write("<!--to publish change draft to published-->\n")

print(this_file_name)

Python Base Types

2025-01-02T18:09:00+00:00

Making notes as I work through Dr Chucks Python for Everyone course on Coursera.

There are 3 main types in Python:

Lists []
Dictionaries {}
Tuples ()

List

Lists are mutable, ie elements can be changed.
Creation of a list:

emptylist = []
thislist  = ["A","B","C"]
print( thislist )
  ['A', 'B', 'C']
print( thislist[1] )
  B

Dictionary

Dictionaries are key value pairs.
Creation of Dictionary

emptydict = {}
thisdict  = {0:"A", 1:"B", 2:"C"} 
print( thisdict )
  {0: 'A', 1: 'B', 2: 'C'}
print( thisdict[1] )
  B

Tuple

Tuples are unmodifiable lists. elements can not be changed or reordered.
Creation of Tuple.

emptytuple = () # This is of no real use as imutable
thistuple  = ("A", "B", "C")
print( thistuple )
  ('A', 'B', 'C')
print( thistuple[1] )
  B

Modify Pelican theme

2025-01-02T16:53:00+00:00

First figure out which theme you are using. List installed themes via:

% pelican-themes -l
simple
notmyidea

pelicanconf.py does not set a THEME, therfore defaulting to notmyidea.

The template locaions are (update your python version as appropriate):

cd venv/lib/python3.13/site-packages/pelican/themes/notmyidea/templates

At a minimum a theme must contain these files, which could be altered in your local copy of the theme.

└── templates
    ├── archives.html         // to display archives
    ├── period_archives.html  // to display time-period archives
    ├── article.html          // processed for each article
    ├── author.html           // processed for each author
    ├── authors.html          // must list all the authors
    ├── categories.html       // must list all the categories
    ├── category.html         // processed for each category
    ├── index.html            // the index (list all the articles)
    ├── page.html             // processed for each page
    ├── tag.html              // processed for each tag
    └── tags.html             // must list all the tags. Can be a tag cloud.

Pelican Site add Tags and Categories list

2025-01-02T15:39:00+00:00

I think it improves website usability when they are navigatable via the URL.

For example when viewing Posts under the caetegory 'Tech' ie https://lizard-spock.co.uk/category/tech.html,

removing the category and viewing https://lizard-spock.co.uk/category/ should list the possible categories.

The page is created by pelican but it is placed as :

https://lizard-spock.co.uk/categories.html

Not

https://lizard-spock.co.uk/category/index.html

To remedy this, modify your pelicanconf.py Adding in some page mappings.

## Adding template pages creating /tag/index.html from tags.html
TEMPLATE_PAGES = {'tags.html': 'tag/index.html'}

The Above takes the tags.html template and makes it available via example.com/tag

Japanese Garden 10 Years on

2025-01-02T13:02:00+00:00

An update to the Japanese Garden, aorund 10 years after it was built.
The ground cover is being removed in some of these images for the next iteration.

The large panorama is 270 degree view of 3 sides of it.

Various iterations of ground cover, last one was partially paved.

Older pictures during Construction

Then main structure nearly complete

Leveling up the roofs for the seating area. The large panorama is a 270 degree view of 3 sides of it.

Python Regular Expressions

2024-12-23T10:21:00+00:00

Python Regular Expressions Quick Guide:

^        Matches the beginning of a line
$        Matches the end of the line
.        Matches any character
\s       Matches whitespace
\S       Matches any non-whitespace character
*        Repeats a character zero or more times
*?       Repeats a character zero or more times 
         (non-greedy)
+        Repeats a character one or more times
+?       Repeats a character one or more times 
         (non-greedy)
[aeiou]  Matches a single character in the listed set
[^XYZ]   Matches a single character not in the listed set
[a-z0-9] The set of characters can include a range
(        Indicates where string extraction is to start
)        Indicates where string extraction is to end

Based on Dr Chucks from Python for Everyone course.

Usage:

import re

list_of_strings = re.findall(<pattern>, string)

Adaptive Filter Theory Notes 1

2024-12-19T11:04:00+00:00

Notes From Reading Adaptive Signal Theory (5th Ed) by Simon Haykin

Three Basic Kinds Of Estimation

Filtering - Extraction of Current and previous information. RealTime operation.
Smoothing - Data after the time of interest is used. Posteriori operation.
Prediction - forcasting for some time in the future. RealTime operation.

Filter optimization is useful to think of minimising the mean-square-error.

For stationary inputs the Wiener filter is considered optimal in mean-square-error sense.

Plots of the mean-square value of the error signal versus the adjustable parameters of the linear filter is known as the error-performance-surface. The min point on this is the Wiener solution.

Wiener Filter is no good with moving signals, or precense of noise. Kalman Filters are useful in this sitation.

Node Red vs Home Assistant

2024-10-24T15:58:00+01:00

Node Red vs Home Assistant

Which is better* ?

*better: CPU/RAM efficient, easier to learn and or offer better support of devices

Materials used for comparison video this review, end with the conclusion:

Home Assistant and Node-RED have their merits when it comes to automating your home. The choice ultimately depends on your preferences and specific requirements. While Home Assistant offers a user-friendly interface and integration within a single system, Node-RED provides versatility, the ability to connect to multiple Home Assistant instances and other APIs. Consider your needs, technical proficiency, and desired level of customization to determine which platform suits you best. Let us know your thoughts in the comments.

Proxmox Plex Container

2024-10-24T13:10:00+01:00

With Proxmox installed time to setup Plex in a container, and migrate from Synology NAS.

I am following these guides for plex setup, and there following guide for synology to proxmox migration.

Starting with ProxMox

2024-10-24T12:56:00+01:00

Having decided that Proxmox is the way forward to manage docker and ivrtualisation outside of the synology NAS. i need to figure out how to install , use and manage proxmox.

For the first instance I will be following the guide to Proxmox.

There is another good tutorial here which covers installing proxmox and then creating a virtual machine for home assistant.

Note from :

> You manage a Docker instance from the host, using the Docker Engine command-line interface. It is not recommended to run docker directly on your Proxmox VE host. If you want to run application containers, for example, Docker images, it is best to run them inside a Proxmox QEMU VM.

Beelink N200 Proxmox and Plex

2024-10-24T11:43:00+01:00

To improve the Plex transcoding options and off load the computation from the NAS, the plan is purchase a BeeLink EQ13 Alder Lake N200 16GB Ram and 500GB Drive, currently for sale at £215.

The Beelink will then have proxmox installed as the main operating system. A docker container for Plex and the other dockers that are currently hosted on the NAS box.

Theguide for plex install I will be following here.

A virtual machine for Hssistant OS can also be installed to run HomeAssistant.

Cat8 T-568

2024-10-21T13:31:00+01:00

Cat 8 Wiring, comes in 2 variants T-568A and T-568B.

Cat8 replaces the need for crimping tools with field termination kits. Both ends need to wired the same otherwise there is no perfomance difference.

Synology Connecting Across VLAN with active VPN

2024-10-16T11:30:00+01:00

When a Synology NAS creates a VPN connection it overides the default gateway, except for devices listed as contained within its subnet. According to the a post on the synology forum even if the subnet is changed to 255.255.0.0 it will not see devices on another VLAN. It feels like a subnet mask of 255.255.255.0 is hardcoded.

For Allowing my Synology NAS to create a VPN connection and see device on my VLANS I had to add a static route defining a gatweway for the VLAN IP/subnet.

Network Destination: 192.168.107.0  # This is the VLAN 107
Netmask            : 255.255.255.0  # Standard netmask for a VLAN
Gateway            : 192.168.100.1  # Gateway for the Synology NASs VLAN
Interface          : physical interface that the Synology NAS uses to connect to the VLAN

TeX hyphenation

2024-10-14T14:45:00+01:00

When TeX/LaTeX is fully justifying text there are times when it could do better but it does not know how to hyphenate certain words. Here we can give it guidnace on how to split words.

For example (insert into the pre-amble):

\hyphenation{acro-nym}

Multiple hyphenation points can also be defined, and for related words:

\hyphenation{ac-ro-nym ac-ro-nym-ic a-cro-nym-i-cal-ly}

The hyphenation point can be inserted manually with a \-, but it is best to setup in the pre-amble and keep all the layout rules together.

acro\-nym

Preventing Hyphenation

Preventing hyphenation can be done by decalring in the pre-amble without a hyphen or inline with an \mbox command

\hyphenation{automobile}

this will stop hyphenation of inline text \mbox{automobile}

Global Hyphenation Control

Use the hphenat package to prevent all hyphenation

\usepackage[none]{hyphenat}

There are some better ideas on this TeX SO Question.

TeX Paragraph Box

2024-10-11T14:18:00+01:00

parbox is a LaTeX command used to place a box around text.

Remeber that optional arguments are in [] (Square brackets)

Typical usage is :

\parbox[alignment]{width}{text}

The options are:

alignment:
  t - Top alligned
  c - vertically centered
  b - Bottom alligned
  s - Stretch to fill vertically

width fractional value followed by ISO units of mm, cm and in are supported

Example:

\documentclass{article}
\begin{document}
  \parbox[b]{2.3cm}{b for bottom aligned}
\end{document}

If a large amount of text is to be placed in the box minipage is preffered over parbox.

\documentclass{article}
\begin{document}
  \begin{minipage}{2.3cm}
    minipage not parbox
  \end{minipage}
\end{document}

minipage supports all the arguments of \parbox, as well as \footnote

\documentclass{article}
\begin{document}
  \begin{minipage}{5cm}
    minipage not parbox \footnote{this is a foot note}.
    Second Line with another foot note \footnote{Another foot note}.
  \end{minipage}
\end{document}

LaTeX macros

2024-10-10T14:17:00+01:00

LaTeX macros can be used as simple text replacments for example:

\documentclass{article}
\newcommand{\LUG}{LEGO User Group}
\begin{document}
  \section{Welcome to the \LUG}
\end{document}

More Advanced usage allows LaTeX macros to be used like functions:

\documentclass{article}
\newcommand{\LUG}[1]{\textbf{#1} LEGO User Group}
\begin{document}
  \section{Welcome to the \LUG{tartan}}
\end{document}

Tools for Technical Writing

2024-09-10T10:17:00+01:00

WYSIWYG editor for LaTeX lyx, and a manager for Bibliography JabRef.

Lyx Tutorial: Lyx mac Guide

JabRef Tutorial: Getting Started

Tools avialable via home brew:

brew install lyx
brew install jabref

Bike Chain Cleaning

2024-06-14T12:27:00+01:00

Chain Cleaning method:

 Clean the chain with WD40 (water dispersant).
 Wipe dry with kitchen roll. 
 Spray with Comma White Grease and wipe clean again.

The chain should be lubricated on the moving parts of the chain, not the surface in contact with cogs.

Pyhton_virtual_env

2024-05-30T16:03:00+01:00

Creating/Setup a pyhton virtual enviroment called 'venv'

python3 -m venv venv

Load the virtual env called venv

source venv/bin/activate

RealPython Guide, Docs.

Convolution in Python

2024-05-03T14:25:00+01:00

Convolution in Python, for merging filter responses, creating pascals triangle ...

import numpy as np

a= np.array([1,1])
b= np.array([1,1])

c =np.convolve(a, b)
c
> array([1, 2, 1])

Perforce Update files in a Shelve

2024-04-30T11:04:00+01:00

Perforce can temporarily checkins of changes that you might want to share with others before fully commiting them to the code base. These P4 Shelves have some properties that seem undesirable for a revision control system. They are not imuttable.

From there nature they are temporary but they can also be altered and maintain the same changelist number. Solution based on this SO answer.

Lets create file a.txt with some default content, and create a shelve.

echo "File a - line 1" >> a.txt
p4 add a.txt
p4 shelve ...

> Change 3265397 created with 1 open file(s).
> Shelving files for change 3265397.

Remeber the Changelist number for the shelve, we will refer to it as \<change#>. Now lets modify a and create a b.txt.

p4 edit a.txt
echo "File a - line 2 after intial shelve" >> a.txt
echo "File b - line 1 Missed in first shelve" >> b.txt
p4 add b.txt

p4 reopen -c <change#> b.txt

> b.txt#1 - reopened; change 3265397

p4 shelve -r -c <change#>

> Shelving files for change 3265397.
> add //./a.txt#1
> add //./b.txt#1
> Change 3265397 files shelved.

Python merge PDFs

2024-04-22T18:49:00+01:00

Using python script to merge pdfs together.

Install package

pip install pypdf

Script:

from pypdf import PdfWriter

pdfs = ['file1.pdf', 'file2.pdf', 'file3.pdf', 'file4.pdf']

#merger = PdfMerger()
merger = PdfWriter()

for pdf in pdfs:
    merger.append(pdf)

merger.write("result.pdf")
merger.close()

source

Pythonista pip install pelican

2024-04-20T12:04:00+01:00

On the journey towards publish static site generator blog posts from iPadOS, my next step after installing stash on pythonista is uisng pip to install the pelican library.

Pythonista using stash for pip

2024-04-19T17:04:00+01:00

To run pip in pythonista we need to install stash first.

See stash page sfor latest details, at time of install I had to run this from the pythinista terminal:

import requests as r; exec(r.get('https://bit.ly/get-stash').content)

Then to start stash from a new (restart pyhtonista app) find and run the launch_stash.py script

there will then be a second terminal with the stash command line open up

Python read a CSV file

2024-04-19T12:34:00+01:00

Python example for reading data from a csv file.

import csv
with open(data.csv', newline='') as csvfile:
    spamreader = csv.reader(csvfile, delimiter=' ', quotechar='|')
    for row in spamreader:
        print(', '.join(row))

Import csv into a numpy array.

import numpy as np
import csv
with open('data.csv', 'r') as f:
  reader = csv.reader(f)
  data   = list(reader)
# data_array = np.array(data)  # Conversion for strings
data_array = np.array(data, dtype=float) # Conversion for doubles

# Print first 10 data elements.
for a in range(0,10):
  print( data_array[a] )

Outputs:

source

Python Sinewave

2024-04-19T12:34:00+01:00

Python example for creatign and plotting a sinewave:

# coding: utf-8

import numpy as np
import matplotlib.pyplot as plt

fs   = 48000
freq = 1000 #Hz
amp  = 1.0 # Linear Amplitude
t    = 100/fs # Seconds sample length

amp_db = 20*np.log10(amp)
file_name = 'sine_%dHz_%4.2f_amp' % ( freq, amp_db)
label_name = "Sinewave %dHz %5.2fdB" % (freq, amp_db)

#samples = np.linspace(0, t, int(fs*t), endpoint=False)
samples = np.arange(t * fs) /fs

signal =amp * np.sin(2 * np.pi * freq * samples)

fig, ax = plt.subplots()
ax.plot(signal, label=label_name)
ax.set_title('Sinewave')

plt.legend()
plt.show()
plt.savefig(filename + '.png')

Generates and saves this plot

To export the 'signal' data as a CSV file:

import csv
with open(file_name+'.csv', 'w', newline='') as csvfile:
  f_writer = csv.writer(csvfile, delimiter=' ',quotechar='|', quoting=csv.QUOTE_MINIMAL)
  f_writer.writerows(map(lambda x: [x], signal))

*.csv output:

0.0
0.13052619222005157
0.25881904510252074
0.3826834323650898
0.49999999999999994
0.6087614290087207

"Home Directory File Structure"

2015-10-22T10:32:44+01:00

Apples default directory structure is :

/Users/username
├── Desktop
├── Documents
├── Downloads
├── Library   # Hidden by default
├── Movies
├── Music
├── Pictures
├── Public

My current setup After adding Dropbox, dotfiles stored on github, Code, and user level applications folder:

/Users/username
├── Applications
├── Code
├── Desktop
├── Documents
├── Downloads
├── Dropbox
├── Library
├── Movies
├── Music
├── Pictures
├── Public
├── dotfiles

At present though my Dropbox is a mess of some documents, some code and lots of ebooks. Free Dropbox does not have enough space for me to the entire home directory. Considering a BtSync pro account which allows selective sync. BtSync will allow me to set the root as my home directory and select which folders from that to sync.

I have started using USB flash drives again, and have found unison to be a useful tool for syncing local drives to each other.

Me example unison sync (USB drive is called 'Dropbox'):

unison ~/ /Volumes/Dropbox/Unison/ -fat -auto -links true \
-path Code      \
-path Documents \
-path Dropbox

#-fat Work With FAT filesystem (ThumbDrive)
#-auto Accept default action for non-merges
#-links true follow symlinks

Now that the 'Dropbox' root is my home directory I can reorganise. Books should become a top level folder, and share a place along side Music and Movies.

Dropbox is kept but mainly used for sharing temporary files with others.

/Users/username
├── Applications
├── Books
├── Code
├── Desktop
├── Documents
├── Downloads
├── Dropbox
├── Library
├── Movies
├── Music
├── Pictures
├── Public
├── dotfiles

Dropbox: sending large files BT Sync: Synchronising files (eBook collection) Unison: Synchronising local drives (Thumbdrive to local documents/ebooks) ReadyNAS: Remote access to larger volume drives (Movies and TV Collections) Above could be a BT Sync non populated folder

"JapaneseGarden"

2015-10-10T12:50:55+01:00

First step creating the retaining wall, to become a raised bed.

"Potting Bench"

2015-10-10T12:23:15+01:00

Homemade potting bench, using 15 2.4M Fence boards (£45).

Note for ease of building the height was 1.2M, half a 2.4 meter board, this is too high.

"Self Watering Propagator"

2015-10-10T12:04:12+01:00

Propagator hack using some seed trays and capillary matting.

"Planter"

2015-10-10T10:52:30+01:00

3 Fence boards used to create planter.

"Matlab: floating point checking equality"

2015-06-10T20:43:32+01:00

As previously decribed floating point arithmetic is not associative. Which means it is very easy for floating point models not to match even though they are performing the same arithmetic operations. In matlab we compare the results:

a = 0.1 + 0.2 + 0.3 ;
b = 0.1 + (0.2 + 0.3);

isequal(a, b)
> 0

a & b are not equal, they are a least significant bit out, when comparing floating point numbers it is common to allow this amount of tolerance. Matlab anonymous functions can be used to create a new isequal function which takes a tolerance value. Idea from Stackoverflow.

isequalAbs = @(x,y,tol) ( all(abs(x-y) <= tol ));
floating_point_tol = 1e-15;

isequalAbs(a, b, floating_point_tol)

"Matlab: linear progressions"

2015-06-10T20:19:05+01:00

Progressions can be created using the Colon operator

min   = 10
max   = 100
steps = 20

step_size = (max-min)/steps

i = min:step_size:max

Alternatively linspace can be used:

min   = 10
max   = 100
steps = 20

i = linspace(min,max,steps)

This also allows for easily switching to a log scale using logspace.

"Matlab: functions inputs parsed based on outputs"

2015-06-10T20:10:54+01:00

It is quite common to detect how many input arguments have been passed to a function, using nargin (N arguments in). Commonly used to set defaults for arguments not specified.

function result = fun_name(a,b,c);
  if nargin <1
    error('a must be supplied');
  end
  if nargin <2
    b = 1; 
  end
  if nargin <3
    c = 1;
  end

  % ...

However I just discovered nargout (N arguments out(.

This allows the scripts to differentiate between:

x     = fun(a)
[x,y] = fun(a)

Example 1:

function [ varargout ] = nargout_test( input_args )
  disp(['nargout : ', num2str(nargout)])

  % Set outputs
  for i=1:nargout
    varargout{i} = 0;
  end
end

Example 2, changing input args usage based on number of outputs: note the input keyword change to the input arguments varargin Variable argument in.

function [ varargout ] = nargout_test( varargin )
  disp(['nargin : ', num2str(nargin)])
  disp(['nargout : ', num2str(nargout)])

  if nargout > 2
    error('Too many output arguments')
  end

  if nargout == 1
    % single output first input means something
    varargout{1} = varargin{1};
  end

  if nargout == 2
    % two outputs first input means some thing else
    varargout{1} = varargin{1} / varargin{2};
    varargout{2} = varargin{1} * varargin{2};
  end

end

A good example is the dcblock script by J M De Freitas.

Which has this syntax:

% SYNTAX    [a] = dcblock(Fc);  
%           [a] = dcblock(fc,fs);  
%           [aQ] = dcblock(fc,fs,B);  
%           [Fc,fc] = dcblock(a,fs);  
%           dcblock(Fc)  
%           dcblock(fc,fs)  
%           dcblock(fc,fs,B)

"SystemVerilog: RTL Types"

2015-03-26T20:08:34+00:00

reg and wire were the original synthesisable types. Wires are constantly assigned and regs are evaluated at particular points, the advantage here is for the simulator to make optimisations.

wire w_data;
assign w_data = y;

// Same function as above using reg
reg r_data;
always @* 
  r_data = y ;

A common mistake when learning Verilog is to assume the reg type implies a register in hardware. The earlier optimisation for the simulator can be done through the context of its usage.

This introduces logic which can be used in place of wire and reg.

logic  w_data;
assign w_data = y;

// Same function as above using reg
logic r_data;
always @* 
  r_data = y ;

The type bit and byte have also been created that can only hold 2 states 0 or 1 no x or z. byte implies bit [7:0]. Using these types offers a small speed improvement but I would recommend not using them in RTL as your verification may miss uninitialized values or critical resets.

The usage of bit and byte would be more common in testbench components, but can lead to issues in case of having to drive x's to stimulate data corruption and recovery.

Update

At the time of writing I was under the impression that logic could not be used for tristate, I am unable to find the original paper that I based this on. Until further updates, comments or edits, I revoke my assertion that logic can not be used to create tri-state lines.

The tri type has been added, for explicitly defining a tri-state line. It is based on the properties of a wire, logic is based on the properties of a reg.

tri t_data;
assign t_data = (drive) ? y : 1'bz ;

If you no longer have to support backwards compatibility Verilog then I would recommend switching to using logic and tri. Using logic aids re-factoring and and tri reflects the design intent of a tristate line.

Originally posted as a SO answer.

"Verilog: define if not defined"

2015-03-26T19:45:10+00:00

To set a default define option while allowing it to be overridden from the command line.

`ifndef mode_sel
  `define mode_sel 0
`endif

The command line should override testbench defined options but this has proven unreliable.

command line to set value:

irun -define mode_sel=1 ...

"Verilog: shm waveforms"

2015-03-26T19:38:29+00:00

The best practice is to use a tcl file:

shm.tcl

database -open waves -shm
probe -create your_top_level -depth all -all -shm -database waves
run 
exit

run with :

irun -access +r testcase.sv -input shm.tcl

Alternatively the following can be added to the simulation:

initial begin
  $shm_open("waves.shm"); $shm_probe("AS");
end

run with irun -access +r testcase.sv

NB: I have had trouble getting this last version to work, the tcl file method is more reliable.

"Verilog Timeformat"

2015-03-26T19:21:25+00:00

Time can be displayed during simulation using %t.

$display("%t", $realtime);

Timeformat is used to control the way (%t) this is displayed:

//$timeformat(unit#, prec#, "unit", minwidth);
$timeformat(-3, 2, " ms", 10); // -3 and " ms" give useful display msg

unit is the base that time is to be displayed in, from 0 to -15
precision is the number of decimal points to display.
"unit" is a string appended to the time, such as " ns".
minwidth is the minimum number of characters that will be displayed.

0 = 1 sec -1 = 100 ms -2 = 10 ms -3 = 1 ms -4 = 100 us -5 = 10 us -6 = 1 us -7 = 100 ns -8 = 10 ns -9 = 1 ns -10 = 100 ps -11 = 10 ps -12 = 1 ps -13 = 100 fs -14 = 10 fs -15 = 1 fs

"Tiered Raised Bed"

2015-03-24T19:17:45+00:00

Decorative raised bed for lavender:

A couple of images before it was filled:

"OS X disable back gesture"

2015-02-18T18:26:07+00:00

After accidentally scrolling back a page when browsing the web in chrome too many times. Figured out how to disable it: from your terminal

defaults write com.google.Chrome AppleEnableSwipeNavigateWithScrolls -bool FALSE

From http://apple.stackexchange.com.

"SystemVerilog: Constrained Random"

2015-02-18T17:01:56+00:00

A minimal example of constrained random to constraining a 4 bit value to 0 to 11 when randomised.

module tb;

  class cr_example_t
    rand bit val;
    rand bit [3:0] sel;

    constrain c1 {
      sel < 12;
    }
  endclass

  cr_example_t cr_example = new;

  initial begin :test_program
    cr_example.randomise();
    $display(cr_example.val);
    $display(cr_example.sel);

    $finish;
  end

endmodule

"Verilog: Thermometer Code"

2015-02-18T16:51:43+00:00

Efficiently create a [thermometer code][wiki] in verilog:

localparam M = 32;

function [M-1:0] therm_code;
  input    [$clog2(M):0] val;
  begin
    for (int i = 0; i

"Vim: Macro"

2015-02-18T16:41:40+00:00

When . just will not do (repeats last action) because you need to capture a movement as well, macros are quick to create and use.

q<number><actions>q

Replay macro

@<number>

Replay macro 10 times

10@<number>

Example Yank and put line, then repeat 10 times.

q1 yyP q

10@1

"Find your ruby gems path"

2015-02-18T16:39:32+00:00

 ruby -r rubygems -e "p Gem.path"

From Giles Bowkett.

"Bread: Doves Gluten free"

2014-12-21T20:12:44+00:00

For use with the Panasonic Bread Maker SD-2501 & SD-2500.
Online Manual.

Gluten Recipes can not use timer function.

For best results follow this order of ingredients:
water, salt, fat, gluten free bread mix.

Doves Farm Gluten Free (Panasonic recipe)

SD-2501 Menu 12
SD-2500 Menu 11

Dark Crust (1hr 55min)

Water              320ml (330ml for Brown flour)
Cider Vinegar      1 teaspoon
Salt               1 teaspoon
Vegtable Oil       4 tablespoon
Medium Egg         1
Medium Egg White   1
Sugar              1 tablespoon
Flour              450g
Yeast              2 teaspoon

Doves farm recommends these ingredients:

SD-2501 Menu 12
SD-2500 Menu 11

Dark Crust (1hr 55min)

         Medium        Large
Milk     310g          465g
Vinegar  1 teaspoon    1.5 teaspoon
Oil      6 tablespoon  9   tablespoon
Eggs     2             3
Flour    450g          675g
Salt     1 teaspoon    1.5 teaspoon
Sugar    2 tablespoon  3   tablespoon
Yeast    2 teaspoon    3   teaspoon

Mix milk, vinegar, oil and eggs. Pour into the bread machine.
Add flour, salt and sugar, stir.
Sprinkle Yeast on top
Start machine, pausing after a few minutes to scrape down the sides.
Resume programme until completion

"Verilog: Calculate primes"

2014-12-20T07:28:41+00:00

Based on my answer to this SO Question.

Definition of Prime:

A Prime Number can be divided evenly only by 1, or itself. And it must be a whole number greater than 1.

A simple method would be to iterate over numbers 2 to N, checking if it was divisible by all natural numbers greater than 2, and below the current value.

Once checked that it is not divisible by 2 there is not point checking for 4, 6, 8 etc. Remembering the definition of prime all numbers that are not prime are integer multiples of prime. so we have reduced the amount of work involved in testing primality.

parameter        N        = 1000;          
reg       [31:0] prime_number [0:N-1]; Store 0 to N prime numbers
integer          test     ; // Result of primality test
integer          k        ; // Currently looking for k'th prime 
integer          index    ; // Counts 1 to k, indexing previous primes 
integer          number_ut; // Number Under test

reg        [1:0] state   ; 
localparam       S_INC   = 2'b01;
localparam       S_CHECK = 2'b10;

initial begin
  prime_number[0] = 'd2; //Preload first Prime
  state           = S_CHECK; //Check set count first
  number_ut       = 'd3; // Number Under Test
  k               = 'd1; // Position 0 preloaded
  index           = 'd0;
  test            = 'd1;
end

always @(posedge clk ) begin
  if (state == S_INC) begin
    number_ut <= number_ut+1 ;
    state     <= S_CHECK ;
    index     <= 'd0;
    test      <= 'd1; // Safe default
  end
  else if (state == S_CHECK) begin
    if (test == 0) begin
      // Failed Prime test (exact divisor found)
      $display("Reject %3d", number_ut);
      state           <= S_INC ;
    end
    else if (index == k) begin
      //Passed Prime check
      //Use k+1 so that 2 is number 1, 3 is 2nd etc
      $display("Found the %1d th Prime, it is %1d", k+1, number_ut);
      prime_number[k] <= number_ut;
      k               <= k + 1;
      state           <= S_INC ;
    end
    else begin
      test  <= number_ut % prime_number[index] ;
      index <= index + 1;          
    end
  end
end

Example on EDA Playground.

This is however just a programming exercise as the resulting hardware is likely substantially bigger than just implementing a look up table to the maxim number of primes you can fit in prime_number. The look up table will also be ready from time zero and not need to recompute every time you power up.

"tcsh Remove trailing /"

2014-10-08T21:15:43+01:00

#!/bin/tcsh

set var = "helloworld/"

## http://dbaspot.com/shell/350417-sed-removing-trailing.html
set var = `echo "$var" | sed -e 's,\(.\)/$,\1,'`

echo $var

"F-Stop Loka & Tripod"

2014-09-18T11:28:47+01:00

F-stop Loka with side mounted Manfrotto 055XPROB (3 stage carbon), with a Manfrotto 488 rc2 head.

{% img centre /images/Photography/Loka/morganp-20140416-Loka-_MG_7445.jpg %}

Tripod relatively secure in this position, although if not tightly strapped down movement does loosen the straps.

NB: also a thinktank skin 50 mounted on the hip belt.

"Command line bulk file rename"

2014-09-05T18:06:05+01:00

To prepend to to filenames

cd to_folder
ls | xargs -I {} mv {} addthis-{}

or target jpgs

cd to_folder
ls *.jpg | xargs -I {} mv {} addthis-{}

http://www.peteryu.ca/tutorials/shellscripting/batch_rename

"Word WORD the Difference"

2014-08-19T06:27:30+01:00

Just realised there is a difference between word and WORD in Vim.

WORD is non-blank delimited by whitespace. word is alpha-numeric and other non-blank characters delimited by whitespace and punctuation. 'iskeyword' can be used to move delimiters in to part of the selection of the word.

by default :

this-is-four-words
this-is-one-WORD

"List files ignored by git"

2014-07-30T20:18:07+01:00

From Github Training & Guides.

git ls-files --others --ignored --exclude-standard

"xkill"

2014-07-30T20:16:39+01:00

I just discovered the xkill command, when a window has crashed you can call xkill and get a skull and crossbones cursor to kill the application.

It even works well with remote GUI applications (Sun Grid Engine SGE).

"Submit to SGE as if working locally"

2014-07-30T20:13:23+01:00

Setting an alias in you .tcshrc

alias qrun 'qrsh -V -noshell -cwd !*'

or bash

alias qrun='qrsh -V -noshell -cwd !*'

Which makes submitting any script to the grid just:

qrun helloworld.sh

Originally asked on superuser.

"Simulink: Scroll wheel erratic behaviour"

2014-07-30T20:08:10+01:00

On Mac OS X matlab behaves quite oddly with the track pad zooming in and out very quickly and erratically to remove this behaviour Disable Mouse Scroll Wheel Zoom Behavior.

To disable the zoom behavior for the scroll wheel:

File > 
  Simulink Preferences > 
    Editor Defaults > 
      Scroll wheel controls zooming preference.

If you hold the Ctrl key and use the scroll wheel, the scroll wheel behavior is the opposite of how the preference is set.

source.

"Matlab editor no tabs"

2014-07-30T20:04:15+01:00

Matlab always use to open text files in tabs in the same editor window. When switching to 2014a documents started opening as separate windows.

It seems to have been a problem which occasionally shows up for others

Current solution is to dock the editor (ctrl-shift-D) , open multiple files (2 or more) then undock the group (ctrl-shift-U).

"Simulink: Globally set sample time"

2014-07-30T20:01:49+01:00

To set each constant in a model to sample time -1:

blks = find_system(dut, 'BlockType', 'Constant');
for i = 1:length(blks)
    set_param(blks{i}, 'SampleTime', '-1');
 end

Source.

"Simulink: list programmable block properties"

2014-07-30T20:00:28+01:00

Select a block ie gain in Simulink then in Matlab type:

get(gcbh)

This shows the list of properties which can be controlled from Matlab. TO change one for example changing the gain paramter from double to a 10 bit fixed point number (sfix10_en9).

set_param(gcbh, 'ParamDataTypeStr', 'fixdt(1,10,9)');

From Matlab Central.

"Matlab: Find all gain blocks"

2014-07-30T19:58:53+01:00

find_system('BlockType', 'Gain')

This will list all gain blocks in currently loaded models. to limit to a particulat model:

find_system('testharness', 'BlockType', 'Gain')

From Mathworks.

"error: storage class specified for parameter"

2014-06-19T20:42:33+01:00

error: storage class specified for parameter

There is probably a missing semicolon ; in a header file! Just written my first C Header and received the above warning. It was indeed due to a missing semicolon.

"Shell redirection"

2014-06-19T20:10:57+01:00

To redirect stdout and stderr in bash we use:

./ShellFile.sh &> test.log

However in tcsh that results in:

Invalid null command.

Switch the order of & and > in tcsh :

./ShellFile.sh >& test.log

"Floating Point Arithmetic is not Associative"

2014-06-19T20:00:45+01:00

This can be shown with some easy examples:

a = 0.1 +  0.2 + 0.3 ;
b = 0.1 + (0.2 + 0.3);

sprintf('%.20f', a) % Display with 20 fractional places
sprintf('%.20f', b)

ans =
  0.60000000000000008882

ans =
  0.59999999999999997780

Multiplication examples:

c = 0.1 *  0.2 * 0.3 ;
d = 0.1 * (0.2 * 0.3);

sprintf('%.20f', c)
sprintf('%.20f', d)

ans =
0.00600000000000000099

ans =
0.00600000000000000012

By default gcc will not rearrange equations for optimal performance as this would change the accuracy. The GCC flag -ffast-math optimizes equations as if they were associative.

The examples shown here were found on Hacker News.

"Adobe Creative Cloud is ..."

2014-06-19T18:15:59+01:00

Inconsistent, annoying, cheap?

My main bugbear with the creative cloud application is the way it updates applications. Photoshop CC and Lightroom are handled differently.

Photoshop switches from installed to update. Which is great it will pull in the update on my command.

Lightroom switches from Installed to Try.

Not only that but I have now have 2 version of Photoshop CC and CC (2014) ready for updates, one of which has not already been installed.

SO I have 2 applications with updates ready, one wants an update the other refuses to acknowledge it has been installed and wants a new install. A new program, Photoshop CC (2014), which only requires an update.

"Octopress categories with different styles"

2014-06-14T08:24:01+01:00

As I use the code blocks for ingredient lists on my recipe pages I wanted to have a different style, lighter background instead of black.

I currently manually set a different layout in the _post header:

layout: post
Category: 
- Tech

layout: recipe
Category: 
- Cooking

The layout will then look for a matching layout in source/_layouts

Manually create your new layout (instructions from top level Octopress site):

cp source/_layouts/post.html source/_layouts/recipe.html

Edit source/_layouts/recipe.html changing the role to recipe:

---
layout: default
single: true
---

<div>
<article class="hentry" role="recipe">
  \{\% include article.html \%\}
  <footer>
    <p class="meta">

This will now pick up the styling that post also gets but we can target our modifications to article[role="recipe"]. For custom stylings apply changes in to the relevant file in sass/custom/.

To modify the background colour of a code block
sass/custom/_styles.scss add:

// Customise the recipe layout
article[role="recipe"] pre {
  background-color: $sidebar-bg;
}

NB: $sidebar-bg is defined in sass/base/_theme.scss

"Verilog: Timeout"

2014-06-14T08:08:26+01:00

To wait for a maximum of 10ns for positive edge on clk then carry on with simulation.

fork : wait_or_timeout
  begin
    #10ms;
    disable wait_or_timeout;
  end
  begin
    @(posedge clk);
    disable wait_or_timeout;
  end
join

Often use to fail simulation if the expected signal does not occur, this stops simulation hanging and allows status reports to be generated.

Originally posted as SO answer.

"Matlab Remove Elements from Array"

2014-06-02T19:08:09+01:00

Removing elements based on index

A      = 1:10    ; % 1-D array
A =
 1     2     3     4     5     6     7     8     9    10

ind    = [1 4 7] ; % indices to be removed
A(ind) = []      ; % remove

A =
 2     3     5     6     8     9    10

Based on Matlab Central.

"Matlab: Formatting Strings"

2014-06-02T18:46:09+01:00

The official documentation can be found on mathworks.

To display a number with 3 Integer decimal places and 3 fraction places $f7.3 7 rather than 6 as need place for the decimal point.

>> a = sprintf('6.3-%6.3f-', 123.678)
a =
6.3-123.678-

>> a = sprintf('6.3-%6.3f-', 23.678)
a =
6.3-23.678-

>> a = sprintf('6.3-%6.3f-', 3.678)
a =
6.3- 3.678-

-ve numbers

If signed you need to leave space for -ve $f8.3 :

>> a = sprintf('7.3-%7.3f-', -123.678)
a =
7.3--123.678-

>> a = sprintf('7.3-%7.3f-', -23.678)
a =
7.3--23.678-

>> a = sprintf('8.3-%8.3f-', -23.678)
a =
8.3- -23.678-

For reliable and consistent floating point displays use:

%(fractional places + integer places + 2).(fractional places)f

"Matlab: Grid"

2014-05-28T19:49:38+01:00

To add X and Y grids to plots :

grid on;

To add Y only grid:

set(gca,'XGrid','off','YGrid','on');

To add X only grid

set(gca,'XGrid','on','YGrid',’off');

"Matlab: Line Breaks in Strings"

2014-05-28T19:34:30+01:00

Wrap strings with sprintf to allow the \n to be escaped correctly.

>> disp('hello\nworld')
hello\nworld

>> disp(sprintf('hello\nworld'))
hello
world

"Matlab: Listing field name values of a struct"

2014-05-28T19:05:01+01:00

s = struct ;
s(1).dat =‘a' ;
s(1).freq=11 ;
s(2).dat =‘b' ;
s(2).freq=22 ;

Where:

s(1)

ans =

     dat: 'a'
    freq: 11

How do you access [‘a’, ‘b’] and [11, 22]?

[s.dat] , [s.freq]

The [] are really important here.

[s.freq]

ans =

    11    22

Solution found on a Loren Post.

"F-Stop ICU Strobies"

2014-05-28T18:44:55+01:00

My large ICU loaded with my Strobies portrait kit and Canon 580EX MKII.

The collapsed soft box is folded into the right hand side. Additional accessories are a 3M Lastolite off camera cord, Colorvision SpyderCube and a Stofen.

"Kettlebell Rack"

2014-05-28T18:32:43+01:00

Kettlebell rack with 24kg, 16kg, 8kg, 12kg, 16kg, 20kg.

End detail showing bracing.

Underside of rack.

"Matlab toolboxes with absolute path setup"

2014-05-07T18:22:48+01:00

When a script or function is called with run(./relative/path/script) the working directory is changed to the ./relative/path. This means pwd it can be used to specify absolute paths:

run(./libs/example_toolbox/load_toolbox)

Which contains :

addpath([pwd, '/function']);

Now The path will contain C:/ ... /libs/example_toolbox/function

As shown in the example this is useful for toolboxes etc which could be distributed with a top level script which adds the toolbox functions on to the path.

"Matlab: Array content check"

2014-05-07T18:13:24+01:00

Checking if an Array contains a number:

input = [1,2,3,4];
check = 4;
any(input==4)

Check if a number is contained in an array:

input = 32;
check = [32,64,128];
any( check==input )

"Matlab: Split Odd & Even Array Elements"

2014-05-07T17:58:33+01:00

Using Matlab to splitting data into odd and even samples.

A for loop approach:

data_odd  = [];
data_even = [];
for i = 1:length(data)
  if mod(i,2)
    %% disp('odd')
    data_odd = [data_odd, data(i)]
  else
    %% disp('even')
    data_even = [data_even, data(i)]
  end
end

Matlab approach using ranges to remap values:

data_odd =data(1:2:end);
data_even=data(2:2:end);

Ranges are composed of start_index:step_size:end_index. If step_size is omitted, 1 is assumed.

end has a special meaning when used inside an array, it is the position of the last element. To append to an array you could use data(end+1) = append_value

No error or warning is triggered if the end_index can not be reached with the given step size, which is why this works with end as the stop point of both sides.

Example

a   = [1, 2, 3, 4, 5];
odd = a(1:2:end)
even= a(2:2:end)

odd =
     1     3     5

even =
     2     4

Lizard-Spock

SoC Article 06: Interconnects and Bus Protocols - AXI, AHB, and APB

Introduction

Why a Standard Bus Matters

The AMBA Family

APB -- Advanced Peripheral Bus

APB Signals

APB Write Timing

AHB -- Advanced High-performance Bus

Key AHB Signals

AHB Pipelined Burst Read

AHB Arbitration

AXI -- Advanced eXtensible Interface

The Five AXI Channels

Valid/Ready Handshake

AXI Burst Transfers

AXI IDs and Out-of-Order Transactions

The Interconnect: From Bus to Crossbar

QoS: Quality of Service in Interconnects

AXI4-Lite: The Simplified Register Interface

APB Bridge: Connecting the Bus Tiers

Network-on-Chip (NoC)

Summary

Further Reading

SoC Article 05: Memory Architecture - Caches, DRAM, and On-chip Storage

Introduction

The Memory Speed Gap

The Memory Hierarchy

How Caches Work

Cache Organisation

Static RAM (SRAM): The Cache Technology

DRAM: The Main Memory Technology

DRAM Organisation

On-chip SRAM (Tightly Coupled Memory)

The DRAM Controller

Non-Volatile Storage

Memory Mapping: The Software View

Cache Coherency: The Multi-Core Problem

Memory Management Unit (MMU)

Summary

Intermediate Articles This Topic Connects To

SoC Article 04: Processor Cores - CPU, DSP, GPU and Hardware Accelerators

Introduction

The Processing Landscape

General-Purpose CPU Cores

Architecture Fundamentals

Pipeline Stages

The Big-Little Concept

Key Performance Metrics

Soft vs Hard CPU Cores

Digital Signal Processors (DSPs)

The MAC Operation

DSP Architecture Features

Graphics Processing Units (GPUs)

Hardware Accelerators

Neural Processing Unit (NPU / Neural Engine)

Video Codec Engine

Cryptographic Accelerator

Image Signal Processor (ISP)

The Processor Cluster: Putting It Together

Processor State Machine: A Simplified View

Choosing the Right Processor for Your SoC

Summary

Intermediate Articles This Topic Connects To

SoC Article 03: The SoC Design Stack - From Transistors to Software

Introduction

The Abstraction Hierarchy

The Gajski-Kuhn Y-Chart

Layer 1: Devices and Transistors

Layer 2: Logic Gates

Layer 3: Register Transfer Level (RTL)

Layer 4: The Instruction Set Architecture (ISA)

Layer 5: Microarchitecture

IP Cores: Pre-Built Design Blocks

The Design Flow Overview

Modelling Languages: Choosing the Right Abstraction

Summary

Intermediate Articles This Topic Connects To

SoC Article 02: What is a System on Chip? - Anatomy and Motivation

Introduction