James W. Hanlon

Personal data and self hosting

2024-08-26T00:00:00+02:00

As part of a conscious effort to reduce or remove my dependence on cloud services for storing my data, I have been running a modest self-hosted setup for quite a few years, which has worked well and required very little ongoing maintenance. I haven’t attempted to self-host services like email, opting instead for trusted providers. This short note goes over the main details.

The goals for my personal computing are:

To have complete control over my personal data, giving me flexibility over how to manage and access it. Even with GDPR, this would be an ambitious goal for all personal data, so I really mean files and media created on personal computing devices. Anything that I can download from a cloud service, I aim backup on my own storage, or master it there if I no longer require access via the cloud service.
To have independence from companies that (a) offer free services in return for collecting profiling data or to target adverts at me, (b) lock me in as a user so it is hard to move to another service and (c) to avoid services that I come to rely on being end-of-lifed.
To have a system that is simple to set up, maintain, use, upgrade and possibly/eventually to migrate from.
To provide a significant amount of storage (in personal data terms, ~tens of TBs). This is because accessing volumes of data this large through cloud services can be expensive when you factor in monthly charges and transfer costs.

The main philosophy of my approach is to minimise maintenance effort whilst still achieving the above goals, so my setup is very vanilla. Many more exotic and interesting self hosted systems can be found (I’ve linked to a few resources at the end).

Synology Diskstation

The main machine is a Synology Diskstation DS220+, a two-bay network-attached-storage (NAS) box. I have this running with two 8 TB disks in RAID 1 configuration (two-way redundant using one disk as a mirror), and I upgraded it with 16 GB of memory in addition to the 2 GB it comes with. There are many applications that Synology provide, but the main ones I use are:

Fileserver (SMB for access via Windows and Mac machines, and the Drive app for accessing and syncing files).
Photos (in particular the photos mobile app automatically syncs photos to the NAS for backup).
Music.
Hyperbackup.
VPN server.
DNS server.

The advantage of a Synology system is good hardware complemented by their ecosystem of applications, spanning iPhone and Android too. The catch is that this ecosystem is closed source and managed by Synology. As such, support for old hardware is eventually dropped and some software packages are deprecated. To mitigate these problems, an alternative is TrueNAS (formerly FreeNAS), running on some suitable hardware. Other non-Synology software can be run on a Synology device using Docker, however I’ve had problems doing this with constant disk accesses caused by container health checks.

A neat feature of Synology hardware is their Quickconnect remote access, without needing a VPN or having an open port. This works with the web interface and phone apps.

The single most important aspect of managing personal data is ensuring it is robustly backed up. RAID 1 provides protection against loss of a single disk (and Synology handles this well), but not against damage to the system such as would happen in an accident or fire. To mitigate this, I have setup an off-site backup using another Synology Diskstation NAS. A full incremental backup is performed nightly using Synology’s Hyperbackup. I have checked that files are retrievable but I admit I have not tried a full system restore since it has not yet been necessary.

Linux host

The second box in the picture above is a Lenovo ThinkCentre M75q Tiny PC that I got to plug the gap in the Synology’s capabilities, namely in running additional services and providing a Linux host that I can use for development etc, rather than paying for an under powered VPS. The machine has a Ryzen 5 3400GE processor with 16GB DDR3 RAM and a 500 GB NVMe SSD. You can pick these machines up very cheaply.

Currently it runs:

Homepage providing a general internal landing page for statuses and convenient links.
FreshRSS for aggregating and reading RSS feeds.
Speedtest Tracker for monitoring my internet connection.
Octograph for monitoring my home electricity use and pricing.

Access

Using Synology VPN server on the DS220+, I have an OpenVPN service setup that allows me to access my home network remotely. This gives me access to the various services, as well as to machines via RDP and SSH. Within the network, I have a local DNS service (also running on the DS220+) to provide convenient names for devices.

Other services

As I mentioned at the start, there are a number of third-party services that I use. The key ones are:

Proton primarily for email, calendar and passwords.
Github for code and Github pages for hosting this website (at the time of writing).
Digital Ocean for object storage with Spaces.
Google Sheets for word processing and spreadsheets.
Standard notes for note taking, since they have recently been acquired by Proton.
Apple iCloud for contacts and reminders.
Strava and Garmin for fitness data.

This list is not exhaustive but these services all hold valuable data that I would not want to lose in the event the provider loses the data or I get locked out of my account. Although these scenarios is unlikely, I mitigate the risks by taking manual backups, albeit on a less frequent basis that I should.

Summary

This note details hardware and software alternatives for operating personal services that are east to setup and maintain, with scope to add much more functionality. This approach provides a strong alternative to entrusting a third party to hold your data. Moreover, it can be done cheaply too, with the cost of NAS setups being dominated by the price of disks themselves and many great open-source software options.

Discrete-event simulation

2024-08-14T00:00:00+02:00

Discrete event simulation (DES) is a methodology for modelling dynamic systems as a sequence of events in time. There are plenty of places to read about DES, but in this note I want to outline how it works and can be simply implement, recognising several subtleties. DES is widely used in different areas where analytical solutions are difficult; I am focusing on its use in modelling digital logic and computer systems.

In a DES, each event is scheduled to occur at a particular point in time and represents a change in the state of the system and the possible generation of future events. Because there are no state changes between events, the simulation jumps through time from one event to the next. These variable time steps are in contrast with a discrete-event scheme with fixed timesteps. Fixed timesteps are particularly suited to digital systems with clocked logic, where each time increment corresponds to clock cycle. Fixed-time simulation has the drawback that all time steps are evaluated regardless of whether anything happens, although it is easier to reason about since everything proceeds in lockstep. DES is inherently more flexible but can be harder to parallelise because of the need to maintain a centralised event list.

Operation

The main components of a DES are:

A state (or set of states) representing the components of the system.
Events, that occur atomically at a particular instant and can update the system state and create new future events.
A clock, that records the simulation time.
A list of future events (the event list). This is most often implemented as a priority queue with events queued in chronological order, soonest at the front.

An outline of the DES algorithm is as follows:

Create one or more initial events and add them to the event list.
While the event list not empty:
- Choose a next event with the earliest time.
- Advance simulation clock to time of event.
- Execute the event.
  - State updates are committed immediately.
  - New events are added to the event queue.

Simulation proceeds until there are no more events to process, or a maximum time is reached.

During the simulation the following must be ensured:

For events that occur at the same time, it must be possible to execute them in any order, without affecting the behaviour of the simulation. In other words, the outcome of the simulation must not depend on any ordering of simultaneous events.
Duplicate events must not be created. For example, if a component of the system is servicing some kind of input queue, when an item is added to the queue a corresponding ‘service’ event must be created, but only when the queue is empty. As such, delegation of responsibility for event creation must be clear.

To avoid violating point 1 above, each time step can be divided into phases to impose an ordering of events.

The simplest case is to divide each timestep into two phases to serialise the handling of two dependent events. As an example, consider nodes in a ring topology that can pass tokens between themselves in one direction, with it taking one timestep to for a token to traverse one node. Each node has two associated events: transmit and receive. It must hold that a transmit event for a node must be scheduled any receive events for that node have been processed. By separating event processing in this way, there can be no dependencies between the serialisation of transmit and receive events as they are fetched from the simulation queue.

DES of a ring of nodes that exchange a token with events for transmit and receive, separated by different phases within a simulation timestep.

Extending this concept of phases, a timestep can be divided into an arbitrary number of sub phases to model more complex behaviours. An interesting example of this is SystemVerliog, which defines its execution semantics in terms of multi-phase discrete event simulation. Roughly, a design or test bench defines a set of stateful processes that respond to changes on their inputs to produce outputs. Every change in state of a net or variable causes processes sensitive to them to be evaluated. There may be many steps of evaluation to produce a final output for the timestep. The timestep is divided into a fixed set of ordered regions (17 in total) to provide predictable interactions with a design. Within a region, many events may be processed and further ones scheduled to resolve sensitivity dependencies.

Example implementation

Using the above example of a ring of nodes passing a token around them, the following Rust code implements a DES of the system. This is a very simple DES example and only one possible implementation, but sufficient to illustrate the main concepts.

The main component is a Simulator object that maintains the event queue and the system state:

struct Simulator {
    max_cycles: usize,
    current_time: usize,
    event_queue: BinaryHeap<Event>,
    state: State,
}

Events have a type, a time at which they occur and node in the system that they belong to. The node_id is used for directing state updates.

#[derive(Debug, PartialEq, Eq, PartialOrd, Ord)]
enum EventType {Transmit, Receive }

#[derive(Debug, PartialEq, Eq, PartialOrd, Ord)]
struct Event {
    event_type: EventType,
    time: usize,
    node_id: usize,
}

The main simulation loop pops events off of the queue while it is not empty and dispatches them to a handler function:

fn run(&mut self) {
        while let Some(event) = self.event_queue.pop() {
            if self.max_cycles > 0 && self.current_time >= self.max_cycles {
                break;
            }
            self.current_time = event.time;
            self.handle_event(event);
        }
    }

The simulation current_time is updated to the time of the current event being processed. The event handler function implements the behaviour for each event:

fn handle_event(&mut self, event: Event) {
        match event.event_type {
            EventType::Transmit => {
                // Deactivate.
                self.state.nodes[event.node_id].active = false;
                println!("Node {} inactive", event.node_id);
                // Schedule receive at next node.
                let recv_event = Event {
                    event_type: EventType::Receive,
                    time: self.current_time + 1,
                    node_id: self.state.next_node(event.node_id),
                };
                self.schedule_event(recv_event);
            }
            EventType::Receive => {
                // Activate.
                self.state.nodes[event.node_id].active = true;
                println!("Node {} active", event.node_id);
                // Schedule transmit.
                let send_event = Event {
                    event_type: EventType::Transmit,
                    time: self.next_timestep(self.current_time),
                    node_id: event.node_id,
                };
                self.schedule_event(send_event);
            }
        }
    }

Each event action updates the node state and creates a new event corresponding to the passing of the token to the next node of the ring.

The simulation is setup with a initial receive event at node 0:

let mut sim = Simulator::new(20);
for _ in 0..10 {
    sim.state.add_node();
}
let initial_event = Event { event_type: EventType::Receive, time: 0, node_id: 0 };
sim.schedule_event(initial_event);
sim.run();

And running it produces the output:

Node 0 active
Node 0 inactive
Node 1 active
Node 1 inactive
Node 2 active
Node 2 inactive
Node 3 active
Node 3 inactive
Node 4 active
Node 4 inactive
Node 5 active
Node 5 inactive
Node 6 active
Node 6 inactive
Node 7 active
Node 7 inactive
Node 8 active
Node 8 inactive
Node 9 active
Node 9 inactive

The complete source code for the example can be found in this Gist.

There are many libraries for implementing DES such as SystemC and SimPy. Different libraries provide varying approaches for creating and managing events with supporting infrastructure, and their applicability depends on the application and system being simulated.

Summary

This note explains how DES simulation works and how it simple to implement. DES is well suited to modelling synchronous and asynchronous digital systems, but care must be taken to ensure that simultaneous events are scheduled without dependencies and events are not duplicated.

References / further reading

GitHub repository
Discrete-event simulation, Wikipedia.
List of DES software, Wikipedia.
Introduction to discrete event simulation, CMU lecture notes.
Distributed discrete event simulation, Jayadev Misra (1986).
Parallel discrete event simulation, Richard M. Fujimoto (1990).
Principles and Practices of Interconnection Networks, Chapter 24, William Dally, Brian Towles (2004).
1800-2017 SystemVerilog LRM, section 4 ‘Scheduling semantics’.

Review of heat pump use and performance

2024-07-31T00:00:00+02:00

NOTE: Updated October 2024 with improved charts.

My 10kW Vaillant Arotherm Plus.

I had a 10 kW Vaillant Arotherm heat pump installed in July 2022, and a year later a Vaillant Sensonet gateway, which provides monitoring and logging services via the ‘myVaillant’ smartphone app. Since I now have a year’s worth of data, this note reviews what has been logged to see how the system is performing.

The heat pump serves my house of approximately 90 square meters internal area. I have previously posted about the building’s energy efficiency and additional first floor insulation added. This pump’s capacity exceeds the current requirements of the house, but we are planning an extension in the near future.

System operation

The way I run the system is for space heating to run continuously with a fixed temperature of 19 degrees C is set in the downstairs hallway (a central point in the house), and hot water to run continuously at 50 degrees C. In the first year of running the system, I experimented with running heating and hot water for set periods during each day of the week, but I found that the heat pump had to work hard to bring the system and the fabric of the house back up to temperature.

I was advised that continuous operation was more efficient and since the house is almost always occupied, this matched our use. At that point I hadn’t taken a close look at the measured performance and was just monitoring the electricity demand ad hoc. It is not to say that running the system with setback temperatures would not be effective and may better match occupancy: see analysis from Heatgeek or Protons for Breakfast on this subject, But for me, having a continuous temperature is the most comfortable and seems to work well.

The myViallant app

The myVaillant app usefully provides a button to download all logged data per year in a set of CSV files and this code is available on Github. I have summarised the year period from July 2023 to July 2024 in the following charts. Having read this PFB review, I am aware that there are issues with the quality of the logged data. The review measured a ~8% error in electricity consumed and a ~20% error in the heat energy produced, as well as pointing out many logged values are quantised to kWh units, which I also observe in my data. Significantly, this means that the raw Vaillant data under reports COP. I don’t have a point of comparison with with an alternative measurement of the consumed and generated energy (although I would like to install an OpenEnergyMonitor to do this). Despite the potential inaccuracies of the Vaillant data, it remains useful for a high-level review of the system.

Analysis

The overall performance of the system for the year from July 2023 to July 2024 is summarised in the following table.

Metric	Value
Consumed electricity heating	1.34 MWh
Consumed electricity hot water	1.01 MWh
Total consumed electricity	2.36 MWh
Average daily electricity consumption	6.65 kWh
Heat generated heating	4.91 MWh
Heat generated hot water	3.13 MWh
Total heat generated	8.04 MWh
Heating SCOP	3.65
Hot water SCOP	3.09
Total SCOP	3.41

Note that when scaling consumed electricity by 8% and generated electricity by 20% to adjust for possible inaccuracy, heating SCOP is 4.06, hot water SCOP is 3.43 and they are combined at 3.79. Note also, that these figures do not include the electricity used for the weekly Legionella purge performed by an immersion heater I have installed in my system.

Looking more closely at consumption, the chart below shows all measurements over this period for heating, hot water and their combination.

Electrical energy consumed in kWh.

Most obviously, electricity consumption during the winter months increases significantly when the heat pump is using approximately 10 kWh per day. There are two spikes in November and January where temperatures went below zero, and at these times consumption went up close to 30 kWh per day. As expected, electricity consumption for hot water is more consistent throughout the year with a lesser increase through the winter months. The short periods where both drop to zero are due either to a holiday and the system being in ‘absence’ mode or a technical issue. The technical issue has been due to a loss of pressure in the system, requiring a manual top up from the mains water supply.

The next chart is the heat energy generated, which is tightly correlated with the consumption graph.

Heat energy generated (hot water and heating) in kWh.

Combining the previous two charts by calculating the ratio between generated and consumed, gives the coefficient of performance (COP). A handful of measurements produced very large COP values, that are unrealistic, so I have clipped these with a maximum COP of 6.

COP calculated by dividing heat generated by electrical energy consumed.

This is the same COP data averaged over weekly intervals.

Weekly averaged COP.

The next chart is a different presentation of the COP data, with COP plotted as a function of heat output. It’s clear that peak COP is at ~10 kW heat output, but there is little penalty in efficiency between that and the highest recorded output.

Heat output versus weekly averaged COP.

Looking at the temperature of the hot water tank, this stays constant as expected but with a few exceptions: when I changed the temperature from 45 to 50 degrees C in October 2023; when the system has been off or out of order; and when every week on a Monday the immersion heater kicks in to perform a Legionella purge (which curiously it has stopped since March 2024. After later investigation this appears to be a faulty timer or immersion heater, so I switched to performing the purge using the heat pump itself).

Hot water temperature in degrees Celsius.

Finally, we have a plot of internal (red) vs external (blue) temperature in degrees C. This clearly shows that the 19 degrees C target was maintained throughout the year, notwithstanding the periods of absence/downtime and on particular hot days when the temperature rose above the target. Given how quickly our summers are changing with more intense heat, having a system that can also perform cooling would be a big benefit. But overall, I think this chart well represents the benefit of having a heat pump, providing a home environment with a continuous temperature throughout the year.

Internal and external temperatures in degrees Celsius.

For the same period I obtained the electricity use and cost data from Octopus using their excellent API via the Octograph tool, visualised below on a Grafana dashboard. According to the Vaillant data, the heat pump used 2.39 MWh of energy, which is only 32% of the total electricity use. I am suspicious that this is inaccurate, even factoring in an 8% underestimate from the Vaillant measurements. I would expect the heat pump to be using more like half of total electricity on average, given that other electricity use is cooking and appliances etc, but perhaps I am wrong. Otherwise the usage profile matches between the two data sets.

Electricity use from Octopus data.

Summary

The data collected by the Vaillant heat pump control system appears to be somewhat inaccurate but nevertheless provides a high-level overview of the performance of the system. I’ve been very pleased with how it has performed over the last year, and this is backed up by the statistics I have collated. With work planned on the house, there are more thermal-efficiency gains to be made, so hopefully I can further improve it’s running efficiency.

References and further reading

Protons for Breakfast, articles about heat pumps is a fantastic set of articles by physicist Michael de Podesta.
Energy Stats provides pricing data for various Octopus Energy tariffs.
Guy Lipman’s Octopus Energy resources is a collection of notes focusing on using the Octopus API to access energy data.
Octopus Energy API is the landing page for using their API.
Octograph (Github) A Python tool for extracting Octopus Energy meter readings to InfluxDB and Grafana.

Silicon infrastructure

2023-08-02T00:00:00+02:00

Modern chip design differs to conventional software engineering in three fundamental aspects that require a somewhat different approach to project development:

Transformations and representations. The creation of a chip design from a source-level representation through to a final GDSII description of the layout involves many stages of incremental transformations of the circuit and layout, and then incremental assembly of components into various subsystems before finally the entire chip. At various stages through this process, checks are performed on the design typically using simplified representations to reduce complexity and make run times practical.
Tooling. Compared to software tooling, standard chip-design tooling (known in the industry as electronic design automation) : (1) is almost all proprietary and used under license, meaning that interactive and automated use is limited and at odds with a continuous-integration model of development; (2) can have long run times (upwards of 12 hours for a job are not uncommon) and produce vast quantities of data, making it very unattractive to rerun something unless absolutely necessary; and (3) can be non-deterministic in that rerunning a job with the same set of inputs produces a different output.
Tape out. When a design is released for manufacture (known in the industry as a tape out), there are typically high non-recoverable expenses associated with setting up the processes and a long lead time in receiving a (hopefully) working device. There are two implications of this situation: (1) chip tape outs precludes incremental releases, for example to fix trivial bugs, and therefore means that the confidence in the correct functionality of the design must be very high; (2) post tape out, the design source code is effectively frozen forever more for the purposes of debug and analysis.

Despite these differences, many of the techniques and tools from software engineering can readily be applied to chip development, particularly to manage complexity and maintain high standards of code quality, testing and integration. This note lays out some thoughts and opinions on the components and structure of a software infrastructure to build chips.

Aims
Guiding principles
Flows
Model
Details
Summary
Acknowledgments
Related projects

Aims

The overall objective of a silicon infrastructure is to support the development of a verified chip design from RTL to GDSII. To make this more specific, I also define the following capabilities that should be supported as an overall philosophy of the approach that is explored in this note:

To rerun everything from scratch, requiring full automation of an the end-to-end flow. This is intended to: (1) distribute the task of integrating components of a design across a team, thereby revealing issues at as earlier stage in the project as possible to avoid disruptive changes towards the end; (2) enable faster design iteration; and (3) provide traceability of results (a foundation for the next aim).
Provide a full audit trail such that a release of a design for tape out has data and a set of reports, logs, coverage metrics, documentation and signoffs that are traceable back to the original RTL source files. This is important for building confidence to tape out, as well as providing information for future work on a completed design.
Support multiple chips and frozen designs to keep previous generations alive for debug of silicon issues and/or as a basis for a incremental tape out (known as a respin), and to allow multiple designs to be built concurrently.

Guiding principles

I think it is useful to underpin the aims, implementation and operation of a chip-design infrastructure are a set of guiding principles for the project team to employ when design decisions need to be made. These principles are formed from my own experience and through conversations with others. I am sure that alternative foundations can be constructed and argued for.

Simple and explicit. Build a complex system using simple, well-defined components composed and controlled using explicit mechanisms. Conversely, avoid easy-to-use high-level interfaces that hide important behaviours. This borrows from the Zen of Python: explicit is better than implicit and simple is better than complex. Examples include avoiding the use of global variables, preferring flat rather than nested, preferring decisions to be made explicitly and avoiding special cases that break the rules.
Use a monorepository. One repository should contain all the code for all active projects. This enhances all team members’ ability to integrate their changes across projects and removes barriers to interaction between different teams and/or areas of the design. Other general benefits of a monorepository are the ability to reuse code and do large-scale refactoring. A great deal of care must be taken to manage dependencies between projects/components within a monorepository. Without such care, unexpected interdependencies can cause unexpected breakages, prevent refactoring and preclude focused testing. In general: isolate components by restricting them to only be able to access their listed dependencies; divide components by function and abstraction level (eg don’t group by language or technology); and use a standard structure for each component (such as lib, sources, README etc).
Embrace open source. To save on effort, leverage freely-available tools and libraries wherever possible in the infrastructure, rather than implementing custom versions. Where open source is used, contributions back upstream benefit the community and help to align the project with the way it is being deployed. This particularly applies to open source in the ASIC/FPGA domain, where open-source software is unencumbered by licensing restrictions. Often chip projects will be on tight schedules, so careful judgment of the effort-benefit tradeoff must be made.
Performance is important. With the ability to rerun everything from scratch coupled with a multi-chip and monorepository approach, the compute demands can scale quickly so it is crucial that the infrastructure is performant. This can easily become a problem with codebases make extensive use of a scripting language such as Python. Mitigations include writing (or rewriting) parts in a lower-level language such as C++, and setting things up in such a way that this Python and C++ components can interoperate cleanly (eg well-defined boundaries and dependencies).

Flows

This section outlines the high-level flows that a chip-design infrastructure needs to support, meaning (typically) a sequence of steps to achieve some task. This is not meant to be exhaustive, but characteristic of the types of tasks that need to be performed. Flows can be just a single step or can be composed together to create different flows, but always have defined inputs and outputs. I use the term job to mean a particular program or script that is executed, typically corresponding to a step.

Design representation. To read a design into a tool, the design must have a complete representation including tool-agnostic configuration, macro defines, library files and RTL sources. Often, RTL code will need to be generated programatically using templates or other types of code generators. It is also typical that a design will be implemented in a hierarchical fashion, so a configuration step must gather together the required modules and package it into a single representation. As an example, the open-source Bender dependency management tool provides very similar functionality.

Verification representation. For the purposes of simulation and analysis, a verification representation is a variation of a design representation, adding configuration and macro defines, source files for a test bench, monitors, assertions etc, and possibly substituting parts of the design for fast models or block boxes. These verification components will likely live with the corresponding parts of the design and be collected together as they were for the design representation during a configuration step.

Lint checking. RTL source code can be checked for basic coding issues (referred to as linting) by passing it through tools that perform various built-in or custom checks. The input to this task is the specification of a design and the output is a list of warnings to be reviewed. Example open-source tools that can be used for linting are Verilator, Verible, Slang, svlint and Yosys.

CDC and RDC checking. Clock- and reset-domain crossings can be checked automatically with tools that analyse a design, typically with a set of annotations and constraints. The output will be warning messages from the checker that need to be investigated.

Simulation testbench. A simulation test bench requires a representation of the design, a verification environment and test stimulus. Test stimulus is often randomly generated. Coverage (structural or functional) can be collected during simulation and when many test instances are run for a particular test generator or over a larger regression of different test generators, coverage may need to be merged then reported on. Simulation is typically performed on an RTL representation, but can also be performed on gate-level netlists and with and without delay annotations.

Formal property test bench. Analysing and proving formal properties of a design is a complementary technique to standard functional coverage. Inputs to this are a verification representation of the design and a set of assumptions and properties to be checked.

Formal equivalence check. As a design is incrementally transformed between RTL and GDSII, it is essential to perform equivalence checks to prove that each transformation maintains the functional behaviour of the design. Inputs to an equivalence check are two representations, typically called a reference that is the baseline and an implementation to check.

