1---2name: digital-timing-diagram3description: Use when a diagram must show digital signals changing over time, including clocked interfaces, bus transactions, handshakes, setup/hold relationships, or waveform protocols.4---56# Digital timing diagram78## What it is910A digital timing diagram is a time-aligned view of signals and events. It tells the reader which edges, levels, delays, and sampling relationships are required—not merely which components are connected.1112## Choose it when1314- correctness depends on clock edges, signal levels, latency, pulse width, or ordering in time;15- the reader needs to compare a producer, consumer, clock, enable, reset, or bus on a shared time axis;16- a protocol's “what happens when” is about electrical/logical timing rather than software call order.1718Use a sequence diagram for causal messages between participants. Use a protocol-layout diagram for field positions in a packet. Use an electrical schematic for connectivity and symbols.1920## Story and modeling21221. Define the time direction, scale or “not to scale” status, voltage/logic convention, and active edge.232. Put the reference clock and reset first. Align every signal to explicit edges or intervals.243. Label meaningful transitions: setup window, hold window, valid/ready, request/acknowledge, turnaround, wait state, and sampled value.254. Show unknown, high-impedance, don't-care, and invalid states distinctly; never silently draw them as stable 0 or 1.265. State assumptions such as synchronous domain, propagation delay, bus ownership, and whether the waveform is normative or an example trace.2728## Styling and customization2930Use a consistent signal baseline and equal vertical spacing. Use a single accent for the active transaction, neutral clock/grid lines, and explicit hatch or text for unknown/high-impedance states. Annotate intervals with brackets and values, not only color. Keep the time axis readable at the intended output size and split long traces into named phases rather than shrinking everything.3132## Renderer routing3334- `wavedrom` is the direct diagram.zip fit for clocked waveforms, signal lanes, phase labels, and bus values.35- `vega` can produce bespoke plotted traces when quantitative time data or custom scales matter, but it needs more explicit grammar and does not itself confer electrical meaning.36- `tikz` or `pikchr` can handle a custom timing notation when WaveDrom's primitives are insufficient.37- `plantuml`, `mermaid`, and `seqdiag` show ordered interactions but do not encode waveform-level setup/hold semantics; use them only if that abstraction is intentional.3839Preserve the user's renderer choice. If no renderer is requested, prefer `wavedrom` and state any assumptions. diagram.zip does not currently validate timing constraints against an HDL interface standard or simulate a waveform; an integration that imports interface timing tables or checks setup/hold annotations would be valuable. IEEE 1800/SystemVerilog assertions and vendor timing formats remain unsupported as normative inputs unless separately integrated.4041## Review checklist4243- Is the time axis and scale status clear?44- Are clock edge, polarity, reset, and sampling point explicit?45- Are setup/hold, latency, pulse width, and turnaround intervals labeled where relevant?46- Are X/Z/don't-care states distinguishable from 0/1?47- Does every transition support the stated protocol story?48- Is this a normative timing requirement or one illustrative trace?4950## References5152- [WaveDrom documentation](https://wavedrom.com/) describes the waveform source model supported by diagram.zip.53- [IEEE 1800-2023](https://standards.ieee.org/ieee/1800/10458/) is the SystemVerilog language standard, including assertions and timing-oriented design constructs; diagram.zip does not parse it as a timing-diagram source.54- [JEDEC JESD79-5C](https://www.jedec.org/standards-documents/docs/jesd79-5c) is an example of a memory-interface specification where timing diagrams accompany normative setup/hold requirements.