Glossary & migration

The first section defines the core terms used throughout the manual. The second collects the naming changes from older C⏚ material so you can read pre-v2 sources without confusion.

Glossary

task

An atomic sequential entity with private state, ports, and behaviour. A task may declare setup() (runs once after reset) and loop() (runs once per cycle, repeatedly). Tasks cannot instantiate other entities; they are the leaves of a C⏚ design. See Tasks.

network

A hierarchical entity that instantiates other entities and wires their ports together. A network has no behaviour of its own - no setup, no loop, no state. Networks compose tasks (and other networks) into the design's structural hierarchy. See Networks.

bundle

A stateless entity that holds shared types, constants, and pure helper functions. Bundles have no ports, no state, and no setup or loop. Every function declared in a bundle is implicitly const. See Bundles.

port

A typed connection point on a task or network through which it communicates with the outside. A port has a direction (in or out), a type, and an optional synchronization qualifier. Ports are the only way tasks share information - state variables are strictly private.

bare port

A port with no synchronization qualifier. Bare ports behave like combinational wires: a write is visible to consumers in the same cycle, with no valid flag and no handshake. Use them for combinational outputs and persistent status signals.

push port

A port with push qualifier. The producer asserts valid for exactly one cycle when it writes; the consumer must consume on that cycle or the data is dropped. read() on a push port blocks until valid data arrives. Models a registered output in hardware.

stream port

A port with stream qualifier. Push plus a ready/valid handshake: the consumer can stall the producer by withholding ready. Use streams for FIFO-backed pipelines or anywhere back-pressure matters (e.g. Ethernet inter-frame gaps).

confirm port

A port with confirm qualifier. Push plus an explicit acknowledgement from consumer to producer, but no back-pressure. The producer is not held back if the consumer fails to acknowledge. Use confirm when receipt must be witnessed but the producer cannot afford to stall.

monitor

A task inside a test network that observes the design under test, asserts expected behaviour, and signals when the simulation should end. The canonical monitor has a bool finished state variable and a properties { test: { terminate: "monitor.finished" } } on the enclosing network. See Bytecode simulator.

test network

A network whose purpose is simulation rather than synthesis. It typically instantiates one or more designs under test (DUTs) plus a monitor. Test networks usually carry a test property with either cycle-by-cycle stimulus arrays or a terminate expression.

DUT

Design Under Test. The instance(s) inside a test network whose behaviour is being verified.

IR

Intermediate Representation. The backend-agnostic form the C⏚ compiler emits between source parsing and code generation. Stored as XMI files (typically under .ir/) and consumed by both the bytecode emitter and the HDL generators.

VCD

Value Change Dump. A standard textual waveform format produced by the bytecode simulator and by HDL simulators. Open VCDs in GTKWave, Surfer, or the WaveTrace VS Code extension.

cycle break

A point in a task's body where the current cycle ends and the next begins. Cycle breaks can be explicit (fence, idle(n)) or implicit (reading or writing the same port twice, or each iteration of a sequential loop). See Tasks.

fence

A statement that ends the current cycle. The task resumes execution on the next cycle.

idle

A statement that ends the current cycle and stays idle for n cycles. n is a compile-time constant.

Migration from v1

Synchronization qualifiers

C⏚ v2.0 renamed the three synchronization keywords. The semantics are identical; only the names changed.

When reading pre-v2 examples, mentally substitute the v2 keyword before reasoning about the rest of the code.

Tool naming

The compiler, the IDE, and the documentation rebranded from Synflow Cx to Neosyn C⏚ in 2024. Older material may refer to:

Style and verification conventions

The current documentation prefers:

• Test networks with explicit monitors and a terminate expression rather than cycle-counted stimulus alone.
• Package-qualified examples (package com.example;) over unqualified ones.
• Cross-checking the bytecode trace against an HDL simulator. See Cross-check against HDL.

Older Synflow Cx examples often omit some of that structure for brevity. Modernize them by adding the package declaration, the monitor, and the termination property.

Related pages

• Declarations - full port-qualifier reference.
• Bytecode simulator - monitor and test patterns.
• Project layout - package and folder conventions.