Physical build. All flows up to this point have mainly operated on RTL representations of a design. A physical build flow starts off by transforming RTL into gates using a synthesis tool, then progressively transforming the design into a set of two-dimensional layers. Following synthesis are: scan insertion for DFT, floorplanning (placing ports and macros), placement (placing cells), clock tree synthesis, routing (establishing all required connections using the available routing layers, finishing and checking. See OpenROAD for an example open source physical build flow.

A note on DFT. A central aspect of any chip design is the DFT (device test) strategy. Testability is achieved by adding logic in the form of instruments and connectivity to make the the existing logic controllable and observable. The means by which this is done and the point in the development process is heavily dependent on the design and the tooling used. Typically, DFT logic is inserted using automated tools during the physical build but increasingly it is being added in RTL also using automated tooling - either way adding additional transformation steps to the front- or back-end flows.

A note on physical builds. There are two unique aspects of physical builds that present challenges for the infrastructure presented in this note. The first is that physical EDA tools do not always produce the same output given the same inputs due to the nature of the optimisation algorithms they use. The second is that close to the closure of a design component, manual interventions will be made to address localised issues in the design. The combination of these issues mean that it is not possible to rerun physical builds from scratch and achieve satisfactory results. Therefore, a silicon infrastructure must be able to support frozen data from particular flow stages.

Model

A model for a silicon infrastructure that captures the use cases described is a hierarchical collection of tasks that consume inputs and produce outputs. A task can be dependent on another task by consuming that task’s output and tasks can be composed together in this way into flows. The set of tasks implementing a flow form an acyclic directed graph (DAG) with nodes representing fixed inputs or jobs and edges corresponding to dependencies. The structure of this graph is determined statically (ie without any dependence on runtime data). Execution proceeds by running tasks whose inputs are ready and letting the task run to completion before marking its outputs as available to trigger the execution of more tasks or the termination of the flow.

A task is defined by:

A set of inputs.
A set of outputs.
A set of configuration values.
A set of resource requirements (time, memory, cores).
An action that that operates only on the inputs and must produce all the of the outputs, typically achieved by executing a script or separate tool.
If a task attempts to access an input that is not specified, then an error is raised.

A flow is a hierarchical task and defined by:

A set of inputs.
A set of outputs.
A set of configuration values.
A set of resource requirements.
A action consisting of executing one or more tasks according to their dependencies. Inputs and outputs of the flow must be connected to the sub tasks and similarly for dependencies between sub tasks.
Tasks can be specified using replication with static bounds to create arrays, and conditionality to include or exclude tasks dependent on configuration values.

Configuration values are used to control the behaviour of a flow or task. A flow can propagate configuration into its sub tasks, but it must do so explicitly. Configuration values can be set on the command line. Example use of configuration options is to control features like debug flags, substitution of components of the design for simulation, or the inclusion of tests to run in a regression.

There are a number of similar programming models that support scalable pipelined data processing. In the field of genomics, the Workflow Description Language (WDL) and Common Workflow Language (CWL) are open programming language specifications. Example implementations of WDL are MiniWDL and Cromwell, and of CWL are cwltool and Toil. A Nextflow offers comparable features but is based on a domain-specific language implemented in Groovy. This paper offers a good comparison of WDL, CWL and Nextflow. Also worth mentioning are Snakemake, Apache Airflow, Apache Beam, Luigi and Flyte. I’m still investigating the suitability of these tools for Silicon design workloads.

Implementation details

This section records some important details to consider when implementing a silicon flow, as well as some nice-to-have features.

Environment. A controlled environment execution environment with specific tool versions for reproducability and legacy support. Container technology supports this requirement very will with implementations such as Singularity/Apptainer. A lighter-weight solution is faketree for managing filesystem layout in a dynamic way to meet the constraints of EDA tools.
Access to compute. Dispatching of jobs to compute resources such as a compute cluster requires interaction with a queuing system such as Slurm.
Logging. Extensive logging of job statuses is important for a compute-intensive workload. Straightforward access to these logs for inspection during and after the run should be provided, likely through a web-based dashboard.
Fault tolerance. Flows should be robust to failures. When an task failure does occur, the correct statuses should be propagated up any hierarchy of tasks to provides visibility of the issue. The logging infrastructure should record any progress that was made, providing a starting point for debug or to restart the task. It should be straightforward to rerun part of a job that has failed in a reproducible way.
Storage. The use of a shared filesystem such as NFS is typical in silicon EDA flows, however it creates a single point of failure and has limited scalability. An alternative shared storage system is object storage such as MinIO.
Releasing. It should be simple to release data from the repository into immutable storage that can then be referenced as a dependency.
Periodic jobs. A mechanism for running periodic jobs is required to implement a continuous-integration (CI) and/or continuous-delivery (CD). Jenkins, GitHub Actions or GitLab CI/CD are all directly applicable here.

Summary

This note outlines the principles and requirements for a modern software infrastructure to build chips. This is very different to conventional software engineering due to fundamental differences in processes, and is likely to be quite different from the typical methodologies used in conventional silicon design. Based on some simple use cases, a model is proposed that abstracts the details of resource allocation and data movement by providing tasks with inputs and outputs as primitives. Surprisingly, there already exist a family of tools from data science that employ a very similar model.

Acknowledgments

The motivation for writing this note came from recent discussions on building a from-scratch silicon infrastructure with James Pallister and Peter Birch. This note is a synthesis of ideas from those conversations.

Related projects

Gator, a framework for running a hierarchy of jobs and aggregating logs, metrics, resource utilisation, and artefacts.
Blockwork, is a build system and orchestrator for silicon design.
Blade is a tool for autogenerating modules, interconnects and register definitions from an YAML schema.
Siliconcompiler is a modular build system for silicon hardware.
Berkeley Chipyard is an agile framework for hardware design, using Chisel for RTL specification.
Berkeley Hammer is a physical design framework.
Pulp Platform Bender is a dependency management tool for hardware design projects.
Rich Porter’s series on digital verification and source code for the project.
Melding hardware and software: a story in the making, a position piece by Enfabrica on their approach to ASIC design.

Building a Python processor

2023-06-27T00:00:00+02:00

I have recently spent some time thinking about how hardware can be architected and optimised to better support high-level dynamic languages such as Python and JavaScript. There appears to be a significant gap between the way processors and memory systems are built, which is to prioritise performance, and the characteristics of dynamic-language workloads, which prioritise ease of use. I argue that dynamic languages are setting the direction of travel in the way we use computers and this gap presents a huge opportunity for new hardware innovation.

Dymamic languages
Python and AI
Python performance
Hardware impacts on Python performance
Hardware support for Python
Summary
Acknowledgements
References
Related links

Dynamic languages

According to Stack Overflow’s 2023 developer survey, JavaScript has now been the most commonly-used language for the last 11 years and Python has become the third most commonly-used language amongst all developers and the first amongst non-professional developers and those learning to code. Nestled amongst the most common languages are also TypeScript (a variant of JavaScript), C#, PHP, Lua and Ruby. Applications of these languages are wide ranging and varied, across all aspects of industry, science, business and government.

Dynamic languages have become popular because they are easy to use when compared with their statically-compiled counterparts. There are many aspects of the languages that contribute to this, such as dynamic typing, high-level features, no requirement for a compilation step to produce an executable format (leading to rapid iteration times), portability between platforms, powerful debugging due to runtime introspection, integration with editors and IDEs and natural support for metaprogramming. Ease of use improves programmer productivity and widens participation to non-professionals and those without expertise in low-level programming. These benefits are also a critical factor in the development of new application areas and technologies such as AI, where research and practice moves rapidly and participation across academia and industry is broad.

The cost of these benefits when compared with compiled languages is a runtime performance overhead due to the additional work the language implementation must do, for example to resolve names and types. The overhead depends on the workload, but is often in the realms of tens to hundreds of times slower. The evidence in the use of dynamic languages however is proof that this performance overhead is acceptable price to pay for their benefits. Having said this, there are ongoing substantial efforts to close the gap by optimising the language implementations and compilation strategies. As far as I can see, this effort has not extended to optimisation of the underlying hardware.

Python and AI

In this remainder of this note I will focus on Python and its application to AI, a domain that is significant enough to cause the development of new computer hardware and rapid adoption of new process, integration and packaging technologies.

Python has established itself as the main programming language in AI, and this is due to ease-of-use considerations. Programming in AI is typically done using frameworks, meaning a library that provides facilities to express a computation that is compiled and run within the program, rather than expressing the computation directly in the programming language. TensorFlow and PyTorch are two pre-eminent examples, but with PyTorch having taken the lead in becoming the most widely-used framework. TensorFlow established itself early with support from Google, but it has lost its dominance to PyTorch because PyTorch was easier to use and more flexible. It was thus more widely adopted and more quickly applied to new application areas.

PyTorch’s first design principle is usability over performance which clearly indicates ease of use is the driving force in AI model development and deployment. PyTorch’s third design principle is Python first meaning that working in Python natively (using the features of the language) provides the best experience and results for users, rather than deferring to optimised compiled-language libraries. PyTorch’s primacy and clear prioritisation of ease of use indicates the direction of travel: that Python will continue to become a first-class citizen in AI programming and so its performance will be increasingly under scrutiny.

Since around 2012, AI has undergone a renaissance by scaling the performance of deep neural networks with GPUs. Looking forward, there are many ways in which AI models are expected to develop, requiring programming techniques and hardware to develop to provide these capabilities too:

Model size is growing and will continue to grow. Although GPT-3 has 175 bn parameters, there are an estimated 86 bn neurons in the human brain and an order-of 100 tn parameters (albeit encoded using analog mechanisms). It is likely that sparsity will increasingly be required to train and access these models efficiently.
Conditional sparsity through conditionality in the structure of a network, eg routing of activity based on the data. In a dense network, every input interacts with every weight, but our brains don’t fire all neurons in response to every stimulus, and unconditional sparsity that is not dependent on the input, such as from pruning of connections.
Symbolic representations. Symbolic AI programs are based on creating explicit structures and behaviour rules. This approach was the dominant paradigm in AI from the 1950s up to the mid 1990s. It is however considered a complementary technique to deep learning, possibly reflecting the fast and slow parts of the human cognitive system. Examples are decision trees and PAC learning.
Composition. New models will be created from parts such as whole sub models, or other reusable components. This is the way any complex system is constructed, including our brains.

Python performance

Broadly, the performance of Python programs can be improved at three levels:

Optimising the application.
Optimising the language implementation.
Optimising the hardware.

The work in Quantitative Overhead Analysis for Python [1] provides a detailed analysis of overheads in CPython. ¹ The different types of overhead are described in the following table, which is taken from the paper.

Sources of performance overhead in Python, from [1].
Group	Overhead category	Description
Additional language features
	Error check	Check for overflow, out-of-bounds and other errors
	Garbage collection	Automatically freeing unused memory
	Rich flow control	Support for more condition cases and control structures
Dynamic language features
	Type check	Checking variable type to determine operation
	Boxing/unboxing	Wrapping or unwrapping integer or float types
	Name resolution	Looking up variable in a map
	Function resolution	Dereferencing function pointers to perform an operation
	Function setup/cleanup	Setting up for a function call and cleaning up when finished
Interpreter operations
	Dispatch	Reading and decoding bytecode instruction
	Stack	Reading, writing, and managing VM stack
	Const load	Reading constants
	Object allocation	Inefficient deallocation followed by allocation of objects
	Reg transfer	Calculating address of VM storage
	C function call	Following the C calling convention in the interpreter

The following charts (also taken from the paper) show the proportions are given as a percentage of total execution time, based on the measured execution of a set of benchmarks. On average, 64.9% of overall execution time is overhead, and the remaining 35.1% is used for the execution of the program. Of the language features, name resolution and function setup/cleanup dominate. Of the interpreter operations, dispatch (reading bytecode and executing the correct operations) and C function calls dominate.

Python overheads measured in various benchmarks, from [1].

There has been significant work on tackling (2) the language implementation. Prominent examples include: PyPy, an alternative optimised implementation written in Python that includes a just in-time (JIT) compiler to dynamically optimise common code paths; Cinder is Meta’s internal performance-optimised version of CPython that includes various performance optimisations and a per-method JIT; Cython translates Python to C/C++ for static compilation and execution in the CPython runtime environment; Nuitka is similar to Cython, as a compiler from Python to C, using the CPython interpreter as a library; And not forgetting CPython itself has an active project led by Microsoft and Guido van Rossum called Faster CPython to explore performance optimisations. Approximately, these approaches achieve speedups of up to an order of magnitude when compared to the standard CPython implementation.

Where the previous examples optimise Python as a general-purpose language, some approaches such as Codon, Numba and Triton compile subsets of Python into machine code for host or accelerator devices, eliminating the runtime overhead altogether. These approaches can achieve speedups of the order of 100 times for serial execution. They focus however on accelerating numerical computations and therefore sidestep the difficulties of statically-compiling dynamic features such as naming, large integers and data structures, which are much more challenging.

Within the scope of (1) optimising the application, a significant issue preventing the use of parallelism is Python’s Global Interpreter Lock (GIL). This lock allows only one thread to execute the interpreter at once, which was done originally to make the counting of object references simpler. It is possible to work around the constraints imposed by the GIL, such as with the multiprocessing module but this makes it difficult to express different types of parallelism and creates an ease-of-use problem. A PEP submitted by a PyTorch developer makes the case for removing the GIL, outlining motivating examples in scientific and numerical computing, and tasks using Python for coordination and communication. A decision on adoption of this PEP is yet to be made but a reference implementation is available.

There are various sources of overhead in the execution of a Python program that can contribute to orders-of-magnitude slower runtime compared to a compiled program. Strategies to reduce this overhead are in optimising the sources of overhead directly by improving compilation strategies, improving runtime strategies (such as caching of accesses or performing JIT compilation to machine code of frequent code paths), statically compiling Python code to C code including inline calls to the interpreter, and, for restricted subsets of Python, statically compiling Python code to machine code without the interpreter. These approaches are all within the software domain, so it is interesting to consider in what ways computer hardware could be optimised to further reduce the runtime overheads in Python programs.

Hardware impacts on Python performance

The main findings from the microarchitecture investigation in [1] summarised below provide a useful basis for understanding how Python is limited by current computer hardware. The study is based on a range of benchmarks run with CPython and PyPy with and without JIT.

ILP. Both CPython and PyPy exhibit low instruction-level parallelism. This suggests that choosing a deeply-pipelined out-of-order core may not provide good tradeoff between silicon area and performance. A simpler, in-order core may instead be a better choice, particularly when building a parallel processor with many cores.
Working memory. Across all the benchmarks, large caches do not provide a performance benefit, implying that working sets tend to be relatively small.
Nursery sizing. A critical factor related to working memory is an area used for the allocation for short-term objects called a nursery. When the nursery does not fit in cache, performance is impacted due to cache thrashing. However, there are two things to consider: reducing the nursery size will increase garbage-collection overheads and the optimal nursery size is dependent on the application.
JIT. When JIT compilation is used, the memory system is put under more pressure, so although the number of instructions executed reduces, the latency of memory operations increases due to cache line misses. This implies the working memory increases and so accordingly the overhead of garbage collection also increases.

It is clear from these findings that optimising the memory system will yield a more significant performance improvement than optimising the processor microarchitecture and instruction set design (as is typically the focus of new processor designs). Orthogonal to optimisations in the memory system, providing more execution parallelism at the process level is the only other way to significantly scale performance. This gives us the basis for a new Python processor.

Hardware support for Python

This section presents some rough ideas on what new computer hardware might look like that optimises the execution of Python (or indeed other dynamic languages).

System architecture

The most straightforward way to deploy a new processor chip is as an accelerator to a conventional host processor connected via PCIe. The host processor can then offload parts or all of the Python workload to the accelerator for improved performance. The following diagrams show two ways that this could work: one where the host runs the Python interpreter and offloads parts of the Python program (similar to the way Eager Mode works in PyTorch and TensorFlow); the other where the accelerator runs the Python interpreter and communicates to the host via a standard set of system calls. The first scenario means that execution can fall back onto the host if the Python code was not supported by the accelerator, thereby allowing the design of the accelerator to be simpler. However, managing the communication of Python objects over this boundary is complicated and potentially a significant overhead. In the second scenario, the whole Python program is executed by the interpreter running on the accelerator. This simplifies the interface between the two devices, which would only need to provide basic system calls to the interpreter.

Fine-grained offload

Coarse-grained offload

At a system level, an accelerator device for Python might be integrated between the host processor and other accelerators (typically GPUs in data-centre-type deployments) since Python will be responsible for coordinating offload of computations. Access to external memory can either be to DRAM via the host or on DRAM integrated with the device. The latter has the benefit of being able to supply lower latency and higher bandwidth to the memories.

Core architecture

At the core level, it makes a lot of sense to use RISC-V as the base architecture because it is a general-purpose ISA that is open and easily extensible. As previously noted, the RISC-V microarchitecture can be kept simple because interpreting Python is not heavily dependent on ILP. The complexity of the microarchitecture depends on the best tradeoff between sequential and parallel performance, which in turn depends on the workload. AI for example will be weighted towards highly-parallel execution, so is better suited to a large number of simple processor cores. Extensions to the core can be added to provide optimised support for specific operations (eg floating-point arithmetic and for matrix multiplication), support for concurrency (threading, synchronisation, communication etc) or control over the memory hierarchy.

Memory system

One way to improve the way memory is managed is to bring some level of control of the cache to the processor. In the following diagram, A RISC-V core has extensions that allows it to control a ‘smart cache’. Such a system could enable aggressive caching of computations that are frequently recomputed, such as in the processes of name and function resolution, or from calling a function with the same arguments, which account for a substantial portion of the language overhead. A motivating example is caching of the C strlen function that is used frequently by the Python interpreter in name resolution. A difficulty in caching this function entirely in software is that a full string comparison is required to determine whether to invalidate the cache or not, and this is roughly as expensive as strlen. A hardware caching scheme could be implemented more simply by snooping memory writes and invalidating the cache entry if any part of the string has changed. To support this, hardware extensions would be required to place items in the cache, retrieve items in the cache, monitor ranges of memory and invalidate items in monitored ranges.

Another memory-system optimisation is to provide garbage collection (GC) as a hardware-managed function. GC is a technique that has been studied for decades, including in hardware: it was first introduced in Lisp in the 1950s and appeared as a hardware extension in the 1981 Intel iAPX 432 (see [4] for a literature review of hardware GC techniques and implementations). Surprisingly, hardware GC has never caught on and this is certainly related to the challenges of a performant solution requiring integration across many levels of abstraction: microarchitecture, architecture, tooling, operating systems and languages. However, it seems that this precedent should be challenged given that GC is central to the way dynamic languages work.

Scaling the number of cores

Building a system with multiple processing cores can be done in a conventional way by sharing access to higher levels of cache and adding a coherency mechanism for lower-level private caches, but this does not scale well past a few tens or hundreds of cores due to the overheads of maintaining coherency. A different and more radical approach is to use a distributed-memory architecture where each core has a private memory and communication between cores or to external DRAM is performed explicitly using messages. The major benefit of such an architecture is that is scalable to large numbers of cores, providing more performance from parallelism, and that processor-memory pairs can flexibly be used as units of memory or processing dependent on the application. This approach generalises the concept of a programmable cache hierarchy by using processor-memory pairs as units of memory with the processor providing access logic and building arbitrary caching schemes in software, dependent on the characteristics of the workload. I have previously written about this idea in my work on emulating large memories. Alternatively, processor-memory pairs can be turned over to processing and used to execute parts of an application in parallel, a great example of which would be running one or several JIT compiler processes concurrently with the application.

The following diagram sketches how such a machine might be built. The main building blocks are a processor-memory tile and a router. The tile includes communication facilities, allowing it to communicate to all other tiles in the system and to off-chip communication interfaces via routers. The arrangement of routers and tiles is flexible but the routers have enough links that high-dimensional topologies can be created to provide communication with bounded latency and throughput, which is essential for a general-purpose machine. The operation of the communications fabric could be dynamic allocated with packet switching, or statically allocated with circuit switching. Special packet types can be used for accessing external memory or other off-chip IO, or for implementing shared-memory operations such as direct access to remote tile memories. Collective operations such as scatters and gathers are likely to be frequently used, so could be optimised with supporting hardware in the tile and routers. These are the essential ingredients of a general-purpose fine-grained parallel machine. I have previously outlined a similar kind of machine in my PhD thesis, and I intend to post a note with a revised and fuller description at some point soon.

Summary

This note makes the argument that ease of use the critical factor in the development of new application areas and the adoption of new computer hardware. Ease of use has in many regards won as the most important factor in software and programming, but new computer hardware prioritises performance. Closing this gap would mean that rapidly-developing application areas such as AI would benefit by moving the boundary away from optimised low-level libraries, making fuller use of languages such as Python. For computer designers, there is a huge opportunity for new architectural innovations that support a radically different workload from conventional low-level compiled languages. Contrary to conventional wisdom, hardware is easier to innovate rapidly and it is software that bears the weight of legacy.

Acknowledgements

The hardware ideas in this note were developed in conversations with James Pallister. Closely related to some of the ideas explored is a new UK startup VyperCore co-founded by Ed Nutting who are building a RISC-V-based processor that includes facilities for hardware memory allocation and GC for performance and safety.

References

Mohamed Ismail and G. Edward Suh, Quantitative Overhead Analysis for Python, 2018 IEEE International Symposium on Workload Characterization (IISWC). [IEEE, PDF]
Nagy Mostafa, Chandra Krintz, Calin Cascaval, David Edelsohn, Priya Nagpurkar, Peng Wu, Understanding the Potential of Interpreter-based Optimizations for Python. UCSB Technical Report #2010-14 August, 2010. [PDF]
Gergö Barany, Python Interpreter Performance Deconstructed, Proceedings of the Workshop on Dynamic Languages and Applications, June 2014. [ACM, PDF]
Andres Amaya Garcia, Integrated hardware garbage collection for real-time embedded systems, PhD thesis, University of Bristol 2021. [University of Bristol, PDF]

Cornish Unit House retrofit insulation

2022-12-29T00:00:00+01:00

I live in a Cornish Unit house (Type 1) and have recently had a heat pump installed to replace an ageing gas boiler. Having lived in the house for several years, I was well aware of significant thermal issues, particularly upstairs, due to the house being very cold in the winter and very hot in the summer. Temperature changes in the house were noticable with cold returning quickly after the heating being on. A non-invasive survey of the building last winter showed up various minor issues but didn’t pinpoint a particular issue. Further investigation into the upstairs walls revealed there to be virtually no insulation, only ~50 mm of glass wool insulation hanging behind the plasterboard, as well as direct routes into the floor cavity (along the joists) from the eaves. The effective result is a plasterboard tent upstairs with cold air circulating just behind the walls, and to an extent the floor/ceiling. In contrast, the ground floor walls are a more modern cavity construction from them being replaced in the 1980s, and they have, at some point subsequently, been filled with polystyrene insulation beads.

Given that the upper part of the house is a timber construction, the walls have voids between the timbers that new insulation can be fitted into (directly replacing the glass wool). This seemed like a great opportunity given that it would be much more difficult to add significant insulation were the walls a typical masonry construction, since insulation could only be added externally (expensive) or internally (limited depth). Insulation is often added to Cornish Unit houses when they are retiled since all of the timbers are exposed. However, in my case since the roof is fine, installing the insulation from internal access is simpler and much cheaper, albeit a more messy job. The detail below shows the planned modification: adding 80 mm of PIR insulation board between the joists, and 25 mm insulated plasterboard on top with a sandwiched breathable vapour membrane, providing 105 mm of insulation and an expected U value of 0.25 W/m$^2$K, in line with the new Part L Building Regulations. Note that a short section of insulation is added at the floor level to make the insulation continuous from the brick wall cavity up to the loft.

The full description as submitted to Building Control is as follows. They subsequently inspected and signed off the work.

Upgrading external wall insulation within timber framed wall at first floor level, which forms lower section of tiled mansard roof on a Cornish Unit Type 1 house. Hanging tiles with breather membrane to remain as existing. Replacing existing 80mm mineral wool insulation with 80mm rigid PIR insulation board between studs within the timber frame. Adding a vapour control layer and dry lining the internal face with 37.5mm insulated plasterboard, plaster and finish.

Proposed wall build up:

Roof tiles hanging (to remain as existing).
Breather membrane (to remain as existing).
Ventilated cavity (30mm at high level - 335mm at low level).
80mm PIR insulation board between studs (Celotex GA4000 80mm).
Combined vapour control & air tightness layer, taped (Procheck Adapt VCL with integral tape).
37.5mm insulated plasterboard (Celotex PL4025 25 + 12.5mm).
Internal finish (plaster and paint).

Method of installation: Renovation to be completed from inside the property by removing plasterboard and existing mineral wool insulation internally to expose the frame. Mineral wool insulation to be replaced by 80mm PIR insulation boards between timber studs. Breather membrane and roof tiles to remain as existing. Timber battens to be installed at high level to form a 30mm ventilated cavity. Continuous vapour control and air tightness layer to be added on the internal face of the PIR insulation board and taped. 37.5mm layer of insulated plasterboard to be installed onto the VCL. Plaster and paint to finish.

Notes: Insulation at lower eaves to be made continuous with existing cavity wall bead insulation to ground floor masonry wall. Similarly, insulation to be made continuous at ceiling junction with existing mineral wool insulation between ceiling joists in roof void, where possible. Estimated U-value of proposed build-up = 0.25 W/m$^2$K (source: Saint Gobain UK U-value calculator).

I investigated alternatives to PIR board, such as insulation board constructed from natural fibres, but these generally seemed twice as expensive per square metre and offered approximately half the U value. Given that wall depth was critical, these weren’t good solutions.

Materials pile: 80 mm PIR top and 37.5 mm insulated plasterboard bottom. A total of 13 80 mm sheets and 16 37.5 mm sheets were used.

Section detail showing additional insulation and it’s integration with the existing structure and insulation.

Bedroom 1

Roofing baton is added at the top of the wall to ensure there is an air gap behind the insulation board and at the bottom of the wall to prevent the insulation from pushing into the cavity. Unfortunately there were few consistent dimensions between the timbers so all boards had to be cut to measure for each space.

An awkward section was above the windows where the was a steel lintel as well as a void for the section of roof that protrudes over the window. Liberal amounts of expanding foam were used to fill gaps as well as possible.

Bedroom 2

PIR sections cut to sit on top of the ground floor brick wall, fitting between the floor joists.

Bedroom 3

Hallway

Insulation providing continuity between the brick cavity and the new wall insulation, as well as plugging the gap from the eaves into the floor.

Performance

The work was completed in the summer, but the results became evident during a cold snap in December. Purely from a comfort point of view, the upstairs went from being the colder part of the house, to the warmer part. I also used a thermal imaging camera to inspect the insulation. The camera confirmed that the new insulated sections provide a consistent warm temperature as expected, with no unexpected temperature changes within these ares. Some minor issues highlighted were at the intersections with other surfaces and areas.

The two images below highlight a minor cold bridge effect from the plasterboard fixing.

The image on the left below shows a cold corner section, which was due to cold ingress on the next door room before that room had been upgraded. The image on the right below shows a piece of missing insulation (unrelated to the work!).

Finally, these two images show intersection of the new insulation with masonry walls and there being an ingress of cold air, although only a minor temperature difference of ~1-2 degrees.

Summary

Upgrading the insulation within the upper timber frame of my Cornish Unit house was relatively straightforward and a cheap way to substantially improve the thermal performance of the building. The effects of this work are significant, making the house a much more comfortable and stable environment, and a great deal more suitable environment to heat using an air-source heat pump.

From logic gates to a programming language using the Hex architecture

2022-11-18T00:00:00+01:00

This note walks through a hardware implementation of a simple processor and complete compiler for a programming language targeted at it. The processor architecture is designed to as simple as possible but provide a sensible target for the compilation of complex programs using simple strategies. The implementation of the processor and its supporting tooling is small and self contained so to be understandable and easily extendable. Besides being an interesting side project, my motivation was to create a complete example as a point of reference to explain how programming languages work and correspond to the underlying hardware of a computer processor, or to provide a useful reference for compilers and simulators, a starting point for another project or just a curiosity in itself.

First, to provide some background. The project is based on the Hex processor architecture that was designed by David May as a vehicle for teaching about how computers work at the University of Bristol, whilst being flexible enough to execute substantial programs and easily extensible. David provided a simulator written in C and a bootstrapping compiler written in an accompanying simple imperative programming language called X. The design of Hex draws on the Transputer architecture and the earlier Simple 42, particularly with the use of short instruction encodings, a prefixing mechanism for creating larger immediates and A, B and C registers for expression evaluation. These kind of architectural features made the silicon implementation of the Simple 42 and Transputers small enough to fit on a single chip in the technology of the day. X draws on the basic sequential features of the occam programming language but it not dissimilar to a small subset of C, for example. I include some more historical details at the end.

In my implementation, I have created a simple C++ toolchain with a simulator, Hex assembler and X language compiler, and a Verilog implementation of Hex. Before describing them, the next two sections introduce Hex and X.

The Hex architecture
The X language
Hex processor integrated circuit
Hex tooling
A historical note
Summary
Similar projects
Further reading

The Hex architecture

The Hex architecture is described in detail in a separate PDF, but I will give a brief summary here and focus on several important aspects for reference. Hex has four registers: program counter pc, operand register oreg and the A and B registers areg and breg used for expression evaluation. The architecture is agnostic of a particular word size, but it has to be a minimum of a byte and multiples of a byte. In the included implementation the word size is 4 bytes. Hex has sixteen instructions (hence its name!) that are summarised in the following table. Each instruction has a 4-bit opcode and a 4-bit immediate. The immediate value can be extended using the prefix instructions to form a wider value in the oreg, adding four bits per instruction. Operations beyond the 16 available encodings are made accessible by the OPR instruction that encodes the operation type with its immediate. The instructions are grouped into memory access with absolute or relative addressing modes, loading of constants, branching, inter-register operations and supervisor calls.

Opcode	Behaviour	Description
`LDAM`	`areg := mem[oreg]`	Load from memory with an absolute address into areg
`LDBM`	`breg := mem[oreg]`	Load from memory with an absolute address into breg
`STAM`	`mem[oreg] := areg`	Store to absolute address from areg
`LDAC`	`areg := oreg`	Load constant into areg
`LDBC`	`breg := oreg`	Load constant into breg
`LDAP`	`areg := pc + oreg`	Load program counter-relative address into areg
`LDAI`	`areg := mem[areg + oreg]`	Load from memory with base and offset into areg
`LDBI`	`breg := mem[breg + oreg]`	Load from memory with base and offset into breg
`STAI`	`mem[breg + oreg] := areg`	Store to memory with base and offset from areg
`BR`	`pc := pc + oreg`	Branch relative
`BRZ`	`if areg = 0: pc := pc + oreg`	Conditional branch relative on areg being zero
`BRN`	`if areg < 0: pc := pc + oreg`	Conditional branch relative on areg being negative
`BRB`	`pc := breg`	Absolute branch
`PFIX`	`oreg := oreg << 4`	Positive prefix
`NFIX`	`oreg = 0xFFFFFF00 \| oreg << 4`	Negative prefix
`OPR`	-	Inter-register operation
`ADD`	`areg := areg + breg`	Add areg and breg and set areg to the result
`SUB`	`areg := areg - breg`	Subtract areg and breg and set areg to the result
`SVC`	-	Supervisor call

Prefixing

Prefixing using the PFIX and NFIX operations generates operand values in oreg larger than the 4-bit instruction immediate. For example, the following instructions generate the value 16 in oreg and use LDAC to assign it to areg :

PFIX 1  # oreg = oreg (1) << 4 (0x000010)
LDAC 0  # areg = oreg 16

Prefixes can be chained to extend the operand range, for example, generating the value 496 requires two positive prefixes before a load constant instruction:

PFIX 1  # oreg = oreg (1) << 4 (0x000010)
PFIX 15 # oreg = oreg (31) << 4 (0x0001f0)
LDAC 0  # areg = oreg 496

Negative values always require a negative prefix to fill the top most oreg bits with ones, so to load the value -1 into oreg then areg:

NFIX 15 # oreg = 0xFFFFFF00 | oreg (15) << 4 (0xfffffff0)
LDAC 15 # areg = oreg 4294967295

And to load -512, a positive prefix is required to scale the negative value:

NFIX 14 # oreg = 0xFFFFFF00 | oreg (14) << 4 (0xffffffe0)
PFIX 0  # oreg = oreg (4294967264) << 4 (0xfffffe00)
LDAC 0  # areg = oreg 4294966784

Inter-register operations

The inter-register operations use the OPR opcode and consist only of addition and subtraction. The group can be extended by implementing additional immediate opcodes to add new operations to the processor (such as other arithmetic and bitwise operations). The 4-bit immediate supports up to 16 inter-register operations without the need for prefixing, but many more with prefixing and the according overhead to form larger immediates. The following instruction sequence adds two numbers from fixed locations in memory, with the result written to areg:

LDAM 1  # areg = mem[oreg (0x000001)] (7)
LDBM 2  # breg = mem[oreg (0x000002)] (9)
OPR  1  # ADD areg = areg (7) + breg (9) (16)

A special inter-register operation is a supervisor call that transfers control to the system to complete an action such as read or write from a file, or to halt the program. The supervisor call type is encoded in the oreg and arguments and return values specific to the call type are passed and returned on the stack using the standard calling convention. An example code sequence to invoke the exit supervisor call is:

LDAC 0  # Set areg to 0, the exit opcode value.
LDBM 1  # Load the stack pointer in breg.
STAI 2  # Store areg into stack offset two as a parameter.
LDAC 0  # Load the exit opcode.
OPR SVC # Perform the supervisor call

With the following execution trace, noting that the simulator implements the system call directly rather than being handled by a kernel routine:

LDAC 0  # areg = oreg 0
LDBM 1  # breg = mem[oreg (0x000001)] (16383)
STAI 2  # mem[breg (16383) + oreg (2) = 0x004001] = areg (0)
LDAC 0  # areg = oreg 0
OPR  3  # exit 0

Load-store operations

There are two variants of load and store instructions: using absolute addresses and addresses relative to a base address. Absolute addressing (LDAM, LDBM and STAM) is intended to access objects in memory that are allocated at offsets that are fixed with respect to a program, such as constant values and global variables. Relative-addressing (LDAI, LDBI and STAI) is typically used to access objects that are relative to a dynamic position, such as the stack pointer, or index into an array. The particular variants of load/store instructions is influenced by their targeting from a compiler. Having pairs of load instructions that can write to areg or breg (such as LDAM and LDBM) gives flexibility when generating operands for binary operations, whereas having only single variants of stores (STAM and STAI) fits most cases where expression results generated into areg need to be written to memory.

Branching

For branching, a relative branch is provided with BR, which can be used, for example, to reach a label location. Conditional branch versions BRZ and BRN are used to implement logical binary operations (less than, equal etc) and BRB is an absolute branch that is used, for example, to return to a calling function using an address retrieved from memory (see example in next section).

Address generation

A special constant-loading instruction LDAP is used to generate bytewise program addresses, relative to the program counter, such as for branch targets. The following instruction sequence performs a call to foo but first loads the return (link) address using LDAP to use with BR. The callee foo returns to the caller using BRB.

FUNC foo
LDBM 1
STAI 0 # Save caller address
...
LDBI 0 # Restore caller address
OPR 0  # Return to caller

PROC main
...
LDAP lab2
BR foo
lab2

These instructions have the following execution trace:

main+32  LDAP 2   # areg = pc (60) + oreg (2) 62
main+33  NFIX 13  # oreg = 0xFFFFFF00 | oreg (13) << 4 (0xffffffd0)
main+34  BR   1   # pc = pc + oreg (4294967249) (0x00000f)
foo+0    LDBM 1   # breg = mem[oreg (0x000001)] (199994)
foo+1    STAI 0   # mem[breg (199994) + oreg (0) = 0x030d3a] = areg (62)
...
foo+10   LDBI 0   # breg = mem[breg (199994) + oreg (0) = 0x030d3a] (62)
foo+11   OPR  0   # BRB pc = breg (0x00003e)
main+35  ...

The X language

The X language is defined in a separate PDF. X is simple enough that it can be compiled using simple techniques to the Hex architecture, whilst providing enough flexibility to express complex programs such as its own compiler (more on that later). X is an imperative language and has features for procedure calling, composition of statements, looping and conditional statements, expressions including function calls, and representation of memory with variables and arrays. To give an indicative example of X programming, the following program implements Bubblesort to sort an array of four elements:

val length = 4;
var data[length];

proc sort(array a, val n) is
  var i;
  var j;
  var tmp;
{ i := 0;
  while i < n do
  { j := 0
  ; while j < n - i - 1 do
    { if a[j] > a[j+1] then
      { tmp := a[j]
      ; a[j] := a[j+1]
      ; a[j+1] := tmp
      }
      else skip
    ; j := j + 1
    }
  ; i := i + 1
  }
}

proc main() is
{ data[0] := 3
; data[1] := 2
; data[2] := 1
; data[3] := 0
; sort(data, length)
}

Limitations of X to note that simplify its implementation are:

Arrays are limited to one dimension.
No operator precedence to avoid built-in rules so precedence must be indicated explicitly with bracketing (apart from associative operators).
Conditional statements (beginning if) must always have an else part to simplify parsing.
Variables can only be passed by value into procedures.
There is no block scoping so variable and array declarations can only be made at global and procedure scopes. Similarly, nested definitions of procedures are not permitted.

Other noteworthy features of X are:

There are two types of procedure: processes (using the proc keyword) that execute a sequence of steps with possible side effects, and functions (using the funckeyword ) that have no side effects and return a value.
Names in a program are introduced as definitions of processes or functions, declarations that represent memory locations, and abbreviations that introduce alternative names for expressions, arrays, processes and functions.
The scoping and abbreviation rules are defined so that that actual parameters act as abbreviations of the supplied formals. This allows processes and functions to be compiled by either as closed subroutines or by substitution of the body at the call site, either as a source code transformation or compiler optimisation. For example, given the definition proc foo(val a, array b) is B, it can be called as a subroutine: foo(x, y) or substituted: val a = x; array b = y; B providing the names are unique in the procedure.
A valof element allows processes to be called from expressions to generate values, however it is not implemented in xhexb or xcmp.

Hex processor integrated circuit

A hardware implementation of the Hex processor is written in System Verilog, processor.sv, in just 150 lines. This implementation is single cycle in that all elements of instruction execution (ie instruction fetch from memory, decode, instruction memory access and state writeback) are completed in that time. A separate memory module, memory.sv implements a single-cycle random-access memory with two ports: one for instruction fetch and the other for data access so that they can occur simultaneously in the same cycle. Note that because memory access time increases with the memory capacity, a implementation of Hex accessing a large memory (ie more than a few thousand bytes) would add pipelining to hide the latency to memory. Some degree of pipelining is standard in processor implementations. The hardware design is simulated using Verilator, with C++ testbench driver code in hextb.cpp.

Using OpenROAD, an open-source tool chain for performing synthesis, optimisation and physical layout of digital circuits, we can compile Hex into an integrated circuit layout in order that it could be manufactured into a silicon device. OpenROAD uses the SkyWater Process Design Kit (PDK), for creating designs in 130 nm process technology, which was a technology first commercialised in 2001. The PDK is a collection of analog and digital cell libraries, design rules and tooling. Since OpenROAD uses Yosys for synthesis, and it doesn’t support particular SystemVerilog features, I used sv2v to convert the implementation to plain Verilog 2005 (see processor.v).

The physical design is based on an OpenROAD default flow, which takes a few minutes to be compiled from the source RTL. The final design has the following characteristics:

A die size of ~280x280 microns.
A total of 9,719 standard cells.
A cell area of 16,706 square microns at 25% utilisation.
A clock speed of 229 MHz.
Total switching power of 4.12 mW.

The OpenROAD GUI provides many ways to visualise and explore the design. The following images are some examples of the different views.

Floorplan showing the standard cells only, with the two lowest metal layers (logic and M1).

A zoomed view showing standard cells with logic and M1 layers only.

A view showing all nets constituting the clock tree.

A heatmap view representing routing congestion.

A visualisation of the worst setup path in the design, including the nets and cells on the path as well as the paths for the launch and capture clocks.

The same visualisation for the worst (least slack) hold path in the design.

Hex tooling

There are three tools provided in the Hex toolchain: a Hex instruction set simulator hexsim, a Hex assembler hexasm and an X compiler xcmp. Instructions on how to build the tools are included in the documentation. The implementation is provided in a small number of source files (with only one external dependency on boost::format):

General Hex definitions are provided in hex.hpp and hex.cpp.
The Hex simulator is implemented in the headers hexsim.hpp and hexsimio.hpp. (Note that listings for a complete simulator in C are given in the Hex definition (PDF).)
The Hex assembler is implemented in the header hexasm.hpp.
The X compiler is implemented in the header xcmp.hpp.
Driver code for the respective command-line tools hexsim, hexasm and xcmp is implemented in hexsim.cpp, hexasm.cpp and xcmp.cpp.

A simple example

Taking a most basic example of an assembly program that simply exits:

➜ cat tests/asm/exit0.S
BR start
DATA 16383 # sp
start
LDAC 0 # areg <- 0
LDBM 1 # breg <- sp
STAI 2 # sp[2] <- areg
LDAC 0
OPR SVC

The assembler can display the program layout in memory and computed symbol values:

➜ hexasm tests/asm/exit0.S --instrs
00000000 BR start (7)         (1 bytes)
0x000004 DATA 16383           (4 bytes)
0x000008 start                (0 bytes)
0x000008 LDAC 0               (1 bytes)
0x000009 LDBM 1               (1 bytes)
0x00000a STAI 2               (1 bytes)
0x00000b LDAC 0               (1 bytes)
0x00000c OPR SVC              (1 bytes)
00000000 PADDING 3            (3 bytes)
13 bytes

And create a 13-byte executable binary:

➜ hexasm tests/asm/exit0.S

This binary can then be simulated with tracing to show what’s going on (the first column is the cycle count and the second is the pc value):

➜ hexsim a.out -t
0      0      BR   7  pc = pc + oreg (7) (0x000008)
1      8      LDAC 0  areg = oreg 0
2      9      LDBM 1  breg = mem[oreg (0x000001)] (16383)
3      10     STAI 2  mem[breg (16383) + oreg (2) = 0x004001] = areg (0)
4      11     LDAC 0  areg = oreg 0
5      12     OPR  3  exit 0

The X compiler can be used to produce more complex Hex programs. Starting with a similar most basic program written in X:

proc main() is skip

This null program is compiled into Hex assembly, where the entry code calls main then exits, and main does nothing (apart from saving and restoring the link location):

➜ xcmp tests/x/exit.x --insts-lowered
BR start
DATA 199999
start
LDAP _exit
BR main
_exit
LDBM 1
LDAC 0
STAI 2
OPR SVC

PROC main
LDBM 1
STAI 0
lab0
LDBM 1
LDBI 0
OPR BRB

And when simulated produces the following trace where execution through main can be seen since it is the only labelled portion of the code:

➜ hexsim a.out -t
0      0                   BR   7  pc = pc + oreg (7) (0x000008)
1      8                   LDAP 1  areg = pc (9) + oreg (1) 10
2      9                   BR   4  pc = pc + oreg (4) (0x00000e)
3      14     main+0       LDBM 1  breg = mem[oreg (0x000001)] (199999)
4      15     main+1       STAI 0  mem[breg (199999) + oreg (0) = 0x030d3f] = areg (10)
5      16     main+2       LDBM 1  breg = mem[oreg (0x000001)] (199999)
6      17     main+3       LDBI 0  breg = mem[breg (199999) + oreg (0) = 0x030d3f] (10)
7      18     main+4       OPR  0  BRB pc = breg (0x00000a)
8      10                  LDBM 1  breg = mem[oreg (0x000001)] (199999)
9      11                  LDAC 0  areg = oreg 0
10     12                  STAI 2  mem[breg (199999) + oreg (2) = 0x030d41] = areg (0)
11     13                  OPR  3  exit 0

The program can also be run on the Verilog Hex implementation using hextb (which doesn’t provide as rich instruction tracing as hexsim):

➜ hextb a.out -t
Wrote 20 bytes to memory
[11] 8      0x51 LDAP
[13] 9      0x94 BR
[15] 14     0x11 LDBM
[17] 15     0x80 STAI
[19] 16     0x11 LDBM
[21] 17     0x70 LDBI
[23] 18     0xd0 OPR
[25] 10     0x11 LDBM
[27] 11     0x30 LDAC
[29] 12     0x82 STAI
[31] 13     0xd3 OPR
exit 0

Hello World

A more fulsome example is ‘Hello World’, where the main process is simply:

proc main() is prints("hello world\n")

And prints unpacks the bytewise string representation by using routines for performing division and remainder by 265. The full program listing is:

➜ cat tests/x/hello_prints.x
val put = 1;
val bytesperword = 4;
var div_x;

proc main() is prints("hello world\n")

proc putval(val c) is put(c, 0)

func lsu(val x, val y) is
  if (x < 0) = (y < 0)
  then
    return x < y
  else
    return y < 0

func div_step(val b, val y) is
  var r;
{ if (y < 0) or (~lsu(y, div_x))
  then
    r := 0
  else
    r := div_step(b + b, y + y);
  if ~lsu(div_x, y)
  then
  { div_x := div_x - y;
    r := r + b
  }
  else
    skip;
  return r
}

func div(val n, val m) is
{ div_x := n;
  if lsu(n, m)
  then
    return 0
  else
    return div_step(1, m)
}

func rem(val n, val m) is
  var x;
{ x := div(n, m);
  return div_x
}

proc prints(array s) is
  var n;
  var p;
  var w;
  var l;
  var b;
{ n := 1;
  p := 0;
  w := s[p];
  l := rem(w, 256);
  w := div(w, 256);
  b := 1;
  while (n <= l) do
  { putval(rem(w, 256));
    w := div(w, 256);
    n := n + 1;
    b := b + 1;
    if (b = bytesperword)
    then
    { b := 0;
      p := p + 1;
      w := s[p]
    }
    else skip
  }
}

Compiling and running this shows that it takes ~50K cycles to execute and inspecting the trace is clear to see that most time is spent in the arithmetic routines.

➜ xcmp tests/x/hello_prints.x
➜ hexsim a.out
hello world
➜ hexsim a.out -t
...
48902  61                  OPR  3  exit 0

Building an X compiler and bootstrapping

A third example is a complete compiler for X, written in X: xhexb.x written by David May in ~3,000 lines of X. This serves as a challenging program to compile, and interesting that it can bootstrap itself. Using the notation X(Y) to mean compile source Y using binary X, we can first create an xhexb binary by running xcmp(xhexb.x):

➜ xcmp -S tests/x/xhexb.x
...
20739 bytes

We can then use xcmp(xhexb.x) to compile Hello World as xcmp(xhexb.x)(hello_prints.x):

# Create an xhexb compiler binary.
➜ xcmp tests/x/xhexb.x

# Compile Hello World.
➜ hexsim a.out < tests/x/hello_prints.x
tree size: 602
program size: 414
size: 414

# Run it.
➜ hexsim simout2
hello world

Similarly, we can use xcmp(xhexb.x) to bootstrap itself by running xcmp(xhexb.x)(xhexb.x):

# Create an xhexb compiler binary.
➜ xcmp tests/x/xhexb.x

# Use xhexb binary to compile xhexb.x.
➜ hexsim a.out < tests/x/xhexb.x
tree size: 18631
program size: 17093
size: 177097

# Use the bootstrapped xhexb binary to compile Hello World.
➜ hexsim simout2 < tests/x/hello_prints.x
tree size: 602
program size: 414
size: 414

# Run it.
➜ hexsim simout2
hello world

Implementation details

Both the assembler and compiler are based on the xhexb.x bootstrapping compiler for X discussed above.

The assembler works in two main phases:

Parsing the program to form a list of directives (instructions, labels, data etc).
Code generation to iterate through the directives and emit binary output.

Before emission, the value of labels must be determined, which involves solving two problems. The first is that for a given relative reference, the length of the encoding (ie number of prefixes) depends on the value of the reference and vice versa. This is solved by iteratively increasing the encoding length until it meets the required range (see instrLen()). The second problem is that the value of a relative reference depends on the length of any relative encodings contained within the range. This is solved by iteratively updating label values until they reach a stable state (see resolveLabels()). The assembler adds additional rudimentary debug information to the binary, with a mapping of instruction ranges to symbol values. This allows the simulator to display the current symbol and offset.

The compiler works a traditional way, structured as a sequence of phases, first creating a parse tree, then performing passes on the tree to optimise it and then lowering the tree to machine instructions:

Parse the program to form an abstract syntax tree.
Walk the tree to populate a symbol table with names occurring in the program.
Walk the tree to propagate constant values within expressions.
Walk the tree to transform expressions into a canonical form.
Walk the tree to generate a sequence of intermediate machine instructions.
Lower the intermediate instructions to machine instructions.
Optimise the machine instruction sequence.
Assemble and emit the machine instruction sequence.

Command line options such as --tree are available to inspect the internal representation of the program in between these stages.

Compared with a more sophisticated compiler, Hex and X afford two significant simplifications. First, the small set of features in X make it straightforward to map to directly to machine instructions rather than an intermediate machine-independent representation. Secondly, the register architecture of Hex means that allocation of registers can be handled easily during mapping to machine instructions, rather than having to allocate physical registers to a virtual set as is typical in machines with more registers.

More details of the xhexb compiler implementation are included in the X and Hex notes PDF, with aspects such as the calling convention, handling of operators and arithmetic and memory layout being shared in xcmp.

A historical note

Hex, apart from being related to the Transputer, has some other interesting historical roots. David May learned about languages and compilers from Martin Richards who was a young lecturer when David completed his final-year Computer Science course as a student at King’s College Cambridge (the first student to do so). Martin was the designer of the influential language BCPL and its portable compiler technology. BCPL found its way to Bell Labs where UNIX was being developed. BCPL was the direct precursor to C and so led to the portability of UNIX.

When David moved from Cambridge to Warwick, the only useful language on the Modular One minicomputer that was available was BCPL but the compiler was incomplete. So David completed the compiler and ported BCPL to other computers, including some microprocessors. Using techniques similar to BCPL’s bootstrapping compiler and interpreter, David designed and implemented a concurrent language (EPL), bringing him into contact with Tony Hoare and Iann Barron (founder of the company that designed the Modular One and also of Inmos).

David employed the same techniques again at Inmos to build the first implementation of Occam in the 1980s and then again in 2008 for the project that led to the founding of XMOS (incidentally, I used this compiler in my PhD work to demonstrate techniques of compiling message-passing programs). Hex and X follow directly from the BCPL-derived approaches, used by David as a tool to teach students about instruction sets, compilers, bootstrapping etc.

Summary

Modern processors, languages, compilers, and tooling are complex and difficult to understand. This note walks through possibly the simplest processor architecture that allows a compact implementation of rudimentary tooling and a complete high-level programming language to be targeted at it. The definitions and implementations are contained in a single repository and just a small set of source files, making it an excellent project to use to explore processors and compilers.

Similar projects

The Big Hex Machine is a giant hands-on implementation of a Hex processor. It was designed and built by students and staff at the University of Bristol’s Computer Science Department.

Here are some other related projects that include simple implementations of processors and/or their toolchains.

VSPL, is a very simple programming language designed by Martin Richards to be used as a case study for comparing compiler implementations. The provided source distribution includes several implementations of VSPL in different languages.
Experiments in Computer System Design is a walk through of an implementation of a Tiny Register Machine (TRM) in Verilog with serial communication, DRAM access and multiprocessing (Niklaus Wirth, 2010).
Selfie is an educational platform for teaching programming languages and runtime systems. It is based on a simplified RISC-V architecture and includes a self-contained self-hosting compiler for a subset of C, an emulator, a hypervisor and a small standard library for the language. These tools are implemented in a single file (~12K lines of code).
Luz CPU, a simulator, assembler and linker for the Luz processor architecture written by Eli Bendersky.
Nibbler 4 Bit CPU is a complete description of a processor that has been implemented in discreet logic chips.
Discrete logic IC CPU us an architecture, discrete-logic implementation and basic tooling including a programming language.

Seeding parallel xoroshiro128+ generators

2022-10-01T00:00:00+02:00

As part of the statistical quality analysis I did of the of the xoroshiro128aox PRNG, I looked at interleaved parallel generators (where a single generator is created by round-robin interleaving the output $n$ identical generators with different seeds) as a way to test its suitability for parallel processing. Against my intuition, I found that simple seeding schemes produce poor interleaved generators, and even when the subsequences are disjoint. These findings equally apply to xoroshiro128+ as we will see.

The xoroshiro128+ creators recommend using a jump function to seed parallel generators to deterministically move to disjoint parts of the sequence. However, computing jumps is expensive to do in hardware because it involves 128-bit arithmetic and so it is preferable to compute seed values based on a simpler function of a machine’s state, such as an integer identifier for a process/thread. Since the probability of any two randomly-chosen sequences overlap is very small even with a large number of sequences, it seems reasonable to assume that a simple seed generator will perform okay in practice. Note also that the creators separately recommend “that initialization must be performed with a generator radically different in nature from the one initialized to avoid correlation on similar seeds”, based on research from 2007.

To investigate the use of simple seeding schemes, I ran tests against interleaved generators with three representative options (the source code is available on GitHub):

With equidistant intervals from 1 in the natural number sequence [Scheme A], defined in Python notation as:

for i in range(NUM_SEEDS):
    seed[i] = int(1 + i * ((2**128) // NUM_SEEDS))

With equidistant intervals starting from a random offset [Scheme B]:

for i in range(NUM_SEEDS):
    seed[i] = int(rand(0, (2**128) // NUM_SEEDS) + i * ((2**128) // NUM_SEEDS))

By adding a fixed offset to a initial state of balanced 0s and 1s [Scheme C]:

for i in range(NUM_SEEDS):
    seed[i] = 0x55555555555555555555555555555555 + i

And, as baselines:

Using the xoroshiro128 jump function, jumping $2^{64}$ steps [Scheme D].
Using a minimum-size jump for the number of generators to pass PractRand [Scheme E] (for example, the distance for 1000 generators is 4398046511 = (32 * 1024**4) / (8 * 1000)).
Using a non-linear PRNG to choose seeds (PCG64) [Scheme F].

To test these seeding schemes, I ran each generator against the standard PractRand test battery. PractRand is a good choice for these tests since it reports results at intermediate points and consumes much more output than Big Crush or Gjrand: 32 TB by default. A pass is achieved if no overtly suspicious $p$-values are flagged.

The results are summarised in the following table:

Seeding scheme	Number of generators	Output seen	Failing tests
Scheme A	10	256 MB	`DC6`, `FPF`
Scheme A	100	512 MB	`DC6`, `FPF`
Scheme A	1000	16 GB	`BCFN`
Scheme B	10	256 MB	`FPF`
Scheme B	100	2 GB	`DC6`
Scheme B	1000	32 GB	`BCFN`
Scheme C	10	256 MB	`DC6`, `Gap`, `FPF`, `mod3`
Scheme C	100	256 MB	`BCFN`, `DC6`, `Gap`, `FPF`, `mod3n`
Scheme C	1000	256 MB	`BCFN`, `DC6`, `Gap`, `Brank`, `FPF`, `mod3n`
Scheme D	10,100,1000	32 TB	Pass
Scheme E	10,100,1000	32 TB	Pass
Scheme F	10,100,1000	32 TB	Pass

Note that DC6 and BCFN are both tests for linearity. For the failing generators (schemes A-C), I checked there are no duplicate values between the different generators to establish that no two sequences overlap (using the analyse mode). This means that the above failures are due to correlations between disjoint sequences.

For reference, below is sample output for running the Scheme A generator with 10 parallel streams against PractRand. There are comprehensive failures within the first 256 MB of output.

$ ./build/xoroshiro128plus_il_equia_10 stdout std64 0 0 | ./install/PractRand-pre0.95/RNG_test stdin64 -a
RNG_test using PractRand version 0.95
RNG = RNG_stdin64, seed = unknown
test set = core, folding = standard (64 bit)

rng=RNG_stdin64, seed=unknown
length= 256 megabytes (2^28 bytes), time= 2.3 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+0,13-2,T)                  R=  -0.0  p = 0.494     normal
  BCFN(2+1,13-2,T)                  R=  +4.1  p = 0.050     normal
  BCFN(2+2,13-3,T)                  R=  +0.0  p = 0.484     normal
  BCFN(2+3,13-3,T)                  R=  +1.3  p = 0.292     normal
...
  [Low16/64]BCFN(2+12,13-9,T)       R=  -2.1  p = 0.849     normal
  [Low16/64]DC6-9x1Bytes-1          R=  +1.6  p = 0.332     normal
  [Low16/64]Gap-16:A                R=  +0.5  p = 0.523     normal
  [Low16/64]Gap-16:B                R=  +4.3  p =  1.3e-3   normalish
  [Low16/64]FPF-14+6/16:(0,14-0)    R=  +0.2  p = 0.434     normal
  [Low16/64]FPF-14+6/16:(1,14-0)    R=  +2.2  p = 0.061     normal
...
  [Low4/64]BCFN(2+9,13-9,T)         R=  +0.6  p = 0.310     normal
  [Low4/64]BCFN(2+10,13-9,T)        R=  +0.2  p = 0.372     normal
  [Low4/64]DC6-9x1Bytes-1           R= +88.5  p =  5.9e-51    FAIL !!!!
  [Low4/64]Gap-16:A                 R=  +4.4  p =  4.6e-3   normalish
  [Low4/64]Gap-16:B                 R=  -0.6  p = 0.656     normal
  [Low4/64]FPF-14+6/16:(0,14-1)     R=  -1.0  p = 0.759     normal
  [Low4/64]FPF-14+6/16:(1,14-2)     R=  -3.7  p =1-4.2e-3   normal
  [Low4/64]FPF-14+6/16:(2,14-2)     R=  -0.9  p = 0.738     normal
  [Low4/64]FPF-14+6/16:(3,14-3)     R=  +1.3  p = 0.189     normal
  [Low4/64]FPF-14+6/16:(4,14-4)     R=  +1.6  p = 0.134     normal
  [Low4/64]FPF-14+6/16:(5,14-5)     R=  +1.2  p = 0.206     normal
  [Low4/64]FPF-14+6/16:(6,14-5)     R=  +1.4  p = 0.166     normal
  [Low4/64]FPF-14+6/16:(7,14-6)     R=  -1.6  p = 0.877     normal
  [Low4/64]FPF-14+6/16:(8,14-7)     R=  -0.7  p = 0.681     normal
  [Low4/64]FPF-14+6/16:(9,14-8)     R=  +1.2  p = 0.187     normal
  [Low4/64]FPF-14+6/16:(10,14-8)    R= +19.4  p =  5.5e-14    FAIL
  [Low4/64]FPF-14+6/16:(11,14-9)    R= +12.4  p =  4.0e-8   suspicious
  [Low4/64]FPF-14+6/16:(12,14-10)   R= +12.5  p =  3.0e-7   mildly suspicious
  [Low4/64]FPF-14+6/16:(13,14-11)   R=  +5.1  p =  4.8e-3   normal
  [Low4/64]FPF-14+6/16:(14,14-11)   R=  +8.8  p =  1.1e-4   normal
  [Low4/64]FPF-14+6/16:all          R=  +0.3  p = 0.435     normal
  [Low4/64]FPF-14+6/16:cross        R=  +2.1  p = 0.032     normal
  [Low4/64]BRank(12):128(4)         R=  -0.8  p~= 0.670     normal
  [Low4/64]BRank(12):256(2)         R=  +1.6  p~= 0.168     normal
  [Low4/64]BRank(12):384(1)         R=  +1.8  p~= 0.146     normal
  [Low4/64]BRank(12):512(2)         R=  -0.2  p~= 0.554     normal
  [Low4/64]BRank(12):768(1)         R=  -0.7  p~= 0.689     normal
  [Low4/64]mod3n(5):(0,9-6)         R= +14.0  p =  1.3e-5   mildly suspicious
  [Low4/64]mod3n(5):(1,9-6)         R=  -0.0  p = 0.451     normal
  [Low4/64]mod3n(5):(2,9-6)         R=  -0.2  p = 0.492     normal
  [Low4/64]mod3n(5):(3,9-6)         R=  -1.5  p = 0.781     normal
  [Low4/64]mod3n(5):(4,9-6)         R=  +0.0  p = 0.433     normal
  [Low4/64]mod3n(5):(5,9-6)         R=  +0.4  p = 0.353     normal
  [Low4/64]mod3n(5):(6,9-6)         R=  -1.3  p = 0.742     normal
  [Low4/64]mod3n(5):(7,9-6)         R=  +1.9  p = 0.152     normal
  [Low4/64]mod3n(5):(8,9-6)         R=  -1.3  p = 0.731     normal
  [Low4/64]mod3n(5):(9,9-6)         R=  -0.4  p = 0.540     normal
  [Low4/64]mod3n(5):(10,9-6)        R=  -0.6  p = 0.585     normal
  [Low4/64]mod3n(5):(11,9-6)        R=  +0.6  p = 0.322     normal
  [Low1/64]BCFN(2+0,13-6,T)         R=  +7.3  p =  6.5e-3   normalish
  [Low1/64]BCFN(2+1,13-6,T)         R=  -3.2  p = 0.926     normal
  [Low1/64]BCFN(2+2,13-6,T)         R=  -1.5  p = 0.716     normal
  [Low1/64]BCFN(2+3,13-6,T)         R=  +1.6  p = 0.238     normal
  [Low1/64]BCFN(2+4,13-7,T)         R=  +1.7  p = 0.212     normal
  [Low1/64]BCFN(2+5,13-8,T)         R=  +0.8  p = 0.304     normal
  [Low1/64]BCFN(2+6,13-8,T)         R=  +0.2  p = 0.403     normal
  [Low1/64]BCFN(2+7,13-9,T)         R=  +1.0  p = 0.257     normal
  [Low1/64]BCFN(2+8,13-9,T)         R=  -1.8  p = 0.790     normal
  [Low1/64]DC6-9x1Bytes-1           R= +1379  p =  3.6e-777   FAIL !!!!!!!
  [Low1/64]Gap-16:A                 R= +4863  p =  5e-3914    FAIL !!!!!!!!
  [Low1/64]Gap-16:B                 R=+11222  p =  6e-8467    FAIL !!!!!!!!
  [Low1/64]FPF-14+6/16:(0,14-2)     R=+10120  p =  5e-8851    FAIL !!!!!!!!
  [Low1/64]FPF-14+6/16:(1,14-3)     R= +7164  p =  2e-6279    FAIL !!!!!!!!
  [Low1/64]FPF-14+6/16:(2,14-4)     R= +5071  p =  9e-4144    FAIL !!!!!!!!
  [Low1/64]FPF-14+6/16:(3,14-5)     R= +3567  p =  1e-2956    FAIL !!!!!!!!
  [Low1/64]FPF-14+6/16:(4,14-5)     R= +2180  p =  7e-1807    FAIL !!!!!!!!
  [Low1/64]FPF-14+6/16:(5,14-6)     R= +1535  p =  1e-1174    FAIL !!!!!!!!
  [Low1/64]FPF-14+6/16:(6,14-7)     R=+350.5  p =  9.0e-279   FAIL !!!!!!
  [Low1/64]FPF-14+6/16:(7,14-8)     R=+255.2  p =  1.1e-183   FAIL !!!!!!
  [Low1/64]FPF-14+6/16:(8,14-8)     R=+235.5  p =  1.7e-169   FAIL !!!!!
  [Low1/64]FPF-14+6/16:(9,14-9)     R=+152.7  p =  2.0e-96    FAIL !!!!!
  [Low1/64]FPF-14+6/16:(10,14-10)   R= +87.1  p =  6.7e-47    FAIL !!!
  [Low1/64]FPF-14+6/16:(11,14-11)   R= +58.4  p =  2.6e-26    FAIL !!
  [Low1/64]FPF-14+6/16:(12,14-11)   R= +58.0  p =  3.9e-26    FAIL !!
  [Low1/64]FPF-14+6/16:all          R=+14029  p = 0           FAIL !!!!!!!!
  [Low1/64]FPF-14+6/16:cross        R= +3119  p =  3e-2681    FAIL !!!!!!!!
  [Low1/64]BRank(12):128(2)         R=  -0.2  p~= 0.554     normal
  [Low1/64]BRank(12):256(2)         R=  -1.0  p~= 0.744     normal
  [Low1/64]BRank(12):384(1)         R=  -0.7  p~= 0.689     normal
  [Low1/64]BRank(12):512(1)         R=  +0.4  p~= 0.366     normal
  [Low1/64]mod3n(5):(0,9-6)         R=+322.9  p =  4.1e-111   FAIL !!!!!
  [Low1/64]mod3n(5):(1,9-6)         R=  -0.5  p = 0.563     normal
  [Low1/64]mod3n(5):(2,9-6)         R=  +2.1  p = 0.129     normal
  [Low1/64]mod3n(5):(3,9-6)         R=  +5.0  p = 0.016     normal
  [Low1/64]mod3n(5):(4,9-6)         R=  +2.5  p = 0.099     normal
  [Low1/64]mod3n(5):(5,9-6)         R=  -0.8  p = 0.614     normal
  [Low1/64]mod3n(5):(6,9-6)         R=  -1.4  p = 0.757     normal
  [Low1/64]mod3n(5):(7,9-6)         R=  +1.7  p = 0.167     normal
  [Low1/64]mod3n(5):(8,9-6)         R=  +2.3  p = 0.111     normal
  [Low1/64]mod3n(5):(9,9-6)         R=  +2.2  p = 0.125     normal

Conclusion

When choosing seeds for PRNGs operating in parallel, it might seem sufficient to ensure that the sequences they range over are disjoint, provably or with high probability. However, correlations between disjoint subsequences do exist in PRNGs based on the xoroshiro128 linear engine. It is known that these correlations can manifest when sequences are chosen by a linear generator. Based on the findings in this note, these correlations also occur when seeds are created using non-linear operations such as addition. The safest course of action to take is to follow the guidance of the xoroshiro128 authors and either use the jump function to traverse the state space or use a high-quality non-linear PRNG to generate random seeds.

References

My PRNG testing source code.
xoshiro / xoroshiro generators and the PRNG shootout.
PractRand.
Makoto Matsumoto, Isaku Wada, Ai Kuramoto, and Hyo Ashihara. 2007. Common defects in initialization of pseudorandom number generators. ACM Transactions on Modeling and Computer Simulation.

The hardware pseudorandom number generator of the Graphcore IPU

2022-09-21T00:00:00+02:00

This note is a short summary of my IEEE Transactions on Computers journal paper and was originally written to appear on the Graphcore blog.

The Graphcore IPU contains a novel pseudorandom number generator (PRNG) that was designed to produce high-quality statistical randomness, whist also being cheap to implement in hardware. Having an efficient hardware RNG means randomness can be used frequently: the IPUs generator can produce 64-bits of unique randomness from all of its 1,216 tiles every clock cycle. This, for example, makes it possible to perform on-the-fly stochastic rounding of low-precision floating-point numbers.

We needed a new PRNG because typical state-of-the-art generators are designed to be performant when run as software routines, but operations that are cheap to execute on a processor may not be cheap to implement in hardware as is the case for multiplication or division. Our generator xoroshiro128aox is based on Sebastiano Vigna’s xoroshiro128 linear-feedback shift register (LFSR), which is attractive because it uses 128 bits of state and is cheap to implement in hardware. The LFSR operates by performing XOR and fixed-distance shift and rotate operations on the state. Following Vigna’s approach of adding a function to ‘scramble’ the LFSR state, we have devised a function consisting of AND, OR and XOR operations (called AOX for short). An C implementation of xoroshiro128aox is as follows:

uint64_t s0, s1; // State vectors

uint64_t rotl(uint64_t x, int k) {
  return (x << k) | (x >> (64 - k));
}

uint64_t next(void) {
  uint64_t sx = s0 ^ s1;

  // Calculate the result, the 'AOX' step.
  uint64_t sa = s0 & s1;
  uint64_t res = sx ^ (rotl(sa, 1) | rotl(sa, 2));

  // xoroshiro128 state update
  s0 = rotl(s0, 55) ^ sx ^ (sx << 14);
  s1 = rotl(sx, 36);
  return res;
}

To determine that this new PRNG provides a good source of randomness, we took the conventional approach of subjecting the generator to batteries of statistical tests, that aim to detect correlations over large portions of the generator’s output. Given that any PRNG is inherently non-random because they produce numbers according to a fixed sequence, statistical testing is only as good as the tests that they run, and their performance can only be judged on their ability to distinguish existing good generators from bad ones. Indeed, a novel statistical test could immediately raise the bar for all PRNGs.

Within the field of PRNG design, TestU01’s BigCrush battery is accepted as the gold-standard statistical test, however it is not always clear exactly what methodology has been used to obtain a pass/fail result. In particular, the choice of initial state (the seed) is important because different parts of a sequence may have different properties, and TestU01 has known biases in the way it uses bits from a generator’s output. To mitigate these issues, we run every generator from 100 unique seeds and supply six permutations of the output bits. And as well as running TestU01, we also run PractRand and Gjrand with the same 100 seeds, which are the two other most well-regarded test sets. This gives us a comprehensive testing methodology that goes beyond the typical level of analysis.

To provide a point of comparison, we include the following PRNGs:

32-bit Mersenne Twister, mt32, since it is one of the most widely used software PRNGs (although it has 19,937 bits of state!).
xoroshiro128+, which is Vigna’s closest variant of xoroshiro128, using 64-bit addition to scramble 128-bit LFSR states.

And to represent the current state-of-the-art 128-bit generators, we include:

philox4x32-10, a counter-based generator whose transition between states is a 128-bit increment and output scrambling function is 10 rounds of 32-bit multiplications and XORs.
pcg64, a linear-congruential generator (LCG) that uses multiplication and addition by 128-bit constants for the state-transition function, and XOR and variable rotation operations to produce outputs.

The table below summarises the TestU01 BigCrush results, where the six output columns correspond to different permutations of the generators bits (eg 1 is unchanged, 2 is swapping the most and least significant 32 bits) and the numbers are total failures. Since a true random number generator has a probability of failing, the expected number of failures can be calculated. BigCrush runs 160 individual tests (and consumes approximately 1 TB of random data), so in this case the expected number is 32. A generator is considered to fail only when it fails on the same test over all seeds, which can be seen in the entries highlighted in red. The Mersenne Twister consistently fails, whereas xoroshiro128+ fails on a particular output permutation where the lower 32 bits are discarded (this is a known deficiency of the generator).

Generator	Output 1	Output 2	Output 3	Output 4	Output 5	Output 6	Total failures
`mt32`	236	237	233	238	246	237	1427
`pcg64`	34	30	38	37	38	27	204
`philox4x32-10`	33	32	32	32	28	38	195
`xoroshiro128+`	33	29	28	40	353	42	525
`xoroshiro128aox`	31	32	41	30	44	32	210

The table below summarises the Gjrand results, which just runs 13 tests and by default consumes approximately 10 TB of data. Unlike BigCrush and TestU01, xoroshiro128aox fails Gjrand on both versions of its z9 test, which looks for dependencies in the Hamming Weight of successive outputs. Although BigCrush and PractRand include similar tests that analyse Hamming Weight dependencies, they do not detect correlations. What this shows is that the scrambling of the xoroshiro128 LFSR’s state serves to hide correlations due to the linear operations only to an extent, and a particular test will be sensitive enough to detect them. Given that BigCrush and PractRand did not, xoroshiro128aox represents a significant improvement over xoroshiro128+, whilst still being cheap to implement in hardware as we show in the next section.

Generator	Total failures
`mt32`	107
`pcg64`	15
`philox4x32-10`	7
`xoroshiro128+`	210
`xoroshiro128aox`	205

To demonstrate that xoroshiro128aox is indeed cheap to implement in hardware, we compare physical implementations of the generators (excluding Mersenne Twister because of its considerable state size) after they have been fully synthesised and placed and routed using Graphcore’s 7 nm cell library and a target clock period of 1 GHz. The table below summarises the results.

Generator	Total cells (state update)	Logic depth (state update)	Total cells (output)	Logic depth (output)	Total cells
`xoroshiro128aox`	331	4	353	4	684
`xoroshiro128+`	331	3	906	13	1237
`pcg64`	9564	26	658	7	10222
`philox4x32-10`	1003	13	29553	89	30556

Key takeaways from these results are:

That AOX is approximately one third of the cost of a full 64-bit addition and the cheapest option overall by a factor of two.
For pcg64 the cost is dominated by the 128-bit arithmetic for its state update.
For philox4x32-10 the cost is dominated by the output function composed of 10 stages of 32-bit arithmetic.

The following are illustrations of the four PRNG circuit floorplans, which make clear the differences in implementation complexity (left to right: xoroshiro128aox, xoroshiro128+, pcg64, philox4x32-10):

xoroshiro128+

xoroshiro128aox

pcg64

philox4x32-10

And scaled to relative sizes:

xoroshiro128+

xoroshiro128aox

pcg64

philox4x32-10

Summary

This note has provided an overview of the methodology and results of the analysis we conducted into the statistical quality of our novel PRNG xoroshiro128aox. This has established that our generator mitigates known existing weaknesses of xoroshiro128+ on which it is based, and delivers comparable levels of statistical quality on the gold-standard BigCrush test set as two contemporary fast PRNGs : pcg64 and philox4x32-10. Extending testing by using PractRand and Gjrand, we do eventually find that a weakness is detectable by Gjrand. Since this is not systematic across the test suites, as we have seen for the Mersenne Twister, we can consider xoroshiro128aox to provide an excellent tradeoff between quality and implementation cost in hardware.

Full details of the investigation can be found in the preprint paper on arXiv, and the source code for the experiments on GitHub.

Garden workshop

2021-10-04T00:00:00+02:00

During the summer of 2021 I built a garden workshop. This was a joint endeavour with my partner, who designed and specified the form and finish (credit for the CAD drawings goes to her). The basic construction follows the methodology of Oakwood Garden Rooms who’s YouTube channel proved invaluable guidance through the process. I also bought from them parts for the rod system for the footings, and a ‘build pack’ that crucially provided a preliminary materials list. This note documents the process of the design and build, but making sure not to reveal any of the details supplied in the Oakwood Garden Rooms build pack.

Groundworks

After clearing and levelling the workshop site, holes were dug for each of the steel rod footings. The setting out of these was carefully determined with string lines since the base timbers slot directly onto the rods with a relatively small amount of tolerance, and determining the overall size and shape of the base.

Base

The base is constructed with a frame bolted down onto the 24 mm threaded rod piles and joists supported with hangars bridge between the frame timbers. 100 mm insulation is cut and inserted between the joists, and supported below from falling by treated batten fastened to the joists. All gaps were filled with expanding foam. A layer of breathable roofing sheet is laid over the base before the 22 mm chipboard floor sheets are glued and fastened down.

Structure

The walls are constructed using 50 x 100 mm studwork timbers and covered with 12 mm OSB sheet. The roof is constructed with 47 x 125 mm timbers, doubled up to span the wall-to-wall gap, and covered in 18 mm OSB tongue-and-groove roofing sheets.

Waterproof wrap and batons

The walls are covered in a breathable waterproof membrane (standard roofing sheet) and two perpendicular layers of roofing batten to support the vertical cladding.

Cladding

The cladding is made from rough-sawn cedar, sourced from Gladstone Sawmills in South Wales. The vertical pattern is 150 mm widths separated by a 25 mm gap, fastened to 75 mm widths sitting behind.

Warm roof and rooflights

The roof is built up following a warm roof construction. On the bottom deck of 18 mm OSB, a 100 mm perimeter is built around the edge and roof light openings. A damp-proof membrane is laid in the resulting area, and 100 mm insulation boards laid on top and packed tightly. The roof is covered with a Bauder single-ply roofing system, installed by County Flat Roofing. The roof lights measure 1,200 x 900 mm external dimensions.

Buildups

The following two images show the buildups of the roof and wall. The roof buildup consists of (starting inside) 125 mm structural timber, 18 mm OSB bottom deck, 100 mm insulation perimeter, 18 mm OSB top deck, roofing felt, Bauder membrane, roof light upstand and rooflight. The wall buildup consists of (starting inside) 100 mm studwork, 12 mm OSB, waterproof membrane, two layers of 25 mm roofing batten, two layers of 20 mm Cedar board. Both buildups do not show the 15 mm internal plywood panelling that was installed later.

Windows

The two windows are 1,040 x 1,040 mm double-glazed aluminium casement, supplied by Panoramic Windows.

Internal fit out

Socket and switch positions

Positions of sockets, lights and wiring was marked out using tape.

Wall insulation

The wall carcassing was filled with 80 mm sheet insulation, into which channels were created for the wiring. In order to create a moisture barrier, all sheets were taped together with aluminium foil to create a single air-tight surface. Special attention was paid to the interaction between the roof and walls, where otherwise it would have been easy to have areas of missing or shallow insulation.

Wiring and first-fix electrics

Wiring for electrical and data sockets and all the lighting was pulled though holes in the carcassing. We created two separate socket circuits (right and left), and a circuit for wall-mounted heaters. The lighting is divided into three ceiling circuits branched off the switches, plus an outdoor light.

Boarding

The internal finish is done with 15 mm WISA-Spruce Special boards fixed to the walls and ceiling.

Second-fix electrics

With the second-fix electrics completed, the workshop was operational.

More details of the final details to be added as they are completed…

Drawings

The following drawings are taken from the Revit model of the workshop.

Plan views.

Elevation views.

Section view showing buildups of the roof, walls and floor. and intersections between them.

Home thermal-imaging survey

2021-03-31T00:00:00+02:00

I recently moved into a Cornish Unit Type 1 house, and with my involvement with The CHEESE Project I was keen to perform a thermal-imaging survey to better understand how well the building performs thermally. Also, with the first few months in the house being in winter and it feeling very cold in places, I had extra motivation to find out where heat was being lost, and to try and resolve some faults. I have written this note to record what I found as a case study that others may find useful, from the point of view of understanding the benefits of using thermal imaging to assess building performance, and to see the kinds of thermal faults that are standard among domestic buildings. Included also are some simple remedial measures that I took to address thermal faults. The emphasis of these were low cost and low effort to improve the house in the short term, and particularly during the winter. With plans to renovate and extend in the next couple of years, the survey would also provide guidance on where more significant interventions could be targeted.

I followed the methodology of The CHEESE Project to perform the survey (more details about home surveys and the process). To summarise: the best thermal imaging results are obtained when there is a good temperature differential (at least 10 degrees) between inside the building and outside. For this reason, winter is the best period, with the building heated for 24 hours to warm up the fabric rather than just the air inside it. A blower door fitted to an external door is used to reduce the internal air pressure and accentuate any draughts. Once the heating is switched off, the house will start to cool down by thermal conduction through materials and ingress of cold air through draughts. While this is happening the thermal camera is used to capture the effects of any areas of rapid cooling, ie ‘thermal faults.

External

I did the survey in December, and the external temperature was close to 0 degrees. The images below show the back of the house in infra red (thermal) and visible light. There is little to learn from the thermal picture, and note that the windows will be reflecting some of the cool night sky.

There are a few things to remember when inspecting the thermal images. The thermal image is overlaid on the larger visible-light image, the temperature value is the measurement taken at the cross hairs, and often each image is taken with a particular temperature range to give the best contrast to the subject of the image. The temperature range is given in the top left-hand corner, and the black and white squares show the degree increments along the colour scale. In the thermal image above left, the range is centred on 20 degrees plus and minus 23 degrees. All the thermal images in this note use a colour palette called ‘ironbow’, which I find most intuitive, there are however other choices such as rainbow and greyscale.

Front door

The area by the front door was noticeably cold when walking past it. The thermal images reveal cold single glazed glass sections (at ~15 degrees compared with ~22 degrees ambient temperature of the hallway), and draughts, particularly at the bottom where the temperature drops to 10 degrees.

To tackle the leakiness of the front door, I added some acrylic secondary glazing to the glass sections and blocked up the letter box with glass fibre insulation and a wooden plug (there is another letter box in the porch). I admit this was not an elegant solution, but it was quick and cheap. The look of acrylic could have been improved by using magnetic strip for attaching it, also allowing for it to be removed. But since the door will be replaced in the next 18 months, I was not too worried.

Windows

The house has uPVC double glazing throughout (installed within the last 10 years), but a main finding of the survey was the windows had some significant thermal faults.

Leaking trim

The most obvious fault was draughts around the edges of the frames, from behind a plastic trim. In the left-hand images, the cold area is a draught emerging from a section of silicon sealant that had detached.

When I removed the trim to investigate, I found the frames had not been sealed to the wall in any way (left), so there was a gap all around where air could penetrate. On several windows, daylight was visible without the trim. Mostly the plastic trims were doing a good job preventing draughts, but they were not providing much insulation against air circulating behind them. I fixed the issue by using expanding foam to fill the gaps, and used filler to address any smaller gaps and make it flush with the window reveals.

Leaking sill

Related to the lack of sealing of the window frames to the wall was draughts emerging from under the window sill. In the thermal picture below this is particularly visible being above a warm radiator. With the blower door running, it is also easy to feel these with the back of a finger.

Leaking seals

Two opening panes had leaks along part of their seals, where the window did not shut tight to the frame to make it airtight. This was not a significant source of a draught, but a problem that is commonly found with uPVC windows. Often the hinges can be adjusted to remedy this issue, or foam insulation tape could be added.

Missing insulation

An interesting aspect of the house is that the upper floor has a Mansard roof and is timber construction. The first-floor walls have had insulation inserted behind the tiles, but the thermal picture below shows clearly no insulation has been added above the window. This is the case for all the upstairs windows.

First floor walls

The images below of the first-floor walls show clearly the timber sub structure of the roof and the voids between where insulation has been added. Below the window in the top-left image, there is evidence of air ingress from around the frame into the wall. In the bottom-right image, there is evidence of air ingress from the loft space into the wall, due to missing or lacking insulation at that intersection. In the same picture, you can see a rectangle of missing insulation in the corner. In the bottom-left image, you can see warm walls, the cold window frames and the missing insulation at the top.

By coincidence, a near by Cornish Unit Type 1 house was undergoing some extension work, and has its upper timbers exposed. The picture below shows clearly the construction, and notably the wall voids contained no insulation.

Ground wall

The Mansard roof construction means that the interface between the roof and masonry walls is at the top of the ground floor walls (rather than more conventionally at the top of the upper floor walls). The images below show ingress of cold air from the eaves and into the surrounding wall, stairs and floor. Note also the shape of the block work in the ground floor wall.

Air brick

The building has one air brick that vents into the wall cavity. This is particularly visible inside, as a cascade of cold air down the wall. Presumably the ventilation is necessary to prevent moisture buildup in the cavity.

Loft hatch

One of the first jobs after moving in was to install a loft ladder for better access to the loft space for storage. The job still requires some finishing touches, but the thermal image shows there is only one main area that requires some additional sealing. Otherwise, I packed more insulation around the frame to resolve the more minor cold patches.

Loft insulation

Due to my work boarding out the loft, there was another piece of missing insulation in the corner (here in the bathroom). These images clearly show the value of loft insulation, and it extending to the edges.

Installing boarding in the loft for storage was a good opportunity to redistribute and top up insulation, and make sure it extended into corners (whilst maintaining space for airflow from the roof). In the right-hand picture, the black columns are stilts that boarding is attached to.

Kitchen

Another particularly cold spot in the house was in a corner of the kitchen, and inside the corner cupboard. This was due to a soil pipe running up through the house to avoid the angle of the Mansard roof, and the boxing carrying it up through the kitchen channelling cold air from the outside. As you can see, the internal temperature of the cupboard was about 10 degrees lower than the ambient room temperature, similar to the front door. I tackled this issue by sealing as much as possible around the boxing and stuffing fibre insulation in all of the remaining gaps. This made a big difference, but a complete fix would require taking the cabinets out and redoing the boxing.

Bathroom

The thermal images in the bathroom did not reveal any significant draughts, but they do show cold air circulating behind the walls. This was confirmed when the bathroom was reorganised, revealing a void behind the sink with plenty of daylight visible through the eaves. Note also in the image of the toilet, the cold water sitting in the cistern.

Central heating

It was interesting for the thermal images to reveal the workings of the central heating system. The condensing boiler and its pipework is clearly visible in the top two images. The hot water tank is middle-left, a radiator middle-right and otherwise hidden pipework in the bottom two images.

Kit

The left-hand image show the the CHEESE blower door installed on the side door, which precludes that door from being inspected, but it was less of a worry than the front door. The right-hand image shows the CHEESE camera kit, with the iPhone and Flir camera attachment.

Reflections on the state of nature

2020-12-04T00:00:00+01:00

For a long time I have been deeply worried about the looming threat of climate change and its broad consequences. But greenhouse gas emissions from human activities are just one part of a complex picture in which we (human beings) are damaging our environment so severely that the future of our life on Earth uncertain, and this uncertainty is within the timescale of our children’s lifetimes. Indeed, there is some degree of consensus that we are heading for some form of societal collapse. In this note, I wanted to try and articulate the complex picture of human impacts on nature as a way to reflect on the situation in which we find ourselves in, and provide something to navigate the stream of environmental bad news that we receive. The information in this note is drawn primarily from recent significant reports that focus on global impacts, linked at the end.

Nature’s biodiversity and ecosystem services

Nature is the rich variety of life and environments found on Earth, but because of human impacts it is in decline.

The 2019 UN Global Assessment Report on Biodiversity and Ecosystem Services is the work of an intergovernmental body and represents the most comprehensive assessment of life on earth ever completed. The report finds that human activities have caused huge declines in terrestrial, freshwater and marine environments. Across an estimated eight million known animal and plant species, approximately one million are currently threatened with extinction. This rate of extinction is estimated to be 10 to 100 times higher than any of the previous known five mass extinction events in the history of Earth, thus it has been named the Holocene extinction, characterising the current geological epoch.

The WWF Living Planet Report 2020 provides a similarly stark assessment of the state of the world’s ecosystems and lifeforms: between 1970 to 2016 there was been an average decline of 68% in populations of mammals, birds, amphibians, reptiles and fish according to the ‘Living Planet Index’, which aggregates data from 20,811 populations representing 4,392 species globally and does not include insects. Rates of decline vary significantly by region, with the highest average declines in tropical regions (94% of vertebrate populations in Latin America and the Caribbean).

A 2018 study found that of all mammals on Earth, 96% are livestock, 36% are humans and only 4% are wild animals. Of birds, 70% are poultry and 30% are wild. These proportions correspond to intensification of animal agriculture with losses of 83% of wild terrestrial mammals, 80% of marine mammals, 50% of plants and 15% of fish.

The issues of biodiversity and ecosystems are central to the functioning of our planet and to our health and wellbeing. Biodiversity relates to the variety of genes, species and functional traits in an ecosystem, which is defined as a community of living things in an environment, all interacting as a system. It is recognised that biodiversity affects the functioning of ecosystems, the flows of energy, materials, minerals, and water. At a high level, all ecosystems are powered by the sun’s energy that is captured by photosynthesis, and this energy is transferred upwards through the food web. The movement of nutrients occurs as living organisms exchange them though their interactions with the physical environment.

Humans too are part of an ecosystem, depending on plants and organisms to capture the sun’s energy and convert it into edible products. However, human activities such as agriculture and forestry management can be seen as ways of manipulating our ecosystems to increase the output of particular provisions. Unfortunately, such interventions have effects that are detrimental to other aspects of ecosystem functioning.

Apart from the wonder and beauty of the natural world and a sense that it should be respected and preserved, biodiversity can be viewed through a more functional lens as providing services for the benefit of humans, and indeed our survival. These ecosystem services can be broken down into four groups: provisioning, regulating, support and cultural, summarised in the following table. According to the Global Assessment Report, the trend of 16 of these 19 categories is that decline over the last 50 years. Only energy, food, and raw materials have seen increases in the level of provisioning to humans. However, these service benefits directly impact other services due to dramatic changes in land use and associated air, water and soil pollution.

Summary of nature’s ecosystem services it provides to humans
Group	Service	Historical 50-year trend	Details/examples
Provisioning services that support the production of renewable resources.
	Food and feed	Increase	Such as crops and fisheries, feeding humans directly and indirectly with livestock.
	Energy	Increase	Such as biofuels.
	Raw materials	Increase	Such as wood for construction and natural fibres for clothing.
	Freshwater	Decline	Water is essential for human life and for the cultivation of crops.
	Medicinal, biochemical and genetic resources	Decline	For example, new antibiotics are discovered in nature, rather than being created artifically.
Regulating services that lessen environmental change.
	Regulation of climate	Decline*	By sequestration of carbon dioxide to reduce the effects of global warming. *The capacity of the oceans to do this has remained constant in this period.
	Regulation of local climate and air quality	Decline	Examples including shade from trees, forests influencing rainfall and plants regulating air quality by removing pollutants.
	Moderation of extreme events and natural disasters	Decline	Such as floods, storms, tsunamis, landslides and droughts.
	Regulation of freshwater and coastal water quality	Decline	Such as treatment of waste water to eliminate harmful pathogens.
	Regulation of freshwater flow	Decline	Which affects the quantity, location and timing of freshwater.
	Regulation of soil fertility and prevention of soil erosion.	Decline	Fertility refers to the ability of soil to sustain plant growth, and erosion is the displacement of soil, most immediately impacting crop production.
	Biological control of disease and pests	Decline	Such as by the control of the population of a species that acts as a vector for a disease by another, perhaps predatory, species.
	Pollination of plants	Decline	To enable reproduction of many plants.
Supporting services that provide a basis for all ecosystems and their biodiversity with habitats and genetic diversity.
	Soil formation	Decline	To provide a habitat for many types of plant.
	Nutrient cycling	Decline	To provide the necessary mineral nutrients, including water, to organisms.
Cultural services are non-material human benefits.
	Recreation and mental and physical health in natural spaces	Decline	Such as walking, running or sports in a park.
	Tourism though the enjoyment of nature	Decline	Benefiting those experiencing nature, as well as providing income for those facilitating it.
	Aesthetic appreciation and inspiration for culture, art and design	Decline	Much of culture, art and design draws on the natural world.
	Spiritual experience and sense of place	Decline	Nature is a common element of most religions.

Since 1970, the global population has more than doubled (3.7 billion to 7.6 billion), global trade has increased ten fold and average GDP has increased four fold. It is estimated there has been a 15% per-capita increase in consumption globally and this is compounded by increasing levels of long-distance goods transportation. Increased consumption, along with technological development, has driven increased production of food, materials and fuels, and has driven urbanisation, which is reflected in global statistics:

Crop production has increased 300% since 1970.
Timber production has increased by 50% since 1970.
Extraction of resources has almost doubled since 1980.
Urban areas have more than doubled since 1992.

Consequently, the primary driver of biodiversity loss in terrestrial and freshwater ecosystems is land-use change, closely followed by direct exploitation through harvesting, logging and hunting. In marine ecosystems, direct exploitation through fishing is the primary driver, followed by land-/sea-use change. Together these issues account for more than 50% of the global impact on nature, but approximately 30% is this is attributable to three other significant factors: climate change, pollution and invasive alien species.

The UN Global Assessment Report summarises human impact thus: 75% of the earth’s land surface is now significantly altered, 66% of the oceans are significantly altered, and global indicators of the condition of biodiversity and ecosystems indicate a 47% decrease from before human impacts, with a continuing decline of approximately 4% per decade.

A recent report by the Swiss Re global insurance company concludes that 20% of the world’s countries are at risk of their ecosystems collapsing due to a decline in biodiversity and consequent ecosystem services decline. (Ecosystem collapse is when processes and features supporting life are reduced or disappear, typically leading to a drastic reduction in the number of organisms living in an environment, and often mass extinction.) Swiss Re frame this decline as a critical issue because they estimate 55% of global GDP depends on high-functioning biodiversity and ecosystem services. The graphic below summarises the global distribution of the problem with an index developed by Swiss Re to compare biodiversity and ecosystem services by aggregating data across indicators. Included in the index are habitat intactness, pollination, air quality and local climate, water security, soil fertility, erosion control, coastal protection, food provision and timber provision.

Swiss Re Institute global biodiversity index.

Terrestrial and freshwater ecosystems

Transformation of land use over the last 8,000 years, from UN Global Land Outlook 2017.

Growth in consumption has driven land-use change and now 33% of the Earth’s land surface is dedicated to crop and animal agriculture. Such is the scale of this production, that it is responsible for 25% of greenhouse emissions (18% for animals and 7% for plants), and it consumes 75% of global freshwater resources. Destruction of habitats is a primary driver for biodiversity loss and the expansion of agriculture has mainly replaced tropical forests, wetlands and grasslands, which are home to the highest levels of biodiversity, as well as providing huge carbon sinks, protecting against extreme weather events and are difficult or impossible to replace.

Compared with pre-industrial times, it is estimated that 30% of global habitats have lost the ability to support long-term survival for the species they accommodate.

Forests cover 31% of the Earth’s land area and harbour most of terrestrial biodiversity, but are distributed unequally. Tropical and subtropical forest accounts for 42% of global cover, of the remaining cover, 24% is in boreal regions and 22% in temperate regions (see the UN The State of the World’s Forests report graphic below).

Globally, it is estimated that there has been a 46% reduction in the number of trees prior to human impacts, and approximately 10 billion trees are now felled annually. This deforestation is driven primarily by agriculture, with secondary factors accounting for <20% of total deforestation being urban, infrastructure and mining expansion.

In Latin America for example, 100 million hectares (or 1 million square km, or four times the land area of the UK) of tropical forest were lost in the period 1980 to 2000, mainly to cattle and palm oil plantations, and this ecosystem destruction continues today, pushing areas of the Amazon to a tipping point where rainforest is converted to open savannah. There is also a strong link between deforestation and the emergence of dangerous novel viruses.

Of the remaining forests, 66% have been subject to human impacts causing significant changes to their ecological processes and ability to naturally regenerate. Forests are being degraded primarily by logging for raw material and fuel, with secondary factors accounting for <20% of total degradation being forest fires and livestock.

Due to the expansion of new forest area, the net rate of forest loss has decreased by 50% since 1990 (an estimated 16 million hectares per year, compared with 10 million between 2015 to 2020), which is encouraging but still falls short of increasing forest cover in the near term to mitigate climate change and to preserve biodiversity. Replacement of old growth forests is not one-for-one: the ability of trees to absorb carbon dioxide improves with age and establishment of new forests also takes decades.

Forests by ecological zone.

Drivers of deforestation and degradation.

From the UN The State of the World’s Forests report 2020

Wetlands are inland areas of water such as lakes, rivers, floodplains, swamps, marshes, peatlands, mangroves and coral reefs, and include artificial areas such as reservoirs and rice paddies. Wetlands provide additional important ecosystem services: water purification and a source of food. More than 85% have been lost between 1700 (pre-industrial times) to 2000, and this has accelerated: the rate of destruction has been approximately three times faster than that of forests with 30% lost between 1970 and 2008. This destruction is driven primarily by land-use change due to agriculture, but also climate change, direct extraction and pollution. Globally, there are now approximately 5.7 million square kilometres of wetlands, or 6% of global land area. Creation of artificial wetlands has also accelerated, accounting for 12% of the total area, with mixed impacts on wildlife.

Once land has been converted to agricultural purposes from pristine habitats, it is further subject to degradation, primarily from intensive practices that do not allow soil to naturally regenerate between harvests and abundantly use chemicals for fertilisation and pest control. Secondary drivers are urbanisation, development of infrastructure, production of energy and mining. The UN’s Global Land Outlook report states that over the last 20 years, approximately 20% of land supporting the growth of plants shows persistent declining trends in productivity (16% of forests, 19% of grasslands and 27% of rangeland). The impacts vary significantly by region, with Africa and Europe having some of the highest levels of land degradation, with effects of future food production insecurity, water insecurity and reduced protection against extreme weather events.

Although land-use change and direct exploitation are dominant factors in the decline of terrestrial nature, the combined pollution of harmful substances and introduction of invasive alien species account for more than 20% of the declines in nature.

Anthropogenic pollution that negatively impacts nature takes numerous forms: chemicals released into the air (including greenhouse gasses causing global warming), contamination of soil and water with chemicals including hydrocarbons, heavy metals, fertilisers and pesticides, as well as raw sewage. Every year into the world’s waters, more than 80% of global untreated wastewater and 300-400 million tons of industrial waste is discharged.

The introduction of invasive terrestrial species have risen approximately 70% since 1970, due mainly to the growth of long-distance transport of goods and people, but increasingly from changing climates enabling habitation in new areas. Alien species can have significant direct effects on new ecosystems because of a lack of natural predators, because they carry diseases and because they outcompete native wildlife or prey on them. They can case indirect detrimental effects through impacting the ecosystem by, for example, changing soil chemistry or the intensity of wildfires. Alien species are a particular problem in marine ecosystems and are discussed in the next section.

Climate change, which is discussed in the final section, has a relatively smaller impact, but one that is increasing rapidly, and simultaneously exacerbating other drivers.

The oceans and marine ecosystems

The oceans cover approximately 70% of the earth’s surface, account for 90% of the earth’s ecosystems and hold 97% of the earth’s water. In marine ecosystems the primary driver of biodiversity loss is fishing, closely followed by sea and coastal land-use change. Only 3% of the ocean is now considered to be free from human impacts.

The vastness of the oceans have provided a significant buffer against the effects global warming by absorbing huge quantities of CO₂ and heat. Between 2009-2018, the oceans absorbed 23% of global CO₂ emissions, however absorption of CO₂ comes at the cost of acidification, meaning a decrease in the pH level. Since the 1980s, pH has been decreasing by 0.017-0.027 pH units per decade. Acidification is known to reduce the ability of marine organisms to form hard parts such as shells and skeletons, affecting their ability to grow and reproduce, but the exact effects on different species and their ecosystems is not yet well understood. This situation is not easy to remedy: if CO₂ emissions were to stop today, we would see a lag of one or more decades where acidification would continue and it is expected that it would take tens to hundreds of thousands of years for the oceans to return to a normal pH level. As a point of comparison, the largest extinction event of marine life occurred approximately 55 million years ago when global temperatures increased by 5-8 C with a rate of carbon emissions 16 times less than we have now, and over a course of 30,000 years.

The oceans are also estimated to have absorbed 90% of the energy accumulation from global warming between 1971 and 2010, which equates to a 0.11 C rise in the upper 75 m of water from 0.09-0.13 C. The effects of ocean heating are thermal expansion causing sea level rise (accounting for ~30% of the observed rise), increased melting of sea ice, increased stratification, reduced sequestering of atmospheric CO₂ and altering of ocean currents and storm tracks. In 2019, the global average sea temperature reached the highest recorded value, and more than 84% of the ocean experienced at least one abnormally high temperature event.

Stratification occurs when the sea’s surface warms but the water underneath does not, or because runoff from ice melt leads to a layer of less-salty water. Such a differential prevents nutrient-rich water from upwelling and mixing with the warmer, lighter water that supports more biodiversity, depriving marine life such as corals and algae, from food.

Ocean heating also causes the upper layer to be deoxygenated because oxygen is less soluble as water warms, making it harder for marine organisms that depend on oxygen to survive. Water with oxygen saturation between 1-30% is called hypoxic which leads to the death of fish and invertebrates such as worms and clams. Water with oxygen below 1% is called anoxic. In 2008, it was estimated that there were 400 hypoxic or anoxic ‘dead zones’, totalling 245,000 km$2$. Compounding these issues are feedback effects: warming water increases the metabolic rate of marine organisms that produce oxygen causing them to respire more and generate less oxygen; additionally, the lack of nutrients due to stratification inhibits photosynthesis by organisms such as phytoplankton (microscopic organisms that create organic compounds including oxygen from dissolved CO₂).

Because the oceans are so vast, it might not seem that deoxygenation and hypoxic areas pose a significant threat to marine ecosystems, but the area in which oxygen-rich waters occur is bounded by a naturally-occurring oxygen-minimum zone located beyond the continental shelves. The result is a narrow region of water on the coast of the continents, with only the upper part of the water column suitable for supporting most marine life. As hypoxic and anoxic regions grow, the part of the ocean supporting most marine life is shrinking, and the combination of deoxygenation and decreased nutrient supply is destabilising the base of complex food webs and ecosystems.

As if the effects of climate change on marine ecosystems were not bad enough, they are under attack from other issues including overfishing, eutrophication and pollution, and foreign species.

Fishing accounts for the extraction of approximately 110 million tonnes of fish and invertebrates every year, having increased from 28 million tonnes in 1950, and is the primary driver of biodiversity loss in oceans. Peak catches were in 1996 at 130 million tonnes, and have been declining at 1.2 million tonnes annually since then. Of these quantities, approximately 35% is bycatch and discarded and 12-18% is illegal and unregulated. More than 55% of ocean area is now subject to industrial fishing. Destructive and poorly-regulated practices like bottom trawling further cause almost irreparable habitat destruction for reefs, sponges and shellfish. These factors have led to a situation where 33% of fish stocks are caught at unsustainable levels, 60% are maximally sustainably fished and only 7% are underfished. Global populations of sharks and rays have declined by 71% since 1970.

Global fishing activity 2016 (Global Fishing Watch)

Eutrophication is a particular kind of pollution where excess nutrients are deposited in water, typically by land runoff or direct discharge of nitrogen and phosphorus from fertilisers used in agriculture, in industry or from sewage. The effect is that water becomes stratified into a layer where phytoplankton and other algaes rapidly multiply to create huge blooms. These blooms lower the oxygen levels in the water, can produce toxins and reduce the sunlight entering the water. Blooms can last days to months, and when they die their decomposition further deoxygenates the water, creating longer-lasting effects. Globally, algal blooms due to eutrophication are becoming more frequent and more toxic, in 2018 there were 300 reported incidents reported worldwide.

There are many other forms of non-nutrient marine pollution, including any substance or object introduced that has a harmful effect on ecosystems. There are a vast array of non-nutrient pollutants, each with their own harmful effects, but including pesticides, herbicides, fungicides, hydrocarbons, oil spills, plastics, heavy metals, radioactive waste and hot water from power stations. Like nutrient pollution, non-nutrient pollutants typically come from diffuse sources such as land runoff, wind-blown debris, atmospheric emissions, shipping, and oil extraction. These sources include waste material or chemicals from industrial, agricultural and residential activities. Industrial activities that do discharge contaminants directly into waterways or by incineration, discharge them as airborne particles that eventually settle. For example: pesticides are widely used in plant agriculture and antibiotics and growth hormones in livestock agriculture, transport produces substantial oil and rubber residues, and domestic use of a variety of chemicals and medicines leads to contaminants eventually finding their way into watercourses. To give one example it is estimated that the amount of plastic pollution has increased tenfold since 1980, and that 4 to 12 million tonnes of plastic entered the oceans in just one year in 2010. The Great Pacific Garbage Patch is estimated to be 700,000 square km and containing 80,000 tonnes of waste.

The introduction of foreign species into non-native habitats is another form of ocean pollution that has dramatic, negative effects on marine ecosystems and biodiversity. The movement happens primarily via the ballast water of ships. When a ship is docked, it will fill internal water reservoirs to counterbalance cargo. When the ship arrives at its destination and has unloaded, it will discharge its ballast, along with whatever stowaways it contains, from fish to microscopic organisms. Plastics are being recognised as another vector for species movement, with organisms that can attach themselves to floating plastic debris such as jellyfish polyps and algae. Recorded invasive species have doubled in the last 50 years, and the threat posed is acknowledged to be one of the main drivers impacting global biodiversity.

Global warming

Global warming induced climate change has a broad impact on nature and interacts with many of the other drivers discussed, exacerbating the negative impacts. With an accelerating rate of climate change, it poses a significant and growing risk to nature and humans.

There are clear indicators of the drivers and effects of global warming due to anthropogenic emissions (hazardous emissions caused by humans), as shown by the charts below. Atmospheric concentration of carbon dioxide (CO₂) is at 408 parts per million and 147% more than pre-industrial levels (PIL, of which 1750 is used as a representative baseline); methane (CH₄) is at 1,870 parts per billion and 259% more than PIL; and nitrous oxide (N₂O) is at 331 parts per billion and 123% of PIL. As a consequence, the global mean temperature and the global mean sea level are 1.2C and 20 cm higher respectively than PIL with year-on-year records being set. Temperature and sea-level rises are variable across the globe, for instance the Arctic has been experiencing sustained higher-than-average temperatures. The global oxygen (O₂) level has been declining since it was first measured in 1991, approximately 0.05% higher than the present day.

Climate Levels (2 Degrees Institute).

The 2018 IPCC ‘Global Warming of 1.5C’ report sets out the current status and trajectory of planetary temperature. Humans have caused approximately 1.2C of global warming since pre industrial levels. Historical emissions of greenhouse gasses are likely to cause further warming of 0.5C over the next two to three decades, with effects persisting for millennia. In other words, the possibility of avoiding 1.5C warming is now vanishingly small, even if there was an immediate halt of anthropogenic emissions. This puts us on a pathway of warming from 1-2 C warming and beyond, which is predicted to have significantly worse effects compared with 1.5C until the end of the century, including:

Sea ice extent Sep 2012, National Snow and Ice Data Center Boulder.

More frequent extreme weather events including heatwaves, heavy precipitation, severe drought, with effects including large-scale wild fires and flooding.
Higher average temperatures, with increases being 2 to 3 times greater in some regions.
More frequent ice-free Arctic, once per decade rather than once per century, with consequences for ocean circulation and more warming due to less reflection of heat (see 2012 ice extent image, showing a 12% loss per decade since 1979). 2020 has continued the trend with a later than ever ice-free arctic. Similar reductions in ice affect polar mountain glaciers and ice sheets.
Increased sea level rise driven by ocean warming and melting ice: 10cm more by 2100, affecting approximately 10.4 million more people.
Potential to trigger instabilities in the Greenland and Antarctic ice sheets, which would result in multi-meter sea-level rises.

These effects have consequent impacts in terrestrial ecosystems:

Species habitat loss through reduction in their climatically determined geographic range, a total of 6% to 18% loss for insects, 8% to 16% loss for plants and 4% to 8% loss for vertebrates. Some species will adapt by moving further north, but some will not be able to. Other species will exploit the opportunity, to move into areas once too cold, often with detrimental effects.
Transformation of terrestrial and wetland ecosystems, such as the expansion of desert, is 13% globally, vs 4% at 1.5C.
Thawing of permafrost with an area of 1.5 to 2.5 million km$^2$, which is approximately 40% of the arctic’s permafrost.

In ocean ecosystems:

Tropical coral reef loss is almost total at >99%, compared with 70-90% lost at 1.5C.
Substantial changes to ocean chemistry leading to acidification, hypoxia and dead zones.
Increasing numbers of jellyfish, particularly in blooms.

On water resources:

Increase in water scarcity by up to 50%.
Reduced food security caused by reduced crop yields, reduced fisheries (twice the level of decline compared with 1.5C) and reduced production livestock.
Substantial decline in fisheries productivity at low latitudes.

And impact humans as well:

Substantial increase in human exposure to flooding, affecting 10 million more people.
Increased negative consequences to human health due to heat, diseases and malnutrition, with greater risks in urban areas.
Pest species such as mosquitos and ticks that spread disease, and locusts and beetles that ruin crops.
Increased poverty.

Limiting global warming to 1.5-2 C requires nothing short of immediate and dramatic reductions in global emissions to reach net zero CO₂ and similar reductions in gasses such as methane, but policy and aspirations fall short of the change necessary. The charts below illustrate the different pathways that can be taken, and this stark contrast: current pledges and targets fall 50% short of the expected reduction of emissions to limit warming to 1.5 C under the Paris agreement and 30% of the expected emissions for 2 C. By the end of the century, we will end up with around 4 C of warming if we carry on as normal, but still almost 3 C with the realisation of current policy and pledges.

Climate Action Tracker 2030 emissions gaps.

Climate Action Tracker 2100 warming projections.

Final thoughts

This note attempts to concisely and objectively summarise the issues surrounding human impact on nature. Since I’m not an expert, it necessarily skims along the top of what are hugely complex issues. What I do hope however is that it conveys the magnitude and gravity of the situation for nature on earth and how the contributing issues are deeply interconnected.

Climate change is now beginning to be taken more seriously and is increasingly becoming part of normal discourse. But the declines in biodiversity and ecosystem services are generally poorly understood and regarded as risks, but currently have a disproportionately greater impact on humans with issues such as access to freshwater, air pollution and protection from extreme weather. The UN Global Assessment Report finds that negative trends in nature will continue until 2050 and beyond due to the projected impacts of increasing land-use change, exploitation of organisms and climate change under current trajectories. These impacts will also be distributed unevenly and will affect many of the world’s indigenous people and poorest communities first.

The ongoing assessment of the state of nature and modelling of the future are imperfect and we cannot fully understand the consequences of human actions. What we can be sure about however is that our situation is unprecedented in history. Measured against the earth’s history, the time frame for these effects to become catastrophic is just a blink of an eye. Should things change dramatically tomorrow, many of these impacts are locked in for decades. Momentum to mitigate these issues is building but will it be enough, and in time?

The UN report concludes that avoiding such a scenario requires systematic, transformative change across across economic, social, political and technological factors. Everyone has a part to play.

References / further reading

Climate Action Tracker, 2030 emissions gaps.
Climate Levels, live graphs of atmospheric concentrations of greenhouse gasses and global mean temperature, sea level and oxygen level.
Deep Adaptation: A Map for Navigating Climate Tragedy, Jem Bendell, 2018.
Global biodiversity outlook 5, Secretariat of the Convention on Biological Diversity 2020.
Global Fishing Watch
Global Forest Watch
Global Warming & Climate Change Myths
Global Wetland Outlook: State of the World’s Wetlands and their services to people, Ramsar Convention on Wetlands 2018.
Ocean Pollution: Causes and Effects, Deep Ocean Facts.
One Ocean Project, issue briefs
State of the World’s Forests 2020. In brief
Stung! On Jellyfish Blooms and the Future of the Ocean, Lisa-ann Gershwin, 2013.
Swiss Re Institute’s report on Biodiversity and Ecosystem Services: A business case for re/insurance (Guardian coverage)
The future is grim, Cache Baba, 2019.
UK National Ecosystem Assessment (2014).
UN Global Assessment Report on Biodiversity and Ecosystem Services (UN blog article with good summary of facts) (Guardian coverage)
UN Global Environment Outlook 6, 2019.
UN Global Land Outlook, UN Convention to Combat Desertification (UNCCD), 2017. (Guardian coverage)
UN State of The World’s Forests 2020 report, UN Food and Agriculture Organization.
WWF Living Planet Report 2018: Aiming Higher (Guardian coverage)
WWF Living Planet Report 2020: Bending the Curve of Biodiversity Loss (Guardian coverage)
World Meteorological Organization, Statement on the State of the Global Climate in 2019
World of Change, satellite imagery of the changing Earth surface from NASA Earth Observatory.

Error-correcting codes

2020-05-02T00:00:00+02:00

Error correcting codes (ECCs) are used in computer and communication systems to improve resiliency to bit flips caused by permanent hardware faults or transient conditions, such as neutron particles from cosmic rays, known generally as soft errors. This note describes the principles of Hamming codes that underpin ECC schemes, ECC codes are constructed, focusing on single-error correction and double error detection, and how they are implemented.

ECCs work by adding additional redundant bits to be stored or transported with data. The bits are encoded as a function of the data in such a way that it is possible to detect erroneous bit flips and to correct them. The ratio of the number of data bits to the total number of bits encoded is called the code rate, with a rate of 1 being a an impossible encoding with no overhead.

Simple ECCs

Parity coding adds a single bit that indicates whether the number of set bits in the data is odd or even. When the data and parity bit is accessed or received, the parity can be recomputed and compared. This is sufficient to detect any odd number of bit flips but not to correct them. For applications where the error rate is low, so that only single bit flips are likely and double bit flips are rare enough to be ignored, parity error detection is sufficient and desirable due to it’s low overhead (just a single bit) and simple implementation.

Repetition coding simply repeats each data bit a fixed number of times. When the encoded data is received, if each of the repeated bits are non identical, an error has occurred. With a repetition of two, single-bit errors can be detected but not corrected. With a repetition of three, single bit flips can be corrected by determining each data bit as the majority value in each triple, but double bit flips are undetectable and will cause an erroneous correction. Repetition codes are simple to implement but have a high overhead.

Hamming codes

Hamming codes are an efficient family of codes using additional redundant bits to detect up to two-bit errors and correct single-bit errors (technically, they are linear error-correcting codes). In them, check bits are added to data bits to form a codeword, and the codeword is valid only when the check bits have been generated from the data bits, according to the Hamming code. The check bits are chosen so that there is a fixed Hamming distance between any two valid codewords (the number of positions in which bits differ).

When valid codewords have a Hamming distance of two, any single bit flip will invalidate the word and allow the error to be detected. For example, the valid codewords 00 and 11 are separated for single bit flips by the invalid codewords 01 and 10. If either of the invalid words is obtained an error has occurred, but neither can be associated with a valid codeword. Two bit flips are undetectable since they always map to a valid codeword. Note that parity encoding is an example of a distance-two Hamming code.

00 < Valid codeword
|
10 < Invalid codeword (obtained by exactly 1 bit flip)
|
11 < Valid codeword

With Hamming distance three, any single bit flip in a valid codeword makes an invalid one, and the invalid codeword is Hamming distance one from exactly one valid codeword. Using this, the valid codeword can be restored, enabling single error correction. Any two bit flips map to an invalid codeword, which would cause correction to the wrong valid codeword.

000 < Valid codeword
 |
001
 |
011
 |
111 < Valid codeword

With Hamming distance four, two bit flips moves any valid codeword Hamming distance two from exactly two valid codewords, allowing detection of two flips but not correction. Single bit flips can be corrected as they were for distance three. Distance-four codes are widely used in computing, where is it often the case where single errors are frequent, double errors are rare and triple errors occur so rarely they can be ignored. These codes are referred to as ‘SECDED ECC’ (single error correction, double error detection).

0000 < Valid codeword
 |
0001
 |
0011 < Two bit flips from either codeword.
 |
0111
 |
1111 < Valid codeword

Double errors can be corrected with a distance-five code, as well as enabling the detection of triple errors. In general, if a Hamming code can detect $d$ errors, it must have a minimum distance of $d+1$ so there is no way $d$ errors can change one valid codeword into another one. If a code can correct $d$ errors, it must have a minimum distance of $2d+1$ so that the originating code is always the closest one. The following table summarises Hamming codes.

Distance	Max bits corrected	Max bits detected
2	0	1	Single error detection (eg parity code)
3	1	1	Single error correction (eg triple repetition code)
4	1	2	Single error correction, double error detection (a ‘SECDED’ code)
5	2	2	Double error correction
6	2	3	Double error correction, triple error detection

Creating a Hamming code

A codeword includes the data bits and checkbits. Each check bit corresponds to a subset of the data bits and it is set when the parity of those data bits is odd. To obtain a code with a particular Hamming distance, the number of check bits and their mapping to data bits must be chosen carefully.

To build a single-error correcting (SEC) code that requires Hamming distance three between valid codewords, it is necessary for:

The mapping of each data bit to check bits is unique.
Each data bit to map to at least two check bits.

To see why this works, consider two distinct codewords that necessarily must have different data bits. If the data bits differ by:

1 bit, at least two check bits are flipped, giving a total of three different bits.
2 bits, these will cause at least one flip in the check bits since any two data bits cannot share the same check-bit mapping (ie by taking the XOR of the two check bit patterns). This also gives a total of three different bits as required.
3 bits, this is already sufficient to give a Hamming distance of three.

To build a SECDED code that requires Hamming distance of four between valid codewords, it is necessary for:

The mapping of each data bit to check bits is unique.
Each data bit to map to at least three check bits.
Each check bit pattern to have an odd number of bits set.

Following a similar argument, consider two distinct codewords, data differing by:

1 bit flips three check bits, giving a total of four different bits.
2 bits flip check bits in two patterns, and since any two odd-length patterns must have at least two non-overlapping bits, the results is at least two flipped bits, giving a total of four different bits. For example:

Check bits:  0 1 2 3
data[a]      x x x
data[b]        x x x
-----------  --------
Flips        x     x

Check bits:  0 1 2 3 4
data[a]      x x x
data[b]      x x x x x
----------   ---------
Flips              x x

3 bits flip check bits in three patterns, and this time it is possible to overlap odd-length patterns in such a way that a minimum of 1 bit is flipped. For example:

Check bits:  0 1 2 3 4
data[a]      x x x
data[b]        x x x
data[c]      x     x x
-----------  ---------
Flips                x

Check bits:  0 1 2 3 4
data[a]      x x x x x
data[b]      x x x
data[c]      x     x x
-----------  ---------
Flips        x

4 bits is already sufficient to provide a Hamming distance of four.

An example SEC code for eight data bits with four parity bits:

Check bits:  0 1 2 3
data[0]      x x x
data[1]        x x x
data[2]      x   x x
data[3]      x x   x
data[4]      x x
data[5]        x x
data[6]          x x
data[7]      x     x

An example SECDED code for eight data bits with five parity bits:

Check bits:  0 1 2 3 4
data[0]      x x x
data[1]      x x   x
data[2]      x   x x
data[3]        x x x
data[4]      x x     x
data[5]      x   x   x
data[6]        x x   x
data[7]      x     x x

Note that mappings of data bits to check bits can be chosen flexibly, providing they maintain the rules that set the Hamming distance. This flexibility is useful when implementing ECC to reduce the cost of calculating the check bits. In contrast, many descriptions of ECC that I have found in text books and on Wikipedia describe a specific encoding that does not acknowledge this freedom. The encoding they describe allows the syndrome to be interpreted as the bit index of the single bit error, by the check bit in position $i$ covering data bits in position $i$. Additionally, they specify that parity bits are positioned in the codeword at power-of-two positions, for no apparent benefit.

Implementing ECC

Given data bits and check bits, and mapping of data bits to check bits, ECC encoding works by calculating the check bits from the data bits, then combining data bits and check bits to form the codeword. Decoding works by taking the data bits from a codeword, recalculating the check bits, then calculating the bitwise XOR between the original check bits and the recalculated ones. This value is called the syndrome. By inspecting the number of bits set in the syndrome, it is possible to determine whether there has been an error, whether it is correctable, and how to correct it.

Using the SEC check-bit encoding above, creating a codeword from data[7:0], the check bits are calculated as follows (using Verilog syntax):

assign check_word[0] = data[0] ^ data[2] ^ data[3] ^ data[4] ^ data[7];
assign check_word[1] = data[0] ^ data[1] ^ data[3] ^ data[4] ^ data[5];
assign check_word[2] = data[0] ^ data[1] ^ data[2] ^ data[5] ^ data[6];
assign check_word[3] = data[1] ^ data[2] ^ data[3] ^ data[6] ^ data[7];

And the codeword formed by concatenating the check bits and data:

assign codeword = {check[3:0], data[7:0]};

Decoding of a codeword, splits it into the checkword and data bits, recomputes the check bits and calculates the syndrome:

assign {old_check_word, old_data} = codeword;
assign new_check_word[0] = ...;
assign new_check_word[1] = ...;
assign new_check_word[2] = ...;
assign new_check_word[3] = ...;
assign syndrome = new_check_word ^ old_check_word;

When single bit errors occur, the syndrome will have the bit pattern corresponding to a particular data bit, so a correction can be applied by creating a mask to flip the bit in that position:

unique case(syndrome)
  4'b1110: correction = 1<<0;
  4'b0111: correction = 1<<1;
  4'b1011: correction = 1<<2;
  4'b1101: correction = 1<<3;
  4'b1100: correction = 1<<4;
  4'b0110: correction = 1<<5;
  4'b0011: correction = 1<<6;
  4'b1001: correction = 1<<7;
  default: correction = 0;
endcase

And using it to generate the corrected data:

assign corrected_data = data ^ correction;

The value of the syndrome can be further inspected to signal what action has been taken. If the syndrome is:

Equal to zero, no error occurred.
Has one bit set, then this is a flip of a check bit and can be ignored.
Has a value matching a pattern (three bits set or two bits in the adjacent positions), a correctable error occurred.
Has a value not matching a pattern (two bits set in the other non-adjacent positions: 4'b1010, 4'b0101), or four bits set, a multi-bit uncorrectable error occurred.

The above SECDED check-bit encoding can be implemented in a similar way, but since it uses only three-bit patterns, mapping syndromes to correction masks can be done with three-input AND gates:

unique case(syndrome)
  syndrome[0] && syndrome[1] && syndrome[2]: correction = 1<<0;
  syndrome[0] && syndrome[1] && syndrome[3]: correction = 1<<1;
  syndrome[0] && syndrome[2] && syndrome[3]: correction = 1<<2;
  syndrome[1] && syndrome[2] && syndrome[3]: correction = 1<<3;
  syndrome[0] && syndrome[1] && syndrome[4]: correction = 1<<4;
  syndrome[0] && syndrome[2] && syndrome[4]: correction = 1<<5;
  syndrome[1] && syndrome[2] && syndrome[4]: correction = 1<<6;
  syndrome[0] && syndrome[3] && syndrome[4]: correction = 1<<7;
  default:                                   correction = 0;
endcase

And any syndromes with one or two bits set are correctable, and otherwise uncorrectable.

References / further reading

Error correction code, Wikipedia.
Hamming code, Wikipedia.
ECC memory, Wikipedia.
Error detecting and error correcting codes (PDF), R. W. Hamming, in The Bell System Technical Journal, vol. 29, no. 2, pp. 147-160, April 1950.
Constructing an Error Correcting Code (PDF), Andrew E. Phelps, University of Wisconsin, Madison, November 2006.

Recycled allotment shed

2019-11-10T00:00:00+01:00

A friend was in need of a shed on her allotment to store tools and as a place to shelter in the rain, so I helped her to build one. The aim was to build something solid that would stand up to the elements (unlike most allotment sheds), to use recycled materials as far as possible, and ideally to fit within a £100 budget.

The main costs were the structural timber, which was sourced from the Bristol Wood Recycling Project:

~15m of 2x3” softwood timber;
~60m of 1.5x2.5” softwood timber.

Also from the BWRP were: sheets of 12mm ply for the floor and roof, solid wood planks for the door, an odd piece of shelving which worked brilliantly as a big window sill, baton for the window frame. Other costs were: two boxes of screws and roofing nails (Screwfix), acrylic sheet for the window (Wickes). Everything else was sourced for free, from friends or found on the streets of Bristol: breeze blocks for the base, pallet wood for the cladding, miscellaneous timber for the frame, roof felt and felt glue and hinges and shackles for the door.

I didn’t keep details of all the money spent, but the final cost was approximately £150 and the end result was a sturdy shed that should last quite a few years.

The existing structure that was intended to become a shed but never did.

The site with the old shed cleared.

Breeze blocks in position for a base.

The floor in position.

Progress of the frame construction, finally with the roof in place.

Details of the roof notches to sit level on the frame.

Details of the pallet-wood cladding.

With the window frame installed (now looking more like a shed, rather than a ticket office).

The completed shed, with window and door installed. One final job is to install guttering on the back edge of the roof, which can feed a water butt.

New chips for machine intelligence

2019-10-04T00:00:00+02:00

This note summarises details of some of the new silicon chips for machine intelligence. Its aim is to distil the most important implementation and architectural details (at least that are currently available), to highlight the main differences between them. I’m focusing on chips designed for training since they represent the frontier in performance and capability. There are many chips designed for inference, but these are typically intended for use in embedded or edge deployments.

In summary:

*Speculated
† Figures given for a single chip
Chip	Process	Die size mm²	TDP (W)	On-chip RAM (MB)	Peak FP32 (TFLOPs)	Peak FP16 (TFLOPs)	Mem b/w (GB/s)	IO b/w (GB/s)
Cerebras WSE^†	TSMC 16nm	510	180	225	40.6	n/a	0	Unknown
Google TPU v1	28nm	Unknown	75	28	n/a	23 (INT16)	30 (DDR3)	14
Google TPU v2	20nm*	Unknown	200*	Unknown	Unknown	45	600 (HBM)	8*
Google TPU v3	16/12nm*	Unknown	200*	Unknown	Unknown	90	1200 (HBM2)*	8*
Graphcore IPU	16nm	800*	150	300	Unknown	125	0	384
Habana Gaudi	TSMC 16nm	500*	300	Unknown	Unknown	Unknown	1000 (HBM2)	250
Huawei Ascend 910	7nm+ EUV	456	350	64	Unknown	256	1200 (HBM2)	115
Intel NNP-T	TSMC 16FF+	688	250	60	Unknown	110	1220 (HBM2)	447
Nvidia Volta	TSMC 12nm FFN	815	300	21.1	15.7	125	900 (HBM2)	300
Nvidia Turing	TSMC 12nm FFN	754	250	24.6	16.3	130.5	672 (HBM2)	100

Cerebras Wafer-Scale Engine

The Cerebras Wafer-Scale Engine (WSE) is undoubtedly the most bold and innovative design to appear recently. Wafer-scale integration is not a new idea, but integration issues to do with yield, power delivery and thermal expansion have made it difficult to commercialise (see the 1989 Anamartic 160 MB solid state disk). Cerebras use this approach to integrate 84 chips with high-speed interconnect, uniformly scaling the 2D-mesh based interconnect to huge proportions. This provides a machine with a large amount of memory (18 GB) distributed among a large amount of compute (3.3 Peta FLOPs peak). It is unclear how this architecture scales beyond single WSEs; the current trend in neural nets is to larger networks with billions of weights, which will necessitate such scaling.

General details:

Announced August 2019.
46,225 mm² wafer-scale integrated system (215 mm x 215 mm) om TSMC 16 nm.
1.2T transistors.
Many individual chips: a total of 84 (12 wide by 7 tall).
18 GB total of SRAM memory, distributed among cores.
426,384 simple compute cores.
Silicon defects can be repaired by using redundant cores and links to bypass a faulty area. It appears that each column includes one redundant core, leaving 410,592 functional cores.
Speculated clock speed of ~1 GHz and 15 kW power consumption.

Interconnect and IO:

Interconnections between chips, across scribe lines, with wiring added in post-processing steps after conventional wafer manufacturing.
IOs brought out on east and west edges of wafer, which is limited by the pad density on each edge. It is unlikely there are any high-speed SerDes since these would need to be integrated in every chip, making a sizeable part of the wafer area redundant apart from chips with edges on the periphery.
2D mesh-based interconnect, supports single-word messages. According to their whitepaper: “The Cerebras software configures all the cores on the WSE to support the precise communication required” indicating that the interconnect is statically configured to support a fixed communication pattern.
Interconnect requires static configuration to support specific patterns of communication.
Zeros not transmitted on the interconnect to optimise for sparsity.

Each core:

Is ~0.1 mm² of silicon.
Has 47 kB SRAM memory.
Zeros not loaded from memory and zeros not multiplied.
Assumed FP32 precision and scalar execution (can’t filter zeros from memory with SIMD).
FMAC datapath (peak 8 operations per cycle).
Tensor control unit to feed the FMAC datapath with strided accesses from memory or inbound data from links.
Has four 8 GB/s bidirectional links to its neighbours.

Each die:

Is 17 mm x 30 mm = 510 mm² of silicon.
Has 225 MB SRAM memory.
Has 54 x 94 = 5,076 cores (two cores per row/column possibly unused due to repair scheme leaving 4,888 usable cores).
Peak FP32 performance of 40 Tera FLOPs.

References:

Google TPU v3

With few details available on the specifications of the TPU v3, it is likely an incremental improvement to the TPU v2: doubling the performance, adding HBM2 memory to double the capacity and bandwidth.

General details (per chip):

Announced May 2018.
Likely to be 16nm or 12nm.
200W estimated TDP.
105 TFLOPs of BFloat16, likely from doubling the MXUs to four.
Each MXU has dedicated access to 8 GB of memory.
Integrated in four-chip modules (pictured), 420 TFLOPs peak performance.

IO:

32 GB HBM2 integrated memory with access bandwidth of 1200 GBps (assumed).
PCIe-3 x8 assumed at 8 GBps.

References:

NextPlatform Tearing apart google’s TPU 3.0 AI coprocessor

Google TPU v2

The TPU v2 is designed for training and inference. It improves over the TPU v1 with floating point arithmetic and enhanced memory capacity and bandwidth with HBM integrated memory.

General details (per chip):

Announced May 2017.
Likely to be 20nm.
200-250W estimated TDP.
45 TFLOPs of BFloat16.
Two cores with scalar and matrix units.
Also supports FP32.
Integrated in four-chip modules (pictured), 180 TFLOPs peak performance.

Each core:

128x128x32b systolic matrix unit (MXU) with BFloat16 multiplication and FP32 accumulation.
8GB of dedicated HBM with access bandwidth of 300 GBps.
Peak throughput of 22.5 TFLOPs of BFloat16.

IO:

16 GB HBM integrated memory at 600 GBps bandwidth (assumed).
PCIe-3 x8 (8 GBps).

References:

Google TPU v1

Google’s first generation TPU was designed for inference only and supports only integer arithmetic. It provides acceleration to a host CPU by being sent instructions across PCIe-3, to perform matrix multiplications and apply activation functions. This is a significant simplification which would have saved much time in design and verification.

General details:

Announced in 2016.
331 mm² die on 28nm process.
Clocked at 700 MHz and 28-40W TDP.
28 MB on-chip SRAM memory: 24 MB for activations and 4 MB for accumulators.
Proportions of the die area: 35% memory, 24% matrix multiply unit, 41% remaining area for logic.
256x256x8b systolic matrix multiply unit (64K MACs/cycle).
INT8 and INT16 arithmetic (peak 92 and 23 TOPs/s respectively).

IO:

8 GB DDR3-2133 DRAM accessible via two ports at 34 GB/s.
PCIe-3 x 16 (14 GBps).

References:

Graphcore IPU

DISCLAIMER: I work at Graphcore, and all of the information given here is lifted directly from the linked references below.

The Graphcore IPU architecture is highly parallel with a large collection of simple processors with small memories, connected by a high-bandwidth all-to-all ‘exchange’ interconnect. The architecture operates under a bulk-synchronous parallel (BSP) model, whereby execution of a program proceeds as a sequence of compute and exchange phases. Synchronisation is used to ensure all processes are ready to start exchange. The BSP model is a powerful programming abstraction because it precludes concurrency hazards, and BSP execution allows the compute and exchange phases to make full use of the chip’s power resources. Larger systems of IPU chips can be built by connecting the 10 inter-IPU links.

General details:

16 nm, 23.6 bn transistors, ~800mm² die size.
1216 processor tiles.
125 TFLOPs peak FP16 arithmetic with FP32 accumulation.
300 MB total on-chip memory, distributed among processor cores, providing an aggregate access bandwidth of 45 TBps.
All model state held on chip, there is no directly-attached DRAM.
150 W TDP (300 W PCIe card).

IO:

2x PCIe-4 host IO links.
10x inter-card ‘IPU links’.
Total of 384 GBps IO bandwidth.

Each core:

Mixed-precision floating-point stochastic arithmetic.
Runs up to six program threads.

References:

Habana Labs Gaudi

Habana’s Gaudi AI training processor shares similarities with contemporary GPUs, particularly wide SIMD parallelism and HBM2 memory. The chip integrates ten 100G Ethernet links which support remote direct memory access (RDMA). This IO capability allows large systems to be built with commodity networking equipment, compared with Nvidia’s NVLink or OpenCAPI.

General details:

Announced June 2019.
TSMC 16 nm with CoWoS, assumed die size ~500mm².
Heterogeneous architecture with:
- a GEMM operations engine;
- 8 Tensor Processing Cores (TPCs);
- a shared SRAM memory (software managed and accessible via RDMA).
200W TDP for PCIe card and 300W TDP for the mezzanine card.
Unknown total on-chip memory.
Explicit memory management between chips (no coherency).

TPC core:

VLIW SIMD parallelism and a local SRAM memory.
Mixed precision: FP32, BF16, plus integer formats (INT32, INT16, INT8, UINT32, UINT8).
Random number generation.
Transcendental functions: Sigmoid, Tanh, Gaussian error linear unit (GeLU).
Tensor addressing and strided access.
Unknown local memory per TPC.

IO:

4x HBM2-2000 DRAM stacks providing 32 GB at 1 TBps.
10x 100GbE interfaces are integrated on-chip, supporting RDMA over Converged Ethernet (RoCE v2).
IOs are implemented with 20x 56 Gbps PAM4 Tx/Rx SerDes and can also be configured as 20x 50 GbE. This allows up to 64 chips to be connected with non-blocking throughput.
PCIe-4 x16 host interface.

References:

Huawei Ascend 910

Huawei’s Ascend also bears similarities to the latest GPUs with wide SIMD arithmetic and a 3D matrix unit, comparable to Nvidia’s Tensor Cores, a (assumed) coherent 32 MB shared L2 on-chip cache. The chip includes additional logic for 128 channel video decoding engines for H.264/265. In their Hot Chips presentation, Huawei described overlapping the cube and vector operations to obtain high efficiency and the challenge of the memory hierarchy with ratio of bandwidth to throughput dropping by 10x for L1 cache (in the core), 100x for L2 cache (shared between cores), and 2000x for external DRAM.

General details:

Announced August 2019.
456 mm² logic die on a 7+ nm EUV process.
Copackaged with four 96 mm² HBM2 stacks and ‘Nimbus’ IO processor chip.
32 DaVinci cores.
Peak 256 TFLOPs (32 x 4096 x 2) FP16 performance, double that for INT8.
32 MB shared on-chip SRAM (L2 cache).
350W TDP.

Interconnect and IO:

Cores interconnected in a 6 x 4 2D mesh packet-switched network, providing 128 GBps bidirectional bandwidth per core.
4 TBps access to L2 cache.
1.2 TBps HBM2 access bandwidth.
3x 30 GBps inter-chip IOs.
2x 25 GBps RoCE networking interfaces.

Each DaVinci core:

3D 16x16x16 matrix multiply unit providing 4,096 FP16 MACs and 8,192 INT8 MACs.
2,048 bit SIMD vector operations for FP32 (x64), FP16 (x128) and INT8 (x256).
Support for scalar operations.

References:

Intel NNP-T

This chip is Intel’s second attempt at an accelerator for machine learning, following the Xeon Phi. Like the Habana Gaudi chip, it integrates a small number of wide vector cores, with HBM2 integrated memory and similar 100 Gbit IO links.

General details:

27 bn transistors.
688 mm² die on TSMC 16FF+ TSMC with CoWoS.
32 GB HBM2-2400 in four 8 GB stacks integrated on a 1200 mm² passive silicon interposer.
60 MB on-chip SRAM memory distributed among cores and ECC protected.
Up to 1.1 GHz core clock.
150-250W TDP.
24 Tensor Processing Cluster (TCP) cores.
TPCs connected in a 2D mesh network topology.
- Separate networks for different types of data: control, memory and inter-chip communication.
- Support for multicast.
119 TOPs peak performance.

IO:

1.22 TBps HBM2 bandwidth.
64 lanes of SerDes with peak 3.58 Tbps aggregate bandwidth (28 Gbps each direction in each lane) for inter-chip IOs.
x16 PCIe-4 host interface (also supports OAM, Open Compute).

TPC core:

2x 32x32 BFloat16 multiplier arrays supporting FMAC operation with FP32 accumulation.
Vector FP32 and BFloat16 operations.
- Support for transcendental functions, random number generation, reductions and accumulations.
- Programmable FP32 lookup tables.
A separate convolution engine for non-MAC compute.
2.5 MB two-port private memory with 1.4 TBps read/write bandwidth.
Memory supports tensor transpose operation.
Communication interface supporting dynamic packet routing on the mesh (virtual channel, reliable transmission).

Scaling:

Up to 1024 chips with direct interconnections, providing the same distributed-memory programming model (explicit memory management, synchronisation primitives, message passing).
Scaling demonstrated up to 32 chips connected in a ring topology.

References:

Nvidia Volta

Volta introduces Tensor Cores, HBM2 and NVLink 2.0, from the Pascal architecture.

General details:

Announced May 2017.
815 mm² on TSMC 12nm FFN, 21.1 bn transistors.
300 W TDP (SXM2 form factor).
6 MB L2 cache.
84 SMs, each containing: 64 FP32 CUDA cores, 32 FP64 CUDA cores and 8 Tensor Cores (5376 FP32 cores, 2688 FP64 cores, 672 TCs).
Tensor Cores perform 4x4 FMA, achieving 64 FMA ops/cycle, and 128 FLOPs.
128 KB L1 data cache/shared memory and four 16K 32-bit registers per SM.

IO:

32 GB HBM2 DRAM, at 900 GBps bandwidth.
NVLink 2.0 at 300 GBps.

References:

Nvidia Turing

Turing is an architectural revision of Volta, manufactured on the same 16 nm process, but with fewer CUDA and Tensor cores. It consequently has a smaller die size and lower power envelope. Apart from ML tasks, it is designed to perform real-time ray tracing, for which it also used the Tensor Cores.

General details:

Announced September 2018.
TSMC 12nm FFN, 754 mm² die, 18.6 bn transistors.
260 W TDP.
72 SMs, each containing: 64 FP32 cores, and 64 INT32 cores, 8 Tensor cores (4608 FP32 cores, 4608 INT32 cores and 576 TCs).
Peak performance with boost clock: 16.3 TFLOPs FP32, 130.5 TFLOPs FP16, 261 TFLOPs INT8, 522 TFLOPs INT4.
24.5 MB on-chip memory between 6 MB L2 cache and 256 KB SM register files.
1455 MHz base clock.

IO:

12x 32-bit GDDR6 memory providing 672 GBps aggregate bandwidth.
2x NVLink x8 links, each providing up to 26 GBps bidirectional.

References:

Testing silicon logic with scan structures

2019-04-18T00:00:00+02:00

Design for test (DFT) is a methodology for silicon integrated-circuit chips to enable devices to be tested during and after manufacture. Such testability permits the detection of faults due to problems in the manufacturing processes that would adversely affect the functional behaviour of the device. This note explains the concepts of a particular DFT methodology called scan test, which modifies the logic of a design in such a way that the functional behaviour is preserved but classes of faults become detectable.

Scan chains

A chip can be viewed as a set of input ports that feed into a series of combinatorial and sequential cells, and arrive at a set of output ports. To test that the function of the chip is correct, it would suffice to check that a particular output is generated for a particular input, or sequence of inputs and outputs. However, if the intervening logic contains sequential elements, is computationally difficult to setup inputs each clock cycle to observe desired values on all outputs. Doing so requires sequencing of state transitions through the logic, but the size of the state space grows exponentially with the number of states.

Conceptually, a silicon chip is a set of input ports driving logic with sequential elements, in turn driving output ports.

To avoid an intractable state space, the design is changed so that inputs and observable outputs are separated only by combinatorial logic. This is done by adding new controllable primary inputs and observable outputs, called scan chains. A scan chain adds three ports to the chip: a scan chain input, scan_in, a scan chain output scan_out and an enable scan_enable. All registers are converted by adding a multiplexer on the D pin, with one input connected to the data signal. The first scan-chain register has it’s other multiplexer input connected to scan_in. Subsequent scan registers take their other multiplexer inputs from the output of the previous register in the chain. The final register in the chain drives scan_out from it’s D pin. All multiplexers are controlled by scan_enable.

A standard flip flop (left) and a scanned flip flop with scan-in and scan-enable inputs (right).

Scan chain topology providing a set of controllable primary inputs and a set of observable outputs.

When scan_enable is pulled high, and the clock pulsed, data is shifted into each register in the chain. Each bit of a chain of N registers can be set in N clock cycles. When pulled low, the chip is in normal functional mode. These inputs allow a simple test procedure to be implemented:

Set scan_enable high (scan mode).
Shift in N bits of input data.
Set scan_enable low (functional mode).
Tick the clock once to propagate input vector though combinatorial logic into outputs.
Set scan_enable high (scan mode).
Shift out N bits of output data.
Check that the output data equals the input data transformed by the same logic function.

Since typical tests will contain large numbers of patterns, the time to test one pattern is critical. It is determined by the length of the chain, to shift in and out data. To reduce test time, additional scan chains can be introduced to allow shifting to be performed in parallel. Each chain adds scan_in and scan_out ports to the chip. The number of scan chains is chosen to trade off the physical requirements of the additional ports and routing with test time and coverage. To avoid many additional ports at the top level, a set of parallel scan chains can be driven by DFT logic that supplies compressed patterns to the inputs and compresses results from the outputs.

Parallel scan chains to reduce test time.

Wrapper chains

Typically, a chip is too complex to test with a single set of scan chains. Even with only combinatorial logic between primary inputs and observable outputs, it becomes computationally difficult to analyse to generate patterns that can effectively exercise it to achieve good coverage and fault isolation. Instead, a chip is divided into sub components, each of which is amenable to testing (an approach known as hierarchical DFT). The components are referred to as test cores and typically naturally correspond to functional blocks of the chip design.

It is necessary for a test core to be isolated from the rest of the design. At a chip-level primary inputs are controllable in that their values are always known. However, the values of an input to a test core are unknown and likely to be Xs. If X values propagate into a test core, coverage can be reduced, or worse, the testing methodology may be invalidated altogether. Isolation is achieved with wrapper chains that are inserted between the IO ports and the core logic of the design. A bypass multiplexer is inserted on the output of the wrapper scan register to control whether the input or output is used or driven respectively. If the input or output is directly connected to a register, then a bypass is not necessary.

Wrapper flops inserted on input and output ports.

A test core isolated with input and output wrapper chains. One or more additional scan chains may be connected to sequential elements of the core logic.

An input wrapper chain is the chain of registers that capture the primary inputs to the core, with their D inputs corresponding to each input of the test core. Some inputs may be omitted from the wrapper chain, such as clock, reset and test-related signals. Input wrapper chains are different to regular scan chains only in the way that their scan_enable is controlled. During test mode, the scan enable of the input wrapper is held high when the regular scan_enable is low and all other registers are in functional mode. The effect of this is that the input wrapper chain continues to shift in known values, rather than Xs from outside of the test core. When the input wrapper registers are not shared with any other test core, the captured values can be shifted out with the other test pattern results to ensure all of the registers are functioning correctly.

An output wrapper chain behaves exactly as an internal scan chain during test mode. However, when they are shared with an adjacent test core, their scan_enable is controlled differently since they will function as an input wrapper chain for that core, with the behaviour described above.

Test core B shares core B’s output wrapper chain, using it as an input wrapper chain in test mode.

X bounding

It may not be possible to add all registers into the scan chains for a design. In this case, to prevent Xs from propagating into the logic during test, all sources of Xs must be masked with known values. This is done by inserting a multiplexer to take the Q pin as input, with the other input as an alternative known value, typically from a register on a scan chain. The multiplexer is controlled by an xbnd_enable signal, which when set high will prevent X propagation during test mode, and otherwise maintains the functional behaviour of the circuit.

A X-source flop with bypass multiplexing of a known value.

References / further reading

Acknowledgements

Thanks to Evan Griffiths for his detailed explanations of DFT insertion, upon which this note is based.

RGB lightbox stacks

2018-12-31T00:00:00+01:00

The ‘RGB stacks’ lightboxes are an experiment with using high-power LEDs, generous volumes and translucent acrylic plastic to create big blocks of colour. They are constructed from 12 mm birch ply and each pixel measures 300 x 300 (outer dimensions). They are built as three columns of three pixels to allow them to be arranged in a square, a line, or in different locations. This note records some of the details of their construction. Although they are now functional, refinement of their controls and modulation continues to be a work in progress. This note records some of the details of how they were built (I will it updated with any new developments).

The project was inspired by a similar light box project (that unfortunately I can no longer find on the internet), but which was a single 3 x 3 cabinet achieving a similar block-colour effect. My motivation was to build something similar but that could also be used as subtle/ambient lighting, making use of the amazing colours and ability to accurately modulate LEDs to create smooth transitions between rich colours and interesting combinations.

An early experiment to see how the LED light diffuses through the acrylic in a plywood volume.

Construction of the stacks was straightforward: all panel dimensions are multiples of 300 and all joints biscuited and glued to avoid any visible fixings. (I unfortunately don’t have any pictures of the construction of the stacks.)

Detail of the lip added to seat the acrylic panels and the narrow double-sided tape to fix them in place.

The acrylic panels were cut to fit the inner box dimensions exactly, but with small variations in the dimensions of the boxes. Getting them all to fit was a long process of sanding down each one to fit a particular opening. A secure fit of the panels was achieved with tight tolerances and narrow double-sided sticky tape (pictured above right).

The boxes with all acrylic panels in place.

Pairs of white and RGB LEDs were mounted on aluminium bar in each pixel. The LED were fixed in place with small bolts. I made small plastic washers to avoid shorting any of the contacts with the bolt heads. Although the aluminium bar probably provides a sufficient heat sink, I added additional heatsink blocks on the rear side, fixed with thermal glue (these were cut up from larger IC heatsinks). All of the LED wiring was conveniently done with CAT6 cable, using all of the eight cores to wire the four channels. Each channel draws about 1 W at 5 V (200 mA), which is within the specification of the CAT6.

The system used to mount the LEDs in the middle of each box.

The boxes with all of the LEDs and their cabling installed.

Each box has a rear plug panel. The central box acts as a master and has connections for power, Ethernet, and provides serial data and power to the other outer boxes.

The master and slave plug panels for each stack.

The inter-box wiring uses 5-pin XLR sockets, to carry power, ground and the differential pair for the serial signal. The wires were made with a dual-core power wire (sufficient to carry the required power at 5V) with a another dual-core wire for the serial, wrapped in a heatshrink coat.

Custom cabling to connect the left and right hand boxes, containing a dual-core wire for power and two CAT-6 cores for serial data.

The electronics for the LED drivers is described in a separate note. Each of the LED driver boards has three outputs, so four boards are required to drive a single stack. The Raspberry Pi microcontroller is used to control all the pixels, and does so with a dual-wire RS-485 serial bus. This bus connects each of the driver boards in series, and the outer boxes are wired in parallel. Despite some concerns about this topology from notes on the MAX-485 driver IC datasheet and that I didn’t use terminating resistors, the arrangement performs fine.

So that I could easily access the electronics, I integrated the drivers and their wiring on a plywood board that sits in the base of a stack. The master stack has the power supply, taking mains voltage and providing 5V up to 60W (12A) for the three stacks. See the table below for calculated power of the LEDs only. Note that the power supply does not output enough power do drive the boxes comfortably (80W would be more comfortable).

Channel	Voltage (V)	Current (A)	LED power (W)	Driver efficiency	Driver power (W)
Red	2.4	0.3	0.72	0.48	1.5
Green	3.4	0.3	1.02	0.68	1.5
Blue	3.5	0.3	1.05	0.7	1.5
White	3.2	0.3	0.96	0.64	1.5
Total (per pixel)	-	-	3.75	-	6
Total (per stack)	-	-	11.25	-	18
Total	-	-	33.75	-	54

To check the above power numbers I performed some measurments with a clamp meter of the central stack:

With all LEDs off, the quiesence current is 360 mA at 5 V, dissipating 1.8 W.
With all LEDs on at full intensity, the current is 4.75 A at 5 V, dissipating 23.75 W.

These numbers are slightly higher than expected, due to the LED driver current ranging between 0.357 mA (blue) and 0.370 mA (green).

Integration of the electronics into the master stack (similar for the outer stacks).

The back panels fasten with M8 bolts into T-nuts.

Details of the back plates, fastened by M8 Allen key bolts.

The boxes in a complete state

It’s hard to capture the quality of the effect of the light boxes on camera. The images below are two early tests: left just using a lamp in one of the pixels, right with no blending of the RGB channels.

Seeing the effect of the acrylic diffusion with just a lamp in one of the cells.

The first RGB test of a stack.

The behaviour of the boxes is determined by the PIC programs and the Raspberry Pi. Since changes to the PIC program requires each of the boards to be programmed individually and for each program to be compiled with a unique identifier, this is not an easy way to experiment with modulating schemes. Instead, each PIC is programmed only to change the output intensity, and experimentation can be done using Python on the Raspberry Pi over SSH. In these scheme, updates are sent to the LED drivers synchronously, as a frame. At 115,200 bps baud rate over RS485, this is sufficient to deliver up to 389 updates per second. In practice there are overheads that will reduce this. If, for smooth graduations between colours the frame rate was not adequate, an optimisation could be to expand the capability of the PIC driver code to perform more complex actions like sweeps over intensity ranges, thereby reducing the number of updates required.

As I mentioned, these boxes are not yet complete. To finish them, I want to add a button panel to switch them on off and control the lighting patterns.

References

Three-channel high-power LED driver

2018-12-30T00:00:00+01:00

This note describes an LED driver I designed for a lighting project. I decided on a custom solution because I couldn’t find any suitable boards available to buy at a reasonable price. The intended application (which I will describe in another note) requires 12 high-power (~1W) LEDs to be driven individually a 3 by 3 grid measuring approximately 1 metre square, with each of the nine cell containing a red, green, blue and white LED.

I embarked on this project without any experience of designing PCBs, and with relatively little knowledge of electronics, so it was a steep but fantastic learning experience. I wanted to record some of the details of this project for others who may find them useful, as I did with some of the resources I’ve linked to at the end. All of the PCB design files and processor firmware are available on GitHub.

Design

The board is designed around the following main IC components:

Microchip PIC12F1572 for PWM LED control and serial communication. This was the simplest PIC I could find that had multiple PWM outputs and UART serial communication capability. It’s an 8-bit device with 16-bit PWMs and 3.5 KBs of program memory.
Maxim MAX485 for communication to multiple of these boards. This IC provides half-duplex communication over a 2-wire differential pair using the RS485 protocol, allowing communication over long distances. Importantly it supports multiple drops, so a number of boards can be wired together with a bus. I chose this as it is very simple to integrate, with no additional components required, compared to the capacitors necessary for the MAX232. Talking to the PIC, this can support a baud rate of 115,200 bps.
ON Semiconductor CAT4101 for driving LEDs with a constant-current up to 1A with PWM control. Because the temperature fluctuations of high-power LEDs affects their forward voltage, driving them with a constant current is important to avoid damage due to over voltage. These chips neatly integrate this with the PWM control ability. Their only downsides were their cost (~£2 each - with 36 of them needed for my lighting project, they were the greatest single expense) and package which isn’t designed to be hand soldered.

Other features:

Header for in-circuit PIC programming. To disconnect the UART pins (required for programming) and to attach a 10K pull up resistor, I included three jumper headers. However, I found connecting the pull up wasn’t necessary for programming.
Screw terminals for all installation connections.
Indicator LEDs for UART TX and RX directions, and power.

I designed the PCB using the excellent KiCAD and had it manufactured very cheaply by Seeed Studio in Shenzhen, China.

Here’s the schematic:

Parts list

Quantity	Package	Description
3	TO-263	CAT4101 LED drivers 5.5V
1	DIP-8	PIC12F1572 microcontroller
1	DIP-8	MAX485 serial interface
3	0805	Green LEDs
3	0805	Resistor 10K
3	0805	Resistor 1.4K
3	0805	Resistor 510
5	0805	Capacitor 0.1 uF
3	SOT-23	2N7002 N-channel MOSFET 300 mA
4	-	2 way 5mm pitch terminal blocks
1	-	3 way 5mm pitch terminal blocks
12	-	2.54mm pitch pin headers
3	-	2.54mm pin header jumper caps

The CAT4101 sense resistors are chosen to give a constant current close to 300 mA, at 1.4 KOhms. See the CAT4101 datasheet for more details.

For reference, I have assumed the following parameters of the LEDs I used (you should however check the datasheet for a particular LED):

Colour	Typical forward voltage (@ 350 mA)	Part	Reference
Red	2.4	3W RGB module	Datasheet (PDF)
Green	3.4	3W RGB module	Datasheet (PDF)
Blue	3.5	3W RGB module	Datasheet (PDF)
White	2.8-3.4	1W Ice White LED (Bridgelux 9000-15000k)	Future Eden

The CAT4101 is a linear driver, so it effectively acts as a variable resistor to deliver constant current, with an efficiency of $V_{led}/V_{supply}$. A disadvantage of driving each LED individually is that its efficiency can be low, down to 50%. The power delivered to the LED is $I_{led} \times V_{led}$ and the power dissipated by the driver is $I_{led} \times V_{supply}$ (not including quiescent power).

Channel	Voltage (V)	Current (A)	LED power (W)	CAT4101 efficiency	Driver power (W)
Red	2.4	0.3	0.72	0.48	1.5
Green	3.4	0.3	1.02	0.68	1.5
Blue	3.5	0.3	1.05	0.7	1.5
White	3.2	0.3	0.96	0.64	1.5

Measurements of each of the LED channels using a current clamp meter showed that the current drawn ranges from 357 mA to 370 mA.

Programming

The intention of the PIC microcontrollers is to react to a simple set of commands sent via the serial interface. In deployment, an array of these driver boards would be controlled by another processor broadcasting on the RS485 bus. I used a Raspberry Pi with an RS485 shield to do this.

At a minimum, the PICs need to set the intensity of each LED they control, which is the current operation of the firmware. They could however be triggered to perform more complex modulations. This would reduce the data transmission requirements on the RS485 bus, potentially improving the quality of animations produced by an array.

The PIC microcontrollers are programmed in C, which I did using Microchip’s XC compiler and MPLab IDE software. In order that each board can uniquely identify it’s control data, they are compiled with a unique ID. With a deployment of 12 boards, firmware updates are a little arduous, particularly since the two jumpers need to be removed as well.

I found that an efficient communication protocol between an array of boards and the main controller (Raspberry Pi) is a sequence of bytes with the first uniquely determining the header and the following 36 determining the intensity of each of the individual LEDs. Each board uses its ID to choose three values in the payload. At 115,200 bps, this in theory allows up to 389 commands to be sent per second. Note that the boards do not send an acknowledgement, since this significantly reduces the throughput. In Python a packet can be sent with (snippet from here):

def set_colour(payload):
    assert len(payload) == (3*12)
    usart.write(bytearray([chr(255)]+payload))
    usart.flush()

The PICs receive UART data and set the output PWMs thus (snippet from here):

...
// Reset if we see the start of packet marker.
if (RCREGbits.RCREG == START_PACKET) {
  uart_count = 0;
} else {
  // Packet payload.
  uart_data[uart_count++] = RCREGbits.RCREG;
  // When we've received the payload, update PWMs and setup for next packet.
  if (uart_count == PAYLOAD_SIZE) {
    // Set the duty cycles, scale an 8-bit range into 16 bits.
    PWM1DC = uart_data[DRIVER_OFFSET+0] * 256;
    PWM2DC = uart_data[DRIVER_OFFSET+1] * 256;
    PWM3DC = uart_data[DRIVER_OFFSET+2] * 256;
    // Reload the PWMs.
    PWM1LD = 1;
    PWM2LD = 1;
    PWM3LD = 1;
    uart_count = 0;
  }
}
...

Pictures

Improvements

Adjust the CAT4101 sense resistor to deliver closer to 300 mA (1.5-1.6 KOhm).
Remove the 10K pull up resistor for programming the PIC since it is unnecessary.
Update the defunct silk screen URL to my new jameswhanlon.com domain.

References

Querying logical paths in a Verilog design

2018-11-20T00:00:00+01:00

I wrote a simple command-line tool for querying logical paths in a Verilog design. My motivation for doing this is that it’s easy to create complex logic in Verilog, particularly between modules, but more difficult to understand exactly what is driving a particular net, just from inspecting the code. It is the complex cones of logic that lead to timing problems in a synthesised design, but having to push a design through a synthesis flow takes time, making speculative timing fixes a lengthy process. A command-line tool is useful as it can be integrated into more complex workflows, in contrast with using more complex and usually graphical EDA tooling.

The tool addresses high-level structural problems in a design, such as incorrect dependencies when a signal including logic that is not necessary to its function. It does not deal with other timing issues that are a product of the synthesis and physical build of the design. As such, all the structural information required is contained within the Verilog source code.

This note briefly explains how the tool works and records some ideas on how it could be extended.

Use

Instructions to build the tool are in the README in the GitHub repository. Assuming the netlist-paths install bin directory is available in your PATH, then using the PicoRV32 processor implementation as an example, its netlist can be generated as follows:

$ git clone https://github.com/cliffordwolf/picorv32.git
$ cd picorv32
$ verilator --dump-netlist-graph -o netlist.graph picorv32.v --top-module picorv32_axi
... # lots of warnings

Here a modified version of Verilator is used to generate the netlist. (Note that netlist-paths can invoke Verilator but with the --compile option, but PicoRV32 requires Verilator’s --top-module option. It may be useful to extend the command line arguments to allow arbitrary arguments to be passed to Verilator.) Verilator performs the generation by traversing the abstract syntax tree of the design and constructs a graph of dependencies between variables and combinatorial logical constructs, and identifies variables corresponding to sequential elements (flip flops).

The graph structure/netlist is written to file in Graphviz dot format, and specifies the vertices, with their type and source code location information, and the edges between them. The analysis tool reads this file and reports on the connectivity between points.

digraph netlist {
  n0[id=0, type="ASSIGNW", loc="picorv32.v:2539"];
  n1[id=1, type="PORT", dir="OUTPUT", name="picorv32_axi.trace_data", loc="picorv32.v:2539"];
  n2[id=2, type="PORT", dir="OUTPUT", name="trace_data", loc="picorv32.v:2539"];
  n3[id=3, type="ASSIGNW", loc="picorv32.v:2538"];
  n4[id=4, type="PORT", dir="OUTPUT", name="picorv32_axi.trace_valid", loc="picorv32.v:2538"];
  ...
  n0 -> n2;
  n1 -> n0;
  n3 -> n5;
  n4 -> n3;
  n6 -> n8;
  ...
}

A vertex in this netlist corresponds to the occurrence of a variable (ie a symbolic name). A given symbolic name can appear in different vertices, corresponding to its different uses. To see this, the option --dumpnames prints the names, types and directions of all the vertices in the graph. This output can be piped through grep to locate particular signals. For example, to see all the output variables:

$ netlist-paths netlist.graph --dumpnames | grep OUTPUT
PORT OUTPUT eoi
PORT OUTPUT mem_axi_araddr
PORT OUTPUT mem_axi_arprot
PORT OUTPUT mem_axi_arvalid
PORT OUTPUT mem_axi_awaddr
PORT OUTPUT mem_axi_awprot
PORT OUTPUT mem_axi_awvalid
...

Or all the registers:

$ netlist-paths netlist.graph --dumpnames | grep REG_DST
REG_DST picorv32_axi.axi_adapter.ack_arvalid
REG_DST picorv32_axi.axi_adapter.ack_awvalid
REG_DST picorv32_axi.axi_adapter.ack_wvalid
REG_DST picorv32_axi.axi_adapter.xfer_done
REG_DST picorv32_axi.picorv32_core.alu_out_0_q
REG_DST picorv32_axi.picorv32_core.alu_out_q
REG_DST picorv32_axi.picorv32_core.alu_wait
REG_DST picorv32_axi.picorv32_core.alu_wait_2
REG_DST picorv32_axi.picorv32_core.cached_ascii_instr
REG_DST picorv32_axi.picorv32_core.cached_insn_imm
...

Here, the REG_DST type corresponds to a variable that is the left-hand side of a non-blocking assignment <=. Conversely, the REG_SRC type is where the same variable appears in an expression on the right-hand side. In general, there can only be a single REG_DST node with a specific name, whereas there can be multiple REG_SRC nodes with a specific names. The same is true with VAR, WIRE and PORT types. When using this tool, I’ve found it straight forward to locate the variables I need using grep with --dumpnames, but there may be more sophisticated approaches that could be implemented.

A start or end point can be specified as any named vertex, which is anything except logic statements. You can query if a path exists between two points:

$ netlist-paths netlist.graph --start picorv32_axi.picorv32_core.cpu_state --end picorv32_axi.picorv32_core.dbg_valid_insn
  picorv32_axi.picorv32_core.cpu_state        REG_SRC         picorv32.v:1160
  ASSIGNW                                     LOGIC           picorv32.v:1373
  picorv32_axi.picorv32_core.launch_next_insn WIRE            picorv32.v:750
  ALWAYS                                      LOGIC           picorv32.v:760
  picorv32_axi.picorv32_core.dbg_valid_insn   REG_DST         picorv32.v:751

In this path report, it lists the sequential dependencies from the start point to the end point, through a sequence of zero or more combinatorial logic statements/blocks, with each dependency corresponding to a variable. Importantly, the filenames and line numbers given reference the original source code.

Since there may be multiple vertices with a name matching the specified start and end points, the register version is preferentially located (SRC for a start point and DST for an end point), followed by VAR, WIRE and PORT types.

You can also query all the paths that fan out from a particular start point:

netlist-paths netlist.graph --start picorv32_axi.picorv32_core.cpu_state
Path 1
  picorv32_axi.picorv32_core.cpu_state        REG_SRC         picorv32.v:1160
  ASSIGNW                                     LOGIC           picorv32.v:1373
  picorv32_axi.picorv32_core.launch_next_insn WIRE            picorv32.v:750
  ALWAYS                                      LOGIC           picorv32.v:760
  picorv32_axi.picorv32_core.q_ascii_instr    REG_DST         picorv32.v:742

Path 2
  picorv32_axi.picorv32_core.cpu_state        REG_SRC         picorv32.v:1160
  ASSIGNW                                     LOGIC           picorv32.v:1373
  picorv32_axi.picorv32_core.launch_next_insn WIRE            picorv32.v:750
  ALWAYS                                      LOGIC           picorv32.v:760
  picorv32_axi.picorv32_core.q_insn_imm       REG_DST         picorv32.v:743

Path 3
  picorv32_axi.picorv32_core.cpu_state        REG_SRC         picorv32.v:1160
  ASSIGNW                                     LOGIC           picorv32.v:1373
  picorv32_axi.picorv32_core.launch_next_insn WIRE            picorv32.v:750
  ALWAYS                                      LOGIC           picorv32.v:760
  picorv32_axi.picorv32_core.q_insn_opcode    REG_DST         picorv32.v:744
...
Found 223 path(s)

Or query all the paths that fan in to a particular end point:

$ netlist-paths netlist.graph --end picorv32_axi.picorv32_core.dbg_valid_insn
Path 1
  picorv32_axi.picorv32_core.trap           REG_SRC         picorv32.v:86
  ALWAYS                                    LOGIC           picorv32.v:760
  picorv32_axi.picorv32_core.dbg_valid_insn REG_DST         picorv32.v:751

Path 2
  picorv32_axi.picorv32_core.instr_lui       REG_SRC         picorv32.v:630
  ALWAYS                                     LOGIC           picorv32.v:684
  ASSIGN                                     LOGIC           picorv32.v:685
  picorv32_axi.picorv32_core.new_ascii_instr VAR             picorv32.v:673
  ALWAYS                                     LOGIC           picorv32.v:760
  picorv32_axi.picorv32_core.dbg_valid_insn  REG_DST         picorv32.v:751

Path 3
  picorv32_axi.picorv32_core.instr_auipc     REG_SRC         picorv32.v:630
  ALWAYS                                     LOGIC           picorv32.v:684
  ASSIGN                                     LOGIC           picorv32.v:685
  picorv32_axi.picorv32_core.new_ascii_instr VAR             picorv32.v:673
  ALWAYS                                     LOGIC           picorv32.v:760
  picorv32_axi.picorv32_core.dbg_valid_insn  REG_DST         picorv32.v:751
...
Found 74 paths

Since the number of paths between any two points in an arbitrary graph grows exponentially with the size of the graph, it infeasible to report all paths between two points, so this tool simply looks for any path that satisfies those constraints. (An option is provided to enumerate all paths, but it can only be used on small netlists.)

When trying to match a particular path in a physical build it it useful to further constrain the search to force it to match the same path. This can be done by specifying through points with the --through option. Each through argument is taken in order as an intermediate point in the path. The same search algorithm is used on each pair of points to build up a composite report. For example:

$ netlist-paths netlist.graph --start picorv32_axi.axi_adapter.ack_wvalid --through picorv32_axi.axi_adapter.mem_axi_wvalid --end mem_axi_wvalid
  picorv32_axi.axi_adapter.ack_wvalid     REG_SRC         picorv32.v:2700
  ASSIGNW                                 LOGIC           picorv32.v:2711
  picorv32_axi.axi_adapter.mem_axi_wvalid PORT            picorv32.v:2671
  ASSIGNW                                 LOGIC           picorv32.v:2556
  picorv32_axi.mem_axi_wvalid             PORT            picorv32.v:2484
  ASSIGNW                                 LOGIC           picorv32.v:2484
  mem_axi_wvalid                          PORT            picorv32.v:2484

Implementation

To avoid writing a preprocessor and parser for Verilog, I modified Verilator to obtain the netlist of a Verilog design. (I would have liked to use Yosys to do this because it provides a neat interface to adding custom AST passes, but unfortunately it does not currently support enough of the SystemVerilog standard.) The Verilator modifications add a new AST visitor, which walks the tree after it has been processed, for example to propagate constants and inline tasks and modules.

The netlist-paths tool is implemented in C++ and makes use of the Boost Graph Library. Paths are identified using the boost::depth_first_search algorithm. The all-fan-out report enumerates paths to all the end points in a depth-first traversal of the graph, the fan-in variant uses the boost::reverse_graph adaptor and performs the same algorithm. Properties are associated with vertices in the graph using a boost::dynamic_property_map. I put together a simple example program to illustrate how to use these maps (plus some other library features) since I found there were some subtleties in getting this to work.

Improvements

There are many ways this tool could be extended and improved. Here are a few ideas:

Provide additional flexibility to allow a choice between multiple matching start, through or end points.
Provide a mechanism to search for high fan-out variables.
Provide a mechanism to seach for the longest paths in the graph.
Provide a mechanism to assert there is no logical path between two sub modules.
Detect and report timing loops.
Add options to dumpnames to filter by type or direction.
Add options to the querys to select only internal paths or only input/output paths.

Retrofit shed insulation

2018-09-30T00:00:00+02:00

To make the shed in my garden (built by the previous owner) a usable space in cold weather, I decided to insulate it. The construction of it is a stud timber frame of 2x4” with a corrugated metal exterior and lined inside with OSB board. The construction has created voids in the floor, walls and roof, providing a convenient space to add insulation.

I considered using natural wool insulation, as opposed to rigid insulation board, but felt that it would difficult to secure it in place in a consistent way, as well as ensuring an air gap remains between the external cladding. I decided on using Celotex rigid insulation board and used 12 sheets of 75mm thick standard 2400 mm x 1200 mm size, and two boards of the same size at 50 mm for the back wall. In total, the insulation cost £512.74 (including VAT). To prevent draughts as much as possible, I decided to tape the gaps between the boards and shed timbers. I bought about 8 rolls of foil tape to do this.

The insulation board turned out to be easy to work with, easy to cut with a panel saw and fitting snugly in the gaps and leaving plenty of space for ventilation. I found the dust created by sawing the board irritating to my eyes and breathing so as much as possible wore eye protection and a mask (although hard to do getting hot in the small space). Working overhead on the roof was the worst part as it was difficult to avoid falling dust on my face. The whole job took three days to complete and has made a substantial difference to the stability of the temperature in the space.

The OSB lining before starting (left) and the 75 mm board (right).

OSB lining removed from the walls and roof.

The remaining OSB removed from the floor.

Complete and taped floor insulation, and half the floor restored.

Installation of insulation into the roof apex. The dust falling from the board as they are positioned in place made this an unpleasant job.

Completed walls and roof, prior to taping.

Timer added to provide a space to install the insulation.

…and the insulation in place.

Details of more completed areas, before and after taping.

The scene before tidying up.

…and after tidying.

Almost done: enough OSB lining back in to install the workbench and shelves.

Vim command composition

2018-08-23T00:00:00+02:00

I’ve been using Vim for a long time and I’m familiar with many of its commands but I’ve never had a good understanding of the underlying components of commands and their composition. Although there are many good Vim references, I felt that I was still not seeing the full picture. So, to try and dig a little deeper and educate myself, I’ve put together this reference, which details a subset of the command language. The approach I’ve taken was inspired by the grammar rules outlined in this blog post, and should be useful for anyone who is familiar with Vim.

A Vim command can be constructed from different rules, and below each rule is specified with a EBNF-style syntax, where <...> is another rule. {...} represents some key presses, | is an alternative and [...] is an optional component. Be warned that since there are many special cases to Vim commands and I’ve not checked all the combinations, some of the rules below may yield invalid compositions! As such, these rules are better viewed as a way of remembering commands. For an exhaustive treatment of the command language, please check the Vim documentation, or use the :help tags that I’ve given.

Motions

Motions change the position of the cursor and can be combined with a count to repeat the motion.

count := {digits}
motion := [<count>] <motion-keys>
command := <motion>

Examples:

2fx - move to the second right-hand occurrence of x in the line (inclusive)
2Tx - move to the second left-hand occurrence of x in the line (exclusive)
w - move to the next word
10j or 10_ - move down 10 lines
10k - move up 10 lines
6w - move to start of the sixth word forwards
6E - move to end of sixth word forwards
4b - move to start of the fourth word backwards
2{ - move two paragraphs down
3/foo - move to the third occurrence of foo later in the buffer
3?foo - move to the third occurrence of foo earlier in the buffer

Text objects

Text objects are a collection of characters relative to the position of the cursor. Compared to motions, text objects on a whole object, regardless of the specific cursor position. The a and i modifiers augment text objects, specifying whether the surrounding context should be included. The context may be whitespace or delimiting characters.

text-object := <text-object-keys>
             | <modifier> <text-object-keys>

Examples:

aw - around word (includes surrounding whitespace)
iw - inner word (excludes surrounding whitespace)
aW - around WORD (where word is delimited by whitespace)
as - around sentence
is - inner sentence
ap - around paragraph
ip - inner paragraph
a' - a single-quoted string
i' - inside a single-quoted string
a( = a)= ab - a parenthesised block, from ( to )
i( = i)= ib - inside a parenthesised block, contents of (...)
a< = a> - a tag, from < to >
at - around tag block, including matching start and end tags <tag>...</tag>
it - inside tag block, excluding tags
aB = a{ = a} - around a {...} block
iB = i{ = i} - inside a {...} block

Operators on text objects

Operators can be applied to text objects. In some circumstances, a count can be applied to the text object to repeat its effect.

command := [<count>] <operator> <text-object>
text-object := <count> <modifier> <text-object-keys>

Examples:

cw - change word from cursor
ciw - change word under cursor
dw - delete until end of word
5dw = d5w - delete until end of right-hand sixth word
caw - change around word under cursor
2d3w - delete six words
5gUw - make the next five words uppercase
dgg - delete lines from cursor to beginning of buffer
dG - delete lines from cursor to end of buffer
3d_ - delete three lines
c$ - change until end of line
y_ = yy = Y - yank the line
c_ = cc = C - change the line
gUap - make paragraph uppercase
gqap - format paragraph text to textwidth line length
dit - delete text between tags <tag></tag>
dat - delete tag block
yi" - yank text in "..." block
yi< - yank text in <...> block
yiB - yank text in {...} block
yaB - yank whole {...} block

Operators on motions

A motion can be applied after an operator to apply the operator on the text that was moved over.

command := [<count>] <operator> <motion>

Examples:

dl = x - delete next character
db - delete backwards to the start of a word
dtx - delete until x character in line (exclusive)
dfx - delete until x character in line (inclusive)
d/foo - delete from cursor to next occurrence of foo
d3/foo - delete from cursor until the third occurrence of foo
c$ = C - change until end of line
d$ = D - delete until end of line
d0 - delete until beginning of line
d^ - delete until first non-blank character in line
c{ - change from current line to beginning of paragraph
gU} - make paragraph uppercase
c{ - change paragraph (same as cap operator-text object)
>} - indent paragraph
y% - yank the entire {...} block
cgg - change lines from cursor to top of buffer
ggdG - delete contents of buffer

Duplicate operators

Operators applied twice affect the entire line, a synonym for <operator>_,

command := [<count>] <operator> <operator>

Examples:

dd = d_ - delete line
cc = c_ - change line
yy = y_ - yank line
>> = >_ = >l - indent line
<< = <_ = >l - unindent line

Note: duplication does not apply to ~ or two-character operators.

Aliases

Some commonly-used commands have aliases.

x = dl - delete next character
C = c$ - change until the end of the line
D = d$ - delete until the end of the line
Y = yy - yank the line
S = cc - change the line
A = $a - append text to end of the line
s = cl - substitute character (delete and insert)
S = cc - substitute line

Filtering

Text lines can be filtered through an external program (see :help filter).

command := ! <motion> <filter>

Examples, using some basic utilities found on Unix platforms:

!8jsort - sort the next 8 lines
!apsort - sort lines in paragraph
!apwc -l - replace paragraph with word count
!apfmt -s - collapse whitespace in paragraph into single spaces
!apfmt -c - centre lines in paragraph
!i(grep foo - remove all lines in (...) block that don’t contain foo (similar to the Ex command :%v/foo/d)
gg!Gsort - sort all lines in buffer
gg!Guniq -c - remove all duplicate lines in buffer and prefix remaining with duplicate counts

Visual selection

Visual selection, character-wise v, line-wise V or block-wise Ctrl+v (all referred to below by {visual}, see :help visual-start), followed by a motion or text object can be used to specify a character range. An operator can then be used to transform the text. Note the operators gu, gU and g@ can’t be used in visual mode and text objects in visual mode, however, there are additional ones that can (see :help visual-operators). A visual block is created by entering a visual mode, then providing a motion or text object to set the selection, or alternatively by any sequence of movement commands (referred to by {move-around}).

visual-block := {visual} {move-around}
              | {visual} <motion>
              | {visual} <text-object>
command := <visual-block> <operator>
         | <visual-block> <visual-operator>
         | <visual-block> ! <filter>

Examples:

vtxd = dtx - delete until x
vt.rx - replace all characters with x until .
v3as~ - make next three sentences uppercase
vapU - make paragraph uppercase
vapd - delete paragraph
{Ctrl+v}{move-around}sfoo{Esc} - replace each line of blockwise selection with foo
{Ctrl+v}{move-around}Ifoo{Esc} - prepend foo to each line of blockwise selection
{Ctrl+v}{move-around}Afoo{Esc} - append foo to each line of blockwise selection
vap!sort - sort the lines of the current paragraph
vap!fmt - use the fmt command-line tool to format selection into lines of 75 characters (similar to the gqap command)
ggvG!indent - use the indent command-line tool to apply automatic indentation all lines of a C-code buffer
{visual}J - join the highlighted lines on the current line
{visual}gJ - join the highlighted lines on the current line (removing whitespace)

Other command combinations

Beyond the above rules, there are further command keys and more restricted combination with motions, operators and text objects.

The . command repeats the last change that was made.

command := [<count>] .

db. - delete the previous two words
db4. - delete the previous five words
{insert text...} then /{pattern}. - insert text again before next text matching {pattern}

The gn and gN motions can be used with operators to move between matching search patterns.

command := [<count>] <operator> gn
         | [<count>] <operator> gN

cgn - change the next search match
3cgn - change the third search match
cgN - change the previous search match

Here are some other interesting and potentially useful commands that I’ve found in the Vim help:

gf - goto file (when cursor is on a valid filesystem path)
gF - goto file and line number (line number following path)
J - Join the current line with the next one (with space in between)
gJ - Join the current line with the next one (without space in between)
3J - join the next three lines on the current line (removing indent)
3gJ - join the next three lines on the current line
gv - reselect previous visual area
g~~ = g~g~ - switch case of line
gUU = gUgU - make line uppercase
guu = gugu - make line lowercase
r{char} - replace character under cursor with {char}
10r{char} - replace the next 10 characters with {char}

Summary of rules

Motions

<motion-keys>

References: :help motion :help various-motions

Action	Effect
`l`,`h`,`j`,`k`	right, left, down, up
`w` / `W`	start of next word / start of next WORD
`b` / `B`	start of pevious word / start of previous WORD
`e` / `E`	end of next word / end of next WORD
`0` / `$`	start / end of line
`^` / `g_`	first / last non-blank character in line
`{` / `}`	start / end of paragraph
`t{char}`	till - move to next character (inclusive)
`f{char}`	find - move to next character (exclusive)
`T{char}`	till - move to previous character (inclusive)
`F{char}`	find - move to previous character (exclusive)
`%`	move to matching character (default pairs: `()`, `{}`, `[]`)
`[(`, `[)`	move to matching parenthesis
`[{`, `[}`	move to matching curly brace
`/{pattern}`	search forward (must be followed by `{CR}`)
`?{pattern}`	search backwards (must be followed by `{CR}`)
`gg` / `G`	move to first / last line in buffer

Operators

<operators>

Reference: :help operator

Key	Operator
`c`	change
`d`	delete
`y`	yank
`~`	swap case (or `g~`)
`>`	shift right (always linewise)
`<`	shift left (always linewise)
`gu`	make lowercase
`gU`	make uppercase
`gq`	format text
`g@`	apply function (set by `operatorfunc`)

Visual operators

<visual-operators>

References: :help visual-operators

Key	Operator
`r{char}`	replace every character in selection with {char}
`s`, `c`	substitute (inserted text replicated on each line for blockwise)
`J` / `gJ`	join / join (remove whitespace)
`p`	put (replace selection with contents of register)
`U`	make uppercase
`u`	make lowercase
`I`	insert (prepend, only on blockwise selection)
`A`	insert (append, only on blockwise selection)

Text objects

<text-object-keys>

References: :help text-objects, :help objects

Key	Text object
`w`	word (delimited by non-keyword characters, see `:help iskeyword`)
`W`	WORD (delimited by whitespace, includes empy line)
`s`	sentence
`p`	paragraph
`t`	tag
`[`, `]`	text block between square brackets
`{`, `}`	text block between curly braces
`(`, `)`	text block between parethesises
`'`, `'`	text block between single quotes
`"`, `"`	text block between double quotes
`<`, `>`	text block between angle braces
`, `	text block between back ticks
`b`	text block between `(` and `)`
`B`	text block between `{` and `}`

Modifiers

<modifiers>

References: :help text-objects

Key	Movement
`a`	a or around
`i`	inner

count := {digits}

text-object := <text-object-keys>
             | <modifier> <text-object-keys>
             | <count> <modifier> <text-object-keys>

motion := [<count>] <motion-keys>

visual-block := {visual} {move-around}
              | {visual} <motion>
              | {visual} <text-object>

command := <motion>
         | [<count>] <operator> <text-object>
         | [<count>] <operator> <motion>
         | [<count>] <operator> <operator>
         | ! <motion> <filter>
         | <visual-block> <operator>
         | <visual-block> <visual-operator>
         | <visual-block> ! <filter>
         | [<count>] .
         | [<count>] <operator> gn
         | [<count>] <operator> gN

Some random commands

Just for fun, here are some random commands using the above rules to show the variety of actions you can perform. Some might not make sense or not work, but they might give you some ideas.

Motions

Text objects

Operators on text objects

Operators on motions

F{ch}
/{pat}
[}
t{ch}
9B
3/{pat}
b
T{ch}
{
j
w
[}
l
g_
5[(
%
{
0F{ch}
w
T{ch}
[}
10
k
[}
%
1G
[{
5k
0
/{pat}
1/{pat}
2l

?{pat}
g_
1h
h
t{ch}
4F{ch}
0$
t{ch}
$
B
l
g_
^
1{
2?{pat}
G
^
k
1[(
$
w
h
^
/{pat}
gg
w
g_
1e
[)
t{ch}
6/{pat}
t{ch}

iw
ab
a}
aw
it
i<
i[
i'
aw
i"
a"
ip
iB
i[
a]
a>
iW
i'
a{
i'
a[
a>
a"
i'
i{
i)
i)
it
ab
i>
iW
a'

at
i{
is
iW
aW
a>
i[
a{
i'
aB
ip
a}
a]
i"
a<
iW
ib
a(
iw
i"
a{
a<
at
a{
ip
a}
a"
as
i)
a{
ap
a<

<aW
5gua{
>4aW
<at
8>iW
gUis
>aW
3g@aw
g@i)
<0ap
~a(
y5a]
<0i)
>3ip
g@a}
da"
gUi[
gq1i{
<i]
2g~ib
g@i]
gua`
gUi(
~8a}
<is
d7a[
g~i(
d5aw
g~a}
4diW
gqiw
<4i{

<is
g~iW
daW
<aB
~a)
c5a<
gUaB
ca}
9g@as
gu0a(
~2a"
ya<
gUa'
~9a`
y2is
gU2i)
c4i'
7ya"
guaB
0<i'
c9i'
guib
g@a`
9g@a>
6c9ip
2g@2ab
yi[
1c3iW
c3ap
8gUi`
gqit
g@i[

0d{
9gu[)
2yT{ch}
8g~?{pat}
2ce
0gUb
8g~j
2c[(
3>}
3>gg
6>G
6~j
0d[{
8gU{
4c[}
4~h
7<l
7g@^
6~/{pat}
7yh
3<}
1<F{ch}
4cw
1gu[)
0cB
7g~[{
3g~[{
7yk
3~k
5g~[)
5g@G
8yt{ch}

0g@e
8>0
6g~[(
5dB
9>T{ch}
0gU{
3<w
1y?{pat}
4g@[{
5~b
2<^
4>w
4y{
1<e
8c[}
6c{
2g~/{pat}
3cj
8cT{ch}
3>%
0<F{ch}
4gqB
3gqT{ch}
3dk
5>[)
2gqh
8ce
7~gg
3cl
4c^
4c%
1gq$

References/further reading

Writing synthesizable Verilog

2018-05-04T00:00:00+02:00

NOTE: Updated February 2024 with improvements and new guidance.

In the last year, I’ve started from scratch writing SystemVerilog for hardware design. Coming from a software background where I was mainly using C/C++ and Python, it has been interesting to experience the contrasting philosophy and mindset associated with using a language to describe hardware circuits. Much of this is because SystemVerilog provides little abstraction of hardware structures, and only through disciplined/idiomatic use, can efficient designs be implemented. A compounding issue is that complex hardware designs rely on a complex ecosystem of proprietary tooling.

As I see it, there are three aspects to writing synthesizable SystemVerilog code: the particular features of the language to use, the style and idioms employed in using those features, and the tooling support for a design. Good coding style can help achieve better results in synthesis and simulation, as well as producing code that contains less errors and is understandable, reusable, and easily modifiable. Many of the observations in this note relate to coding style. The next sections give some context around the use of SystemVerilog in digital design, or you can skip ahead to the guidance.

The SystemVerilog language

SystemVerilog (which subsumed Verilog as of the 2009 standardisation) is a unified language, serving distinct purposes of modern hardware design. These can be enumerated as:

Circuit design/specification at different levels of abstraction:
- Behavioural.
- Structural/register-transfer level (RTL).
- Gate.
- Switch/transistor.
Testbench-based verification.
Specification of formal properties.
Specification of functional coverage.

SystemVerilog provides specific features to serve each of these purposes. For circuit specification, each level of abstraction uses a different language subset, generally with fewer features at lower levels. Behavioural design uses the procedural features of SystemVerilog (with little regard for the structural realisation of the circuit). RTL design specifies a circuit in terms of data flow through registers and logical operations. Gate- and switch-level design use only primitive operations. Typical modern hardware design uses a mix of register-transfer- and gate-level design.

It is interesting to note that the SystemVerilog specification does not specify which features are synthesizable; that depends on the tooling used.

Tooling

There is a variety of standard tooling that is used with SystemVerilog, and indeed other hardware description languages (HDLs). This includes simulation, formal analysis/model checking, formal equivalence checking, coverage analysis, synthesis and physical layout, known collectively as electronic design automation tools (EDA). Since standard EDA tooling is developed and maintained as proprietary and closed-source software by companies like Cadence, Synopsys and Mentor, the tooling options are multiplied.

In contrast with the open-source software ecosystems of programming languages (for example), closed-source EDA tools do not benefit from the scale and momentum of open projects, in the way that conventional software languages do, with a one (or perhaps two) compilers and associated tooling such as debuggers and program analysers. Such a fragmented ecosystem inevitably has a larger variability in precisely how features of SystemVerilog language are implemented and which features are not supported, particularly since there is no standard synthesizable subset. Consequently, engineers using SystemVerilog/HDLs with proprietary EDA tools do so conservatively, sticking to a lowest common denominator of the language features (within their chosen synthesizable subset), to ensure compatibility and good results.

Overview

This note records rules, conventions and guidance for writing SystemVerilog approaches that I have been observed to interact well with the supporting tooling and to encourage good coding style and produce good synthesis results. I owe many of these insights to the guidance of my colleagues.

This note assumes familiarity with SystemVerilog. As such it is not a comprehensive guide to programming practices. Some of the references at the end will serve those purposes better. The remainder is organised in the following sections:

Types
Always blocks
- always_comb
- always_ff
Control flow
- If statements
- Case statements
Expressions
Constants
X values
Naming
Code structure
Formatting

Types

logic should be used to declare point-to-point nets, variables and ports. This is because logic is checked at compile time for multiple drivers. Note that variables are entities driven by procedural assignments (in always blocks), whereas nets occur in any other forms of assignment (continuous, primitive outputs and module ports). An exception to this is when integrating external IP that uses wire types where some sparing use of the wire type may be required for consistency.¹

Multiply-driven nets should be declared using wire. This is because wire data types permit multiple drivers.

Combined logic declarations and assignment statements are not allowed. The behaviour of these is to assign a value at time 0, which is not synthesizable. Continuous assignment after time 0, which is the typical intention, requires a separate assignment. Note that a combined assignment with a wire declaration behaves differently and is equivalent to a separate continuous assignment.

// Assignment of a logic net at time 0, not allowed.
logic [31:0] data = 32'b0;

// Correct way to continuously drive a logic net.
logic [31:0] data;
assign data = 32'b0;

// Wire declarations can use an initial value to specify a continuous
// assignment.
wire value = 0;

// Same behaviour as above declaration.
wire value;
assign value = 0;

Structures and unions must always be fully packed. This applies to their members recursively. For example:

typedef struct packed { // Packed structure.
  valid_t             valid;
  logic [p_width-1:0] data; // Packed array.
  logic               parity;
} bus_t;

Always blocks

The always_ff, always_latch and always_comb constructs should be used instead of the old-style always statement since they provide extra compile-time checking.²

`always_comb`

Use always_comb instead of always for combinatorial logic. The always_comb statement allows tools to check that it does not contain any latched state and that no other processes assign to variables appearing on the left-hand side. (It’s worth checking the LRM for details of of the other differences.) The use of an always_comb block is also a much clearer indication of a combinatorial block that the use of = as opposed to <=.

Always provide an initial value. A latch will be inferred if there exists a control-flow path in which a value of a signal is not set. Since always_comb specifically precludes the creation of latches, doing so will cause a warning or error in simulation or synthesis. For example, the following code implies a latch since there is no assignment to foo when the condition is not true.

always_comb begin
  if (condition) begin
    foo = 1'b1;
  end
end

To prevent this, always provide an initial value as the first line of a block:

always_comb begin
  foo = 1'b0;
  if (condition) begin
    foo = 1'b1;
  end
end

Avoid reading and writing a signal in an always_comb block. Avoid reading and writing a signal in an always_comb block. The sensitivity list only includes variables that are read in expressions or functions and it excludes variables that are also written to. According to these restrictions, a variable that is read and written in a block is excluded from the sensitivity list, and activation of the block will be dependent on other variables. However, this style can cause some tools to warn of a simulation-synthesis mismatch (presumably because they apply conservative rules from older versions of the language standard).

In the following code, the block is triggered only when the the right-hand-side foo changes, rather than entering a feedback loop where it shifts continuously:

always_comb begin
  foo = foo << 1;
end

To avoid reading and writing foo in the same block and possible warnings from tools, a new signal can be introduced:

always_comb begin
  next_foo = foo << 1;
end

Where possible extract logic into assign statements. Extract single assignments to a variable into a separate assign statement, where it is possible to do so. This approach uses the features of SystemVerilog consistently, rather than using two mechanisms to achieve the same effect. This makes it clear that an always_comb is used to introduce sequentiality. Another opportunity to move logic into separate assign statements is with complex expressions, such as the Boolean value for a conditional statement. Doing this makes the control flow structure clearer, potentially provide opportunities for reuse, and provides a separate signal when inspecting the signals in a waveform viewer.

Avoid unnecessary sequentiality. It is easy to add statements to an always_comb to expand its behaviour, but this should only be done when there are true sequential dependencies between statements in the block. In general, parallelism should be exposed where ever possible. In the the following example, the sequentiality is not necessary since the output set_foo depends independently on the various conditions:

always_comb begin
  set_foo = 1'b0;
  if (signal_a &&
      signal_b) begin
    set_foo = 1'b1;
  end
  if (signal_c ||
      signal_d) begin
    set_foo = 1'b1;
  end
  if (signal_e) begin
    set_foo = 1'b1;
  end
end

Clearly the sequencing of the conditions is not necessary, so the block could be transformed to separate the logic for each condition into separate parallel processes (extracting into assign statements as per the rule above) and explicitly combine them with the implied logical disjunction of the original block:

assign condition_a = signal_a && signal_b;
assign condition_b = signal_c || signal_d;
always_comb begin
  set_foo = 1'b0;
  if (condition_a ||
      condition_b ||
      signal_e) begin
    set_foo = 1'b1;
  end
end

It is recommended by the author of Verilator to split up always blocks (combinatorial or sequential) so they contain as few statements as possible. This allows Verilator the most freedom to order the code to improve execution performance. Presumably, this provides similar freedoms to other simulators.

Drive one signal per block. With complex control flow statements, it is tempting to use a single always_comb block to drive multiple signals. In some circumstances, there may be good reasons to do this, such as when many output signals are used in a similar way, but in the general case, splitting each signal into a separate block makes it clear what logic involved in driving that signal, and as such, facilitates further simplification.

An additional reason to avoid driving multiple signals per always_comb block is that Verilator can infer a dependence between two signals, leading to false circular combinatorial loops. In these cases, it issues an UPOPTFLAT warning and cannot optimise the path, leading to reduced emulation performance. Generally, fixing warnings pertaining to unoptimisable constructs can improve Verilator’s simulation performance by up to a factor of two.

The process:

always_comb begin
  foo = foo_q;
  bar = bar_q;
  if (condition_a)
    case (condition_b)
      0: begin
        foo = ...;
        if (condition_c) begin
          bar = ...;
        end
      end
      1: foo = ...;
      2: bar = ...;
      default:;
    endcase
end

Can be written as two independent processes:

always_comb begin
  foo = foo_q;
  if (condition_a)
    case (condition_b)
      0: foo = ...;
      1: foo = ...;
      default:;
    endcase
end

always_comb begin
  bar = bar_q;
  if (condition_a)
    case (condition_b)
      0: if (condition_b) begin
           bar = ...;
         end
      2: bar = ...;
      default:;
    endcase
end

`always_ff`

Use always_ff instead of always for sequential logic. Similarly to always_comb, use of always_ff permits tools to check that the procedure only contains sequential logic behaviour (no timing controls and only one event control) that variables on the left-hand side are not written to by any other process, and makes clear the intent for sequential logic behaviour with non-blocking assignments, <=.

Avoid adding logic to non-blocking assignments. This is primarily a matter of taste, but having non-blocking assignments in always_ff blocks only from a logic signal name, rather than a logical expression, keeps the block simple and limits combinatorial logic to always_comb blocks and assign statements elsewhere in the module. Since synthesizable always_ffs are additionally restricted in that variables assigned to must have a reset condition of a constant value, maintaining this clarity aids the designer. Having separate combinatorial blocks is also useful since it allows the logic signal driving a flip-flop as well as the registered value to be apparent in a waveform viewer, particularly when clock gates are used.

A typical pattern when implementing combinatorial logic and registers is to define the set and clear conditions in an always_comb and register the value in an accompanying always_ff, for example:

logic bit;
logic bit_q;

always_comb begin
  bit <= bit_q;
  if (set_condition) begin
    bit = 1'b1;
  end
  if (clear_condition) begin
    bit = 1'b0;
  end
end

always_ff @(posedge i_clk or posedge i_rst) begin
  if (i_rst) begin
    bit_q <= 1'b0;
  end else begin
    bit_q <= bit;
  end
end

Registers should always be reset to a constant value. Without being reset, a flip flop will drive X on its output, which can lead to simulation-versus-synthesis mismatches, potentially obscuring bugs. Having registers initialised with a defined value precludes these kinds of mismatches. In the above example, bit_q is correctly initialised to 0.

Avoid using synchronous-reset registers. These type of flip flops are not typically used because there are circumstances when a clock is not available and reset-to-clock paths are not timed in the physical implementation. In cases where area and power are constrained, non-reset flip flops can instead be deployed for better savings.

In certain circumstances when it is appropriate to use synchronous-reset registers, then avoid mixing synchronous and asynchronous reset signals. A reset signal (eg i_rst) should not be used as a synchronous reset for one set of registers and an asynchronous reset for another set. This is because the resets must be controlled differently by DFT control logic, and use of a single signal may obscure the designer intent.

Avoid using non-reset registers. To avoid issues with X values in a design as far as possible, non-reset registers should only be used when specifically required to save area and power, such as for the storage elements of a register file. In certain circumstances when it is appropriate to use non-reset registers, then define non-reset registers in a separate always_ff block. For example:

// A non-reset register.
always_ff @(posedge i_clk) begin
  bit_q <= bit;
end

When non-reset registers are used, a separate form of reset must be provided. In the example of a register file, a broadcast write could be used to initialise the contents to a known state.

Control flow

If statements

Avoid mixing block control flow with Boolean expressions. This is because it make it harder for structural coverage analysis tools to break down complex conditions into manageable sub terms, or even that analysis will ignore important conditional context of expressions.

// Replace mixed block control flow and boolean expressions:
if (enabled) begin
  flag = x && y;
  if (flag) begin
    out = a;
  end
end

// With a pure control flow approach:
if (enabled) begin
  if (x && y) begin
    out = a;
  end
end

// Or even better collapsed into a single Boolean expression:
if (enable && x && y) begin
  out = a;
end

Use if-else-if statements to implement priority encoders. Although a priority case statement can be used to do this, it is easier for designers to recognise a priority encoder when it is written as an if-else-if statement. For example:

// Replace an unqualified case:
case (1'b1)
  hold: output = a;
  error: output = b;
endcase

// With an if-else statement:
if (hold) begin
  output = a;
end else if (error) begin
  output = b;
end

Do not use qualifiers with if-else-if statements. The default behaviour of if statements is that of priority, meaning that one condition is matched, the conditions are evaluated in sequence and only the body of the first matching condition is evaluated. For unique and unique0 variants of if statements (one or no matching conditions, which can be evaluated in parallel), use a unique-qualified case statement instead. For example:

// Replace a unique if:
unique if (ctrl == 2'b01) begin
  output = a;
end else if (ctrl == 2'b10) begin
  output = b;
end else begin
  output = c;
end

// With a unique case:
unique case (ctrl)
  2'b01:   output = a;
  2'b10:   output = b;
  default: output = c;
endcase

Note that if statements are X-optimistic in that a condition that evaluates to an X is treated as if it were a zero. This behaviour has drawbacks and benefits, but should be carefully considered since it can be a cause of divergence in behaviour between simulation and synthesis. In contrast, case statements do not select conditions with an input X value.

Case statements

All case statements should include a qualifier for additional checking and guidance to synthesis. The qualifiers are:

unique to specify that all valid conditions have been listed, exactly one condition will always match and the conditions can be evaluated in parallel. A violation is reported in a given cycle if no case conditions match or more than one case condition is matched.
priority to specify that all valid conditions have been listed, that they are evaluated in sequence and only the body of the first matching case is evaluated. A violation is only reported if no case conditions match in a given cycle.

The behaviour of an unqualified case statement is that of priority, but without the requirement for any case item expressions to match and the corresponding violation check. Because case statements are typically used to represent parallel choices, an unqualified case does not clearly indicate whether the designer has intended the case be priority or parallel. Adding a qualifier makes this explicit (leading to the right synthesis result) and adds checking.

It is important to have checking of case behaviour: if a violation is reported during simulation, then this indicates a mismatch between the behaviour of simulation and synthesis, which means the synthesized design will not necessarily be the same as the RTL design being simulated, thereby invalidating the verification.

Note that if a case condition contains a list of expressions, it is not a violation of uniqueness if more than one expression matches since they are selecting the same statement.

Do not use unique0 as a case qualifier. Despite this qualifier being in the SystemVerilog LRM for more than a decade, tool support for unique0 is patchy and sometimes absent. This suggests that adoption of unique0 is low, so the EDA companies have not needed to support it comprehensively. As such, unique0 should not be used, and instead a unique case with an empty default should be used, for example:

// Replace a unique0 case:
unique0 case (1'b1)
  1'b0: output = a;
  1'b1: output = b;
endcase

// With a unique case and empty default:
unique case (1'b1)
  1'b0: output = a;
  1'b1: output = b;
  default: ; // Empty default disables the no-matching-condition violation
             // check, making the unique case statement behave like a unique0
             // case.
endcase

If in doubt, use priority case with a default. If a designer is not completely sure whether the case conditions are always matches and/or are parallel, then they should use a priority case with a default. This way, the logic simulated results will always match the synthesized logic.

The Synopsys full_case/parallel_case compiler directives should not be used. Instead, use either the unique or priority qualifiers, as shown in the table below:

SystemVerilog construct	Approximate Synopsys pragma equivalent
`unique case` without default	`full_case` and `parallel_case`
`priority case` without default	`full_case`
`unique case` with default	`parallel_case`
`priority case` with default	No equivalent

The use of defaults in case statements should be used sparingly since they can obscure designer intent, prevent violation checks from being performed and change synthesis results.

Note that default conditions are matched only if no case condition matches, so they can be used to cover all other case conditions that are not explicitly specified. Their inclusion in a case statement must be considered carefully.

Defaults can be used to assign a value to a combinatorial signal to avoid latches from being inferred, however it is clearer to provide a default value at the beginning of an always_comb block (see above). This is because it is conventional to add a default at the end of a case statement, which obscures the effect of a default, possibly leading to bugs. For example:

// Assign a default at the top of the block.
always_comb begin
  next_state = state_q;
  unique case(state_q)
    STATE_A: next_state = STATE_B;
    STATE_B: next_state = STATE_C;
    ...
    STATE_Z: next_state = STATE_A;
    // No need for a default here.
  endcase
end

If a condition were to be added around the above case statement, the default value assignment of next_state would remain at the top of the block. On the other hand, if the default value assignment were done in a default of the case, and not moved out, a latch would be inferred.

Defaults can be used to trap unexpected case values. However, by specifying unique or priority, unexpected case values will cause either of the no-matching-condition or multiple-conditions matching violation checks to fire. For example, with a one-hot case select, it is not necessary to add a default: $error(...); case condition to trap values that are not one hot.

There is no priority0 case statement qualifier, so it is reasonable to include an empty default with a priority case to disable the no-matching-condition violation check, similarly to unique case. However, it is more conventional to use an if-else-if to implement a priority encoder. Example of a case-based priority encoder:

priority case (cond)
  VALUE_A: ...
  VALUE_B: ...
  VALUE_C: ...
  default: ; // Use an empty default with priority when there are no matching
             // conditions, but could the case equally be written with an
             // if-then-if statement?
endcase

Empty defaults might also be used to plug coverage holes. This can occur when the coverage tool expects to see all input combinations and does not understand when these are prevented by design, eg with one-hot encoding. Adding an empty default may plug this coverage hole, however doing this will typically change the synthesis results because it implies an additional decode/control signal to select the default block, which is probably not what the designer intended. In such a situation, designers should add coverage waivers where a lack of a default case creates a coverage hole rather than changing the RTL to add an empty default case.

// Since the case is unique, the empty default is not necessary and will be
// dead code, and may change the synthesis results.
unique case (four_bit_one_hot_select)
  4'b0001: output = i_a;
  4'b0010: output = i_b;
  4'b0100: output = i_c;
  4'b1000: output = i_d;
  default: ; // This default is not necessary if the case conditions are
             // activated every cycle.
endcase

Use unique case (1'b1) for one-hot conditions. For example, a one-hot multiplexer can be written:

module m_one_hot_mux3 (
    input  logic       i_a,
    input  logic       i_b,
    input  logic       i_c,
    input  logic [2:0] i_sel,
    output logic       o_out
  );

  always_comb begin
    unique case (1'b1)
      i_sel[0]: o_out = i_a;
      i_sel[1]: o_out = i_b;
      i_sel[2]: o_out = i_c;
    endcase
  end
endmodule

As an aside, it is convenient to define a one-hot encoding in a union type with another struct to provide named access to each member. For example, status_q above could be redefined as:

typedef enum logic [2:0] {
  STATUS_START = 3'b001,
  STATUS_END   = 3'b010,
  STATUS_ERROR = 3'b100
} status_enum_t;

typedef union packed {
  status_enum_t u;
  struct packed {
    logic status_start;
    logic status_end;
    logic status_error;
  } ctrl;
} status_t;

status_t status_q;

Bear in mind however that this union introduces potential for the control structure to correspond incorrectly with the enumeration, which may introduce bugs into the design.

Minimise the amount of logic inside a case statement. The rationale for this is similar to extracting logic from always_comb blocks into assign statements where possible: to make the control flow structure clearer to the designer and tooling, and to provide opportunities for reuse or further simplification. For example, avoid nesting case statements:

status_t status_q;
status_t next_status;
logic [3:0] mode_q;

always_comb begin
  next_status = state_q;
  unique case(1'b1)
    status_q.ctrl.stat_start:
      unique0 case (mode) inside
        4'b000?,
        4'b0?00: next_status = STATUS_ERROR;
        default: next_status = STATUS_END;
      endcase
    status_q.ctrl.status_end: ...;
    status_q.ctrl.status_error: ...;
  endcase
end

And instead extract a nested case into a separate process, providing a result signal to use in the parent case:

status_t status_q;
status_t next_status;
status_t start_next_status;
logic [3:0] mode_q;

always_comb begin
  start_next_status = state_q;
  case (mode_q) inside
    4'b000?,
    4'b0?00: start_next_status = STATUS_ERROR;
    default: start_next_status = STATUS_END;
  endcase
end

always_comb begin
  unique case(1'b1)
    status_q.ctrl.status_start: next_status = start_next_status;
    status_q.ctrl.status_end: ...;
    status_q.ctrl.status_error: ...;
  endcase
end

Although this example seems simple, the case-based logic driving a state machine can quickly become complicated.

Use case inside for matching with don’t cares. For example:

localparam p_done  = 4'd0,
           p_init  = 4'd1,
           p_end   = 4'd2,
           p_error = 4'd3;

logic [2:0] status;
logic [3:0] next_state;

always_comb begin
  priority case (status) inside
    3'b00?: next_state = p_done;
    3'b01?: next_state = p_init;
    3'b1?0: next_state = p_end;
    3'b1?1: next_state = p_error;
  endcase
end

Unless matching upon 'bX or 'bZ is genuinely required, then casex or casez should not be used. Instead, the case inside construct should be used to indicate don’t-care bits in the case select as per the previous example.

Expressions

Make operator associativity explicit. This is to avoid any ambiguity over the ordering of operators. In particular, always bracket the condition of a ternary/conditional expression (?:), especially if you are nesting them, since they associate left to right, and all other arithmetic and logical operators associate right to left.

... = (a && b) ||
      (c && d)
... = |(a[7:0] & b[7:0])
... = valid && (|a[3:0])
... = (a == b) ? c : d
... = cond_a              ? e1 :
      (cond_b && !cond_c) ? e2 :
                            e3
... = !(a[1:0] inside {2'b00, 2'b01}) &&
      ^(b[31:0])

Make expression bit lengths explicit. Although the SystemVerilog specification provides rules for the extension of operands as inputs to binary operations and assignments, these are complicated and not always obvious. In particular, the extension is determined either by the operands or by the context of the expression. Since there may be inconsistencies between tools, particularly between simulation and synthesis, explicitly specifying expression bit widths avoids these issues and makes the intent obvious. For example, pad the result of a narrower expression for assignment:

logic [31:0] result;
logic [7:0] op1, op2;
assign result = {24'b0, {op1 & op2}};

Use an explicit type cast to specify the width of an intermediate expression (note that integer literals are interpreted as 32-bit integers):

always_ff @(posedge i_clk or posedge i_rst)
  value_q <= i_rst ? value_t'(42) : value;

Special care should be taken with sub expressions, since their result length is determined automatically by the width of the largest operand. For example, without an explicit type cast to a 17-bit result around a + b, the carry out bit would be lost:

logic [15:0] result, a b;
typedef logic [16:0] sum_t;
assign result = sum_t'(a + b) >> 1;

Capture carry out bits (even if they are unused) so the left-hand-side assignment width matches the full width of the right hand side. Using a prefix like unused_ makes the process of signing off any related warnings with the downstream synthesis and physical build simpler:

assign {unused_co, result} = a + b;

Exceptions to this rule can be made for the common constants 0, 1 and -1 to be specified as integer literals, for example:

assign result = 0;
assign sum = value - 1;

Use signed types for signed arithmetic, and avoid implementing signed arithmetic with manual sign extensions. SystemVerilog uses the signedness of an expression to determine how to extend its width (as well as inferring signedness of parent expressions). Since the rules for sign determination is similar to expression size but not the same, making it explicit avoids errors. It also facilitates the use of optimised arithmetic implementations in synthesis, particularly with multipliers. The following example (adapted from this presentation) shows how these rules can be confusing:

logic signed [3:0] a, b;
logic signed [4:0] sum;
logic ci;
sum = a + b + ci; // Unsigned addition due to unsigned ci.
sum = a + b + signed'(ci); // Signed addition, but ci == 1'b1 will be
                           // sign extended to 4'b1111 or -1.
sum = a + b + signed'({1'b0, ci}); // Safe sign extension.

Note that an operation is only considered signed if all of the operands are signed, and that literal values can be specified as signed, for example: 2'sb11 is -1 in 2 bits.

Avoid splitting arithmetic between statements or modules. This facilitates optimisation during synthesis, for example, to choose or generate an optimised adder implementation for the given set of operands and carry ins/outs. Instead of:

logic [3:0] a, b, c;
logic [4:0] int_sum, sum;
int_sum = a + b;
{unused_co, sum} = int_sum + {1'b0, c};

All of the arithmetic contributing to sum can be written in a single expression:

{unused_co, sum} = a + b + c;

Do not mix bitwise and logical operator in the same expression. There are different precedence rules for the types, so the behaviour may not be what is expected. Instead, break up the expression to make it explicit what the intended behaviour is.

Constants

Avoid magic numbers. All numeric constants, with the exception of zero and one (for incrementing) should be defined symbolically. All assignment to constants must be sized correctly to avoid width-mismatch warnings that must be signed off later in the flow.

Constants should be declared inside packages. Derived constants with a meaning specific to a module should be defined in the appropriate scope of the module.

Constants assigned to an enum port must be of the same enum type. Not doing so relies on an implicit conversion, which can have inconsistent behaviour between tools. Assign an enum value directly, or by using a static cast. For example:

package m_foo_pkg;
  typedef logic [1:0] {
    A, B, C, D
  } enum_t;
endpackage

module m_foo (
  input m_foo_pkg::enum_t in,
  ...
);
...
endmodule

module m_bar (...);
  ...
  m_foo u_foo (
    // Tie the input to a constant value using the enum type, rather than
    // via a value of any other type.
    .in(m_foo_pkg::D),
    ...
  );
  ...
endmodule

Be explicit when assigning values to nets and variables. For example:

logic [127:0] data_a;

// Explicitly 32 bits wide, decimal 0 assigment.
assign data_a = 128'd0;

// Explicitly 32 bits wide, binary 0 assignment.
assign data_a = 128'b0;

// Avoid.
assign data_a = 'd5;

// A user-defined type.
foo_pkg::bar data_b;

// An implicit cast is acceptable.
assign data_b = 'd5;

// But an explicit one is best.
assign data_b = foo_pkg::bar'(5);

With the exception of '0, unsized literal single-bit values (unsigned and without a radix) in assignments should not be used in combinatorial logic, since they can be misinterpreted. They appear similar to explicit assignments with a radix, yet represent very different values. For example, '1 looks similar to 'd1 but encodes the value $2^n - 1$ where $n$ is the width of the variable being assigned to.

logic [15:0] data;

// Sets data to 16'hFFFF, not 16'h0001.
assign data = '1;

// Clearer and harder to misinterpret.
assign data = 16'hFFFF;

// The replication operator should be used to set all bits to a value.
assign data = { 16 {1'b1} }; // Equivalent to above assigment

// Acceptable since repeated zeroes are still zero.
assign data = '0;
assign data = 16'h0; // Equivalent

X values

Assignment of X values as don’t care values should be avoided. This is for similar reasons for not using non-reset registers, which can lead to simulation-versus-synthesis mismatches, potentially obscuring bugs. However, if it can be demonstrated that use of X values can provide better QoR in the physical build of a block, specific and limited use of X values can be justified.

Naming

Clear and consistent naming is important for a design to be easily understood and maintainability by a designer, but naming must facilitate easy manipulation by various tools in the RTL and physical design flows.

During RTL debug, names should allow simple sorting and searching in a wave viewer. By using common prefixes for related signals, sorting will place them together. Similarly, common substrings are useful to filter a subset of signals over, for example to select a set of registers or similar signals different in pipeline stages.

Throughout the physical design flows, names must allow sensible flattening. It is typical for synthesis to flatten the hierarchical structure and consequently symbol names are derived from their place in the module hierarchy. A suitable naming scheme really only requires consistency across a design. As an example, a flip-flop clock pin might be named u_toplevel_u_submodule_p0_signal_q_reg_17_/CK corresponding to the register u_toplevel/u_submodule/p0_signal_q[17].

Names should be meaningful, whilst avoiding excessive verbosity. For example, n3 should be avoided as it lacks meaning whereas floating_point_opcode_bus is excessively long. fp_opcode is a reasonable compromise.

Avoid using C/C++/Verilog/SystemVerilog/VHDL keywords as names. Even if they are not reserved names in the language being used in that file. For example: auto, unsigned, task, register or asm.

All names must be all lower case and underscore separated. For example:

module m_cpu;
module m_cpu_pkg;
logic unused_co
logic p3_ctrl
logic p4_prod_q
begin : ecc_encode

Prefixes and suffixes

Name prefixes are generally used to indicate object types (such as module instances, flip flops, ports etc), and suffixes are generally used to convey semantic information. A good standard set of prefixes and suffixes are enumerated below:

Prefix	Usage
`i_`	Input port
`o_`	Output port
`io_`	Bidirecitonal (inout) port
`u_`	Module instance
`m_`	Module definition
`p_`	Parameter/localparam
`g_`	Generate block
`[a-z][0-9]_`	Pipeline stage
`unused_`	Unused signal for lint signoff

Suffix	Usage
`_clk`	Clock signal
`_gclk`	Gated clock signal
`_rst`	Reset signal
`_q`	Signal driven from a flip flop
`_n`	Active-low signal
`_t`	Type via a typedef
`_pkg`	Package
`_if`	Interface

Where signals are both active-low and require a suffix from elsewhere in the table, the _n suffix should be appended without an extra underscore. For example, _q becomes _qn for an active-low flop output, and _clk becomes _clkn for an inverted clock.

The following code example shows appropriate usage of the above prefix and suffix guidelines:

module m_ctrl_fsm (
  input logic         i_clk,
  input logic         i_rst,
  input logic         i_ready,
  input logic         i_done,
  output logic [2:0]  o_control
);

  typedef enum logic [2:0] {
    IDLE = 3'b000,
    LOAD = 3'b110,
    DONE = 3'b001
  } state_t;

  state_t state_q;
  state_t next;

  assign o_control = state_q;

  always_ff @(posedge i_clk or posedge i_rst) begin
    if (i_rst) begin
      state_q <= IDLE;
    end else begin
      state_q <= next;
    end
  end

  always_comb begin
    unique case (state_q)
      IDLE: if (i_ready) next = LOAD;
            else         next = IDLE;
      LOAD: if (i_done)  next = DONE;
            else         next = LOAD;
      DONE:              next = IDLE;
    endcase
  end

endmodule

Another example illustrates the use of the pipeline prefix, using e to denote an external signal and p an internal one:

module m_mempipe (
  input  logic        i_clk,
  input  logic        i_rst,
  input  logic        i_e1_valid,
  input  logic [18:2] i_e1_addr,
  output logic [31:0] o_e2_data
);
  ...
  logic        p2_valid_q;
  logic [31:0] p2_data;
  logic [31:0] p3_data_q;
  ...

  always_ff @(posedge i_clk or posedge i_rst) begin
    if (i_rst) begin
      p3_data_q <= 32'h00000000;
    end else if (e2_valid_q) begin
      p3_data_q <= p2_data;
    end
  end

  assign o_e2_data = p3_data_q;

endmodule

Signal naming

A strict approach to signal naming should be taken to make it easier to understand and navigate a design:

To make clear their relationship to the structure of a module. Prefixes and suffices can denote, for example, whether a signal is an input or output, the pipeline stage it corresponds to and whether it is driven by logic or directly from a flip-flop. The exact naming convention will be tailored to a project, but here are some examples:

i_p0_operand     // Input into pipeline stage 0.
p1_state         // A current state of a state machine.
p1_state_ns      // The next state.
state_clk        // A clock signal.
m1_sum_co_unused // An unused carryout bit from an addition.
m2_result_ff     // A registered result, driven by a flip-flop.
o_x4_state       // An output signal driven from stage x4.

To allow simple sorting and searching in wave viewer. By using common prefixes for related signals, sorting will place them together. Similarly, common substrings are useful to filter a subset of signals over, for example to select a set of registers or similar signals different in pipeline stages.

To be flattened sensibly by downstream tools. It is typical for synthesis to flatten the hierarchical structure of a SystemVerilog design. Consequently symbols names are derived from their place in the module hierarchy. A suitable naming scheme really only requires consistency across a design. As an example, a flip-flop clock pin might be named u_toplevel_u_submodule_p0_signal_q_reg_17_/CK corresponding to the register u_toplevel/u_submodule/p0_signal_q[17].

Generate block naming

All scopes of a generate block should be named. This avoids automatically-assigned names being created by the elaboration tool, making it hard to understand the structure of the code. This applies to branches of conditional and loop statements. For example, with named conditions:

module m_gen_cond #(
    parameter p_gen_diff = 0)();
  logic gen_op0;
  logic gen_op1;
  logic gen_op2;
  generate
    if (p_gen_diff == 1) begin
      assign gen_op0 = 1'b1;
    end else begin
      assign gen_op0 = 1'b0;
    end
    if (p_gen_diff == 1) begin
      assign gen_op1 = 1'b1;
    end else begin
      assign gen_op1 = 1'b0;
    end
    if (p_gen_diff == 1) begin : g_eq_1
      assign gen_op2 = 1'b1;
    end else begin : g_eq_0
      assign gen_op2 = 1'b0;
    end
  endgenerate
endmodule

In the resulting hierarchy, the first two conditionals are not easily distinguishable, nor are the branches that are chosen:

m_gen_cond
  g_eq_0
  genblk1
  genblk2

With named loops, a similar situation arises:

module m_gen_loop #(
    parameter p_gen_diff = 0)();
  logic [2:0] gen_op0;
  logic [2:0] gen_op1;
  logic [2:0] gen_op2;
  generate
    for (genvar i=0; i<3; i++) begin
      assign gen_op0[i] = 1'b0;
    end
    for (genvar i=0; i<3; i++) begin
      assign gen_op1[i] = 1'b0;
    end
    for (genvar i=0; i<3; i++) begin : g_loop
      assign gen_op2[i] = 1'b0;
    end
  endgenerate
endmodule

In the resulting hierarchy, there is no correspondence to the blocks assigning to gen_op0 or gen_op1, indeed these could be switched with no visibility in the hierarchy:

m_gen_loop
  g_loop[0]
  g_loop[1]
  g_loop[2]
  genblk1[0]
  genblk1[1]
  genblk1[2]
  genblk2[0]
  genblk2[1]
  genblk2[2]

Using a g_ prefix for named generate blocks, clearly distinguishes with instantiations of modules, for example:

module m_foo (
...
);
  m_child u_child (...);
  generate
    for (genvar i=0; i < 3; i++) begin : g_loop
      ...
    end
  endgenerate
endmodule

Has the hierarchy:

m_foo
u_child
g_loop

Code structure

Modules

Place parameters and variables at the top of their containing scope. Nets/variables/parameters should be declared in the minimum scope in which they will be used to avoid polluting namespaces. For example, nets global to a module should be declared at the top of the module for use in the code that follows.

Separate combinatorial and sequential nets. Declarations of combinatorial and sequential nets should be separated into different sections for clarity. This allows the flip-flops in the design to be seen clearly providing a feel for the size and complexity of the block. The following ripple-carry adder with registered outputs illustrates this kind of structuring:

module m_rca
  #(parameter p_width = 8)
  ( input  logic               i_clk,
    input  logic               i_rst,
    input  logic [p_width-1:0] i_op1,
    input  logic [p_width-1:0] i_op2,
    output logic               o_co,
    output logic [p_width-1:0] o_sum );

  // Wires.
  logic [p_width-1:0] carry;
  // Registers.
  logic [p_width-1:0] sum_q;
  logic               co_q;
  // Variables.
  genvar              i;

  assign carry[0] = 1'b0;
  assign {o_co, o_sum} = {co_q, sum_q};

  // Named generate block for per-bit continuous assignments.
  for (i = 0; i < p_width; i = i + 1) begin: bit
    assign {carry[i+1], sum[i]} = i_op1[i] + i_op2[i] + carry[i];
  end

  always_ff @(posedge i_clk or posedge i_rst) begin
    if (i_rst) begin
      sum_q <= {p_width{1'b0}};
      co_q  <= 1'b0;
    end else begin
      sum_q <= sum;
      co_q  <= carry[p_width-1];
    end
  end

endmodule

Use .* and .name() syntax in some circumstances to simplify port lists in module instantiations. Doing so can reduce the amount of boilerplate code and thus the scope for typing or copy-paste errors. The wildcard .* also provides additional checks:³

It requires all nets be connected.
It requires all nets to be the same size.
It prevents implicit nets from being inferred.

Named connections with .name() can be used with wildcards to add specific exceptions, such as when names do not match or for unconnected or tied-off ports. For example:

module foo (input logic i_clk,
            input logic i_rst,
            input logic in,
            output logic out);
  ...
endmodule

u_module foo (.*,
              .in(in),
              .out(out));

Bear in mind that implicit hookups with wildcards may obscure module connectivity when navigating source code during debug. It is up to the designer to make the right tradeoff. Specific examples of where wildcard hookups are useful are in wrapper modules and testbenches.

Avoid logic in module instantiations. By instantiating a module with a set of named signals, mapping one-to-one with ports, it is easier to inspect the port hookups and the widths of the signals for correctness. Not doing so obscures functionality in the design.

In parameter lists, separate parameters that are intended to be set externally from secondary parameters that are only used internally. There is no way to prevent some parameters being set externally, ie with localparam, so a comment can be used to do this, for example:

module m_rf
#(parameter
  p_entry_width = 32,
  p_num_entries = 64,
  // Internal parameter(s) - do not set.
  p_idx_width = $clog2(p_num_entries-1))
( ...,
  input logic [p_entry_width-1:0] wr_data,
  input logic [p_idx_width-1:0] wr_idx,
  input logic wr_en,
...
);

Name scopes that contain local variables. For similar reasons to the naming of generate blocks, if a variable is declared in a local scope, that scope must be named. It may be useful to introduce named local scopes to separate a large module into sections. For example:

begin : p0
  ...
end
begin : p1
  ...
end

Any unused or dangling signals/ports within a block must be terminated with a signal prefixed with unused_. These signals can be AND-reduced to make a single-bit signal. The AND-reduction with constant zeros guarantees the result is always zero, so it can be safely optimised away. For example:

logic _unused_ok = &{1'b0,
                     sig_not_used_a,
                     sig_not_used_yet_b // To be fixed
                     };

Packages

Define packages to share definitions (types, constants, tasks, functions etc) between multiple modules or IPs.

Qualify types, constants, tasks or functions with their package name and avoid * imports. This resolves any potential ambiguity in the providence of symbols to the designer and avoids polluting the current scope with all names defined by the package. For example:

// Avoid
import m_core_pkg::*;

// Prefer
m_core_pkg::FIFO_RAM_WIDTH
m_core_pkg::grey_code(...)

Assertions

Assertions should be written in a separate file that is bound in to the appropriate scope. Verification tests must be written to specifically ensure that the assertions are present in simulation.

Assertion files must be named after the block they apply to, with an _assert.sv suffix. Where assertions have been split into different groups to allow use in gate-level simulations (or other environments), the file name may have a _ports_assert.sv, _regs_assert.sv or _nets_assert.sv suffix as appropriate.

Preprocessor

In general, it should be possible to avoid any preprocessing of code. Other built-in language structures such as parameters and generate statements should be used instead. Don’t use local define statements in modules unless absolutely necessary, use localparam instead of define:

// Avoid
`define CONSTANT 1

// Prefer
localparam p_constant = 1;

This is because SystemVerilog macro definitions are not scoped within a module, which can easily lead to them ‘leaking’ between files in a filelist, making the elaboration dependent on the ordering of the list.

For similar reasons, use generate-if blocks instead of ifdef.

// Avoid
`ifdef FLAG
...
`endif

// Prefer
generate
  if (p_flag) begin
  ...
  end
endgenerate

If a local define is unavoidable, then a corresponding undef must be included before the end of the file. This is to avoid macro definitions polluting the global namespace.

`define LOCAL_DEFINE

...

// End of the file or use of LOCAL_DEFINE
`undef LOCAL_DEFINE

Formatting

Rules for formatting are not mandated so to provide some flexibility to designer’s own tastes and the inevitable exceptions to rules. Above all, the most important issue with formatting is to maintain consistency within a logical part of the design.

Use spaces instead of tabs, consistent with the accepted approach in other programming languages for compatibility with version control and editors etc.

Split long lines or complex expressions with continuations or across statements. Apply indent as appropriate for clarity. In this context, ‘long’ is a reasonable value chosen by the author, but typically between 80 and 120 characters.

Use begin and end to wrap if/else, always_ff and always_comb blocks. This adds consistency to the code and can help to prevent statements from unintentionally being excluded from a block. Only use begin and end in case alternatives when they contain multiple statements.

Summary

SystemVerilog is a large language with many features supporting different purposes. It is used as a standard in hardware design but its specification does not define a synthesizable subset. Although there is a general consensus on which features can be used for synthesis, the fine details are determined by the particular EDA tooling flow used by a design team. SystemVerilog is consequently used in a conservative way for specifying synthesizable designs. The rules and rationale given in this note outline some of the important aspects of a coding style for hardware design. There are many more details of SystemVerilog’s features that are relevant; the references below are a good place to find out more.

References/further reading

IEEE Standard for SystemVerilog (IEEE 1800-2012 and 1800-2017).
Sutherland HDL papers on Verilog/SystemVerilog, in particular:
- Stuart Sutherland and Don Mills, Standard gotchas subtleties in the Verilog and SystemVerilog standards that every engineer should know. SNUG 2006. (PDF)
- Stuart Sutherland, A Proposal for a Standard Synthesizable SystemVerilog Subset. DVCon 2006. (PDF)
- Stuart Sutherland and Don Mills, Synthesizing SystemVerilog: Busting the myth that SystemVerilog is only for verification, SNUG 2013. (PDF).
- Stuart Sutherland and Don Mills, Can my synthesis compiler do that? What ASIC and FPGA synthesis compilers support in the SystemVerilog-2012 standard, DVCon 2014 (PDF).
- Stuart Sutherland, I’m Still In Love With My X! (but, do I want my X to be an optimist, a pessimist, or eliminated?), DVCon 2013, (PDF).
Clifford E. Cummings and Don Mills. Synchronous Resets? Asynchronous Resets? I am so confused! How will I ever know which to use? (PDF.
SystemVerilog’s priority & unique - A Solution to Verilog’s “full_case” & “parallel_case” Evil Twins!, Clifford E. Cummings, SNUG 2005 (PDF).
lowRISC Verilog style guide.
Verilog HDL Coding, Semiconductor Reuse Standard, Freescale Semiconductor (PDF).
Complex Digital Systems, Synthesis, MIT OCW, 2005 (presentation slides, (PDF).
Datapath Synthesis for Standard-Cell Design, Reto Zimmermann, 2009 (PDF).
Getting the Most from Synthesis to Improve your Datapath QoR, Reto Zimmermann, Principal R&D Engineer, DesignWare IP (PDF).

More details on these types is given here and here. ↩
With one exception of memory structures that require initialisation via an external hierarchical reference. If the memory array is written by an always_ block, the memory cannot be driven by another process. Support for $deposit is patchy in tooling, so this cannot always be relied on. ↩
See Section 7 of ‘Synthesizing SystemVerilog: Busting the Myth that SystemVerilog is only for Verification (linked in the references). ↩

Notes on testing random number generators

2017-04-05T00:00:00+02:00

Recently I have been doing some work testing the quality of random number generators (RNGs), so I thought I would record things that should be useful as a reference. I won’t provide too much background here since there are many good existing references to the theory and practice of RNGs, the ones of which I have encountered I have linked to.

Properties

More specifically, a pseudorandom number generator (PRNG) is a repeatable process for producing numbers that have good statistical random properties. A true RNG, in contrast, produces statistically random numbers in a non-repeatable way, for example in electronics by using a physical source of entropy. True RNGs have an obvious importance in cryptographic applications.

A pseudorandom sequence can be repeated by starting with a particular seed number. The period of a PRNG is the longest unique sequence of numbers generated from any seed. The period is bounded by the size of the internal state of a generator ($n$ bits of state can encode $2^n$ numbers), however a generator may produce shorter repeated sequences, called cycles.

The properties of a ‘good’ PRNG are:

That the length of its period exceeds the number of values that taken from the generator by a program. As a rule of thumb, the period should be at least the square of the numbers used.
For independent uses of a generator concurrently, that the probability is low that any two sequences starting at different seeds overlap.
That successive values are uniformly distributed. In the literature this property is also described as equidistribution, which can be stated as the probability of finding a number in an interval of a sequence is proportional to the length of the interval.
That successive values are uncorrelated.
That each value can be computed efficiently.

The first two properties can typically be determined analytically and it is true that PRNGs are designed in order that they can be. Uniformity can be tested by sampling a large number of values and using statistical measures to analyse the difference from the expected distribution. The fifth characteristic is straightforward to determine, whether the generator is implemented in hardware or software. Much harder to determine, however, is the third property. If it were possible to prove whether a generator is free of correlation, no PRNG would be considered random since by definition there exists a well-defined relationship between successive numbers.

Empirical testing

Conventional approaches to testing RNGs subject them to a collection of tests, exploring different aspects of the generator’s statistics. They cannot be exhaustive, but are shown to be effective by their performance in detecting correlations in existing standard RNGs. This pragmatism is summed up well in this paper with the comment: “the different between good and bad RNGs, in a nutshell, is that the bad ones fail very simple tests whereas the good ones fail only very complicated tests that are hard to figure out or impractical to run.”

There are two popular empirical test suites:

TestU01, a comprehensive C library, containing example PRNGs, utilities and a collection of statistical tests drawn from the academic literature of RNGs. The statistical tests can be run ggindividually, or as part of test batteries, which have various run times and levels of stringency.
PractRand, which provides similar functionality to TestU01 but implemented in C++, with more modern features such as multithreading, flexible interfaces and support for long sequence lengths (over 100 terabytes). According to the author, it’s tests are not drawn from the literature (presumably designed by the author instead) and are therefore a good complement to testing with TestU01 or similar. It also requires more random bits than TestU01 and therefore takes longer to run.

Also worth investigating are the Dieharder test suite (an updated version of the original Diehard) and the RaBiGeTe test suite. There is also some interesting discussion from 2010 between the authors of PractRand and RaBiGete here.

Testing with TestU01

TestU01 provides an interface to test external generators written in C. The interface requires a method, GetU01, to generate numbers in the unit interval $[0, 1)$ as a double and a method, GetBits, to return 32 random bits as an unsigned int. Some tests will use random bits and some will use random floats. Just one function can be provided, with the other defined by TestU01 with the relationship $\texttt{GetU01}=\texttt{GetBits}/2^{32}$.

Converting 32 random bits to a double-precision float is lossless in that it has be represented exactly in the 52 bits of mantissa. However, the conversion biases the higher bits since the lowest bits will be most affected by numerical errors. For this reason, it is considered good practice to also test the reversed output of generator, to expose the lowest bits. To test generators with a larger output, say 64 bits, it is important that all the bits are exposed to the tests. One way to do this is to alternately use the high and low bits of a 64-bit value each call to GetBits or GetU01. A further reason to run the reverse of a generator is that the Crush test battery are defined to ignore the bottom-most bit of the generator’s output, and most tests also ignore the second bit (see the TestU01 documentation).

In his testing of the xorshift family of generators, Sebastiano Vigna takes the following approach to measuring quality with TestU01: for a particular generator, run it with 100 different seeds, which are spaced at regular intervals in the state space, i.e. for a generator with $n$ bits of state, choose seeds at $1 + i\lfloor 2^n/100\rfloor$ for $0 \leq i < 100$. The quality of a generator is then measured by the total number of failures over all seeds, with fewer failures meaning higher quality. If a generator has 100 or more failures, the failure is called systematic and the generator is disregarded. Quality is measured with the BigCrush battery, but since it takes many hours to run (using approximately $2^{38}$ random values in 106 tests), potential generators can be assessed by running the smaller test batteries SmallCrush (10 tests) and Crush (96 tests), continuing based on the number of failures.

Through my own experiments, I found that the reverse of a generator won’t always catch weak lower bits. xoroshiro128+ is currently the highest quality and fastest known generator, as measured by the above process, with 31 failures and 27 failures when reversed, but it has a known weak bit 0 that follows a linear recurrence that is not detected by BigCrush, even when reversed. However, the weak bit is detectable with the matrix rank test with parameters $N=1$, $n=80$, $r=15$, $s=15$, $L=k=5000$, or more simply by swapping the high and low 16-bit portions of each 32-bit word to move the bottom bit into the middle. I didn’t discover anything new about xoroshiro128+ here, but what this does highlight is that comprehensive test sets like TestU01 are by no means exhaustive, and it therefore worth testing some of their assumptions, particularly in this case if you are interested in the quality of bit 0.

Incidentally, TestU01 includes a battery of nine tests called Alphabit, which is allows specific bits or ranges of bits from a generator to be tested. It was not stringent enough however to detect the correlation of xoroshirt128+‘s bit 0.

An example

I’ve put together a simple example, available on Github, of using TestU01 to assess the quality of a PRNG, which replicates Vigna’s testing of xoroshiro128+. The code includes a C program to test xoroshiro128+ with the Crush batteries and Python scripts to run the test over different seeds and to summarise the output of TestU01.

A convolutional neural network from scratch

2017-02-10T00:00:00+01:00

The online book ‘Neural Networks and Deep Learning‘ by Michael Nielsen is an excellent introduction to neural networks and the world of deep learning. As the book works through the theory, it makes it concrete by explaining how the concepts are implemented using Python. The complete Python programs are available on Github for further inspection and experimentation.

I decided to write my own implementations of the examples however. Partly to develop a better understanding but also because I felt that the matrix-based presentation of the mathematics and use of NumPy operations in the examples obscured some of the intuition around neurons and their connections, and because the later examples of convolutional layers are implemented using Theano.

So, in the hope that it might be interesting as a simple and self-contained example of a convolutional neural network where nothing is hidden, I’ve put he source code for my implementation (written in C++) on GitHub. For reference I’ve also written up below the various equations for the fully-connected and convolutional layers in element-wise notation. I should thank two particularly useful blog posts by Andrew Gibiansky and Grzegorz Gwardys which helped me to derive the convolutional equations for back propagation.

The source code

The repository contains several example programs with different network configurations. They are instantiated from a generic header Network.hpp, which contains classes for fully-connected, softmax, convolutional and max-pooling layer types, and a network class that performs the stochastic gradient descent, minibatching and training over multiple epochs with randomly-shuffled training data. The header also contains definitions for quadratic and cross-entropy cost functions, and sigmoid and rectified-linear activation functions, which are specified as template parameters to the network. The code is written primarily primarily to be clear and understandable, as such there will be many opportunities for optimisations and other improvements (please let me know if you have any suggestions).

For instructions on how to build and run the examples, see the README.md file. Note that Boost is required for multi_array and Threading Building Blocks to parallelise the training over minibatches and accuracy evaluation by performing inferences in parallel, up to the minibatch size. It should be straightforward to build other network configurations or to modify the implementations or to experiment with new features.

Included in the extra folder, are implementations of the example programs in TensorFlow, adapted from the MNIST tutorial. I found these useful as a point of comparison to validate the behaviour of the networks.

Equations

The following notation roughly follows the notation in the Neural Networks and Deep Learning book:

$l$ is an index of a layer;
$w$ is a weight;
$z$ is a weighted input;
$a$ is an activation;
$y$ is a label;
$\delta$ is an error;
$\sigma$ is the activation function, $\sigma’$ is the derivative of it;
$C$ is the cost function.

For a fully-connected layer

In the forward pass, each neuron takes a weighted sum of its inputs, adds the bias and uses the result as the input to the activation function: $$z_i^l = \sum_j w_{j,i}^{l-1} a_j^{l-1} + b^l$$ $$a_i^l = \sigma(z_i^l)$$

The error of a neuron $i$ in the output layer is given by $\delta_i = (a_i -y_i)\sigma’(z_i)$ for the sigmoid activation function and by $\delta_i = a_i - y_i$ for the cross-entropy activation function.

In the backwards pass, errors are propagated to a neuron from neurons that are connected as outputs. The weighted sum of the output neuron’s errors and connection weight is calculated and this value is then multiplied by the derivative of the activation function: $$\delta_i^l = \sum_j w_{j,i}^{l+1} \delta_j^{l+1} \sigma’(z_i^l)$$

The delta for a weight is calculated from the error held by a neuron and the activation from the neuron connected by the input: $$\frac{\partial C}{\partial w_i^l} = a_i^{l-1}\delta_i^l$$

The delta for the bias is equal to the error held by a neuron: $$\frac{\partial C}{\partial b_i^l} = \delta_i^l$$

For a convolutional layer

Assuming a two-dimensional input of size $N\times N$ and convolutional mask of size $m\times m$.

In the forward pass, each neuron convolves the weights with its receptive field: $$z_{x,y}^l = \sum_{a=0}^{m-1}\sum_{b=0}^{m-1} w_{a,b}^{l-1}a_{x+a,y+b}^{l-1} + b^l$$ $$a_{x,y}^l = \sigma(z_{x,y}^l)$$

In the backwards pass, errors are propagated to a neuron from the neurons connected as outputs in the next layer: $$\delta_{x,y}^l = \sum_{a=0}^{m-1}\sum_{b=0}^{m-1} w_{a,b}^{l+1}\delta_{x-a,y-b}^{l+1}\sigma’(z_{x,y}^l)$$ One way to simplify this is to think of the convolutional layer as one dimensional (as with a fully-connected layer), where each neuron has only $m\times m$ inputs connections. Then, back propagation operates in the same way as it does with fully-connected layers. You can in fact use this approach to derive the above equation.

The delta of a weight is calculated from the activations in the previous layer that influence that weight and the errors held by the neurons that use it: $$\frac{\partial C}{\partial w_{a,b}^l} = \sum_{i=0}^{N-m}\sum_{j=0}^{N-m} a_{i+a, j+b}^{l-1}\delta_{i,j}^l$$

The delta of a bias is calculated from the errors held by the neurons that use it: $$\frac{\partial C}{\partial b^l} = \sum_{i=0}^{N-m}\sum_{j=0}^{N-m} \delta_{i,j}^l$$

With three-dimensional inputs, convolutional layers convolve a three-dimensional mask into the depth of the input. Convolutional layers can themselves produce three-dimensional outputs by stacking up separate convolutional processes in the same layer (called feature maps or channels), each contributing one element in the depth of the output. In this case, the backpropagation of the error must sum over the feature maps to get the contributions of each expression that contribute to the error. The weight and bias updates must sum errors over the input volume they are applied to.

Reducing memory use in deep neural networks

2017-02-05T00:00:00+01:00

The memory requirements for modern deep neural networks can be significant, however memory on-chip is expensive relative to computational resources such as integer and floating-point units, and access to external DRAM memory is orders of magnitude slower. This article surveys some recent results that demonstrate the economy of reducing memory use by reuse and re-computation.

Memory in neural networks is required to store input data, weight parameters, and activations as an input propagates through the network. In training, activations from an forward pass must be retained until they can be used to calculate the error gradients in the backwards pass. A 50-layer ResNet network, for example, has 25 million weight parameters and computes 16 million activations in the forward pass. With a batch of 32, this data alone occupies 5 GB; additional memory is required to store the program’s instructions, input data and temporary values, the last of which is multiplied by the level of parallelism in the execution. Measuring the memory use of ResNet-50 training on a Maxwell-generation Nvidia TitanX GPU shows that it uses up to 7.5 GB of the 12 GB available.

Reducing memory use is beneficial for neural networks for several reasons. First, it enables deeper networks to be trained, which have been shown to deliver superior performance for specific tasks and generalisation to new tasks. Second, it allows larger batch sizes to be used, which improves throughput and parallelisation. And third, and perhaps most importantly, it allows data to remain closer to where it is being operated on, reducing the effects of longer latency and lower bandwidth of larger-capacity off-chip memory, and consequently improving performance. To illustrate the challenge of last point with modern GPU architectures, it has been observed that the Maxwell TitanX GPU processor cores have only 1 KB of memory that can be read fast enough to saturate the floating-point datapath.

Two techniques to reduce memory use draw on the dataflow analysis that has been developed over decades of work with compilers for sequential programming languages. First, operations such as activation functions can be performed in place when the input data can be overwritten directly by the output, so the memory is reused. Second, memory can be reused by analysing the data dependencies between operations in a network and allocating the same memory to operations that do not use it concurrently.

The second approach is particularly effective when the entire neural network can be analysed at compile time to create a fixed allocation of memory since the runtime overheads of memory management reduce to almost zero. The combination of these techniques have been shown to reduce memory in neural networks by a factor of two to three. These optimisation techniques are analogous to the dataflow in a sequential program graph to allow the reuse of registers and stack memory, with their relatively higher efficiency compared to dynamic memory allocation routines.

Another approach is to trade reduced memory for an increase in computation. When the computational resources are underused, as they typically are in GPUs, an increase in computation won’t necessarily increase runtime, and if it does, can produce relatively higher savings of memory compared to the additional computation. A simple technique in this vein is to discard values that are relatively cheap to compute, such as activation functions, and re-compute them when necessary. More substantial reductions can be achieved by discarding retained activations in sets of consecutive layers of a network and re-computing them when they are required during the backwards pass, from the closest set of remaining activations. Recomputing activations over sets of layers has been demonstrated by the MXNet team to deliver a factor-of-four memory reduction for a ResNet-50 network, but more importantly, results in memory use that scales sub-linearly with respect to the number of layers. The team also demonstrated training of a 1000-layer ResNet in under 12 GB on the same Maxwell TitanX GPU.

A similar memory-reuse approach has been developed by researchers ar Google DeepMind with recurrent neural networks (RNNs). RNNs are a special type of DNN that allows cycles in their structure to encode behaviour over sequences of inputs. For RNNs, re-computation has been shown to reduce memory by a factor of 20 for sequences of length 1000 with only a 30% performance overhead. The Baidu Deep Speech team recently showed how they applied various memory-saving techniques obtain a factor of 16 reduction in memory for activations, enabling them to train networks with 100 layers on a Maxwell TitanX, when previously they could only train 9.

Relative to memory, compute resources are cheap. The state-of-the-art results surveyed show efficient use of memory through reuse and trading increased computation for reduced memory use can deliver dramatic improvements in the performance of neural networks. However, these results are for a processor with very limited on-chip memory, just a few megabytes, and just 1KB of fast memory per core. A processor with a better balance between memory and compute, allowing more of a neural network to be stored on-chip, may facilitate much more dramatic improvements.

[An adapted version of this article first appeared on the Graphcore blog and there was some discussion of it on Hacker News]

Machine learning challenges for computer architecture

2016-11-04T00:00:00+01:00

Neural networks have become a hot topic in computing and their development is progressing rapidly. They have a long history with some of the first designs proposed in the 1940s. But despite being an active area of research since then, it has not been until the last five to ten years that the field has started to deliver state-of-the-art results, with deep neural network-based algorithms displacing conventional machine-learning and programmed ones in many areas.

The recent developments in neural networks, since around 2010, has coincided with the availability of commodity high-performance GPUs. These devices provide enough memory and compute that networks can be trained with large datasets, in the order of hours or days, to perform classification tasks for practical and interesting problems such as image and speech recognition. Although GPUs have established themselves as the standard way to accelerate neural networks, they have done this by transitioning relatively quickly from applications in traditional HPC, but they are already evolving to meet the needs of machine learning. In this article I want to discuss some of the challenges that neural networks and their development present to GPUs, and indeed more generally to the status quo of computer architecture.

Compute and memory

The fundamental operations of a neural network are floating-point multiplications and additions. These are used to combine input data with the parameters of the network that control the influence of connections between neurons. Modern networks require considerable resources to store millions of parameters and perform billions of operations per input.

Neurons in fully-connected layers take weighted sums of their inputs (a multiplication and an accumulation, MAC, for each input) from every neuron in the previous layer. The number of MACs grows with the square of the layer size, and the number of layers, so even with modest numbers of layers and neurons per layer, the number of MACs can be large. In the AlexNet network, the last three layers are fully connected with 4,096, 4,096 and 1,000 neurons respectively, requiring 58.6 million parameters and, for the forward pass to classify a single input image with a trained network, the same number of MACs.

The use of convolutional layers reduces the number of parameters by sharing a small sets between the neurons. The five convolutional layers preceding the fully-connected layers in AlexNet contain just 2.5 million neurons, but require 655.6 million MACs per input. AlexNet was state of the art in 2009 and networks since then have developed with many more convolutional layers and a smaller fully connected component, resulting in relatively slow growth in the number of parameters but significant increases in the number of MACs. A variant of the VGG network (2014) with 19 layers (three fully connected) has 143.6 million parameters and requires a total of 19.6 million MACs in the forward pass. A variant of the ResNet network (2015) with 50 layers (one fully connected) has 25.5 million parameters and 3.8 billion MACs for the forward pass. More recent work has demonstrated benefits of networks with more than 1,000 layers.

When a network is being trained, more compute is required by an additional backwards pass and and memory requirements increase since intermediate values for each parameter must be maintained from the forward pass.

The challenge for computer architecture here is to deliver the huge number of MACs required for training and inference, whilst minimising the movement of data between fast local memory and slower main memory, or via a communication link. This will of course require corresponding developments in the implementation of neural networks. A recent result demonstrated that when data is kept on chip, much better use of GPU compute resource can be made to achieve an order of magnitude improvement in the depth of network that could be trained. Another has demonstrated that compute can be traded for a logarithmic reduction of memory in the number of layers.

Precision

Reducing the precision of arithmetic reduces the cost of memory and compute since lower-precision floating-point numbers require less bits of storage and require smaller more power-efficient structures in silicon to implement arithmetic operations. Recent research has demonstrated that representations between 8 and 16 bits can deliver similar results to 32-bit precision for inference and training. This has already has an impact on architecture: Google has claimed a 10x increase in efficiency with it’s Tensor Processing Unit (TPU) using 8-bit precision, and Nvidia’s new Pascal architecture supports 16-bit floating-point arithmetic at twice the rate of single precision, and 8-bit integer arithmetic at four times the rate. Intel have also recently announced a variant of their Xeon Phi processor, code named Knights Mill, that will be optimised for deep learning with variable precision floating-point arithmetic.

Structure

There is no single structure for data movement in deep neural networks. The simplest networks have connections between adjacent layers, which are evaluated in sequence, but many more complex structures have been proposed. For example, residual connections provide a pathway between non-adjacent layers, fractal architectures have self-similar structures at different scales and entire neural networks can be used as basic building blocks. There can also by dynamism in the structure; dropout prevents overfitting by randomly removing connections during training to ‘thin’ the network, and networks with stochastic depth randomly exclude subsets of layers during training to make deep networks more shallow.

These neural-network structures contrast with traditional HPC-style programs, which have long been the focus of parallel computing research and development and are characterised by a single structure and algorithm. The challenge here is for computing hardware and the programming models targeting it to support complex, highly-connected and potentially dynamic communication structures.

Programming

There are many languages, frameworks and libraries available for creating deep-learning applications and they are having to evolve quickly though to keep up with the pace of research. This is a strong indication that the means by which we program neural networks need to be general enough to facilitate experimentation but also deliver reasonable performance so that it is practical to explore different designs and hyper parameters.

However, there is a gulf between the high-level representations of neural networks used by researchers and their actual implementation on hardware. For example, Google’s TensorFlow programming framework is written in C++ and interfaces with GPUs via an abstraction layer that calls CUDA library routines. On top of this, Google have released a high-level Python wrapper for TensorFlow, called TensorFlow-Slim. But despite the abstraction and generality of the TensorFlow framework, achieving good computational efficiency on GPUs depends on a heavily-optimised high-level deep neural network library, such as cuDNN or NEON. The problem for all high-level programming approaches is that the performance of neural network designs that cannot exploit an underlying optimised library directly will degrade significantly. Closing the gap between the methods used to build neural networks and their mapping to a machine architecture would deliver more performance for a wider range of programs.

Deployment and portability

Finally, a unique aspect of machine-learning algorithms is the separation between the phase in which they are trained and their subsequent deployment for inference. Since training demands more compute and memory resources and is typically carried out in a data-centre environment where space, power and, to some extent, time are not constraining issues. A trained neural network can be deployed in more constrained environments, such as mobile or robotics, where they may be reacting in real time, to a voice user interface or sensor input for example, with limited memory and power. They may also continue to learn as they are exposed to more data.

The result of training is a set of parameter values and portability to another platform requires the weights to be loaded in an implementation of the same neural network. The implementation may differ in the numerical precision it uses since trained networks are known to be robust to low-precision parameter representations, and doing so takes advantage of the associated memory, performance and power benefits. A portable neural network might therefore need separate implementations for training and inference, optimised for the memory and compute constraints and to be targeted at different machine architectures. A standardised specification of neural networks, including trained parameters, would further improve portability between platforms.

There have been some efforts to try to measure aspects of the implementation, deployment and performance of deep neural networks. In particular Deepmark, which is based on specific networks, and Deepbench, which takes a simpler approach by just looking at important kernels.

In summary

Modern deep neural networks are now state-of-the-art in many application areas of computing but with their unique characteristics, they pose a significant challenge to conventional computer architecture. This challenge however is also an opportunity to build new machines and programming languages that break away from the status quo of sequential shared-memory von Neumann machines.

The XC Programming Language

2014-12-13T00:00:00+01:00

XC is a programming language developed by XMOS for real-time embedded parallel programming of their XCore processor architecture. XC is based on the features for parallelism and communication in occam, and the syntax and some sequential features of C. In addition, XC provides primitives to expose hardware resources: locks, ports and timers. XC programs can be executed with levels of I/O real-time performance that is usually attributed to FPGA or ASIC devices. The design of XC was heavily influenced by the occam programming language, which first introduced channel communication, alternation, ports and timers. Occam was developed by David May and built on the Communicating Sequential Processes formalism, a process algebra developed by Tony Hoare.

This note was originally written for Wikipedia, but the content was removed owing to it being too much like a manual. To save it from being lost, I’ve posted it here (December 2021).

Architectural model

An XC program executes on a collection of XCore tiles. Each tile contains one or more processing cores and resources that can be shared between the cores, including I/O and memory. All tiles are connected by a communication network that allows any tile to communicate with any other tile. A given target system is specified during compilation and the compiler ensures that a sufficient number of tiles, cores and resources are available to execute the program being compiled.

Features

The following sections outline the key features of XC.

Parallelism

Statements in XC are executed in sequence (as they are in C), so that in the execution of:

f(); g();

the function g is only executed once the execution of the function f has completed. A set of statements can be made to execute in parallel using a par statement, so that the statement

par { f(); g(); }

causes f and g to be executed simultaneously. The execution of parallel statement only completes when each of the component statements have completed. The component statements are called tasks in XC.

Because the sharing of variables can lead to race conditions and non-deterministic behaviour, XC enforces parallel disjointness. Disjointness means that a variable that is changed in one component statement of a par may not be used in any other statement.

Parallel statements can be written with a replicator, in a similar fashion to a for loop, so that many similar instances of a task can be created without having to write each one separately, so that the statement:

par (size_t i=0; i<4; ++i)
  f(i);

is equivalent to:

par { f(0); f(1); f(2); f(3); }

The tasks in a parallel statement are executed by creating threads on the processor executing the statement. Tasks can be placed on different tiles by using an on prefix. In following example:

par {
  on tile[0] : f();
  par (size_t i=0; i<4; ++i)
    on tile[1].core[i] : g();
}

the task f is placed on any available core of tile 0 and instances of the task g placed on cores 0, 1, 2 and 3 of tile 1. Task placement is restricted to the main function of an XC program. Conceptually, this is because when an XC program is compiled, it is divided up at its top level, into separately executable programs for each tile.

Communication

Parallel tasks are able to communicate with each other using interfaces or channels. Interfaces

An interface specifies a set of transaction types, where each type is defined as a function with parameter and return types. When two tasks are connected via an interface, one operates as a server and the other as a client. The client is able to initiate a transaction with the corresponding server, with syntax similar to a conventional function call. This interaction can be seen as a remote procedure call. For example, in the parallel statement:

interface I { void f(int x); };
interface I i;
par {
  select { // server
    i.f(int x):
      printf("Received %d\n", x);
      break;
  }
  i.f(42); // client
}

the client initiates the transaction f, with the parameter value 42, from the interface i. The server waits on the transaction (as a case in the select statement) and responds when the client initiates it by printing out a message with the received parameter value. Transaction functions can also be used for two-way communication by using reference parameters, allowing data to be transferred from a client to a server, and then back again.

Interfaces can only be used by two tasks; they do not allow multiple clients to be connected to one server. The types of either end of an interface connection of type T are server interface T and client interface T. Therefore, when interface types are passed as parameters, the type of connection must also be specified, for example:

interface T i;
void s(server interface T i) { ... }
void c(client interface T i) { ... }
par {
  s(i);
  c(i);
}

Transaction functions in an interface restrict servers to reacting only in response to client requests, but in some circumstances it is useful for a server to be able to trigger a response from the client. This can be achieved by annotating a function in the interface with no parameters and a void return type, with [[notification]] slave. The client waits on the notification transaction in a select statement for the server to initiate it. A corresponding function can be annotated with [[clears_notification]], which is called by the slave to clear the notification. In the following simple example:

interface I {
  void f(int x);
  [[notification]] slave void isReady();
  [[clears_notification]] int getValue();
};
interface I i1, i2;
par {
  for (size_t i=0; i<2; ++i) { // server
    select {
      i2.f(int x):
        i1.isReady();
        break;
      i1.getValue() -> int data:
        data = 100;
        break;
    }
  }
  { int d;                     // client 1
    select {
      i1.isReady():
        d = i1.getValue();
        break;
    }
  }
  i2.f(42);                    // client 2
}

when client 2 initiates the transaction function f, the server notifies client 1 via the transaction function isReady. Client 1 waits for the server notification, and then initiates getValue when it is received.

So that it is easier to connect many clients to one server, interfaces can also be declared as arrays. A server can select over an interface array using an index variable.

Interfaces can also be extended, so that basic client interfaces can be augmented with new functionality. In particular, client interface extensions can invoke transaction functions in the base interface to provide a layer of additional complexity.

Channels

Communication channels provide a more primitive way of communicating between tasks than interfaces. A channel connects two tasks and allows them to send and receive data, using the in <: and out :> operators respectively. A communication only occurs when an input is matched with an output, and because either side waits for the other to be ready, this also causes the tasks to synchronise. In the following:

chan c;
int x;
par {
  c <: 42;
  c :> x;
}

the value 42 is sent over the channel c and assigned to the variable x.

Streaming channels

A streaming channel does not require each input and matching output to synchronise, so communication can occur asynchronously.

Event handling

The select statement waits for events to occur. It is similar to the alternation process in occam. Each component of a select is an event, such as an interface transaction, channel input or port input (see #IO), and an associated action. When a select is executed, it waits until the first event is enabled and then executes that event’s action. In the following example:

select {
  case left :> v:
    out <: v;
    break;
  case right :> v:
    out <: v;
    break;
}

the select statement merges data from left and right channels on to an out channel.

A select case can be guarded, so that the case is only selected if the guard expression is true at the same time the event is enabled. For example, with a guard:

case enable => left :> v:
  out <: v;
  break;

the left-hand channel of the above example can only input data when the variable enable is true.

The selection of events is arbitrary, but event priority can be enforced with the [[ordered]] attribute for selects. The effect is that higher-priority events occur earlier in the body of the statement.

To aid in creating reusable components and libraries, select functions can be used to abstract multiple cases of a select into a single unit. The following select function encapsulates the cases of the above select statement:

select merge(chanend left, chanend right, chanend out) {
  case left :> v:
    out <: v;
    break;
  case right :> v:
    out <: v;
    break;
}

so that the select statement can be written:

select {
  merge(left, right, out);
}

Timing

Every tile has a reference clock that can be accessed via timer variables. Performing an output operation on a timer reads the current time in cycles. For example, to calculate the elapsed execution time of a function f:

timer t;
uint32_t start, end;
t :> start;
f();
t :> end;
printf("Elapsed time %u s\n", (end-start)/CYCLES_PER_SEC);

where CYCLES_PER_SEC is defined to be the number of cycles per second.

Timers can also be used in select statements to trigger events. For example, the select statement:

timer t;
uint32_t time;
...
select {
  case t when timerafter(time) :> void:
    // Action to be performed after the delay
    ...
    break;
}

waits for the timer t to exceed the value of time before reacting to it. The value of t is discarded with the syntax :> void, but it can be assigned to a variable x with the syntax :> int x.

IO

Variables of the type port provide access to IO pins on an XCore device in XC. Ports can have power-of-two widths, allowing the same number of bits to be input or output every cycle. The same channel input and output operators < and > respectively are used for this.

The following program continuously reads the value on one port and outputs it on another:

#include <xs1.h>
in port p = XS1_PORT_1A;
out port q = XS1_PORT_1B;
int main (void) {
  bool b;
  while (1) {
    p :> b;
    q <: b;
  }
}

The declaration of ports must have global scope and each port must specify whether it is inputting or outputting, and is assigned a fixed value to specify which pins it corresponds to. These values are defined as macros in a system header file (xs1.h).

By default, ports are driven at the tile’s reference clock. However, clock block resources can be used to provide different clock signals, either by dividing the reference clock, or based on an external signal. Ports can be further configured to use buffering and to synchronise with other ports. This configuration is performed using library functions. Port events

Ports can generate events, which can be handled in select statements. For example, the statement:

select {
  case p when pinseq(v) :> void:
    printf("Received input %d\n", v);
    break;
}

uses the predicate when pinseq to wait for the value on the port p to equal v before triggering the response to print a notification.

Port timing

To be able to control when outputs on a port occur with respect to the port’s clock, outputs can be timestamped or timed. The timestamped statement:

p <: v @ count;

causes the value v to be output on the port p and for count to be set to the value of the port’s counter (incremented by one each reference clock cycle). The timed output statement:

p @ count <: v;

causes the port to wait until its counter reaches the value of count before the value v is output.

Multiplexing tasks onto cores

By default, each task maps to one core on a tile. Because the number of cores is limited (eight in current XCore devices), XC provides two ways to map multiple tasks to cores and better exploit the available cores.

Server tasks that are composed of a never-ending loop containing a select statement can be marked as combinable with the attribute [[combinable]]. This allows the compiler to combine two or more combinable tasks to run on the same core, by merging the cases into a single select.

Tasks of the same form as combinable ones, except that each case of the select handles a transaction function, can be marked with the attribute [[distributable]]. This allows the compiler to convert the select cases into local function calls.

Memory access

XC has two models of memory access: safe and unsafe. Safe access is the default in which checks are made to ensure that:

memory accesses do not occur outside of their bounds;
memory aliases are not created;
dangling pointers are not created.

These guarantees are achieved through a combination of a different kinds of pointers (restricted, aliasing, movable), static checking during compilation and run-time checks.

Unsafe pointers provide the same behaviour as pointers in C. An unsafe pointer must be declared with the unsafe keyword, and they can only be used within unsafe { ... } regions.

Additional features

References

XC provides references, that are similar to those in C++ and are specified with the & symbol after the type. A reference provides another name for an existing variable, such that reading and writing it is the same as reading and writing the original variable. References can refer to elements of an array or structure and can be used as parameters to regular and transaction functions.

Nullable types

Resource types such as interfaces, channel ends, ports and clocks must always have a valid value. The nullable qualifier allows these types to have no value, which is specified with the ? symbol. For example, a nullable channel is declared with:

chan ?c;

Nullable resource types can also be used to implement optional resource arguments for functions. The isnull() builtin function can be used to check if a resource is null.

Multiple returns

In XC, functions can return multiple values. For example, the following function implements the swap operation:

{int, int} swap(int a, int b) {
  return {b, a};
}

The function swap is called with a multiple assignment:

{x, y} = swap(x, y);

Multicore Hello World

The following program prints Hello World on four processors:

#include <stdio.h>
#include <platform.h>

void hello(int id, chanend cin, chanend cout){
  if (id > 0) cin :> int;
  printf("Hello from core %d!", id);
  if (id < 3) cout <: 1;
}

int main(void) {
  chan c[3];
  par (int i=0; i<4; i++)
    on tile[i] : hello(i, c[i], c[(i+1)%4]);
  return 0;
}

References and further reading

David May. The XMOS XS1 Architecture (PDF).
Douglas R. Watt. Programming XC on XMOS Devices (PDF).
The XMOS programming guide (HTML, PDF)
The XC Language Specification (HTML)
xC is C plus x, Øyvind Teig.

The XMOS XMP-64

2014-12-04T00:00:00+01:00

The XMP-64 is an experimental single-board distributed-memory parallel computer with 512 hardware threads and is programmable with a C-like language. It was developed by XMOS in 2009 to demonstrate the scalablility of the XS1 architecture. Since then it has been discontinued but remains a fascinating device from the point of view of providing a huge amount of parallelism that is programmable in a simple way. As such, I thought I would record some details and images of it here.

The XMP-64 board contains a four-by-four grid of XS1-G4 chips, each with four processor cores, and with core providing eight hardware threads. The G4 chips themselves are connected in an order-four hypercube topology, with every G4 connected directly to four others. The G4 has 16 links, so four links are used to connect each direction. The data rate of each link is 400 Mbits/second, or 1.6 Gbits/second in each edge of the hypercube. The bisection bandwidth of the entire network is four times this again, at 6.4 Gbits/second. Each processor core has 64 KB of SRAM memory and runs at 400 MHz. The whole XMP-64 array therefore provides 512 threads, 4 MB of memory and a peak performance of 25.6 GOPS. (There are more details in the performance experiment document linked below)

Since the G4 is an embedded processor, these performance numbers are not competitive with contemporary CPU or GPU devices; it does however burn only a few tens of watts of power, provides deterministic (completely predictable) execution of 512 threads and provides a very simple programming interface.

As you can see in the pictures, there are two Ethernet interfaces at the top of the board, which could be used to daisy chain multiple XMP-64 boards together. Additionally there are 64-pin headers on either side that expose general-purpose I/O pins connected directly to processors in the array.

Below is an example program for the XMP-64 written in XC, a programming language based on occam designed to target the features of the XS1 architecture. The program uses a ring topology of communication channels to connect one thread on each chip. As a token is passed around, the LED connected to each G4 is switched on for a short period.

#include <platform.h>
#include <xs1.h>

#define NUM_CHIPS (16)
#define STEP      (4)

out port leds[] = {
  on stdcore[0] : XS1_PORT_1E,
  on stdcore[4] : XS1_PORT_1E,
  on stdcore[8] : XS1_PORT_1E,
  on stdcore[12]: XS1_PORT_1E,
  on stdcore[16]: XS1_PORT_1E,
  on stdcore[20]: XS1_PORT_1E,
  on stdcore[24]: XS1_PORT_1E,
  on stdcore[28]: XS1_PORT_1E,
  on stdcore[32]: XS1_PORT_1E,
  on stdcore[36]: XS1_PORT_1E,
  on stdcore[40]: XS1_PORT_1E,
  on stdcore[44]: XS1_PORT_1E,
  on stdcore[48]: XS1_PORT_1E,
  on stdcore[52]: XS1_PORT_1E,
  on stdcore[56]: XS1_PORT_1E,
  on stdcore[60]: XS1_PORT_1E
};

void flash_led(int id, chanend prev, chanend next, out port led) {
  timer t;
  if (id == 0) {
    next <: 1;
  }
  while (1) {
    prev :> void;
    led <: 1;
    delay_milliseconds(100);
    led <: 0;
    next <: 1;
  }
}

int main() {
  chan c[NUM_CHIPS];
  par {
    par (int i = 0; i < NUM_CHIPS; i += STEP) {
      on stdcore[i] : flash_led(i, c[i], c[(i + 1) % NUM_CHIPS], leds[i / STEP]);
    }
  }
  return 0;
}

As an intern at XMOS in 2009, I did some work to investigate the performance of the XMP-64. This is written up in the document linked below. It looks at the performance of barrier synchronisations and exchanges of various permutations of source-destination pairs. Sadly though, to my knowledge, the XMP-64 didn’t see much further use or experimental application development. However, a similar board was developed by the Swallow project, which used XS1 chips (12 cores per board) and allowed direct expansion of the network with multiple boards up to 480 cores. See the research paper (ArXiv) for more details.

Scalable abstractions for general-purpose parallel computation

2014-10-01T00:00:00+02:00

This is my Ph.D. thesis that I completed at the University of Bristol in March 2014. I was supervised by David May and Simon Hollis. I have licensed this work under the Creative Commons BY-NC-ND 4.0 license, so that it can be shared but not modified. I was awarded an Engineering Faculty commendation for the work.

Abstract

Parallelism has become the principal means of sustaining growth in computational performance but there has been relatively little development in general-purpose computer architectures or programming models that can deal effectively with large amounts of it. A new general-purpose model of parallel computing would enable standardisation between architectures, high-volume production and software that is portable between different machines, now and as they develop with future technology. There is substantial opportunity to support this in emerging areas of embedded computing, where the problems of sensing, interaction and decision making can exploit large amounts of parallelism.

This thesis demonstrates the essential aspects of a scalable general-purpose model of parallel computation by proposing a Universal Parallel Architecture (UPA), based on a highly-connected communication network, and a high-level parallel programming language for it called sire that can be compiled using simple techniques. The design of sire combines the essential capabilities of shared-memory programming with the benefits of message passing to support a range of programming paradigms and to provide powerful capabilities for abstraction to build and compose subroutines and data structures in a distributed context. The design also enables program code to be distributed at run time to reuse memory and for processor allocation to be dealt with during compilation so that the overheads of using distributed parallelism are minimal.

To evaluate whether the UPA is practical to build, a high-level implementation model using current technologies is described. It demonstrates that the cost of generality is relatively small; for a system with 4,096 processors, an overall investment of around 25% of the system is required for the communication network. Executing on specific UPA implementations, sire’s primitives for parallelism, communication and abstraction incur minimal overheads, demonstrating its close correspondence to the UPA and its scalability. Furthermore, as well as executing highly-parallel programs, the UPA can support sequential programming techniques by emulating large memories, allowing general sequential programs to be executed with a factor of 2 to 3 overhead when compared to contemporary sequential machines.

Published as

James W. Hanlon, Scalable abstractions for general-purpose parallel computation. Ph.D. thesis, Department of Computer Science, University of Bristol, March 2014.

Download

PDF
Print PDF (no hyperlink colours)

James W. Hanlon

Personal data and self hosting

Synology Diskstation

Linux host

Access

Other services

Summary

Related links

Discrete-event simulation

Operation

Example implementation

Summary

References / further reading

Review of heat pump use and performance

System operation

The myViallant app

Analysis

Summary

References and further reading

Silicon infrastructure

Table of contents

Aims

Guiding principles

Flows

Model

Implementation details

Summary

Acknowledgments

Related projects

Building a Python processor

Table of contents

Dynamic languages

Python and AI

Python performance

Hardware impacts on Python performance

Hardware support for Python

System architecture

Core architecture

Memory system

Scaling the number of cores

Summary

Acknowledgements

References

Related links

Cornish Unit House retrofit insulation

Bedroom 1

Bedroom 2

Bedroom 3

Hallway

Performance

Summary

Related links

From logic gates to a programming language using the Hex architecture

Table of contents

The Hex architecture

Prefixing

Inter-register operations

Load-store operations

Branching

Address generation

The X language

Hex processor integrated circuit

Hex tooling

A simple example

Hello World

Building an X compiler and bootstrapping

Implementation details

A historical note

Summary

Similar projects

Further reading

Seeding parallel xoroshiro128+ generators

Conclusion

References

The hardware pseudorandom number generator of the Graphcore IPU

Summary

Garden workshop

Groundworks

Base

Structure