diff options
| -rw-r--r-- | electrical-specifications.typ | 2 | ||||
| -rw-r--r-- | introduction.typ | 12 | ||||
| -rw-r--r-- | mechanical-specifications.typ | 4 | ||||
| -rw-r--r-- | module-design.typ | 30 |
4 files changed, 24 insertions, 24 deletions
diff --git a/electrical-specifications.typ b/electrical-specifications.typ index caf5c6f..fcc6f7c 100644 --- a/electrical-specifications.typ +++ b/electrical-specifications.typ @@ -325,7 +325,7 @@ are met. ) <table-precision-measurements-conditions-summary> Note that electrical supply requirements will be discussed in -#ref(<power-distribution>). +@power-distribution. === Educational tier <educational-tier> diff --git a/introduction.typ b/introduction.typ index 6948ee9..fd02b0f 100644 --- a/introduction.typ +++ b/introduction.typ @@ -224,13 +224,13 @@ Metrologic aiming at $qty(10, "ppm")$. === Reader's guide <readers-guide> We recommend a reader not familiar with the field to first read this -specification sequentially. #ref(<electrical-specifications>) and -#ref(<mechanical-specifications>) will develop the core specifications of the -SAME ecosystem. #ref(<module-design>) will specify the module design principles -that allows it to achieve its precision goals. #ref(<compliance-verification>) +specification sequentially. @electrical-specifications and +@mechanical-specifications will develop the core specifications of the +SAME ecosystem. @module-design will specify the module design principles +that allows it to achieve its precision goals. @compliance-verification will explain how to verify conformity of a SAME product with this specification. -#ref(<reference-implementation>) will present a reference implementation of the -system. Finally, #ref(<theory-of-operation>) and #ref(<applications>) will show +@reference-implementation will present a reference implementation of the +system. Finally, @theory-of-operation and @applications will show how and when to use a SAME Analog Computer. == Document conventions <document-conventions> diff --git a/mechanical-specifications.typ b/mechanical-specifications.typ index aceb4d1..cabf8a8 100644 --- a/mechanical-specifications.typ +++ b/mechanical-specifications.typ @@ -900,7 +900,7 @@ modules. It includes: This specification defines interface requirements that any compliant chassis must meet. Chassis may vary in capacity (number of module positions), form factor (rack-mount, desktop, portable), and mounting style. The reference -implementation (#ref(<reference-implementation-chassis>)) describes a +implementation (@reference-implementation-chassis) describes a $qty(19, "inch")$ $qty(4, "U")$ rack-mount chassis with $8$ module positions. === Dimensional requirements <chassis-dimensional-requirements> @@ -1192,7 +1192,7 @@ outputs. [AGND jack], [4mm banana, black], [Analog ground reference], [Dual $qty(10, "MHz")$ sine oscillator output jacks $plus.minus qty(1, "V")$], [4mm banana, light blue], - [Master oscillator output (independent paths, to allow verification - see #ref(<the-time-invariant>))], + [Master oscillator output (independent paths, to allow verification - see @the-time-invariant)], [$qty(10, "MHz")$ sine oscillator input jack], [4mm banana, white], [Master oscillator input], diff --git a/module-design.typ b/module-design.typ index bdcff31..cc4ae9d 100644 --- a/module-design.typ +++ b/module-design.typ @@ -42,33 +42,33 @@ component choices that will remain available as specific part numbers inevitably become obsolete. This section proceeds in six parts. -+ #ref(<module-design-terminology>) establishes terminology. Precision analog ++ @module-design-terminology establishes terminology. Precision analog design has a specialized vocabulary; ambiguous terms lead to ambiguous analysis. We define our terms once, carefully, and use them consistently throughout. -+ #ref(<module-design-modules-categories>) categorizes the three types of SAME ++ @module-design-modules-categories categorizes the three types of SAME modules — Interface, Compute, and Control — and specifies the requirements particular to each category. Not all modules face identical constraints; a control module generating voltages from a front-panel knob operates under different rules than a compute module performing four-quadrant multiplication. -+ #ref(<error-budgeting-and-system-level-compensation>) develops the error ++ @error-budgeting-and-system-level-compensation develops the error budget framework. We enumerate every source of error in a precision analog signal path, quantify each source using commodity component specifications, and construct the naive error budget that results from conventional design. This budget exceeds our specifications by factors ranging from $11$ to $4000$. The purpose of this exercise is not despair but clarity: we must know precisely where the errors arise before we can systematically eliminate them. -+ #ref(<error-compensation-strategies>) presents the five fundamental ++ @error-compensation-strategies presents the five fundamental compensation strategies that close the gap between naive and Metrologic performance. Each strategy is developed from physical principles, analyzed mathematically, and specified with design rules sufficient to implement it correctly. -+ #ref(<advanced-compensation-topologies>) extends these techniques for ++ @advanced-compensation-topologies extends these techniques for applications demanding performance beyond the base Metrologic specification. They can push precision into the 1-5ppm range for specialized applications. These techniques are optional — the base compensation strategies suffice for Metrologic tier — but they demonstrate that the approach has headroom. -+ #ref(<implicit-computation>) introduces implicit computation, a ++ @implicit-computation introduces implicit computation, a design philosophy where mathematical operations emerge from feedback equilibrium rather than explicit signal processing. Division, for example, can be implemented explicitly using logarithms (with their associated @@ -79,7 +79,7 @@ This section proceeds in six parts. chain. The reader seeking to understand how the reference implementation in -#ref(<reference-implementation>) achieves its specifications, or to design new +@reference-implementation achieves its specifications, or to design new modules, will find the theoretical foundation here. We make no apology for the depth of what follows. Precision is not achieved by accident or by following recipes without understanding. It is achieved by understanding the physics @@ -88,7 +88,7 @@ deeply enough to make the physics work for you rather than against you. == Terminology <module-design-terminology> This section defines the specialized terminology used throughout -#ref(<module-design>). These definitions establish a consistent vocabulary for +@module-design. These definitions establish a consistent vocabulary for discussing precision analog circuit design within the SAME ecosystem. Terms are organized into logical categories for ease of reference. Terms defined here may have already appeared in earlier sections but are formally defined here for the @@ -97,7 +97,7 @@ Module Design context. === Mathematical symbols <mathematical-symbols> This section defines the mathematical symbols and notational conventions used -throughout #ref(<module-design>). Symbols are organized by category: fundamental +throughout @module-design. Symbols are organized by category: fundamental constants, electrical quantities, circuit parameters, error quantities, and operators. @@ -675,7 +675,7 @@ its role in maintaining system precision and usability. All SAME modules share a common mechanical format: the single-width cassette of $qty(38.0, "mm")$ ($qty(1.5, "inch")$) as specified in -#ref(<shielding-and-construction>) Dual-width or multi-width modules +@shielding-and-construction Dual-width or multi-width modules are not permitted. This constraint ensures uniform thermal behavior across the system, predictable rack utilization, and simplified inventory management. If a function cannot be implemented within the single-width format, the design must @@ -725,11 +725,11 @@ signal path. The module must ensure: Digital supply noise must be attenuated to below the system noise floor ($qty(632, "uV") upright("RMS")$ for $qty(90, "dB") upright("SNR")$). + No RF emissions escape the cassette. The module must meet the EMI shielding -requirements specified in #ref(<cassette-grounding-requirements>), with +requirements specified in @cassette-grounding-requirements, with particular attention to the higher-frequency harmonics generated by digital clocks. + Digital ground (DGND) and analog ground (AGND) remain strictly separated per -#ref(<analog-supply-requirements>), with any necessary coupling occurring only +@analog-supply-requirements, with any necessary coupling occurring only at a single, well-defined point within the module. An interface module containing digital logic that fails to meet these isolation @@ -743,7 +743,7 @@ Interface modules necessarily deviate from the standard SAME I/O format on their external-facing side. The external connector type is determined by the format being interfaced (BNC, XLR, DB-25, optical, etc.). However, the SAME-facing side of an interface module must use standard 4mm banana jacks conforming to -#ref(<signal-standards>). +@signal-standards. Interface modules must provide clear panel markings indicating which jacks connect to the SAME domain and which connect to the external format. Color @@ -808,7 +808,7 @@ Two categories of errors must be distinguished: domain of the implemented function. Examples include negative inputs to a square root function, zero divisors, or inputs exceeding the valid range for a logarithm. The module must implement one of the handling strategies defined in -#ref(<out-of-domain-handling-strategies>) and document which strategy is used. +@out-of-domain-handling-strategies and document which strategy is used. + Internal errors occur when the module's circuitry cannot maintain its precision specification despite valid inputs. Examples include servo unlock conditions, soft saturation in PWAM modulators, or clipping due to internal @@ -900,7 +900,7 @@ the interconnection requirements. ==== Input/output requirements <control-modules-input-output-requirements> Control modules use $qty(4, "mm")$ banana jacks for their outputs, conforming to -#ref(<signal-standards>). Since control modules generate rather than process +@signal-standards. Since control modules generate rather than process signals, they typically have few or no signal inputs. Control modules may incorporate indicator elements (LEDs, meters, numeric |