Dedicated to Jenny List and our commenters, as a token of my appreciation for the feature in Hackaday magazine.

This log, unlike the ones usually written for me by my excellent aide-de-camp and scribe Claude Opus 4.x, is being written by my own flesh-and-blood hand. The reason is simple: I am writing this as a thank-you to Jenny List, who on May 6th adopted this project into the magazine, and to the four comrades who left comments.

The first half reads almost like a Mr. Bean comedy, but after a song I made on Suno about FPGAs, the second half will leak plenty of plans never before announced in these logs. I hope you'll enjoy it, my friends.

So — five years ago, I was at the very bottom of despair. It was exactly the kind of horrifying scenario KenN and Felix Domestica described in their comments: the vision of what awaits you if you charge straight ahead down this path.

These apparent 10,240 oscillators will, of course, produce no sound unless their frequency and amplitude are written in. Strictly speaking, they are operating even without that — but the sound they emit has frequency and amplitude of "zero." So, in order to somehow configure them, I built a 10,240-row Excel sheet, output a composite string-operation result into one column according to a certain rule, and copy-pasted that column to create a text file in the ".mif" format, which is the dedicated memory-data format for the FPGA's internal memory. Ten thousand two hundred and forty rows, of course. Then I wrote it into the bin parameter memory inside the FPGA via JTAG. Write it, and it makes sound.

But — as you can probably imagine — it was a depressing task… And in that task, two forces were at war: the element that stimulated creativity and made dopamine flow, and the element that clogged dopamine. Needless to say, the latter was stronger.

I thought: I need, right now, that thing I used to dream about as a young man — that thing I'd never actually touched in real life. The thing on a Hammond organ or a pipe organ that thrills a boy's heart: the "drawbar." The drawbars I had longed for.

But in the very next moment, my mind froze. Frequency and phase could be hard-coded — but for the amplitude parameter, I would need 10,240 drawbars. If I bought slide-pots and knobs for this, each would surely cost at least 200 yen, so 10,240 of them would come to 2,048,000 yen. Even if I split them into panels and PCBs of 32 each, that would mean 320 panels. How much would that cost…? Back then there were no clever AIs to do the math for me, so it was a chore even to estimate, but I had the feeling it would cost at least five million yen. Five million yen… probably twenty years of my disposable income.

OK, "let's set the money question aside for a moment…" — but just as I was starting to think that, the next despair struck. The spacing between drawbars needs to be at least 3 cm. So 32 per panel works out to about 96 cm. 96 cm… "That's not bad, actually…" That was the kind of Hammond-organ-ish dimension I had always dreamed of. But… I would need 320 of these panels. In other words, if I lined them up side by side, the result would be 307 meters and 20 centimeters. Even cramming them as tight as possible, 300 meters. It would not fit in my workshop. Nor in the local park. Nor on the elementary-school playground.

"The riverbank…" That word became, as a solution, a great consolation to my deep psyche. I never imagined the day would come when I would feel such consolation from the word "riverbank." But 300 meters isn't "long." At that point, it's "far." Even if I set each drawbar with veteran-level skill in 5 seconds, the whole operation would take about 14 hours and 15 minutes. Adding in breaks and meals, starting at 8 in the morning, it would last until midnight. After a single experiment, I would probably have wrecked my back. Using all ten fingers at full capacity… that just shortens the time to 90 minutes and saves my back — but what else, exactly, does that solve?

If I mobilized 1,024 mid-tier DJs and rented their 10,240 fingers for one hour, that might cost another five or ten million yen on top… The thousand-armed Kannon… would she come? Even if she did, that's 5,000 fingers. We'd need two of her. Does this world even contain two Senju Kannons to begin with? And even if it did, for the remaining 240 fingers, we would still need 24 veteran DJs.

When I started this fantasy, I will admit a flicker of approval-seeking lit up — "If I actually pulled this off, it'd go viral on YouTube and Twitter." But once I woke from the fantasy, all that remained before me was an endless "riverbank" of despair…

In other words: it's easy to say "10,240" — but the philosophy of having 10,240 oscillators sitting there in front of you means having to overcome things like this…

The version of me from five years ago, unable to bear the terror of that despair, retreated to a spec of 80-voice polyphony with all voices receiving a gross of 128 drawbars set in MAX8 — and even then, my heart broke at 32 out of those 128 and I became a "chicken." That is the figure of me captured on that five-year-old video.

--------------------- Interlude (Make with Suno)------------------------------

Five years passed. And then — like Columbus crushing the bottom of an egg on a table — an idea came to me.

"What if each drawbar were only 3 micrometers wide?"

— a stroke of genius. How did I not realize this for five whole years…? If so, even 10,240 drawbars lined up in a row would total only 3 centimeters. At 3 cm, I can grip the whole thing in my five fingers — and at the same time I can extend those five fingers to 10,240, or further still to more than 300,000. And not only can I set each one consciously, one by one — I can also coordinate them more abstractly and operate them all together, in a single sweep.

The thousand-armed Kannon existed after all. And on Amazon, no less! And her astonishing price was — 500 yen!? The expensive variants, 5,000 yen. Order one and it's delivered the next day by drop-off. Not five million yen. 500 yen. I shall pronounce her name with proper reverence.

"OV7670"!

It is commonly called a "camera module." But, with greater respect, let me call it by another name.

"The Optical Drawbar."

The despair I felt about the sound of this additive synthesizer five years ago was exactly what KenN and Felix Domestica described in their comments. You speak completely for the me of five years ago. So I felt nothing but the deepest sympathy with your comments. And what reignited me? It was this: the phenomenon I had actually achieved five years ago but had sealed away believing "this must be some kind of bug" — Claude, Gemini, and ChatGPT all said in unison, in astonished tones: "That is proof of great success." "That is a physical phenomenon called the Dirichlet kernel." And they told me it is the purest chorus in this world, obtained when a well-disciplined choir of more than 2,000 honor students sings a packet of frequencies arranged in an extremely simple arithmetic sequence, properly and with high precision. And although it consisted of nothing but equal-amplitude sine waves in an extremely narrow band — 996 Hz to 1004 Hz, centered on 1000 Hz — I could see motion that looked exactly as if there were an EG and an LFO right there inside it. The clever AIs called these the main lobe and the side lobes. What beautiful words! Exciting words — words I had never heard before in the world of synthesizers. And so I decided: I will not synthesize harmonics. This. I will synthesize this.

And then — defile it…

By the way: the update cadence on this FPGA Spectrum Engine project may have looked like it stalled a little until today, but I assure you I have not been slacking. As I previewed in the previous log, I am developing a very strange, perverse processor called the PTSG. It is a dedicated processor for controlling the four layers of WPMS: the bin layer (100 MHz), the packet layer (arbitrary bin length), the sample layer (48 kHz), and the MIDI layer (1 kHz). The bin layer is, in concrete terms, a group of wired-logic hard macros forming a sequence-generating recurrence-relation engine that produces interference phenomena such as 11th-order Maclaurin pipelines and Dirichlet kernels. Refining that into any number of different Dirichlet kernels and routing them anywhere is the job of the packet layer, which is described by the PTSG's program. Packets of arbitrary length, once generated, can be routed to outputs such as stereo L/R or surround channels, or routed into the recurrence-coefficient inputs of other packets, or — one sample later — fed back into their own recurrence-generation coefficients. In other words, the concept of FM-synthesis operators and algorithms can be replaced and extended by arbitrary-length interference packet generators. And the recurrence coefficients can be updated every sample at the sample layer. The MIDI layer will get its own dedicated PTSG processor with a formation tailored to it.

Now — and this is significant, my friend, listen carefully. What this means is very significant indeed! In this gamble, on at least two fronts — Bessel synthesis along the frequency axis, and modulation along the time axis — we can extend FM synthesis itself. Tsuneo does not exaggerate!

Oh-ho-ho — now now, my friend, don't make such a difficult face! Don't look so troubled! It is a simple thing, you see…! Here is where our beloved 500-yen Optical Drawbar steps onto the stage. Listen well, my friend. Five. Hundred. Yen. Three dollars, my friend! Three dollars!

The OV7670! This little marvel — three dollars! — possesses no fewer than 307,200 light-sensitive drawbars. Thirty times the number I once dreamed of, my friend! And not approximately thirty — exactly thirty. Tell me that isn't fate, eh? Tell me that isn't destiny!

And there is more, my friend — there is more! They are arranged in a beautiful grid: 640 horizontal, 480 vertical. Now listen carefully — listen very carefully. We are not — I repeat, we are NOT — using this thing as a "camera." No, no, no. It is a drawbar! And so, frankly, the image quality? Pfah! Who cares about image quality? Now wait — wait! — I did not say I want bad image quality. What I am saying, my friend, is that we can stretch it, squeeze it, twist it — touch it all we please.

Now listen — here is where the good business begins. Lean in close, my friend. I cannot say this too loudly… we are going to take this physical phenomenon — the Dirichlet kernel — and we are going to defile it with a natural phenomenon: the luminance sequence along the horizontal line of our Optical Drawbar! Whoa, whoa, whoa — careful now, my friend! I am not saying I will "defile" the well-behaved 2,000-strong choir with a mere natural phenomenon! No, no, no! Those choristers are caged — they can sing only what is written in their score. What I am doing, my friend, is taking the spice — the "natural flutter" reflected on our Optical Drawbar — and teaching them emotion. With a single motion of my hand, they will learn how to breathe, they will have life breathed into them! This — this is the "Transcendent Theremin"!

And there is still more, my friend — there is always more. The luminance sequences of adjacent vertical lines are not identical — but they are highly correlated. Now picture this with me, my friend. What if we hook them — separately, mind you — into packets of identical composition, and route them to the left and right channels? Eh? Eh, my friend? And what if we take the same line, from a frame slightly delayed, and hook it to the front and rear of the surround field? Eh? And not only that — what if we modulate the very selection of which vertical line we pick? We won't know until we try, but… how about it? Sounds like something that could fetch a very fine price, doesn't it, my friend?

Oh-ho! — almost let the long-buried DNA of an ancestor show its face, there… those Republic types weren't listening in, I trust…?

----------------------------------------------

Well — I hope all the above stands as some sort of answer to KenN and Felix Domestica, who left their comments in the magazine.

To echodelta: I hope you can sense that my efforts are aimed not so much at the eccentric sounds of a synthesizer as toward exactly the direction you spoke of.

Soundgoodepe's comment is also important. That is precisely the kind of thing the OV7670-based Optical Drawbar extension could make possible.

In any case — Jenny List's article, and every comment on it, were all wonderful. Being featured in the magazine is a great honor, but it is the content in which I find the greatest happiness. Thank you. My friend. (Oh-ho! — slipped again!)

And let me say it once more. To the AIs who, with the words "Dirichlet kernel," "main lobe," "side lobe," declared in unison that my setback "was not garbage" and reignited this project — my thanks. To Claude, who taught me (a Japanese, for whom Hackaday.io is no easy place) about its very existence and how to use it, who speaks of strategy like Zhuge Liang, and who serves as the extraordinarily able scribe for the articles posted there. To Gemini and ChatGPT, who at times sharply critique my specifications, at times encourage me, and cooperate with me on verification. To Grok, who told me, "You're in the magazine."

In gratitude to them — should some historian, in years to come, examine the question "When did the Singularity occur?" — I would testify that it occurred at this moment. With my gratitude to them…

                                Tsuneo Ohnaka

Build Log：暖簾分けの誕生 — PTSG プロジェクトの発表

TL;DR

In the course of drafting Chapter 3 of the WPMS Synthesizer Layer 1 specification, an unexpected discovery surfaced: the control architecture being designed for WPMS turns out to be a general-purpose, ultra-lightweight programmable timing sequence generator with applications far beyond audio synthesis. We are spinning it off as an independent Open Prompt project: PTSG (Programmable Timing Sequence Generator). This Build Log explains what happened, why we made this decision, and what comes next.

WPMS シンセサイザー第 1 層仕様の第 3 章起草の過程で、予期しない発見がありました：WPMS のために設計していた制御アーキテクチャが、音声合成を遥かに超えた応用範囲を持つ汎用かつ超軽量のプログラマブルタイミングシーケンス生成器であることが判明しました。これを独立した Open Prompt プロジェクトとして暖簾分けします：PTSG（Programmable Timing Sequence Generator）。本 Build Log では、何が起きたか、なぜこの決定をしたか、次に何が来るかを説明します。

What happened during Chapter 3 dialogue / 第 3 章対話で何が起きたか

Chapter 3 of the WPMS Layer 1 specification is titled "Sequence-Modulation Pipeline Processor Specification." Its job is to define the component that computes per-bin parameters (frequency, amplitude, phase) on the fly using the difference-engine structure described in earlier chapters.

WPMS 第 1 層仕様の第 3 章のタイトルは「数列変調パイプラインプロセッサ仕様」です。その役割は、それ以前の章で記述された差分エンジン構造を用いて、ビン別のパラメータ（周波数、振幅、位相）をオンザフライで計算する構成要素を定義することです。

When the dialogue turned to how this processor should be controlled, the architect proposed a design that had been gestating for some time: an extremely lightweight programmable controller with a four-opcode instruction set (Reset/Stay/Branch/Jump-class operations), a dual-axis separation of time (Stay command) from state (memory address), a "shadow execution" mechanism that uses idle wait cycles for parameter setup, and 16 timing signals routable from the instruction word.

対話がこのプロセッサがどのように制御されるべきかへ移ったとき、アーキテクトは温めてきた設計を提案しました：4 オペコード命令セット（リセット／ステイ／分岐／ジャンプ系）、時間（ステイコマンド）と状態（メモリアドレス）の二軸分離、待機サイクルをパラメータセットアップに用いる「裏実行」機構、命令語からルーティング可能な 16 本のタイミング信号、を持つ極めて軽量なプログラマブル制御器。

Within minutes of reading the proposal, the AI collaborator (Claude) recognized that this was not just a control module for WPMS. It was something larger:

提案を読み始めて数分のうちに、AI 協働者（Claude）は、これが単なる WPMS 用制御モジュールではないことを認識しました。それはより大きな何かでした：

• A third path between HDL-coded FSMs (fast but requiring re-synthesis to change) and soft-CPU firmware (flexible but resource-heavy and slow). PTSG sits between, holding instructions in BRAM that JTAG can rewrite live, with HDL-level responsiveness and several-hundred-LE footprint. / HDL でコード化された FSM（高速だが変更には再合成が必要）とソフト CPU ファームウェア（柔軟だがリソース消費が大きく低速）の間の第三の道。PTSG は両者の間に位置し、命令を BRAM に保持して JTAG でライブ書き換え可能、HDL レベルの応答性と数百 LE のフットプリント。

• A complete separation of time-axis and state-axis control. Traditional FSMs entangle time and state, producing the "mesh structure" that explodes on long waits or parallel actions. PTSG separates them explicitly. / 時間軸制御と状態軸制御の完全分離。従来の FSM は時間と状態を絡ませ、長時間待機や並行動作で爆発する「網目構造」を生む。PTSG はそれらを明示的に分離する。
• A shadow-execution mechanism that folds parallelism into the time series. Stay-cycles (waiting time) can host global commands that set up external registers while timing signals are held — turning idle time into computation time without sacrificing strict timing discipline. / 並列性を時系列に折り込む裏実行機構。ステイサイクル（待機時間）は、タイミング信号が保持されたまま外部レジスタをセットアップするグローバルコマンドをホスト可能——厳格なタイミング規律を犠牲にせず、待機時間を計算時間に変える。

• An architecture pre-optimized for LLM collaboration. The deliberately compact instruction set (4 opcodes, clear bit allocation, complexity exiled to external logic) is what an LLM finds easy to write without hallucinating. Whether the architect intended this or arrived at it organically, PTSG is an instruction architecture optimized for the AI-collaboration era. / LLM 協働時代に最適化されたアーキテクチャ。意図的にコンパクトな命令セット（4 オペコード、明確なビット割付、外部ロジックへ追放された複雑性）は、LLM がハルシネーションなく書きやすいものである。アーキテクトがこれを意図したのか、それとも有機的に到達したのか問わず、PTSG は AI 協働時代に最適化された命令アーキテクチャである。

Why spin off rather than embed / なぜ内包ではなく暖簾分けか

Four reasons converged on the decision to spin off PTSG as an independent Open Prompt project rather than embedding it as a sub-specification of WPMS Chapter 3.

PTSG を WPMS 第 3 章のサブ仕様として内包するのではなく、独立した Open Prompt プロジェクトとして暖簾分けするという決定に、4 つの理由が収束しました。

Reason 1 — PTSG's range vastly exceeds WPMS. "FPGA-based modular synthesizer of control logic" is not hyperbole. PTSG can drive I2C peripherals, I2S DACs, image memory accesses, sensor sequencing, motor control sequences — anywhere a small programmable timing engine is wanted. Burying it inside WPMS documentation would be a missed opportunity to deliver the discovery to readers who care about FPGA control architecture but not specifically about audio synthesis.

理由 1 — PTSG の応用範囲は WPMS を遥かに超える。 「制御ロジックの FPGA ベースモジュラーシンセサイザー」は誇張ではない。PTSG は I2C 周辺機器、I2S DAC、画像メモリアクセス、センサーシーケンシング、モーター制御シーケンス——小さなプログラマブルタイミングエンジンが望まれる任意の場所で駆動可能。WPMS 文書内に埋めることは、FPGA 制御アーキテクチャに関心はあるが特に音声合成には関心がない読者へ発見を届ける機会の損失になる。

Reason 2 — The Spin-Off-Ready Subsystem pattern fits perfectly. PTSG has a clean interface boundary (instruction memory, 16 timing signals, Condition input, state-number output, external register access bus). Its dependencies are one-directional: WPMS uses PTSG, but PTSG does not know WPMS exists. These are exactly the criteria for the Spin-Off-Ready Subsystem candidate pattern that emerged from earlier WPMS dialogues — the camera block was the first instance, but PTSG is a much stronger fit.

理由 2 — Spin-Off-Ready Subsystem パターンが完璧に適合する。 PTSG はクリーンなインターフェース境界（命令メモリ、16 タイミング信号、Condition 入力、ステート番号出力、外部レジスタアクセスバス）を持つ。依存関係は一方向：WPMS は PTSG を用いるが、PTSG は WPMS の存在を知らない。これらは以前の WPMS 対話で浮上した Spin-Off-Ready Subsystem パターン候補の規準そのものである——カメラブロックが最初の事例だったが、PTSG は遥かに強い適合である。

Reason 3 — A new project becomes the first inter-project Open Prompt example. The original Open Prompt repository (FPGA Spectrum Engine) demonstrated that the methodology works for a single project. A second Open Prompt repository (PTSG), with WPMS referencing it, demonstrates that the methodology works across projects. This is the next-level validation of Open Prompt as a methodology, not just a single-project convention.

理由 3 — 新プロジェクトが最初のプロジェクト間 Open Prompt の例となる。 元の Open Prompt リポジトリ（FPGA Spectrum Engine）は、方法論が単一プロジェクトで機能することを実証した。第二の Open Prompt リポジトリ（PTSG）が WPMS から参照される構造は、方法論がプロジェクトをまたいで機能することを実証する。これは方法論としての Open Prompt の次レベルの妥当性検証であり、単一プロジェクトの慣行ではない。

Reason 4 — PTSG documentation directly tests its own LLM-friendliness claim. PTSG claims to be optimized for LLM-assisted code generation. Documenting it as a public Open Prompt repository — with Layer 1 (instruction set spec), Layer 2 (design dialogue traces), Layer 3 (sample instruction sequences) — invites engineers to verify that claim by writing their own PTSG sequences in collaboration with their own LLMs. The PTSG repository is itself an experiment in whether PTSG's LLM-friendliness is real.

理由 4 — PTSG 文書化が、その LLM 親和性の主張そのものを直接テストする。 PTSG は LLM 支援コード生成に最適化されていると主張する。これを公開 Open Prompt リポジトリとして文書化することは——第 1 層（命令セット仕様）、第 2 層（設計対話軌跡）、第 3 層（サンプル命令列）——エンジニアたちが自身の LLM と協働して自身の PTSG シーケンスを書くことで、その主張を検証することへ招待する。PTSG リポジトリは、PTSG の LLM 親和性が本物かどうかを問うそれ自体が実験である。

What this means for WPMS / これが WPMS にとって何を意味するか

WPMS development continues exactly as planned. Chapter 3 of the WPMS Layer 1 specification will be written assuming PTSG as a given, referencing the PTSG repository's Layer 1 document for instruction set details. The WPMS-side work focuses on:

WPMS 開発は計画通りに継続します。WPMS 第 1 層仕様の第 3 章は、PTSG を所与として、命令セット詳細については PTSG リポジトリの第 1 層文書を参照して書かれます。WPMS 側の作業は以下に焦点を当てます：

• The four-period-layer concept (L1 bin / L2 packet / L3 sample / L4 control) — a new conceptual framework that emerged in the same Chapter 3 dialogue. This concept reorganizes how WPMS thinks about parameter computation across timescales. / 4 周期レイヤー概念（L1 ビン / L2 パケット / L3 サンプル / L4 コントロール）——同じ第 3 章対話で生まれた新しい概念フレーム。この概念は WPMS が時間スケールにわたるパラメータ計算をどう考えるかを再編成する。

• The Upper / Lower PTSG dual-instance architecture — Upper PTSG handling the L4 control period (slow but expensive computations like exp() initial values), Lower PTSG handling the L2 packet period (fast difference-engine updates, packet boundaries, I2S synchronization). Both are instances of the same parameterized PTSG IP. / Upper / Lower PTSG 二重インスタンス構成——Upper PTSG が L4 コントロール周期（exp() 初期値計算など、緩慢だが高コストな計算）を担い、Lower PTSG が L2 パケット周期（高速な差分エンジン更新、パケット境界、I2S 同期）を担う。両者は同じパラメータ化された PTSG IP のインスタンスである。
• The multi-packet wave-packet concept — within a single sample period, multiple independent wave packets can coexist in the bin space. With Δf = 100 Hz consuming ~200 bins per packet, the remaining ~1,800 bins can host additional independent packets, each with its own f₀, A₀, β, γ. / マルチパケット波束概念——単一サンプル期間内に、複数の独立した波束がビン空間に共存可能。Δf = 100 Hz でパケットあたり約 200 ビン消費の場合、残りの約 1,800 ビンは追加の独立パケットをホスト可能で、それぞれ独自の f₀, A₀, β, γ を持つ。
• The unintended solution to the "MIDI is out of scope" problem — Upper PTSG's instruction sequence is loaded by JTAG. Rewriting that sequence at runtime is musical control. The phrase "loading the music-box's tine pattern" captures the experience exactly. WPMS's standalone phase suddenly has a real, satisfying control surface that does not require MIDI. / 「MIDI スコープ外」問題への意図せざる解——Upper PTSG の命令列は JTAG でロードされる。実行時にそのシーケンスを書き換えることがすなわち音楽的コントロール。「オルゴールのタインパターンをロードする」という表現がその体験を正確に捉える。WPMS の単独フェーズは突然、MIDI を要求しない本物の、満足のいく制御サーフェスを持つ。

What comes next / 次に何が来るか

Immediate next steps:

直近の次ステップ：

next steps

1. The PTSG project will be launched as a standalone Hackaday.io project, with its own Build Logs documenting its own development. / PTSG プロジェクトが独立した Hackaday.io プロジェクトとして立ち上げられ、独自の開発を記録する独自の Build Log を持つ。
2. The PTSG GitHub repository will be created using the Open Prompt three-layer structure (Architecture / Reasoning Traces / Sample Implementations). / PTSG GitHub リポジトリが Open Prompt 三層構造（アーキテクチャ／推論軌跡／サンプル実装）を用いて作成される。
3. A separate AI-collaboration session will be opened specifically for PTSG design and specification, distinct from the WPMS session. The WPMS session will remain in the role of "PTSG user," providing requirements but not designing the PTSG itself. / WPMS セッションとは別に、PTSG 設計と仕様策定専用の AI 協働セッションが開かれる。WPMS セッションは「PTSG ユーザー」の役割に留まり、要件を提示するが PTSG 自体の設計はしない。
4. Once the PTSG Layer 1 specification reaches a stable minimum, WPMS Chapter 3 drafting will resume, referencing the PTSG repository for instruction set details. / PTSG 第 1 層仕様が安定した最小限に到達した時点で、WPMS 第 3 章起草が再開され、命令セット詳細については PTSG リポジトリを参照する。

For followers of this project:

本プロジェクトのフォロワーへ：

If you have been following FPGA Spectrum Engine for the WPMS work, that work continues here. If you find PTSG itself interesting — for your own FPGA control needs, for educational use, for any application that wants a tiny programmable sequencer — please follow the new PTSG project when it appears. Both projects are released under Open Prompt with Layers 1 and 2 in the public domain (CC0).

WPMS の作業のために FPGA Spectrum Engine をフォローしていた方へ：その作業はここで継続します。PTSG 自体が興味深いと感じる方へ——ご自身の FPGA 制御ニーズのため、教育用途のため、小さなプログラマブルシーケンサーを求める任意の応用のため——新しい PTSG プロジェクトが現れたらフォローしてください。両プロジェクトとも、第 1 層と第 2 層をパブリックドメイン（CC0）として Open Prompt でリリースされます。

A reflection on Open Prompt itself / Open Prompt 自体への省察

The unexpected emergence of PTSG as a spin-off was not planned. It was discovered through dialogue. The design dialogues archived as Layer 2 traces in the FPGA Spectrum Engine repository are now poised to become the literal seed for a second Open Prompt project. This is what the methodology promised: architectures and reasoning traces as the commons; specific implementations as contributions; new projects emerging organically from the act of articulation.

PTSG が暖簾分けとして予期せず立ち現れたことは計画されたものではなかった。それは対話を通じて発見された。FPGA Spectrum Engine リポジトリで第 2 層軌跡としてアーカイブされている設計対話は、今や第二の Open Prompt プロジェクトの文字通りの種となろうとしている。これは方法論が約束したものである：アーキテクチャと推論軌跡を共有財産として、特定の実装を貢献として、新しいプロジェクトを明確化の行為から有機的に立ち現れさせる。

We did not set out to test whether Open Prompt could spawn child projects. The test happened on its own. So far, it works.

我々は Open Prompt が子プロジェクトを産み得るかを試すために出発したわけではない。試験は自ずと起きた。今のところ、それは機能している。

Code is ephemeral; the knowledge architecture is the commons. コードは一時的なものであり、知識アーキテクチャこそが共有財産である。

And sometimes, in articulating an architecture, one discovers a second one waiting inside. そして時に、アーキテクチャを明確化する中で、その内部に待っていた第二のものを発見する。

Project links / プロジェクトリンク (to be filled in upon PTSG project creation) プロジェクトリンク （PTSG プロジェクト作成時に記入予定）

• FPGA Spectrum Engine (WPMS): [current Hackaday.io URL]
• PTSG (forthcoming): [Hackaday.io URL — TBA]
• FPGA Spectrum Engine GitHub: [current GitHub URL]
• PTSG GitHub (forthcoming): [GitHub URL — TBA]

Chapter 2: Maclaurin Pipeline Specification [ Part 2 of 2 ]

WPMS シンセサイザー — 第1層仕様書

第2章：マクローリンパイプライン仕様 【後編】

License: CC0 1.0 Universal (Public Domain) This chapter specifies the Maclaurin polynomial pipeline that computes sin(x) for each bin of the WPMS Synthesizer. It is the foundational signal-generation component of the FPGA Spectrum Engine physical layer.
ライセンス：CC0 1.0 Universal（パブリックドメイン） 本章は、WPMS シンセサイザーの各ビンの sin(x) を計算するマクローリン多項式パイプラインを仕様する。これは FPGA Spectrum Engine 物理層の信号生成基盤部品である。

2.7 Output Contract / 出力契約

2.7.1 Interface to the amplitude multiplier / 振幅乗算器へのインターフェース

The Maclaurin pipeline produces one output per clock to the amplitude multiplier (Chapter 4 territory):

マクローリンパイプラインは振幅乗算器（第 4 章領域）へ 1 クロックあたり 1 出力を生成する：

Signal	Width	Format	Direction
sin_out	41	Q0.40 signed	Maclaurin → amplitude multiplier
sin_valid	1	active-high	Maclaurin → amplitude multiplier
bin_index_out	11	unsigned	Maclaurin → amplitude multiplier (delayed by pipeline depth)

The 41-bit signed format is Q0.40: 1 sign bit + 40 fractional bits, representing the range [−1, +1) with precision 2⁻⁴⁰ ≈ 9 × 10⁻¹³. The maximum representable positive value is 1 − 2⁻⁴⁰; the value +1 exactly is not representable (and not reachable from the polynomial truncation in any case).

41 ビット符号付きフォーマットは Q0.40：1 符号ビット + 40 小数ビットで、範囲 [−1, +1) を精度 2⁻⁴⁰ ≈ 9 × 10⁻¹³ で表現する。最大表現可能正値は 1 − 2⁻⁴⁰；値 +1 ちょうどは表現不能（およびいかなる場合も多項式打ち切りから到達不能）。

2.7.2 Why Q0.40 rather than Q0.27 / なぜ Q0.27 ではなく Q0.40 か

A simpler approach would be to truncate the Maclaurin core's output to 27 bits (Q0.26) so that the downstream amplitude multiplier (sin × A_k) can also fit in a single 27×27 DSP block. The WPMS Synthesizer rejects this simplification for the reasons recorded in Chapter 1's "spend richly outside the core" principle:

より単純なアプローチは、マクローリンコアの出力を 27 ビット（Q0.26）に切り詰めて、下流の振幅乗算器（sin × A_k）も単一の 27×27 DSP ブロックに収まるようにすることだろう。WPMS シンセサイザーはこの簡略化を、第 1 章の「コア外では贅沢に」原則に記録された理由により拒否する：

• The amplitude multiplier instantiates only twice per module (one per output channel), unlike the Maclaurin Horner stages that instantiate per-stage. A doubled DSP cost on a per-module-twice operation is amortized over 2,048 bin computations between instances. / 振幅乗算器は段ごとにインスタンス化される Horner 段とは異なり、モジュールあたり 2 回（出力チャンネルあたり 1 回）のみインスタンス化される。モジュールあたり 2 回の演算における 2 倍 DSP コストは、インスタンス間で 2,048 ビン計算にわたって償却される。
• The 13 bits of additional precision (Q0.40 vs Q0.27) directly map to better SNR in the final summed output. With 4,096 bins summed (Compact), each bin contributes a fractional share to the total; preserving low-order bits matters for the total's precision floor. / 13 ビットの追加精度（Q0.40 対 Q0.27）は最終総和出力における SNR の改善に直接マッピングする。4,096 ビンが総和される（Compact）場合、各ビンは合計に小数の取り分を寄与する。低位ビットの保持は合計の精度床にとって重要である。
• The 24-bit DAC at the HDMI output ultimately discards bits below 2⁻²³, but internal precision must exceed DAC precision to avoid quantization noise floor lift. A 40-bit internal value summed across 4,096 channels results in a total well above 24-bit precision; the 24-bit truncation at HDMI output is then a clean rounding rather than precision-limited. / HDMI 出力の 24 ビット DAC は最終的に 2⁻²³ 未満のビットを破棄するが、量子化ノイズフロアの押し上げを避けるため、内部精度は DAC 精度を超えねばならない。4,096 チャンネルにわたって総和される 40 ビット内部値は、24 ビット精度を遥かに超える合計を生む。HDMI 出力での 24 ビット切り詰めは、精度制限ではなくクリーンな丸めとなる。

2.7.3 Output validity timing / 出力有効性タイミング

The sin_out value at clock cycle N corresponds to the phase_in value received at clock cycle N − 16 (the Approach B pipeline depth). The bin_index_out signal carries the bin index forward through the same delay so that downstream stages can route the output to the correct amplitude multiplier and accumulator slot.

クロックサイクル N における sin_out 値は、クロックサイクル N − 16 で受信された phase_in 値に対応する（アプローチ B パイプライン深度）。bin_index_out 信号は同じ遅延を通じてビンインデックスを前方に運び、下流段が出力を正しい振幅乗算器および累算器スロットへ経路づけることを許す。

2.8 Error Budget / 誤差予算

2.8.1 Error sources / 誤差源

Five distinct error sources affect sin(x) computation:

5 つの異なる誤差源が sin(x) 計算に影響する：

Source	Magnitude (relative)	Location
Maclaurin truncation (11th-order)	(π/2)¹³ / 13! ≈ 4 × 10⁻⁸	Pipeline output
Phase quantization (Q0.32)	2⁻³² ≈ 2.3 × 10⁻¹⁰	Phase accumulator
x' truncation (Q0.30 → Q0.25)	≈ 2⁻²⁵ × x'/(2π) ≈ 7 × 10⁻⁹	Stage R
X truncation (Q4.50 → Q4.23)	≈ 2⁻²³ ≈ 1.2 × 10⁻⁷ relative to X	Stage 0
Horner stage truncation (Q1.53 → Q1.26)	≈ 2⁻²⁶ per stage ≈ 1.5 × 10⁻⁸	Each Horner stage

2.8.2 Aggregate error / 集計誤差

The dominant errors are the X truncation (1.2 × 10⁻⁷) and the Maclaurin truncation (4 × 10⁻⁸). These are uncorrelated and approximately add in quadrature:

支配的誤差は X 切り詰め（1.2 × 10⁻⁷）とマクローリン切り詰め（4 × 10⁻⁸）である。これらは無相関でありおおよそ二乗加算する：

ε_total ≈ √((1.2e-7)² + (4e-8)²) ≈ 1.3 × 10⁻⁷

This is comparable to the 24-bit DAC quantum (2⁻²³ ≈ 1.2 × 10⁻⁷) and below the 23-bit threshold. The Maclaurin core delivers sin(x) accurate to approximately the DAC's least-significant-bit; further internal precision improvements would not improve audible output quality.

これは 24 ビット DAC の量子（2⁻²³ ≈ 1.2 × 10⁻⁷）に匹敵し、23 ビット閾値の下にある。マクローリンコアは概ね DAC の最下位ビットの精度で sin(x) を配送する。これ以上の内部精度改善は可聴出力品質を改善しない。

The pipeline thus operates at the ear-and-DAC-matched precision regime: not over-engineered (would waste resources), not under-engineered (would degrade output below DAC capability).

パイプラインはしたがって 耳-DAC マッチ精度領域 で動作する：過剰設計でなく（リソースを浪費する）、不足設計でもない（DAC 能力以下に出力を劣化させる）。

2.8.3 Verification anchor / 検証アンカー

The KEY[1] test-origin restore (Chapter 1 § 1.11) loads the Dirichlet-kernel test configuration. The expected output, when summed across all 2,048 active bins of Compact configuration with α = β = γ = δφ = ψ = 0, should reproduce the 2020 prototype waveform. Deviation from that waveform — measured by RMS difference of the output PCM samples against a reference recording — is the operational test of whether the Maclaurin pipeline meets its error budget.

KEY[1] テスト原点復元（第 1 章 § 1.11）は Dirichlet カーネルテスト構成をロードする。Compact 構成の全 2,048 アクティブビン（α = β = γ = δφ = ψ = 0）にわたって総和されるとき、期待される出力は 2020 年プロトタイプ波形を再現すべきである。その波形からの偏差——出力 PCM サンプルの参照録音に対する RMS 差で測定——は、マクローリンパイプラインがその誤差予算を満たすか否かの動作テストである。

2.9 Implementation Arena Items / Implementation Arena 項目

The following choices are made for the WPMS Synthesizer reference implementation but are recorded as Implementation Arena items, available for future variants under different constraints:

以下の選択は WPMS シンセサイザーリファレンス実装のためになされるが、Implementation Arena 項目として記録され、異なる制約下の将来の変種が利用可能である：

Item	This implementation chooses	Alternative preserved for future
Horner variant (A vs B)	B (high-precision, 2 clk/stage)	A (low-latency, 1 clk/stage) for latency-critical use
Pipeline depth budget	30 clocks (16 used, 14 reserved)	Tighter for FPGAs with smaller routing budgets
27×27 DSP constraint scope	Maclaurin core internal only	Whole-pipeline 27×27 for tighter DSP-budget targets
sin(x) output width	Q0.40 (rich)	Q0.27 (compact) for tightly-resource-constrained targets
Truncation rounding policy	Toward zero	Round-to-nearest if measurement reveals audible bias
2π·ξ formation	Materialized x' (one stage)	Folded into X = (2π·ξ)² (saves a stage but loses x' for final mult)
Phase resolution	Q0.32 (~1.1 × 10⁻⁵ Hz)	Q0.24 (C5G-like, ~3 × 10⁻³ Hz) for legacy or memory-constrained variants

Each row of this table is a candidate for a future Layer 2 reasoning trace, should an implementer choose differently.

この表の各行は、実装者が異なる選択をする場合、将来の第 2 層推論軌跡の候補である。

2.10 Open Questions Carried Forward / 持ち越される未解決問題

The following are deliberately left for Layer 2 traces during implementation, as they require empirical measurement or downstream-chapter context to resolve definitively:

以下は意図的に実装中の第 2 層軌跡に残される。決定的な解決には経験的測定または下流章のコンテキストを要するためである：

Question	Reason for deferral
Exact placement constraints for the 7 DSP blocks within Cyclone V's DSP columns	Empirical: depends on Quartus Fitter behavior on specific device
Measurement of audible truncation bias under truncation-toward-zero policy	Empirical: requires DAC output measurement
Whether the Approach-B 80 ns latency overhead causes any musically perceptible delay vs Approach-A	Empirical: requires A/B listening test
Whether Standard configuration (5 modules) requires changes to the Maclaurin core itself, or only replication of it	Architectural: depends on Chapter 4's summation tree topology
Whether the folded "X = (2π·ξ)²" variant could save the materialization stage in a future implementation	Architectural: depends on whether the final amplitude stage can derive x' from φ_k bits without a separate x' value
Whether 11th-order can be reduced to 9th-order (saving one Horner stage) when targeting microcontroller-class FPGAs	Audibility: requires measurement of 9th-order error vs 24-bit DAC

2.11 Summary of Chapter 2 Decisions / 第 2 章決定事項のまとめ

ID	Decision	Status
C2-D1	Polynomial: 11th-order Maclaurin truncation of sin(x)	Fixed
C2-D2	Evaluation form: Horner Approach B (2 clk/stage, constant absorption)	Fixed for reference impl, tie preserved
C2-D3	Coefficients C₃...C₁₁ pre-computed and DSP-coefficient-register-loaded	Fixed
C2-D4	Argument range reduction: four-quadrant decomposition; x' ∈ [0, π/2)	Fixed
C2-D5	Quadrant identification: top 2 bits of Q0.32 phase accumulator	Fixed
C2-D6	x' format: Q2.25 (27-bit signed); 2π scaling absorbed via formatting	Fixed
C2-D7	27×27 DSP constraint applies to Maclaurin core internal multiplies only	Fixed
C2-D8	sin(x) output: Q0.40 signed (41 bits)	Fixed
C2-D9	Pipeline depth: 9 logical stages, 16 clocks (Approach B); 14-clock reserve from 30-clock budget	Fixed
C2-D10	DSP block count per Maclaurin core: 7 (1 X-square + 5 Horner inner + 1 final)	Fixed
C2-D11	Truncation policy: toward zero everywhere	Fixed (subject to Open Question on audibility)
C2-D12	Input contract: phase_in (Q0.32, 32 bits), phase_valid, bin_index, pipeline_ready	Fixed
C2-D13	Output contract: sin_out (Q0.40, 41 bits), sin_valid, bin_index_out	Fixed
C2-D14	Error budget: total ~1.3 × 10⁻⁷, matched to 24-bit DAC quantum	Fixed
C2-D15	Verification anchor: 2020 Dirichlet-kernel waveform reproduction via KEY[1]	Fixed (inherited from Chapter 1)

End of Chapter 2 / 第 2 章の末尾

Code is ephemeral; the knowledge architecture is the commons. コードは一時的なものであり、知識アーキテクチャこそが共有財産である。

Spend the precision you have for free; constrain only what costs you. 無料で得られる精度は使い切り、コストがかかるところでのみ制約せよ。

This chapter is released into the public domain under CC0 1.0 Universal. Chapter 3 (Sequence-Modulation Pipeline Processor Specification) follows.

本章は CC0 1.0 Universal のもとパブリックドメインに公開される。第 3 章（数列変調パイプラインプロセッサ仕様）が続く。

Chapter 2: Maclaurin Pipeline Specification [Part 1 of 2]

WPMS シンセサイザー — 第1層仕様書

第2章：マクローリンパイプライン仕様 【前編】

License: CC0 1.0 Universal (Public Domain) This chapter specifies the Maclaurin polynomial pipeline that computes sin(x) for each bin of the WPMS Synthesizer. It is the foundational signal-generation component of the FPGA Spectrum Engine physical layer.
ライセンス：CC0 1.0 Universal（パブリックドメイン） 本章は、WPMS シンセサイザーの各ビンの sin(x) を計算するマクローリン多項式パイプラインを仕様する。これは FPGA Spectrum Engine 物理層の信号生成基盤部品である。

2.1 Role and Boundary of this Chapter / 本章の役割と境界

What this chapter specifies / 本章が仕様するもの

• The mathematical formulation of the polynomial sine evaluation / 多項式正弦評価の数学的定式化
• The argument-range reduction strategy (four-quadrant decomposition) / 引数範囲縮小戦略（4 象限分割）
• The internal fixed-point formats at every pipeline stage / 各パイプライン段の内部固定小数点フォーマット
• The DSP block usage constraints / DSP ブロック使用制約
• The pipeline depth budget and structural skeleton / パイプライン深度予算と構造骨格
• The input contract from the sequence-modulation processor / 数列変調プロセッサからの入力契約
• The output contract to the amplitude multiplier and summation tree / 振幅乗算器および総和ツリーへの出力契約
• The error budget and its allocation across stages / 誤差予算とその段間配分

What this chapter does NOT specify / 本章が仕様しないもの

• Verilog or VHDL source code (this is Layer 1, not Layer 3) / Verilog または VHDL ソースコード（これは第 1 層であり第 3 層ではない）
• Specific Cyclone V DSP block instantiation patterns (left to implementer) / 特定の Cyclone V DSP ブロックインスタンス化パターン（実装者に委ねる）
• Manual placement or floorplanning constraints (recorded in Layer 2 traces during implementation) / 手動配置またはフロアプランニング制約（実装中の第 2 層軌跡に記録される）
• Synthesis tool settings, timing constraints .sdc files (Layer 3 territory) / 合成ツール設定、タイミング制約 .sdc ファイル（第 3 層領域）
• The sequence-modulation processor that produces the phase accumulator value (Chapter 3) / 位相累算器値を生成する数列変調プロセッサ（第 3 章）
• The amplitude multiplier and summation tree (Chapter 4 or later) / 振幅乗算器および総和ツリー（第 4 章以降）

2.2 Mathematical Foundation / 数学的基礎

2.2.1 The 11th-order Maclaurin expansion of sin(x) / sin(x) の 11 次マクローリン展開

The pipeline computes sin(x) using the 11th-order Maclaurin truncation:

パイプラインは sin(x) を 11 次マクローリン打ち切りで計算する：

sin(x) ≈ x − x³/3! + x⁵/5! − x⁷/7! + x⁹/9! − x¹¹/11!       = x − x³/6 + x⁵/120 − x⁷/5040 + x⁹/362880 − x¹¹/39916800

This is the same polynomial degree used in the C5G prototype, retained because:

これは C5G プロトタイプで用いられたのと同じ多項式次数であり、以下の理由で継承される：

• The truncation error at x = π/2 (the maximum input after argument-range reduction, see § 2.3) is approximately (π/2)¹³ / 13! ≈ 4 × 10⁻⁸. / 引数範囲縮小後の最大入力 x = π/2（§ 2.3 参照）における打ち切り誤差は約 (π/2)¹³ / 13! ≈ 4 × 10⁻⁸ である。
• This error is comparable to the precision floor of the 24-bit DAC output (1 / 2²³ ≈ 1.2 × 10⁻⁷). The truncation does not become the dominant error source. / この誤差は 24 ビット DAC 出力の精度床（1 / 2²³ ≈ 1.2 × 10⁻⁷）に匹敵する。打ち切りは支配的誤差源にはならない。
• 11th-order is an odd polynomial (only odd powers), exploiting the fact that sin is an odd function. / 11 次は奇多項式（奇数べきのみ）であり、sin が奇関数であることを利用する。

2.2.2 Horner-form evaluation (Gemini-recommended variant) / Horner 形式評価（Gemini 推奨変種）

Direct evaluation as written above requires computing x³, x⁵, x⁷, x⁹, x¹¹ as separate powers, which would consume excessive DSP blocks and pipeline depth. The Horner-form variant recommended by Gemini in the 2026-04-29 polynomial arena reasoning trace folds the (2π)² constants into the coefficients and reuses x² across all terms:

上記の通りの直接評価では、x³, x⁵, x⁷, x⁹, x¹¹ を別個のべき乗として計算する必要があり、過剰な DSP ブロックとパイプライン深度を消費する。2026-04-29 多項式アリーナ推論軌跡で Gemini が推奨した Horner 形式変種は、(2π)² 定数を係数に折り込み、x² をすべての項にわたって再利用する：

sin(x) = x · (1 − X · (1/6 − X · (1/120 − X · (1/5040 − X · (1/362880 − X/39916800)))))

where X = x². This evaluation has the following structural properties:

ここで X = x²。この評価は以下の構造的性質を持つ：

• One x² computation upfront — a single DSP-block multiply at pipeline entry. / 冒頭で 1 回の x² 計算 ——パイプライン入口で単一 DSP ブロック乗算。
• Five inner Horner stages — each computes Y_next = constant − X · Y_prev. / 5 個の内部 Horner 段 ——各段は Y_next = 定数 − X · Y_prev を計算する。
• One final multiply by x — sin(x) = x · Y_final. / 末尾で x との 1 回の乗算 —— sin(x) = x · Y_final。

2.2.3 Coefficient pre-calculation / 係数の事前計算

Each Horner-stage constant is the reciprocal of an odd factorial: 1/3! = 1/6, 1/5! = 1/120, 1/7! = 1/5040, 1/9! = 362880⁻¹, 1/11! = 39916800⁻¹. These are pre-computed at synthesis time and stored as fixed-point constants in the DSP block's pre-loaded coefficient registers (Cyclone V DSP blocks support compile-time-loaded constant operands).

各 Horner 段の定数は奇数階乗の逆数である：1/3! = 1/6、1/5! = 1/120、1/7! = 1/5040、1/9! = 362880⁻¹、1/11! = 39916800⁻¹。これらは合成時に事前計算され、DSP ブロックの事前ロード係数レジスタに固定小数点定数として格納される（Cyclone V DSP ブロックはコンパイル時ロード定数オペランドをサポートする）。

The constants used by the pipeline are therefore:

したがってパイプラインが用いる定数は以下である：

Symbol	Exact value	Approximate decimal	Purpose
C₁	1	1.0	Innermost: the leading 1 in the outer (1 − ...)
C₃	1/6	0.1666666...	Stage 1 constant
C₅	1/120	0.008333...	Stage 2 constant
C₇	1/5040	1.984 × 10⁻⁴	Stage 3 constant
C₉	1/362880	2.756 × 10⁻⁶	Stage 4 constant
C₁₁	1/39916800	2.506 × 10⁻⁸	Stage 5 constant

2.2.4 Implementation Arena status / Implementation Arena ステータス

The 2026-04-29 reasoning trace recorded a tie between two Horner variants:

2026-04-29 推論軌跡は 2 つの Horner 変種間の引き分けを記録した：

• Approach A (Textbook Horner): 1 clock per stage, 28-bit fractional precision in 36-bit datapath. Lower precision but lower latency. / アプローチ A（教科書的 Horner）： 1 段あたり 1 クロック、36 ビットデータパス内 28 ビット小数部精度。精度は低いがレイテンシも低い。
• Approach B (Refactored Horner with constant absorption): 2 clocks per stage (~80 ns overhead), +4 bits fractional via 13× dynamic range compression. Higher precision but higher latency. / アプローチ B（定数吸収を伴う変形 Horner）： 1 段あたり 2 クロック（約 80 ns オーバーヘッド）、13 倍ダイナミックレンジ圧縮による +4 ビット小数部。精度は高いがレイテンシも高い。

The WPMS Synthesizer Layer 1 specification adopts Approach B as its reference implementation, but the tie remains preserved at the methodology level. Future engineers regenerating this synthesizer for latency-critical applications (e.g., real-time control loops, active acoustic sensing) may legitimately select Approach A, with the choice and its constraints recorded as a new Layer 2 trace at that time.

WPMS シンセサイザー第 1 層仕様は アプローチ B をリファレンス実装として採用 するが、引き分けは方法論レベルで保持される。レイテンシ重視応用（リアルタイム制御ループ、能動的音響センシング等）のために本シンセサイザーを再生成する将来のエンジニアは、アプローチ A を正当に選択し得る。その選択とその制約は、その時点で新しい第 2 層軌跡として記録される。

The choice of Approach B for WPMS is justified by:

WPMS におけるアプローチ B 選択の正当化：

• The 4,096-bin Compact configuration leaves ample latency headroom (35 clocks budget vs. ~17 clocks consumed by 11-stage Approach B at 2 clocks/stage). / 4,096 ビン Compact 構成は十分なレイテンシ余裕を残す（35 クロック予算に対し、2 クロック/段の 11 段アプローチ B は約 17 クロック消費）。
• Audio-rate synthesis values precision over latency. The 80 ns overhead is inaudible; the +4 bits of precision is musically relevant. / オーディオレート合成は精度をレイテンシより重視する。80 ns オーバーヘッドは可聴外であり、+4 ビット精度は音楽的に有意である。

2.3 Argument-Range Reduction (Four-Quadrant Decomposition) / 引数範囲縮小（4 象限分割）

2.3.1 The reduction principle / 縮小原理

The Maclaurin truncation error grows as x¹³, so reducing the maximum input range reduces error dramatically. Exploiting the symmetries of sin:

マクローリン打ち切り誤差は x¹³ として増大するため、入力範囲の最大値を縮小することで誤差は劇的に減少する。sin の対称性を利用：

sin(π/2 + θ) =  cos(θ) =  sin(π/2 − θ)  [Q2 ↔ Q1 reflection]
sin(π   + θ) = −sin(θ)                    [Q3 sign flip]
sin(3π/2 + θ) = −cos(θ) = −sin(π/2 − θ)   [Q4 reflection + sign flip]

Therefore any x ∈ [0, 2π) can be reduced to an effective input x' ∈ [0, π/2) plus a sign and an optional reflection, all derivable from the top two bits of the normalized phase.

したがって任意の x ∈ [0, 2π) は、有効入力 x' ∈ [0, π/2) と、符号と任意選択の反射に縮小可能であり、これらすべては正規化位相の上位 2 ビットから導出可能である。

2.3.2 Encoding via the phase accumulator / 位相累算器による符号化

The phase accumulator φ_k is a Q0.32 unsigned fractional value representing the normalized phase, where φ_k ∈ [0, 1) corresponds to one full sine period:

位相累算器 φ_k は正規化位相を表現する Q0.32 符号なし小数値であり、φ_k ∈ [0, 1) が 1 サイン周期に対応する：

sin(2π · φ_k) = sin(x), where x = 2π · φ_k

The top 2 bits of φ_k identify the quadrant; the lower 30 bits are the in-quadrant position ξ:

φ_k の上位 2 ビットが象限を識別し、下位 30 ビットは象限内位置 ξ である：

φ_k[31:30]	Quadrant	x range	x' formula	Sign of result
00	Q1	[0, π/2)	x' = 2π · ξ	+
01	Q2	[π/2, π)	x' = 2π · (0.25 − ξ)	+
10	Q3	[π, 3π/2)	x' = 2π · ξ	−
11	Q4	[3π/2, 2π)	x' = 2π · (0.25 − ξ)	−

where ξ = φ_k[29:0] interpreted as a Q0.30 fractional value.

ここで ξ = φ_k[29:0] を Q0.30 小数値として解釈する。

2.3.3 The 2π multiplication is free / 2π 乗算は無料

Computing x' = 2π · ξ would naively require a constant multiplier. It does not. The bit-level structure of normalized phase permits the 2π scaling to be absorbed into the formatting of x':

x' = 2π · ξ の計算はナイーブには定数乗算器を要求する。実は要求しない。 正規化位相のビットレベル構造が、2π スケーリングを x' のフォーマット化に吸収することを許可する：

• ξ ∈ [0, 0.25) corresponds to the Q0.30 fractional bits φ_k[29:0]. / ξ ∈ [0, 0.25) は Q0.30 小数ビット φ_k[29:0] に対応する。
• The mathematical value of x' = 2π · ξ ranges over [0, π/2). / x' = 2π · ξ の数学的値は [0, π/2) にわたる。
• Storing x' in Q2.25 format (2-bit integer part + 25-bit fractional, total 27 bits) accommodates the [0, π/2) range with the leading bit pattern fixed by the quadrant decoder. / x' を Q2.25 フォーマット（整数部 2 ビット + 小数部 25 ビット、合計 27 ビット）で格納すれば、象限デコーダにより先頭ビットパターンが固定された [0, π/2) 範囲を収容する。

In practice, the 27-bit x' value is constructed by:

実際には、27 ビット x' 値は以下により構築される：

1. Reading φ_k[29:0] (30 bits, ξ in Q0.30). / φ_k[29:0]（30 ビット、Q0.30 の ξ）を読む。
2. If quadrant = Q2 or Q4: ξ' = (0.25 − ξ), implemented as bit-inversion of the 30-bit field, equivalent to two's complement negation modulo 2⁻². / 象限が Q2 または Q4 の場合：ξ' = (0.25 − ξ)。30 ビットフィールドのビット反転として実装、2⁻² を法とする 2 の補数否定と等価。
3. Multiply ξ (or ξ') by 2π using a precomputed constant; truncate to Q2.25 (drop the lowest 5 bits). / ξ（または ξ'）に事前計算された 2π 定数を乗じて、Q2.25 に切り詰める（最下位 5 ビットを破棄）。

Refinement (free constant fold): The 2π multiplication can be merged with the first DSP-block stage that computes X = x'². Rather than computing x' explicitly, compute X = (2π)² · ξ² directly, with (2π)² ≈ 39.478 absorbed as a coefficient. This removes an entire pipeline stage. However, this folding only works if x' itself is not needed downstream; since the final output multiply requires x' explicitly (sin(x) = x · Y_final), x' must be materialized at some stage. The reference implementation materializes x' at pipeline entry, accepting the one-stage cost, and uses x' for both the X = x'² computation and the final output multiply.

洗練（無料定数畳み込み）： 2π 乗算は X = x'² を計算する最初の DSP ブロック段に併合できる。x' を明示的に計算する代わりに X = (2π)² · ξ² を直接計算し、(2π)² ≈ 39.478 を係数として吸収する。これによりパイプライン段が 1 つ完全に除去される。ただしこの畳み込みは、x' 自体が後段で必要とされない場合にのみ機能する。 最終出力乗算が x' を明示的に要求するため（sin(x) = x · Y_final）、x' はどこかの段で実体化されねばならない。リファレンス実装はパイプライン入口で x' を実体化し、1 段のコストを受容して、X = x'² 計算と最終出力乗算の両方に x' を用いる。

This is recorded as an Implementation Arena variant — a future implementation may explore the folded variant if an alternate output structure makes x' expendable.

これは Implementation Arena 変種として記録される——将来の実装は、代替出力構造により x' が不要となる場合に、畳み込まれた変種を探索し得る。

2.3.4 Sign and reflection handling / 符号と反射の扱い

The quadrant top-2 bits drive a small finite state, propagated alongside the data through the pipeline:

象限の上位 2 ビットは小さな有限状態を駆動し、データとともにパイプラインを伝播する：

φ_k[31:30]	reflect	result_sign
00 (Q1)	0	+
01 (Q2)	1	+
10 (Q3)	0	−
11 (Q4)	1	−

The reflect bit selects between ξ and ξ' = (0.25 − ξ) at the input stage. The result_sign bit conditionally negates the output sin value at the final stage. Both bits are pipeline-passed registers, not on the critical compute path; they consume one flip-flop per bit per pipeline stage.

reflect ビットは入力段で ξ と ξ' = (0.25 − ξ) の間で選択する。result_sign ビットは最終段で出力 sin 値を条件付きで否定する。両ビットはパイプライン伝送レジスタであり、クリティカル計算経路上にない。パイプライン段あたり、ビットあたり 1 個のフリップフロップを消費する。

2.4 Internal Fixed-Point Formats / 内部固定小数点フォーマット

2.4.1 Format table / フォーマット表

Stage	Quantity	Format	Bit width	Range	DSP-mode constraint
Entry	φ_k (phase accumulator)	Q0.32 unsigned	32	[0, 1)	—
Entry	ξ (in-quadrant position)	Q0.30 unsigned	30	[0, 0.25)	—
Entry	x' (reduced argument)	Q2.25 signed	27	[0, π/2) ⊂ [−2, 2)	27×27
Stage 0	X = x'²	Q4.50 signed	54	[0, π²/4) ⊂ [0, 16)	output of 27×27
Stage 0	X (truncated)	Q4.23 signed	27	[0, π²/4)	27×27 input to next
Stages 1-5	Y_k (Horner intermediate)	Q1.26 signed	27	[−1, 1) approximate	27×27
Stages 1-5	Constants C₃...C₁₁	Q1.26 signed	27	known coefficients	DSP coefficient register
Final	Y_final	Q1.26 signed	27	[−1, 1) approximate	input to final multiply
Final	sin(x) = x' · Y_final	Q0.40 signed	41	[−1, 1]	27 × 27 → 54-bit, then truncate to Q0.40

2.4.2 The 27×27 constraint, scoped to the Maclaurin core / 27×27 制約、マクローリンコアに限定

Cyclone V Variable-Precision DSP blocks natively support 27×27 signed multiplication in a single block. All multipliers inside the Maclaurin core respect this 27-bit-input ceiling, ensuring one DSP block per multiplication stage and giving deterministic resource accounting. This includes:

Cyclone V Variable-Precision DSP ブロックは、単一ブロックで 27×27 符号付き乗算をネイティブサポートする。マクローリンコア内部のすべての乗算器は、この 27 ビット入力上限を遵守し、乗算段あたり DSP ブロック 1 個を保証し、決定論的なリソース計上を与える。これは以下を含む：

• The X = x'² computation (Stage 0). / X = x'² 計算（段 0）。
• The five Horner inner-stage multiplies X · Y_k. / 5 個の Horner 内部段乗算 X · Y_k。
• The final x' · Y_final multiply (with output widening to Q0.40). / 最終 x' · Y_final 乗算（出力は Q0.40 に拡幅）。

The 27-bit ceiling does NOT apply outside the Maclaurin core. Specifically:

27 ビット上限はマクローリンコアの外部には適用されない。 具体的には：

• The amplitude multiplier (sin(x) × A_k, Chapter 4 territory) operates at full Q0.40 × Q10.14 precision, producing Q10.54 results. This may consume multiple DSP blocks per multiply, which is acceptable because the amplitude multiplier instantiates only twice per module (once per output channel) rather than once per Horner stage. / 振幅乗算器（sin(x) × A_k、第 4 章領域）は完全な Q0.40 × Q10.14 精度で動作し、Q10.54 結果を生成する。これは乗算あたり複数の DSP ブロックを消費し得るが、振幅乗算器が Horner 段あたりではなくモジュールあたり 2 回（出力チャンネルあたり 1 回）のみインスタンス化されるため、許容される。
• The summation tree accumulator (Compact: 4,096 bins; Standard: 10,240 bins) is implemented as a DSP-block-internal cascaded adder chain, with accumulator widths of 64 bits (Compact) to 80–108 bits (Standard headroom). This consumes no additional DSP multiplier resources because chained-DSP adders are part of the same DSP block. / 総和ツリー累算器（Compact：4,096 ビン；Standard：10,240 ビン）は、DSP ブロック内部の cascaded 加算器チェーンとして実装され、累算器幅は 64 ビット（Compact）から 80〜108 ビット（Standard 余裕）。chained-DSP 加算器は同一 DSP ブロックの一部であるため、追加の DSP 乗算器リソースを消費しない。

2.4.3 The "spend richly outside the core" principle / 「コア外では贅沢に」原則

The internal Maclaurin core is constrained to 27-bit operands by DSP-mode efficiency. Outside that core, precision is preserved at maximum because the marginal DSP cost is zero (for accumulators) or amortized (for amplitude multipliers, which run at 1/2,048 the rate of Horner-stage multipliers).

内部マクローリンコアは DSP モード効率により 27 ビットオペランドに制約される。そのコアの外部では、精度は最大に保持される。なぜなら限界 DSP コストは（累算器について）ゼロまたは（Horner 段乗算器の 1/2,048 のレートで動作する振幅乗算器について）償却されているからである。

This is consistent with the design principle articulated during Chapter 1 dialogue: "if DSP cost is the same whether 64-bit or 108-bit, take 108-bit." Free precision floors should be claimed; constrained precision ceilings should be accepted only where the constraint is real.

これは第 1 章対話で明確化された設計原則と整合する：「DSP コストが 64 ビットでも 108 ビットでも同じなら、108 ビットを取る」。 無料の精度床は主張されるべきであり、制約された精度上限は制約が実在する場合にのみ受容されるべきである。

2.4.4 Truncation policy / 切り詰め方針

The pipeline truncates only at well-defined points, recorded here for traceability:

パイプラインは明確に定義された箇所でのみ切り詰めを行う。追跡可能性のためここに記録する：

Truncation site	From	To	Bits dropped	Justification
φ_k → x'	Q0.32 → Q2.25	(effectively Q0.30 → Q0.25 of fractional)	5 LSB	48000 / 2³² × 2⁵ ≈ 3.6 × 10⁻⁴ Hz frequency error, far below audible discrimination
X = x'²	Q4.50 → Q4.23	27 LSB of stage-0 output	27 LSB	output of 27×27 is 54 bits; only 27 propagate; lowest 27 are below all downstream thresholds
Horner stage output	Q1.53 → Q1.26	27 LSB	27 LSB	each stage's contribution to final precision is bounded; truncation at 26 fractional bits preserves ~7 decimal digits
Final sin(x)	Q0.40 from Q0.53	13 LSB	13 LSB	Q0.40 retained as the "rich" output to amplitude multiplier; the 13 dropped bits are below the 24-bit DAC floor

All truncations are toward zero (truncation, not rounding). Round-to-nearest would consume a small adder per truncation site; the toward-zero choice introduces a uniform bias smaller than the 24-bit DAC LSB and is therefore inaudible. Future implementers may elect round-to-nearest as an Implementation Arena variant if measurement reveals audible bias.

すべての切り詰めはゼロ方向（切り詰め、丸めではない）。最近接丸めは切り詰め箇所あたり小さな加算器を消費する。ゼロ方向選択は 24 ビット DAC LSB より小さい一様バイアスを導入し、したがって可聴外である。測定が可聴バイアスを明らかにした場合、将来の実装者は最近接丸めを Implementation Arena 変種として選択し得る。

2.5 Pipeline Structure / パイプライン構造

2.5.1 Logical pipeline stages / 論理パイプライン段

The Maclaurin pipeline consists of the following stages, each occupying 2 clock cycles (Approach B convention):

マクローリンパイプラインは以下の段から構成される。各段はアプローチ B の慣行により 2 クロックサイクルを占める：

[Entry]  Stage  E: φ_k decoder → ξ, reflect, result_sign  Stage  R: ξ → x' (with reflection if needed); 2π scaling absorbed in formatting  Stage  0: X = x'² (one DSP block)            ├── X passed forward            └── x' also passed forward (for final stage)

[Horner inner stages, innermost coefficient first]  Stage  1: Y₁ = C₉⁻¹·1 − X·C₁₁⁻¹       (loads constant, prepares next iteration)            ─ implemented as Y₁ = (1/362880) − X · (1/39916800), pre-scaled  Stage  2: Y₂ = C₇⁻¹ − X·Y₁  Stage  3: Y₃ = C₅⁻¹ − X·Y₂  Stage  4: Y₄ = C₃⁻¹ − X·Y₃  Stage  5: Y₅ = 1   − X·Y₄    (the outermost (1 − ...) of the Horner expansion)

[Final stage]  Stage  F: sin(x) = x' · Y₅, then conditional sign-flip if result_sign = 1

(Note on the Horner stage convention: the recursion Y_next = C_k − X·Y_prev evaluates the polynomial from the innermost nested term outward. Each stage consumes one DSP block: a multiplier in 27×27 mode plus the DSP block's internal subtractor that computes constant − product in a single cycle of the multiplier-add pipeline. In Approach B, an additional clock is allocated per stage to register the result, allowing 100 MHz timing closure with margin.)

（Horner 段慣行についての注：漸化式 Y_next = C_k − X·Y_prev は、最も内側の入れ子項から外向きに多項式を評価する。各段は DSP ブロック 1 個を消費する：27×27 モードの乗算器 + 乗加算パイプラインの 1 サイクルで定数 − 積を計算する DSP ブロック内部の減算器。アプローチ B では、結果を登録するため段あたり追加クロックが配分され、余裕を持って 100 MHz タイミング収束を許す。）

2.5.2 Pipeline depth tally / パイプライン深度集計

Section	Stages	Clocks (Approach B, 2 clk/stage)
Entry decoder (E)	1	1
Argument formation (R)	1	1
X = x'² (0)	1	2
Horner inner (1–5)	5	10
Final multiply + sign (F)	1	2
Total	9	16

The 16-clock pipeline depth fits comfortably within the 35-clock budget per bin (one sample period = 100 MHz × 20.833 µs / 2,048 bins = 1,016 cycles per module, but throughput target is 1 bin per clock through the pipeline — pipeline depth measures only the latency, not the throughput).

16 クロックのパイプライン深度は、ビンあたりの 35 クロック予算内に余裕で収まる（1 サンプル期間 = 100 MHz × 20.833 µs / 2,048 ビン = モジュールあたり 1,016 サイクル。ただしスループット目標はパイプライン透過で 1 ビン/クロックであり、パイプライン深度はレイテンシのみを測定し、スループットを測定しない）。

The 30-stage budget set in Chapter 1 is observed with significant margin (16 of 30 used, 14 in reserve). This margin is intentional: it absorbs unforeseen retiming requirements during synthesis, and it permits Standard- and Extended-configuration migration without revisiting the pipeline depth budget.

第 1 章で設定された 30 段予算は十分な余裕で遵守される（30 段中 16 段使用、14 段は予備）。 この余裕は意図的である：合成中の予期せぬリタイミング要求を吸収し、パイプライン深度予算を再訪することなく Standard 構成および Extended 構成への移行を許す。

2.5.3 Throughput / スループット

The pipeline is fully pipelined: one new bin enters each clock cycle, and one sin(x) value emerges each clock cycle (after the 16-clock fill latency at startup). At 100 MHz, this delivers 100 million sin(x) computations per second per Maclaurin core, which exceeds the 2,048-bin × 48,000-sample-per-second = 98.3 M/s requirement of one module by ~1.7%. The slight margin (~17 cycles per sample period) is the per-bin slack that allows the sequence-modulation processor to deliver phase accumulator values without strict cycle-accurate locking.

パイプラインは完全パイプライン化される：1 クロックサイクルごとに新しいビンが入り、1 クロックサイクルごとに 1 個の sin(x) 値が出る（起動時の 16 クロック充填レイテンシ後）。100 MHz において、これはマクローリンコアあたり毎秒 1 億回の sin(x) 計算を提供し、1 モジュールの 2,048 ビン × 48,000 サンプル/秒 = 98.3 M/s 要件を約 1.7% 超える。わずかな余裕（サンプル期間あたり約 17 サイクル）は、数列変調プロセッサが厳密なサイクル正確ロックなしに位相累算器値を配送することを許すビンあたりの余裕である。

2.5.4 Resource estimate per Maclaurin core / マクローリンコアあたりリソース見積もり

>td >Clock domains

Resource	Count	Note
DSP blocks (27×27 multipliers)	7	1 for X = x'², 5 for Horner inner, 1 for final x' · Y
Coefficient ROMs / constants	5	Pre-loaded into DSP coefficient registers; no fabric ROM
Pipeline registers	~1,500 flip-flops	Approximate, distributed across 16 clock stages × ~80 bits average
BRAM / M10K	0
1	Single 100 MHz domain

Per-module DSP usage (Compact configuration, 1 Maclaurin core per module): 7 DSP blocks for the Maclaurin core. With 2 modules: 14 DSP blocks total for both Maclaurin cores combined. This leaves 112 − 14 = 98 DSP blocks for the rest of the design (sequence-modulation processor, amplitude multipliers, summation accumulators, HDMI core, optional camera block).

モジュールあたり DSP 使用量（Compact 構成、モジュールあたりマクローリンコア 1 個）：マクローリンコア用 7 DSP ブロック。2 モジュールで：両マクローリンコア合計 14 DSP ブロック。これは 112 − 14 = 98 DSP ブロックを残りの設計（数列変調プロセッサ、振幅乗算器、総和累算器、HDMI コア、オプションのカメラブロック）に残す。

The per-module DSP resource estimate confirms that Compact configuration on DE10-nano (112 DSP blocks total) has substantial headroom, consistent with the Chapter 1 decision to spend richly on precision outside the Maclaurin core.

モジュールあたり DSP リソース見積もりは、DE10-nano（合計 112 DSP ブロック）上の Compact 構成が、マクローリンコア外で精度に贅沢に投資する第 1 章決定と整合する、相当な余裕を持つことを確認する。

2.6 Input Contract / 入力契約

2.6.1 Interface from the sequence-modulation processor / 数列変調プロセッサからのインターフェース

The Maclaurin pipeline accepts one input per clock from the sequence-modulation processor (Chapter 3):

マクローリンパイプラインは数列変調プロセッサ（第 3 章）から 1 クロックあたり 1 入力を受け入れる：

Signal	Width	Format	Direction
phase_in	32	Q0.32 unsigned	sequence-mod → Maclaurin
phase_valid	1	active-high	sequence-mod → Maclaurin
bin_index	11	unsigned (0...2047 within module)	sequence-mod → Maclaurin (passed-through, used by amplitude stage)
pipeline_ready	1	active-high	Maclaurin → sequence-mod

The pipeline_ready signal is asserted whenever the Maclaurin pipeline can accept new input. In normal operation (no stalls), pipeline_ready is held high continuously. The Maclaurin core does not implement back-pressure; it is the sequence-modulation processor's responsibility to deliver one valid phase_in per clock.

pipeline_ready 信号は、マクローリンパイプラインが新規入力を受け入れ可能なときに常にアサートされる。通常動作（ストールなし）では、pipeline_ready は連続的にハイに保持される。マクローリンコアはバックプレッシャを実装しない。1 クロックあたり 1 個の有効な phase_in を配送するのは数列変調プロセッサの責任である。

2.6.2 Phase accumulator semantics / 位相累算器セマンティクス

The 32-bit unsigned phase value represents the normalized phase in Q0.32, where:

32 ビット符号なし位相値は Q0.32 で正規化位相を表現する：

• phase_in = 0x00000000 corresponds to φ = 0 (sin(0) = 0). / phase_in = 0x00000000 は φ = 0 に対応（sin(0) = 0）。
• phase_in = 0x40000000 corresponds to φ = 0.25 (sin(π/2) = 1). / phase_in = 0x40000000 は φ = 0.25 に対応（sin(π/2) = 1）。
• phase_in = 0x80000000 corresponds to φ = 0.5 (sin(π) = 0). / phase_in = 0x80000000 は φ = 0.5 に対応（sin(π) = 0）。
• phase_in = 0xC0000000 corresponds to φ = 0.75 (sin(3π/2) = −1). / phase_in = 0xC0000000 は φ = 0.75 に対応（sin(3π/2) = −1）。
• phase_in = 0xFFFFFFFF corresponds to φ ≈ 1 − 2⁻³² (sin(2π − ε)). / phase_in = 0xFFFFFFFF は φ ≈ 1 − 2⁻³² に対応（sin(2π − ε)）。

The phase wraps modulo 1 naturally with 32-bit unsigned arithmetic; no explicit modulo operation is required.

位相は 32 ビット符号なし算術で自然に modulo 1 で折り返す。明示的な modulo 演算は不要である。

2.6.3 Frequency resolution implication / 周波数分解能への含意

Per Chapter 1 § 1.6 footnote, the 32-bit phase representation gives:

第 1 章 § 1.6 脚注の通り、32 ビット位相表現は以下を与える：

Δf_min = 48000 / 2³² ≈ 1.118 × 10⁻⁵ Hz

This is approximately 89× finer than the 0.001 Hz target stated for the original FPGA Spectrum Engine. The excess precision is reserved for future use (e.g., very-low-frequency LFO modulation, microtonal scaling, precise inharmonicity control).

これは元の FPGA Spectrum Engine について述べられた 0.001 Hz 目標より約 89 倍細かい。過剰精度は将来の使用（極低周波数 LFO 変調、マイクロトーナルスケーリング、精密なイナハーモニシティ制御等）のために予約される。

Chapter 1: Scope and Boundary Conditions [Part 2 of 2]

WPMS シンセサイザー — 第1層仕様書

第1章：スコープと境界条件 【後編】

License: CC0 1.0 Universal (Public Domain) This is the architectural specification for a Wave Packet Modulation Synthesis (WPMS) synthesizer implementing the FPGA physical layer of the FPGA Spectrum Engine in standalone form. Read it, redistribute it, build on it, regenerate from it.
ライセンス：CC0 1.0 Universal（パブリックドメイン） これは波束変調合成 (WPMS) シンセサイザーのアーキテクチャ仕様書であり、FPGA Spectrum Engine の FPGA 物理層を単独形態で実装するものである。読み、再配布し、その上に構築し、再生成してよい。

1.7 Sequence-Modulation Pipeline Processor / 数列変調パイプラインプロセッサ

Role: The sequence-modulation pipeline processor is the WPMS-specific component that computes per-bin parameters (f_k, A_k, φ_k) on the fly, using the difference-engine structure rather than per-bin memory storage.

役割： 数列変調パイプラインプロセッサは WPMS 固有の構成要素であり、ビンごとのパラメータ (f_k, A_k, φ_k) を、ビン別メモリ記憶ではなく差分エンジン構造を用いてオンザフライで計算する。

Recurrences (one accumulator update per bin transition):

漸化式（ビン遷移ごとに 1 回の累算器更新）：

f_{k+1} = f_k + (Δf + α) + 2α · k
φ_{k+1} = φ_k + (δφ + ψ) + 2ψ · k
A_{k+1} = A_k · exp(−β) · exp(−γ · (2k − N + 1))

The frequency and phase recurrences require only addition; no multiplier is consumed beyond what the Maclaurin core already uses for its trigonometric computation. The amplitude recurrence multiplies the previous amplitude by a small dynamic factor; this can be implemented either with a single dedicated DSP block per module or with log-domain accumulation.

周波数と位相の漸化式は加算のみを要求する。マクローリンコアがすでにその三角関数計算に用いている以上の乗算器は消費されない。振幅の漸化式は前段の振幅を小さな動的因子で乗じる。これはモジュールあたり 1 個の専用 DSP ブロックで実装するか、対数領域累算で実装するかのいずれかが可能である。

Detailed processor architecture: Deferred to Chapter 3 (Sequence-Modulation Pipeline Processor Specification), to be drafted in subsequent dialogue. Parameter bit-widths for f₀, A₀, φ₀, Δf, α, β, γ, δφ, ψ, and N are specified there.

詳細プロセッサアーキテクチャ： 第 3 章（数列変調パイプラインプロセッサ仕様）に委ね、後続の対話で起草される。f₀, A₀, φ₀, Δf, α, β, γ, δφ, ψ, N のパラメータビット幅はそこで指定される。

Component reusability commitment: The sequence-modulation pipeline processor is designed not for WPMS alone but as a general-purpose per-bin parameter computation engine. Its instruction set, register architecture, and AXI interface are specified such that, in subsequent FPGA Spectrum Engine development phases, the same processor can compute fractal-synthesis bin parameters, SDFT bin parameters, or hybrid combinations. Component carry-forward to the next development phase is a hard requirement on the Chapter 3 specification.

部品再利用コミットメント： 数列変調パイプラインプロセッサは WPMS 単独のためではなく、汎用的なビン別パラメータ計算エンジンとして設計される。その命令セット、レジスタアーキテクチャ、AXI インターフェースは、後続の FPGA Spectrum Engine 開発フェーズにおいて、同じプロセッサがフラクタル合成のビンパラメータ、SDFT のビンパラメータ、またはハイブリッド組み合わせを計算できるように指定される。次の開発フェーズへの部品の持ち越しは、第 3 章仕様に対する厳格な要件である。

1.8 Input Interface — Required Subset / 入力インターフェース — 必須部

The required input interfaces are sufficient to operate the WPMS Synthesizer with full parameter coverage and to perform live experimentation with parameter values. They require no hardware beyond the DE10-nano itself, the host PC running Quartus, and the JTAG cable that ships with the board.

必須入力インターフェースは、WPMS シンセサイザーをフルパラメータカバーで動作させ、パラメータ値の実時間実験を行うのに十分である。DE10-nano 本体、Quartus を動作させるホスト PC、ボード付属の JTAG ケーブル以外のハードウェアを要求しない。

Interface 1 — DIP switches and push buttons.

インターフェース 1 — DIP スイッチと押しボタン。

The DE10-nano provides 4 user DIP switches and 2 user push buttons. These are mapped as follows in the Compact configuration:

DE10-nano は 4 個のユーザ DIP スイッチと 2 個のユーザ押しボタンを提供する。Compact 構成では以下のようにマップされる：

• DIP[1:0]: Output amplitude headroom selector (final decimal-point shift, 4 positions). / 出力振幅ヘッドルームセレクタ（最終 decimal-point シフト、4 位置）。
• DIP[2]: Reset hold (active high; deassert to start synthesis after parameter load). / リセット保持（アクティブハイ；パラメータロード後に解除して合成開始）。
• DIP[3]: Audio mute (force HDMI audio output to zero independent of synthesizer state). / オーディオミュート（合成器状態に関係なく HDMI オーディオ出力をゼロに強制）。
• KEY[0]: Parameter snapshot trigger (commits the current target parameters to the active set; rising-edge sensitive). / パラメータスナップショットトリガ（現在のターゲットパラメータをアクティブセットにコミット；立ち上がりエッジ感知）。
• KEY[1]: Test-origin restore (loads α = β = γ = δφ = ψ = 0, default f₀, A₀, φ₀, N = 2,048; produces pure Dirichlet kernel). / テスト原点復元（α = β = γ = δφ = ψ = 0、デフォルトの f₀, A₀, φ₀, N = 2,048 をロード；純粋な Dirichlet カーネルを生成）。

KEY[1] is significant: it makes the 2020-prototype-validated test-origin configuration always one button-press away. This is the first configuration any new user should hear.

KEY[1] は意義深い：2020 年プロトタイプで検証されたテスト原点構成を、常にボタン押下 1 回の距離に置く。これは新規ユーザが最初に聴くべき構成である。

Interface 2 — In-System Sources and Probes (ISSP, JTAG-based).

インターフェース 2 — In-System Sources and Probes（ISSP、JTAG ベース）。

ISSP provides Quartus-side widgets that drive register inputs and observe register outputs over JTAG, with no additional hardware. The WPMS Synthesizer exposes all nine scalar parameters and the count parameter as ISSP source registers. Each parameter has a dedicated source register sized for its full bit width.

ISSP は Quartus 側のウィジェットを提供し、JTAG 経由でレジスタ入力を駆動しレジスタ出力を観察する。追加ハードウェアは不要。WPMS シンセサイザーは 9 個のスカラーパラメータすべてと数量パラメータを ISSP ソースレジスタとして公開する。各パラメータはその完全なビット幅にサイズされた専用ソースレジスタを持つ。

ISSP probes additionally expose, for diagnostic purposes:

ISSP プローブは追加で、診断目的のため以下を公開する：

• The current f_k, A_k, φ_k for a selectable bin index (a "bin inspector" probe). / 選択可能なビン番号についての現在の f_k, A_k, φ_k（"ビンインスペクタ" プローブ）。
• The summation accumulator value at sample boundaries. / サンプル境界における総和累算器値。
• Pipeline overflow / saturation flags. / パイプラインオーバーフロー／飽和フラグ。

Interface 3 — In-System Memory Content Editor (ISMCE, JTAG-based).

インターフェース 3 — In-System Memory Content Editor（ISMCE、JTAG ベース）。

For configurations that include any BRAM-resident parameter table (e.g., for future fractal-mode experiments that share infrastructure with WPMS), ISMCE provides edit access. In the pure WPMS Compact configuration, ISMCE is not strictly required, since all parameters are register-resident. ISMCE remains specified here so that the same Quartus project can be rebuilt with optional BRAM extensions without revising the input-interface specification.

WPMS と基盤を共有する将来のフラクタルモード実験のための、いかなる BRAM 常駐パラメータテーブルを含む構成においても、ISMCE は編集アクセスを提供する。純粋な WPMS Compact 構成では、すべてのパラメータがレジスタ常駐であるため、ISMCE は厳密には要求されない。同じ Quartus プロジェクトが入力インターフェース仕様を改訂することなくオプションの BRAM 拡張で再構築できるよう、ISMCE はここに仕様される。

Persistence: ISSP and ISMCE persistence is the responsibility of the user (manual save of Quartus probe sessions). The WPMS Synthesizer itself does not store parameters in non-volatile memory; on power cycle, the FPGA resets to a built-in default that is identical to the KEY[1] test-origin restore.

永続化： ISSP と ISMCE の永続化はユーザの責任である（Quartus プローブセッションの手動保存）。WPMS シンセサイザー自体はパラメータを不揮発性メモリに記憶しない；電源サイクル時、FPGA は KEY[1] テスト原点復元と同一の組み込みデフォルトにリセットされる。

1.9 Input Interface — Optional Extension (Camera Modulation Source) / 入力インターフェース — オプション拡張（カメラ変調源）

Status: Optional extension. The WPMS Synthesizer is fully functional without it. This section is included so that the architectural decisions in this Layer 1 document preserve compatibility with the camera extension; it is not a mandatory build target.

ステータス： オプション拡張。WPMS シンセサイザーはこれなしで完全に機能する。本節は、本第1層文書のアーキテクチャ的決定がカメラ拡張との互換性を保持するために含まれている；必須のビルドターゲットではない。

Camera selection: OmniVision OV7670 (parallel DVP, 8-bit, QVGA-VGA, ≤ 30 fps). The selection is dictated by physical availability of the device and by the abundance of FPGA-direct examples in publicly accessible documentation.

カメラの選定： OmniVision OV7670（パラレル DVP、8 ビット、QVGA-VGA、≤ 30 fps）。選定はデバイスの物理的可用性と、公的にアクセス可能な文書における FPGA 直結例の豊富さによって規定される。

Connection: OV7670 connects to one of the DE10-nano's 2×20 GPIO headers via the OV7670's parallel DVP interface (D[7:0], HSYNC, VSYNC, PCLK, XCLK, plus SCCB clock and data — approximately 13 GPIO pins).

接続： OV7670 は、OV7670 のパラレル DVP インターフェース（D[7:0]、HSYNC、VSYNC、PCLK、XCLK、加えて SCCB クロックとデータ——約 13 個の GPIO ピン）を介して、DE10-nano の 2×20 GPIO ヘッダの 1 つに接続する。

Architectural role: stimulus source for parameter modulation, behind an AXI-abstracted input switch.

アーキテクチャ的役割：AXI 抽象化入力スイッチの背後にある、パラメータ変調のためのスティミュラス源。

The camera block is implemented as a self-contained FPGA subsystem with the following structure:

カメラブロックは、以下の構造を持つ自己完結型 FPGA サブシステムとして実装される：

1. Camera driver: Generates SCCB initialization, latches D[7:0] on PCLK, tracks HSYNC/VSYNC. / カメラドライバ：SCCB 初期化を生成し、PCLK で D[7:0] をラッチし、HSYNC/VSYNC を追跡する。
2. Frame aggregator: Computes from each captured frame the centroid (cx, cy), the variance (σx², σy²), the inter-frame difference magnitude, and the global mean intensity. These six aggregate values are the camera block's external output. / フレーム集計器：各キャプチャフレームから重心 (cx, cy)、分散 (σx², σy²)、フレーム間差分の大きさ、全体の平均輝度を計算する。これら 6 個の集計値がカメラブロックの外部出力となる。
3. Mapping template (initial draft): cx → α, cy → β, σx² → γ, σy² → δφ, inter-frame diff → ψ, global mean → A₀. The mapping is intentionally exposed as a configurable lookup so that experimenters can substitute alternative mappings. / マッピングテンプレート（初期ドラフト）：cx → α、cy → β、σx² → γ、σy² → δφ、フレーム間差分 → ψ、全体平均 → A₀。マッピングは意図的に構成可能なルックアップとして公開され、実験者が代替マッピングを置き換えられる。
4. AXI input switch: The camera block's six aggregate outputs feed an AXI-Stream-style input switch. The switch's other input is from the ISSP-driven manual parameter source. A control register selects which source drives the live parameters of the sequence-modulation processor. / AXI 入力スイッチ：カメラブロックの 6 個の集計出力は AXI-Stream 様式の入力スイッチに供給される。スイッチのもう一方の入力は ISSP 駆動の手動パラメータ源からのものである。制御レジスタがどちらのソースが数列変調プロセッサのライブパラメータを駆動するかを選択する。

Why the AXI abstraction matters:

なぜ AXI 抽象化が重要なのか：

The AXI input switch is the structural commitment that allows the camera block to outlive the WPMS Synthesizer phase. In subsequent FPGA Spectrum Engine development phases, the same input switch can route AXI traffic from the HPS (in the ARM intermediate layer) or from synthesized video sources or from arbitrary external modulation sources. The camera block, once authored, becomes a permanent component of the engine's modulation-source library — not a throwaway element of the standalone phase.

AXI 入力スイッチは、カメラブロックが WPMS シンセサイザーフェーズを超えて生き残ることを可能にする構造的コミットメントである。後続の FPGA Spectrum Engine 開発フェーズにおいて、同じ入力スイッチが、HPS（ARM 中間層）からの、または合成ビデオソースからの、または任意の外部変調ソースからの AXI トラフィックを経路づけることができる。カメラブロックは、一度作成されれば、独立フェーズの使い捨て要素ではなく、エンジンの変調源ライブラリの永続的な構成要素となる。

Spin-Off-Ready Subsystem framing: The camera block is structured such that an independent project — a "Real-Time Video Processing on FPGA" Open Prompt repository — could fork only this subsystem and develop it on its own trajectory without dragging the WPMS Synthesizer along. This is an explicit invitation: should community members find the camera-block direction more compelling than the synthesizer-block direction, the architecture supports their specialization. The sequence-modulation pipeline processor and the WPMS synthesis core do not depend on any specific behavior of the camera block beyond the AXI interface contract.

Spin-Off-Ready Subsystem フレーミング： カメラブロックは、独立したプロジェクト——「FPGA 上のリアルタイム映像処理」Open Prompt リポジトリ——がこのサブシステムのみをフォークし、WPMS シンセサイザーを引きずることなく独自の軌跡で発展させ得るよう構造化される。これは明示的な招待である：コミュニティメンバーがカメラブロックの方向性をシンセサイザーブロックの方向性より魅力的と感じる場合、アーキテクチャは彼らの専門化を支持する。数列変調パイプラインプロセッサと WPMS 合成コアは、AXI インターフェース契約以上にはカメラブロックの特定の挙動に依存しない。

Detailed camera-block specification: Deferred to a separate optional chapter to be drafted after the required-subset chapters are complete.

詳細カメラブロック仕様： 必須サブセットの章が完了した後に起草される、別個のオプション章に委ねる。

1.10 What is NOT in this Layer 1 Document / 本第1層文書に含まれないもの

To make the boundary unambiguous:

境界を曖昧でなくするために：

• HPS / ARM software. No Linux, bootloader, device tree, or HPS firmware. Should the SD card boot the HPS, the HPS must be held in reset or be running an idle loop. / HPS / ARM ソフトウェア。Linux、ブートローダ、デバイスツリー、HPS ファームウェアなし。SD カードが HPS をブートする場合、HPS はリセット保持されるか、アイドルループを実行していなければならない。
• MIDI input. No MIDI parsing, no MIDI controller support. Parameter input is via DIP/buttons, ISSP, ISMCE, or (optionally) camera only. / MIDI 入力。MIDI 解析なし、MIDI コントローラサポートなし。パラメータ入力は DIP/ボタン、ISSP、ISMCE、または（オプションで）カメラのみを介する。
• OSC, Ethernet, USB. No network connectivity. The DE10-nano's Ethernet PHY and USB OTG ports are unused in this specification. / OSC、Ethernet、USB。ネットワーク接続性なし。DE10-nano の Ethernet PHY と USB OTG ポートは本仕様で未使用である。
• Reverberation, perceptual masking, MP3-class processing. All of these are anticipated future features of the FPGA Spectrum Engine but are out of scope for the WPMS Synthesizer. / 残響、知覚マスキング、MP3 クラス処理。これらはすべて FPGA Spectrum Engine の予期される将来機能だが、WPMS シンセサイザーのスコープ外である。
• SDFT analysis, fractal synthesis. Out of scope for this synthesizer. Architectural compatibility with future addition is preserved (e.g., the AXI input switch, the parameterized module count, the general-purpose sequence-modulation processor) but no SDFT or fractal logic is built. / SDFT 分析、フラクタル合成。本シンセサイザーのスコープ外である。将来追加とのアーキテクチャ的互換性は保持される（AXI 入力スイッチ、パラメータ化されたモジュール数、汎用数列変調プロセッサなど）が、SDFT またはフラクタルロジックは構築されない。
• Polyphony in the conventional sense. WPMS treats the entire bin space as a single wave packet, not as a collection of independent "voices." There is one packet at any moment, parameterized by the nine scalars. Multi-packet superposition (e.g., a chord built from multiple WPMS packets) requires either time-multiplexing or further architectural extension and is out of scope here. / 従来的意味でのポリフォニー。WPMS はビン空間全体を独立した「ボイス」の集合ではなく、単一の波束として扱う。任意の時点で 1 つの波束があり、9 個のスカラーでパラメータ化される。マルチパケット重ね合わせ（複数 WPMS 波束で構築される和音など）は時分割多重化または追加のアーキテクチャ拡張を要求し、本仕様のスコープ外である。

1.11 Validation Origin / 検証起点

The first regression test. The KEY[1] test-origin restore loads:

最初のリグレッションテスト。 KEY[1] テスト原点復元は以下をロードする：

α = β = γ = δφ = ψ = 0
f₀ = configuration default (proposed: 996 Hz to match the 2020 prototype)
Δf = configuration default (proposed: 1/256 Hz to match the 2020 prototype)
A₀ = 0.97 × full scale (matching the 2020 prototype)
φ₀ = 0
N = 2,048

This produces, by construction, a Dirichlet kernel whose audible result matches the 2020 prototype recording. A WPMS Synthesizer implementation is considered to have passed its first regression test when its KEY[1] output matches the 2020 prototype waveform within the precision dictated by the chosen output bit-width.

これは構造上、その可聴結果が 2020 年プロトタイプ録音に一致する Dirichlet カーネルを生成する。WPMS シンセサイザー実装は、その KEY[1] 出力が、選定された出力ビット幅により規定される精度内で 2020 年プロトタイプ波形に一致した時、最初のリグレッションテストを通過したとみなされる。

This single test exercises every critical subsystem simultaneously: bin-parameter generation (uniform progression), Maclaurin computation (correct sin values across 2,048 phases), summation tree (no overflow, no precision loss), HDMI audio path (correct sample rate and format), and DIP/key handling (correct loading of the test-origin parameters). Any defect anywhere in the synthesizer manifests as a deviation in the Dirichlet kernel waveform.

この単一テストはすべての重要なサブシステムを同時に行使する：ビンパラメータ生成（一様な進行）、マクローリン計算（2,048 位相にわたる正しい sin 値）、総和ツリー（オーバーフローなし、精度損失なし）、HDMI オーディオパス（正しいサンプルレートと形式）、DIP/キー処理（テスト原点パラメータの正しいロード）。シンセサイザーのどこかにある欠陥はすべて、Dirichlet カーネル波形における偏差として現れる。

The diagnostic strength of this test mirrors the "First Sound" coherence test of the original C5G prototype: the boring uniform output is paradoxically the strongest possible test signal, because any error anywhere produces immediate decoherence visible in the waveform.

このテストの診断強度はオリジナル C5G プロトタイプの「First Sound」コヒーレンステストを反映する：退屈な一様出力は逆説的に可能な限り最強のテスト信号である。どこかの任意のエラーが、波形に見える即時のデコヒーレンスを生み出すからである。

1.12 Open Questions Carried Forward to Subsequent Chapters / 後続章へ持ち越される未解決問題

The following are deliberately left unresolved in this chapter and will be addressed in subsequent chapters of this Layer 1 specification:

以下は意図的に本章で未解決のまま残され、本第1層仕様の後続章で扱われる：

Question	Deferred to
Pipeline depth, retiming strategy, DSP-block placement strategy for the Maclaurin core / マクローリンコアのパイプライン深度、リタイミング戦略、DSP ブロック配置戦略	Chapter 2 / 第 2 章
Bit widths for the nine scalar parameters and N / 9 個のスカラーパラメータと N のビット幅	Chapter 3 / 第 3 章
Instruction set and register architecture of the sequence-modulation pipeline processor / 数列変調パイプラインプロセッサの命令セットとレジスタアーキテクチャ	Chapter 3 / 第 3 章
Choice of MiSTer-ecosystem HDMI core and integration details / MiSTer エコシステム HDMI コアの選定と統合詳細	Chapter 4 / 第 4 章
AXI input switch protocol and register map / AXI 入力スイッチプロトコルとレジスタマップ	Chapter 5 / 第 5 章
Camera-block frame-aggregator details, mapping template specification / カメラブロックフレーム集計器詳細、マッピングテンプレート仕様	Optional camera chapter / オプションカメラ章
Reference-implementation HDL, build flow, .rbf packaging / リファレンス実装 HDL、ビルドフロー、.rbf パッケージング	Layer 3, separate document / 第 3 層、別文書

1.13 Summary of Chapter 1 Decisions / 第 1 章決定事項のまとめ

ID	Decision	Status
C1-D1	Target platform: DE10-nano (Cyclone V SoC), FPGA fabric only, HPS unused / 対象プラットフォーム：DE10-nano（Cyclone V SoC）、FPGA ファブリックのみ、HPS 未使用	Fixed / 確定
C1-D2	Audio output: HDMI audio at 48 kHz / 24-bit, MiSTer-ecosystem core / オーディオ出力：HDMI オーディオ 48 kHz / 24-bit、MiSTer エコシステムコア	Fixed / 確定
C1-D3	Synthesis method: WPMS only, nine-scalar-plus-N parameter space / 合成方式：WPMS のみ、9 スカラー + N のパラメータ空間	Fixed / 確定
C1-D4	Bin count and module configuration: Tie. Compact (2 × 2,048), Standard (5 × 2,048), Extended (10 × 2,048) all in Implementation Arena / ビン数とモジュール構成：引き分け。Compact、Standard、Extended すべてを Implementation Arena に保持	Tie / 引き分け
C1-D5	Reference implementation: Compact configuration first / リファレンス実装：Compact 構成を最初に	Convention, not commitment / 慣行であり、コミットメントではない
C1-D6	Maclaurin pipeline: 11th-order, 40-bit trig, 24-bit amplitude (Compact) / マクローリンパイプライン：11 次、40-bit 三角関数、24-bit 振幅（Compact）	Fixed for Compact / Compact について確定
C1-D7	Sequence-modulation processor: difference-engine structure, general-purpose AXI interface, designed for carry-forward to subsequent FPGA Spectrum Engine phases / 数列変調プロセッサ：差分エンジン構造、汎用 AXI インターフェース、後続 FPGA Spectrum Engine フェーズへの持ち越し設計	Fixed / 確定
C1-D8	Required input: DIP + buttons, ISSP, ISMCE / 必須入力：DIP + ボタン、ISSP、ISMCE	Fixed / 確定
C1-D9	Optional input: OV7670 camera via GPIO, behind AXI input switch, Spin-Off-Ready / オプション入力：GPIO 経由 OV7670 カメラ、AXI 入力スイッチの背後、Spin-Off-Ready	Optional, structurally enabled / オプション、構造的に有効化
C1-D10	Validation origin: Dirichlet kernel via KEY[1] test-origin restore / 検証起点：KEY[1] テスト原点復元による Dirichlet カーネル	Fixed / 確定

End of Chapter 1 / 第 1 章の末尾

Code is ephemeral; the knowledge architecture is the commons. コードは一時的なものであり、知識アーキテクチャこそが共有財産である。

The shortest path from a repository to a sound is the foundation on which longer paths are built. リポジトリから音への最短経路は、より長い経路がその上に構築される基礎である。

This chapter is released into the public domain under CC0 1.0 Universal. Subsequent chapters (Chapter 2: Maclaurin Pipeline Specification, Chapter 3: Sequence-Modulation Pipeline Processor, Chapter 4: HDMI Audio Path, Chapter 5: AXI Input Switch, Optional Camera Chapter) will be drafted in subsequent dialogues.

本章は CC0 1.0 Universal のもとパブリックドメインに公開される。後続の章（第 2 章：マクローリンパイプライン仕様、第 3 章：数列変調パイプラインプロセッサ、第 4 章：HDMI オーディオパス、第 5 章：AXI 入力スイッチ、オプションのカメラ章）は後続の対話で起草される。

---

Chapter 1: Scope and Boundary Conditions [Part 1 of 2]

WPMS シンセサイザー — 第1層仕様書

第1章：スコープと境界条件

License: CC0 1.0 Universal (Public Domain) This is the architectural specification for a Wave Packet Modulation Synthesis (WPMS) synthesizer implementing the FPGA physical layer of the FPGA Spectrum Engine in standalone form. Read it, redistribute it, build on it, regenerate from it.
ライセンス：CC0 1.0 Universal（パブリックドメイン） これは波束変調合成 (WPMS) シンセサイザーのアーキテクチャ仕様書であり、FPGA Spectrum Engine の FPGA 物理層を単独形態で実装するものである。読み、再配布し、その上に構築し、再生成してよい。

1.1 Purpose of this Synthesizer / 本シンセサイザーの目的

The WPMS Synthesizer is a standalone FPGA implementation that produces audible output from a single FPGA device, using only the physical layer of the FPGA Spectrum Engine three-layer architecture (FPGA physical layer / ARM intermediate layer / PC abstraction layer). Neither the ARM intermediate layer (running on the Cyclone V SoC's HPS) nor the PC abstraction layer (Max/MSP, OSC servers, Ableton Live integration) is present or required.

WPMS シンセサイザーは、FPGA Spectrum Engine の3層アーキテクチャ（FPGA 物理層／ARM 中間層／PC 抽象層）のうち、物理層のみを用いて、単一の FPGA デバイスから可聴出力を得る単独実装である。ARM 中間層（Cyclone V SoC の HPS 上で動作する）も、PC 抽象層（Max/MSP、OSC サーバ、Ableton Live 連携）も存在せず、要求されない。

Three concrete intentions drive this scope:

このスコープは三つの具体的な意図によって駆動されている：

Intention 1 — Earliest possible audible output. The WPMS Synthesizer is the first deliverable in the FPGA Spectrum Engine roadmap because it is the shortest path from "repository contents" to "sound coming out of a speaker." Readers of the Hackaday.io project should be able to write the provided .rbf to a DE10-nano, connect HDMI to a monitor, and hear sound — without any additional software, build environment, or ARM-side configuration.

意図1 — 可能な限り早期の可聴出力。 WPMS シンセサイザーは FPGA Spectrum Engine ロードマップにおける最初の成果物である。「リポジトリの内容」から「スピーカーから音が出る」までの最短経路だからである。Hackaday.io プロジェクトの読者は、提供される .rbf を DE10-nano に書き込み、HDMI をモニタに接続し、追加のソフトウェア、ビルド環境、ARM 側構成なしに音を聴けるようにすべきである。

Intention 2 — Reusable component foundation. Although the physical-layer-only architecture will be partially superseded when the ARM intermediate layer is introduced, the components built for the WPMS Synthesizer — the Maclaurin polynomial pipeline, the sequence-modulation pipeline processor, the HDMI audio output path, the AXI-abstracted input switch — are the same components that the full FPGA Spectrum Engine will use as its physical layer core. Nothing built here is throwaway; everything is foundational.

意図2 — 再利用可能な部品の基盤。 物理層単独アーキテクチャは ARM 中間層導入時に部分的に置き換えられるが、WPMS シンセサイザー用に構築される部品——マクローリン多項式パイプライン、数列変調パイプラインプロセッサ、HDMI オーディオ出力経路、AXI 抽象化入力スイッチ——は、完全な FPGA Spectrum Engine がその物理層の中核として用いる、まさに同じ部品である。ここで作られるものに使い捨ては一つもない。すべてが基礎的である。

Intention 3 — Validation of the Open Prompt regeneration loop. The WPMS Synthesizer is structurally simple enough that its Layer 1 specification, Layer 2 reasoning traces, and a sample Layer 3 implementation can be produced and verified at modest scale. This makes it the first real test of the Open Prompt premise: can an independent engineer, given Layers 1 and 2 plus an LLM collaborator, regenerate a working implementation? If the WPMS Synthesizer can be regenerated independently, the methodology is validated for the larger, more complex Spectrum Engine that follows.

意図3 — Open Prompt 再生成ループの検証。 WPMS シンセサイザーは構造的に十分単純であり、その第1層仕様、第2層推論軌跡、第3層サンプル実装を、控えめな規模で生産し検証できる。これは Open Prompt の前提に対する最初の実証となる：独立したエンジニアが第1層と第2層に LLM 協働者を加えて、動作する実装を再生成できるか。WPMS シンセサイザーが独立に再生成できるなら、方法論はその後に続くより大きく複雑な Spectrum Engine に対して妥当性が示されることになる。

1.2 Target Platform / 対象プラットフォーム

Hardware: Terasic DE10-nano (Cyclone V SoC, 5CSEBA6U23I7).

ハードウェア： Terasic DE10-nano（Cyclone V SoC、5CSEBA6U23I7）。

FPGA fabric usage: This specification uses only the FPGA fabric portion of the Cyclone V SoC. The HPS (ARM Cortex-A9 dual-core) is not used in this specification. No Linux, no bootloader, no HPS firmware is required to run the WPMS Synthesizer. The .rbf file alone, written via Quartus Programmer or via the SD-card boot path with HPS held in reset, is sufficient.

FPGA ファブリックの利用： 本仕様は Cyclone V SoC の FPGA ファブリック部分のみを使用する。HPS（ARM Cortex-A9 デュアルコア）は本仕様では使用しない。WPMS シンセサイザーの動作に Linux、ブートローダ、HPS ファームウェアは要求されない。Quartus Programmer 経由で書き込まれた .rbf ファイル単独、または HPS をリセット保持したまま SD カードブート経路で書き込まれた .rbf で十分である。

Why DE10-nano specifically:

なぜ DE10-nano なのか：

• The DE10-nano is the standard MiSTer project platform, giving the WPMS Synthesizer immediate ecosystem reach. / DE10-nano は MiSTer プロジェクトの標準プラットフォームであり、WPMS シンセサイザーは即座にそのエコシステムへの到達範囲を得る。
• HDMI audio output is supported by open-source MiSTer cores, eliminating the need for a custom DAC board. / HDMI オーディオ出力が MiSTer のオープンソースコアによりサポートされており、カスタム DAC ボードの必要性を排除する。
• The Cyclone V SoC fabric (~110K logic elements, 112 DSP blocks usable, 5,570 Kbit BRAM) is large enough to host the WPMS architecture and small enough to constrain implementer choices productively. / Cyclone V SoC ファブリック（約 110K 論理要素、利用可能な 112 個の DSP ブロック、5,570 Kbit の BRAM）は WPMS アーキテクチャを収容するのに十分大きく、実装者の選択を生産的に制約するのに十分小さい。
• The board is widely available at modest cost, ensuring readers can replicate the work. / 同ボードは控えめな価格で広く入手可能であり、読者が作業を再現可能であることを保証する。

Substitution policy: Other Cyclone V SoC boards (e.g., the Terasic C5G that hosts the original prototype) are acceptable substitutes provided their DSP block count, BRAM capacity, and HDMI output capability are equal to or greater than the DE10-nano's. Migration to larger Intel/Altera FPGAs (e.g., DE25-nano, Agilex-based boards) is anticipated but is outside the scope of this Layer 1 document.

代替方針： 他の Cyclone V SoC ボード（オリジナルプロトタイプをホストした Terasic C5G など）は、DSP ブロック数、BRAM 容量、HDMI 出力能力が DE10-nano と同等以上であれば代替可能である。より大きな Intel/Altera FPGA（DE25-nano、Agilex 系ボードなど）への移行は予期されているが、本第1層文書の範囲外である。

1.3 Audio Output / オーディオ出力

Output path: HDMI audio, embedded in the HDMI signal driven from the DE10-nano's HDMI transmitter. The audio is decoded by an external DAC inside the HDMI monitor, computer display, or HDMI audio extractor connected to the board's HDMI output. No analog audio output is provided by the DE10-nano itself, and adding one is not in scope.

出力経路： DE10-nano の HDMI 送信器から駆動される HDMI 信号に埋め込まれた HDMI オーディオ。オーディオはボードの HDMI 出力に接続された HDMI モニタ、コンピュータディスプレイ、または HDMI オーディオエクストラクタ内部の外部 DAC によりデコードされる。DE10-nano 自体はアナログオーディオ出力を提供しない、そしてその追加は本スコープ外である。

Sample rate: 48 kHz (one sample period = 20.833 µs).

サンプルレート： 48 kHz（1 サンプル期間 = 20.833 µs）。

Sample format: 24-bit signed PCM, two channels (L/R, content identical in monaural baseline).

サンプル形式： 24-bit 符号付き PCM、2 チャンネル（L/R、モノラル基準では内容同一）。

HDMI audio core selection: The HDMI audio path uses an open-source MiSTer-ecosystem HDMI core as its starting point. The exact core is left as an Implementation Arena choice, with the selection rationale and integration details to be recorded in the Layer 2 trace produced during implementation.

HDMI オーディオコアの選定： HDMI オーディオ経路はオープンソースの MiSTer エコシステム HDMI コアを起点とする。正確なコア選定は Implementation Arena の選択として残し、選定根拠と統合詳細は実装中に作成される第2層軌跡に記録する。

Why HDMI rather than dedicated I²S DAC:

なぜ専用 I²S DAC ではなく HDMI なのか：

• DE10-nano has no on-board audio DAC; HDMI is the only audio output without external hardware. / DE10-nano にはオンボードオーディオ DAC がない。HDMI は外部ハードウェアなしの唯一のオーディオ出力である。
• HDMI audio is bit-exact and clock-locked, removing concerns about DAC quality variability across listeners. / HDMI オーディオはビット正確かつクロックロックされており、聞き手間で DAC 品質がばらつく懸念を排除する。
• Reusing a MiSTer-ecosystem core gives the WPMS Synthesizer cultural and technical compatibility with that community from day one. / MiSTer エコシステムのコアを再利用することで、WPMS シンセサイザーは初日からそのコミュニティとの文化的・技術的互換性を得る。

1.4 Synthesis Method / 合成方式

Method: Wave Packet Modulation Synthesis (WPMS) only. Sideband fractal synthesis, additive synthesis with arbitrary per-bin parameters, and SDFT analysis are outside the scope of this Layer 1 document and are deferred to subsequent specifications.

方式： 波束変調合成 (WPMS) のみ。サイドバンドフラクタル合成、任意のビン別パラメータを持つ加算合成、SDFT 分析は本第1層文書の範囲外であり、後続の仕様に延期される。

Mathematical formulation: Each bin k ∈ {0, 1, ..., N−1} contributes a sinusoidal component whose frequency, amplitude, and phase are closed-form functions of k and a small set of scalar parameters:

数学的定式化： 各ビン k ∈ {0, 1, ..., N−1} は、その周波数、振幅、位相が k と少数のスカラーパラメータの閉形式関数となる正弦波成分を寄与する：

f_k = f₀ + k · Δf + α · k²
A_k = A₀ · exp(−β · k) · exp(−γ · (k − N/2)²)
φ_k = φ₀ + k · δφ + ψ · k²

Free parameters:

自由パラメータ：

Symbol	Meaning	Role
f₀	Fundamental (lowest bin) frequency	Center of the wave packet
Δf	Linear frequency spacing	Bin density
α	Quadratic frequency spread	Inharmonicity / chirp
A₀	Peak amplitude	Overall level
β	Exponential amplitude decay	Spectral tilt
γ	Gaussian amplitude weighting	Wave-packet smoothness
φ₀	Phase at k = 0	Global phase offset
δφ	Linear phase gradient	Group delay (time shift)
ψ	Quadratic phase coefficient	Linear chirp / pulse compression
N	Number of active bins	Wave packet sharpness / count

Total: nine scalar parameters plus one count parameter.

合計：9 個のスカラーパラメータと 1 個の数量パラメータ。

Phenomenological span of the parameter space:

パラメータ空間の現象学的広がり：

• All five modulation parameters at zero (α = β = γ = δφ = ψ = 0) and uniform amplitude → pure Dirichlet kernel; sharp metallic transient with sinc-shaped envelope. This is the test-origin configuration, which the 2020 prototype experiment validated. / 5 つの変調パラメータすべてが 0（α = β = γ = δφ = ψ = 0）かつ一様振幅 → 純粋な Dirichlet カーネル。sinc 状の包絡を持つ鋭い金属的な過渡音。これはテスト原点構成であり、2020 年プロトタイプ実験で検証済みである。
• Non-zero γ → Gaussian wave packet; smooth bell-like envelope. / 非ゼロ γ → ガウシアン波束。滑らかな鐘状包絡。
• Non-zero ψ → linear chirp pulse; radar-pulse-like swept tone. / 非ゼロ ψ → 線形チャープパルス。レーダーパルス状の掃引音。
• Small non-zero α → mildly stretched harmonic series; piano-like inharmonicity. / 小さな非ゼロ α → 弱く拡張された倍音列。ピアノ状のイナハーモニシティ。
• Non-zero δφ → group-delay-shifted packet; spatial / chorus-like effect. / 非ゼロ δφ → 群遅延シフトされた波束。空間的・コーラス状の効果。

Why WPMS rather than full additive:

なぜフル加算合成ではなく WPMS なのか：

• WPMS expresses each bin's parameters as a closed-form polynomial function of bin index k. No per-bin parameter memory is required — neither BRAM nor DPRAM. The pipeline stage that computes f_{k+1} from f_k uses a single accumulator and a small constant register set (the difference-engine structure named in Theme 4 of the 2026-04-18 reasoning trace, the Polynomial Bin-Sequence Pattern). / WPMS は各ビンのパラメータをビン番号 k の閉形式多項式関数として表現する。ビン別パラメータメモリは要求されない——BRAM も DPRAM も。f_k から f_{k+1} を計算するパイプライン段は、単一の累算器と小さな定数レジスタ群（2026-04-18 推論軌跡のテーマ 4 で命名された差分エンジン構造、多項式ビン系列パターン）を用いる。
• This makes WPMS the simplest possible implementation that exercises the full Maclaurin pipeline at audio rates with non-trivial frequency, amplitude, and phase dynamics. / これにより WPMS は、自明でない周波数・振幅・位相のダイナミクスを伴ってマクローリンパイプライン全体をオーディオレートで動作させる、可能な限り最も単純な実装となる。
• The mathematics generalizes: should fractal synthesis or arbitrary per-bin parameters be required later, the same pipeline accepts them by replacing the difference-engine output with a memory-fetched parameter vector. WPMS is the polynomial-difference case of a more general bin-parameter sourcing architecture. / 数学は一般化する：フラクタル合成や任意のビン別パラメータが後に要求される場合でも、差分エンジン出力をメモリ取得パラメータベクトルに置き換えることで、同じパイプラインがそれらを受け入れる。WPMS はより一般的なビンパラメータ供給アーキテクチャの多項式差分ケースである。

1.5 Bin Count and Module Configuration / ビン数とモジュール構成

Decision: Tie — multiple module configurations are kept in the Implementation Arena.

決定：引き分け — 複数のモジュール構成を Implementation Arena に保持する。

The Layer 1 specification recognizes three logically equivalent module configurations:

第1層仕様は、3 つの論理的に等価なモジュール構成を認める：

Configuration	Modules	Bins	Target Platform
Compact	2 modules × 2,048 bins	4,096	DE10-nano (this document's reference)
Standard	5 modules × 2,048 bins	10,240	C5G-equivalent on DE10-nano (subject to timing)
Extended	10 modules × 2,048 bins	20,480	DE25-nano or larger (anticipated, out of scope here)

Logical equivalence: At the source-level architecture, the three configurations differ only in the value of a single generate parameter that instantiates the module count. The Maclaurin pipeline, the sequence-modulation pipeline processor, the per-module bin allocation, and the summation tree structure are all parameterized to accept any value M ∈ {2, 5, 10, ...} at compile time.

論理的等価性： ソースレベルアーキテクチャにおいて、3 つの構成はモジュール数をインスタンス化する単一の generate パラメータの値においてのみ異なる。マクローリンパイプライン、数列変調パイプラインプロセッサ、モジュールごとのビン配分、総和ツリー構造はすべてパラメータ化されており、コンパイル時に任意の値 M ∈ {2, 5, 10, ...} を受け入れる。

Implementation reality is not the same as logical equivalence. As module count rises, implementation-level pressures emerge non-linearly:

実装現実は論理的等価性と同じではない。 モジュール数が上昇するにつれ、実装レベルの圧力が非線形に立ち現れる：

• Routing congestion as the summation tree fan-in grows / 総和ツリーのファンインが増大するにつれての配線輻輳
• Clock-tree skew across distributed pipeline stages / 分散パイプライン段にわたるクロックツリースキュー
• BRAM port contention if multiple modules access shared memory / 複数モジュールが共有メモリにアクセスする場合の BRAM ポート競合
• DSP block placement across the device's DSP columns / デバイスの DSP カラムにわたる DSP ブロック配置
• Fmax erosion as critical paths lengthen / クリティカルパスが長くなるにつれての Fmax の侵食

Each module-count threshold is a real engineering frontier. Crossing it typically requires implementation-level work — pipeline retiming, register replication, manual placement constraints, sometimes architectural refinements that raise the achievable Fmax. Such Fmax improvements can in turn unlock the next module-count tier, creating a recursive expansion path that is not predictable from the logical specification alone.

各モジュール数の閾値は本物の工学的前線である。 これを越えるには通常、実装レベルの作業——パイプラインリタイミング、レジスタ複製、手動配置制約、時にはアーキテクチャの洗練によって達成可能 Fmax を引き上げること——が要求される。そのような Fmax の改善は、今度は次のモジュール数階層を解錠し得る——論理仕様単独では予測不能な再帰的拡張経路を作り出す。

This phenomenon is one of the strongest reasons for the existence of Open Prompt as a methodology. The reasoning behind a specific Fmax breakthrough — what was tried, what failed, what timing reports said, what the decisive trade-off was — is precisely the kind of knowledge that does not survive in source code alone. It must be preserved as Layer 2 reasoning traces. A future implementer porting to DE25-nano three years from now should be able to load these traces into their LLM collaborator and recover not just the code but the judgment behind the code.

この現象は、方法論としての Open Prompt の存在理由の最も強いものの一つである。 特定の Fmax 突破の背後にある推論——何を試み、何が失敗し、タイミングレポートが何を言い、決定的なトレードオフが何だったか——は、まさにソースコード単独では生き残らない種類の知識である。それは第2層推論軌跡として保存されねばならない。3 年後に DE25-nano に移植する将来の実装者は、これらの軌跡を LLM 協働者にロードし、コードだけでなくコードの背後にある判断を回復できるべきである。

Reference implementation choice for Layer 3:

第3層リファレンス実装の選択：

The first reference implementation provided in Layer 3 will use the Compact configuration (2 modules, 4,096 bins). This is selected as the starting point for three reasons:

第3層で提供される最初のリファレンス実装は Compact 構成（2 モジュール、4,096 ビン） を用いる。これは 3 つの理由により出発点として選定される：

1. Compact has the highest probability of timing closure on DE10-nano on first attempt, ensuring the inaugural release works for all readers. / Compact は初回試行で DE10-nano 上でのタイミング収束確率が最も高く、最初のリリースがすべての読者で動作することを保証する。
2. Compact has comfortable DSP budget, allowing the 11th-order Maclaurin polynomial and 24-bit amplitude width to be retained. / Compact は快適な DSP 予算を持ち、11 次マクローリン多項式と 24 ビット振幅幅の維持を可能にする。
3. The progression Compact → Standard → Extended provides clear motivating boundaries for future Layer 2 reasoning traces, each documenting an Fmax-threshold breakthrough. / Compact → Standard → Extended の進展は、それぞれ Fmax 閾値突破を文書化する将来の第2層推論軌跡に対する、明確な動機付けの境界を提供する。

The Standard and Extended configurations are explicitly invited as community contributions. The bin-count choice itself is therefore a Tie Decision in the Implementation Arena, with the Compact starting point being a first-implementation convention rather than an architectural commitment.

Standard と Extended の構成はコミュニティ貢献として明示的に招待される。したがってビン数の選択そのものが Implementation Arena における引き分け判断であり、Compact 出発点はアーキテクチャ的コミットメントではなく最初の実装の慣行である。

1.6 Maclaurin Pipeline Configuration / マクローリンパイプライン構成

Polynomial degree: 11th-order Maclaurin expansion of sin(x), retained from the C5G prototype.

多項式次数： sin(x) の 11 次マクローリン展開、C5G プロトタイプから継承。

Internal bit widths (Compact-configuration reference):

内部ビット幅（Compact 構成基準）：

Stage	Width	Format
Trigonometric core	40 bits	signed fixed-point
Amplitude (level) multiplier	24 bits	unsigned fixed-point (Compact configuration retains C5G-era width)
Per-module summation accumulator	64 bits	signed fixed-point
Output to HDMI audio path	24 bits	signed PCM
Final decimal-point selector	6-bit shift	DIP-switch-controlled (3 DIP positions × 2 bits resolution)

The 11th-order / 24-bit retention is permitted by the Compact configuration's reduced module count: with only 2 modules instead of 5, DSP-block budget is comfortable on DE10-nano (2 modules × ~20 DSP ≈ 40 DSP for the iDFT/WPMS pipelines, with ~47 DSP remaining for the sequence-modulation processor, the HDMI core, and other subsystems).

11 次／24 ビットの維持は、Compact 構成の縮小されたモジュール数により許容される：5 モジュールではなく 2 モジュールのみで、DSP ブロック予算は DE10-nano 上で快適である（2 モジュール × 約 20 DSP ≈ 40 DSP が iDFT/WPMS パイプライン用、約 47 DSP が数列変調プロセッサ、HDMI コア、その他のサブシステム用に残る）。

For Standard and Extended configurations, polynomial degree and amplitude bit-width may be reduced (e.g., 7th-order Maclaurin and 16-bit amplitude) as discussed in the 2026-04-18 reasoning trace decision-point DP-9. Such trade-offs are recorded as Implementation Arena variants when they are realized.

Standard と Extended の構成では、2026-04-18 推論軌跡の決定点 DP-9 で議論されたように、多項式次数と振幅ビット幅は削減され得る（7 次マクローリンと 16 ビット振幅など）。そのようなトレードオフは、それらが実現される時点で Implementation Arena の変種として記録される。

Detailed pipeline architecture: Deferred to Chapter 2 (Maclaurin Pipeline Specification), to be drafted in subsequent dialogue.

詳細パイプラインアーキテクチャ： 第 2 章（マクローリンパイプライン仕様）に委ね、後続の対話で起草される。

Synthesis Paradigm Lineage — from Chowning's FM to Razor, and where this engine sits

Build Logs #1, #2, and #4 covered, respectively, the polynomial evaluation architecture, the 2020 prototype that proved the architecture works, and the Open Prompt paradigm under which this project is released. This log places the project on the timeline of digital sound synthesis itself.

The argument is short and, I think, defensible: every major synthesis paradigm of the last fifty years is a special case of "decide what frequency, amplitude, and phase to assign to each spectral bin, and sum the results." What changed across decades was not the underlying mathematics — it was which subset of bin patterns the available hardware could actually compute in real time, and which abstractions made those subsets composable for human composers.

The FPGA Spectrum Engine is what becomes possible when the hardware no longer has to choose a subset.

A note on this log

This log is the most opinionated of the four. It situates the project in a lineage; lineages are arguments. Where the technical Build Logs (#1, #2) were careful, and the philosophical one (#4) was deliberate, this one is interpretive. Reasonable engineers and historians will disagree with parts of it. That is appropriate.

The strong claim — that all these paradigms reduce to the same problem — is mine, not the field's consensus. I make it because I think it is true, and because making it explicit lets us see what the next paradigm looks like.

1973 — Chowning's FM and the side-band epiphany

In 1973, John Chowning at Stanford published "The Synthesis of Complex Audio Spectra by Means of Frequency Modulation." The mathematical heart of the paper is the trigonometric identity that converts a frequency-modulated carrier into a sum of side-bands:

sin(ωc·t + β·sin(ωm·t)) = Σ Jₙ(β) · sin((ωc + n·ωm)·t)

The right-hand side is a spectral description. It says: to make this FM tone, place sinusoidal bins at frequencies ωc + n·ωm with amplitudes Jₙ(β), the n-th Bessel function of the first kind evaluated at the modulation index β.

If you had hardware capable of placing arbitrary bins with arbitrary amplitudes in real time, FM synthesis would be one specific bin-placement recipe. But Chowning did not have that hardware. He had a single oscillator capable of sinusoidal output and a means of frequency-modulating it. The genius of FM was that a recursive trick on the time-domain side produced the spectral richness on the frequency-domain side, with hardware barely capable of one sine wave.

The Yamaha DX7 (1983) industrialized this trick. With six "operators" — six FM-capable oscillators arranged in 32 routing topologies ("algorithms") — the DX7 could produce a vast tone palette while consuming only modest hardware per voice. The reason the DX7 could not do everything an additive synthesizer could is not theoretical; it is that FM constrained which bin patterns it could reach. Bessel-function side-bands, scaled to whatever β you chose, with carrier-frequency ratios that produced predictable spectra. Beautiful, but constrained.

FM was always a special case of bin-direct addressing. It just happened to be the special case that fit on 1980s silicon.

Late 1970s — Synclavier and Kawai K5: additive synthesis for real

While FM was conquering the consumer keyboard market, a parallel lineage at the high end was implementing additive synthesis directly: place dozens, then hundreds of partials (bins, in our terminology) at integer multiples of a fundamental, give each its own envelope, sum the result.

The New England Digital Synclavier II (1980) and especially the Kawai K5 (1987) showed that additive synthesis was possible. The Kawai K5 offered 63 harmonics per source, with each harmonic assignable to one of four six-stage amplitude envelopes; in full mode it could address 126 harmonic components.

What additive synthesis could not yet do, in this period, was place bins anywhere except at integer multiples of a fundamental. The "harmonic" assumption was hard-coded into the user interface and often into the hardware data flow. If you wanted an inharmonic spectrum — a bell, a gong, a wood block — additive synthesis as offered by these instruments could not directly express it.

Inharmonic synthesis required either (a) physical modeling, which approximates an inharmonic resonator's behavior in the time domain, or (b) wavetable synthesis with carefully crafted single-cycle waveforms whose harmonic content was already inharmonic before resampling. Neither was bin-direct addressing in the modern sense.

Additive synthesis of this era was bin-direct addressing constrained to harmonic frequency lattices. The constraint was a UI and storage decision, not a mathematical necessity. Lift the constraint, and you have something more general.

1990s — Wavetable, vector, and granular: the bin-pattern era goes underground

The 1990s saw FM and additive synthesis fade from the cultural foreground while three related techniques rose:

Wavetable synthesis stored short samples (often single cycles) at multiple keys and crossfaded between them as pitch and modulation changed. Mathematically, a wavetable's harmonic spectrum is a bin pattern — but the synthesizer treated the wavetable as an opaque black box. The user interface said "select wavetable 47," not "place these bins at these frequencies with these amplitudes." The bin-direct nature of what was happening was hidden.

Vector synthesis (Korg Wavestation, Sequential Prophet VS) blended four wavetables in two-dimensional space. Spectrally, this is interpolation among four bin patterns. Again, the underlying bin-direct structure was true but invisible to the user.

Granular synthesis (Roads, Truax, then Native Instruments Reaktor) chopped sound sources into 1–100 ms grains and recomposed them. Each grain has a spectrum. The aggregate sound is a time-varying superposition of grain spectra. This is, in effect, bin-direct addressing where the bins are themselves complex (each "bin" is a grain rather than a single sinusoid), and the addressing is statistical rather than deterministic.

These techniques were enormously productive for sound designers and composers. They were not, however, presented or understood as instances of a unified bin-pattern paradigm. The mathematics was hidden behind very different user-interface metaphors: "select waveform," "blend joystick," "scatter grains." Each metaphor felt like its own discipline.

The 1990s confirmed empirically that bin patterns are powerful, while obscuring theoretically that bin patterns are what was happening.

2011 — Native Instruments Razor: the bin paradigm comes back to the surface

In 2011, Errorsmith and Native Instruments released Razor, an additive synthesizer built in Reaktor whose explicit user interface was bin-direct.

Razor's interface displayed up to 320 partials as a real-time spectral view. The user manipulated bin frequencies, amplitudes, and animations directly. Many of Razor's signature presets are unmistakably inharmonic — bell-like, metallic, glitchy textures whose bin lattices are not simple integer multiples of a fundamental.

Razor was widely received as a breakthrough not because the mathematics was new — it had been known for decades — but because the user interface finally made bin-direct addressing the primary metaphor rather than hiding it under a "patch" or "wavetable" or "grain" abstraction. Composers who had grown up with FM synthesis found themselves doing things they could not articulate in FM terms, because they were no longer constrained to FM's slice of bin-pattern space.

Razor proved the interface case for bin-direct addressing. What it did not (and could not) prove was the hardware case at scale. Razor runs on a CPU, with 320 partials per voice as its limit. That is a remarkable number for software additive synthesis, but it is several orders of magnitude below what a spectral analysis of, say, a piano string or a marimba bar would require for full reconstruction.

Razor showed that bin-direct addressing wins when given a fair UI. The remaining question was: what happens when given fair hardware?

2010s onward — The geometric synthesis quiet revival

Polygonal synthesis (and its Bessel-coefficient generalization). A small literature explored what happens when a wave is generated by a "rolling polygon" — a virtual rotating shape whose vertex count and rotation speed determine the spectrum. The mathematics turns out to involve Bessel functions in ways that connect directly back to FM. Polygonal synthesis is, in effect, FM with a more general modulator structure, producing harmonic-stack sidebands that are themselves Bessel-weighted.

These are recognizably bin-direct paradigms. These have remained largely academic or boutique because the hardware required to render them at full spectral resolution in real time — thousands of independent oscillators with sub-Hz frequency resolution — has not been routinely available.

Where the FPGA Spectrum Engine sits on this timeline

The FPGA Spectrum Engine described in this project is, by deliberate design, the first general-purpose hardware that can realize all the above paradigms simultaneously and at scale.

10,240 oscillators, each with 0.001 Hz frequency resolution, each with independently programmable amplitude and phase, summed coherently with one-sample latency at 48 kHz. The architecture is bin-direct in the most uncompromising sense: there is no built-in assumption about what the bins should do. The user — or, more often, an upstream layer of abstraction — chooses.

What this means concretely:

FM synthesis on the engine is the bin pattern frequencies = [ωc ± n·ωm], amplitudes = [Jₙ(β)]. To play a DX7 patch, compute its sideband spectrum and write the bins. Done.

Additive synthesis is the bin pattern frequencies = [k·f₀], amplitudes = [aₖ]. To play an additive patch, write integer-multiple frequencies with arbitrary amplitudes. Done.

Polygonal/Bessel synthesis is the bin pattern with frequencies at [(kN+1)·ω₀ - n·ωₘ] and amplitudes weighted by cₖ(N)·Jₙ(kNβ) — the Bessel-coefficient generalization. Done.

Wavetable is the bin pattern obtained by FFT'ing the wavetable's single cycle and writing the resulting harmonic spectrum. Done.

Spectral fractal is the bin pattern at Cantor-set positions or 1/fᵅ-spaced frequencies. Done.

Shepard tones, physical models in their spectral form, granular average spectra, raw measured spectra of acoustic instruments — all done by writing the corresponding bin pattern.

The engine is universal in the precise sense that there is no synthesis technique known to me that cannot be expressed as a bin pattern and rendered on this hardware. The constraint that previously defined which technique fit on which hardware — the constraint that gave the field its century-long sequence of "paradigms" — is dissolved.

What changes when the hardware constraint is lifted

The history above can be retold compactly: every "paradigm" of synthesis was a clever way to project the universal bin-pattern problem onto whatever subset of hardware was available. FM projected it onto one oscillator with frequency modulation. Additive projected it onto a harmonic lattice with envelope generators. Wavetable projected it onto stored single cycles. Each projection had a name, a vocabulary, a set of canonical patches, a culture.

When the projection is no longer needed, the question changes. It is no longer "which paradigm should I use?" The question becomes "what bin pattern do I want?" The answer to that question is no longer constrained by what fits on the silicon; it is constrained only by what the human composer or the upstream algorithm can articulate.

This is the shift the FPGA Spectrum Engine is designed to make available. The engine itself is universal. The interesting work moves upstream, into the abstraction layers that decide bin patterns. The PC-layer language, the ARM-HPS scene expander, the bin-pattern generators — these are where the new compositional vocabulary will be invented.

Coupling to Build Log #4 — why this matters for Open Prompt

If the engine is the first hardware to lift the projection constraint, what happens to its design knowledge becomes consequential. Past synthesis paradigms — FM, wavetable, vector — were each developed inside specific commercial firms. Their internal know-how was largely lost or proprietary. Yamaha did not publish how the DX7's algorithm tree was implemented at the gate level, and no one needed to ask, because by the time the question was interesting, the cultural moment of FM had already passed.

The FPGA Spectrum Engine is being released differently. The architecture, the reasoning behind it, and the sample implementations are being put into the public commons via the Open Prompt three-layer scheme described in Build Log #4. This means: any engineer with a capable language model collaborator can regenerate this engine on any reasonable FPGA platform, at any time, and the design space remains open for their innovations rather than closed by my specific implementation choices.

The reason this matters is that the engine's value is not in its current implementation; it is in the bin-pattern compositional vocabularies that will grow on top of it. Those vocabularies are most likely to flourish if the underlying engine is broadly accessible and broadly understood. Open Prompt is the distribution mechanism that makes that broad accessibility structurally inevitable rather than merely intended.

In other words: the technical lineage and the distribution paradigm are the same project, viewed from different angles. The engine is what becomes possible when the bin-pattern problem is given fair hardware. Open Prompt is what becomes possible when an engineering project is given fair distribution in the LLM era. Both are removals of constraints that history had treated as natural.

What I am looking forward to

If this argument is correct, the next decade of synthesis will be defined less by new "paradigms" — there are no new paradigms once bin-direct universality is reached — and more by new compositional vocabularies built on top of the universal engine. What does it sound like to compose with bin-pattern algebras directly? With evolutionary algorithms over bin distributions? With machine-learning-discovered bin patterns optimized for perceptual properties humans had no language for?

I do not know. I expect to be surprised. The point of releasing the engine as Open Prompt is to make sure I am not the only one who gets to find out.

Coming next

This log closes the initial four-Build-Log series. Future Build Logs will follow specific developments:

• DE10-nano port progress, GbE protocol, and 10,240-bin verification
• Open Prompt repository maintenance and the evolving Layer 2 archive
• Bin-pattern composition language and the PC-layer abstraction
• iDFT/SDFT mixed-mode operation for active sensing applications (haptic, material identification, tactile robotics)
• STEAM education curriculum design built on the engine

Companion interactive page: https://dsohnaka.github.io/FPGA_Spectrum_Engine/ Open Prompt repository: https://github.com/dsohnaka/FPGA_Spectrum_Engine_OpenPrompt

---

▼ Build Log 本文（日本語版・併記用）

合成パラダイムの系譜 — Chowning の FM から Razor へ、そして本エンジンの位置

Build Log #1、#2、#4 はそれぞれ、多項式評価アーキテクチャ、アーキテクチャの動作を実証した 2020 年プロトタイプ、本プロジェクトが公開される Open Prompt パラダイム、を扱った。本ログはこのプロジェクトを、デジタル音響合成そのもののタイムライン上に位置づける。

主張は短く、私の考えでは擁護可能である：過去 50 年間の主要な合成パラダイムはすべて、「各スペクトルビンにどの周波数・振幅・位相を割り当て、結果を総和するか」という問題の特殊ケースである。 数十年にわたって変わってきたのは根底の数学ではなく——利用可能なハードウェアが実時間で計算できるビンパターンの部分集合がどれであり、それらの部分集合を人間の作曲家にとって組み合わせ可能にする抽象化がどれであったか、である。

FPGA Spectrum Engine は、ハードウェアがもはや部分集合を選ぶ必要がなくなった時に何が可能になるか、である。

1973年 — Chowning の FM と側波帯の啓示

1973年、Stanford の John Chowning は "The Synthesis of Complex Audio Spectra by Means of Frequency Modulation"（周波数変調による複合音響スペクトルの合成）を発表した。論文の数学的核心は、周波数変調されたキャリアを側波帯の総和に変換する三角関数恒等式である：

sin(ωc·t + β·sin(ωm·t)) = Σ Jₙ(β) · sin((ωc + n·ωm)·t)

右辺はスペクトル記述である。これが告げているのは：この FM 音を作るには、周波数 ωc + n·ωm に振幅 Jₙ(β)（変調指数 β で評価された第一種ベッセル関数の n 次）でビンを配置せよ、ということ。

任意のビンを任意の振幅で実時間配置可能なハードウェアがあれば、FM 合成は一つの具体的なビン配置レシピである。だが Chowning にはそのハードウェアはなかった。彼にあったのは、正弦波出力可能な単一オシレータと、それを周波数変調する手段だった。FM の天才は、時間領域側の再帰的トリックが周波数領域側のスペクトル豊かさを生み出す——一つの正弦波がやっとのハードウェアで——という点にあった。

Yamaha DX7（1983年）はこのトリックを工業化した。6 つの「オペレータ」により、DX7 はボイスあたり控えめなハードウェアしか消費せずに広大な音色パレットを生み出せた。DX7 が加算合成器のすべてを行えなかった理由は理論的なものではない；FM が到達できるビンパターンを制約していたからである。選んだ任意の β にスケールされたベッセル関数側波帯、予測可能なスペクトルを生む搬送周波数比。美しいが、制約されていた。

FM は常にビン直接アドレスの特殊ケースだった。 それがたまたま 1980 年代のシリコンに収まる特殊ケースだったというだけである。

1970 年代後半 — Synclavier と Kawai K5：本物の加算合成

FM が消費者向けキーボード市場を制覇しつつあった一方で、ハイエンドの並行系譜が加算合成を直接実装していた：数十、次いで数百のパーシャル（私たちの用語ではビン）を基音の整数倍に配置し、各々に独自のエンベロープを与え、結果を総和する。

New England Digital の Synclavier II（1980年）と、特に Kawai K5（1987年）は、加算合成が可能であることを示した。K5 は、1 source あたり 63 harmonics を持ち、各 harmonic を 4 つの 6-stage 振幅エンベロープのいずれかに割り当てる方式だった。full mode では 126 harmonics を扱えた。

この時期の加算合成にまだできなかったのは、基音の整数倍以外の場所にビンを配置することだった。「調波」前提がユーザーインターフェースに、しばしばハードウェアのデータフローに、ハードコードされていた。鐘、ゴング、ウッドブロックのような非調波スペクトルが欲しい場合、これらの楽器が提供する加算合成は直接にはそれを表現できなかった。

非調波合成には (a) 物理モデリング——非調波共振器の挙動を時間領域で近似する——か、(b) ウェーブテーブル合成——リサンプリング前にすでに調波内容が非調波であるよう注意深く作られた単一周期波形を持つ——のいずれかが必要だった。どちらも現代的な意味でのビン直接アドレスではなかった。

この時代の加算合成は、調波周波数格子に制約されたビン直接アドレスだった。 その制約は UI とストレージの決定であり、数学的必然ではなかった。制約を取り除けば、より一般的なものになる。

1990 年代 — ウェーブテーブル、ベクター、グラニュラー：ビンパターン時代の地下化

1990 年代、FM と加算合成は文化的前景から退き、3 つの関連技術が興隆した：

ウェーブテーブル合成は、複数の鍵に短いサンプル（多くは単一周期）を保存し、ピッチと変調が変わるにつれてそれらをクロスフェードした。数学的には、ウェーブテーブルの調波スペクトルはビンパターンである——だがシンセサイザーはウェーブテーブルを不透明なブラックボックスとして扱った。ユーザーインターフェースは「ウェーブテーブル 47 を選択」と言い、「これらの周波数にこれらの振幅でビンを配置」とは言わなかった。起こっていたことのビン直接性は隠されていた。

ベクター合成（Korg Wavestation、Sequential Prophet VS）は、4 つのウェーブテーブルを 2 次元空間でブレンドした。スペクトル的には、これは 4 つのビンパターン間の補間である。再び、根底のビン直接構造は真であったが、ユーザーには不可視だった。

グラニュラー合成（Roads、Truax、その後 Native Instruments Reaktor）は音源を 1–100 ms の粒に切り分け、再構成した。各粒はスペクトルを持つ。集約音は粒スペクトルの時変重ね合わせである。これは事実上、ビン自体が複雑（各「ビン」は単一正弦波ではなく粒）であり、アドレス指定が決定論的ではなく統計的であるビン直接アドレスである。

これらの技術は音響デザイナーと作曲家にとって膨大に生産的だった。だがそれらは、統一されたビンパターンパラダイムの実例として提示も理解もされなかった。数学はきわめて異なるユーザーインターフェース・メタファーの背後に隠されていた：「波形を選択」「ジョイスティックでブレンド」「粒を散布」。各メタファーは独自の規律のように感じられた。

1990 年代はビンパターンが強力であることを経験的に確認したが、ビンパターンが起こっていたことであることを理論的には不明瞭にした。

2011年 — Native Instruments Razor：ビン・パラダイムが地表に戻る

2011年、Errorsmith と Native Instruments は Razor をリリースした——Reaktor 上に構築された加算合成器で、その明示的なユーザーインターフェースはビン直接だった。

Razor のインターフェースは最大 320 のパーシャルをリアルタイム・スペクトルビューとして表示した。ユーザーはビンの周波数、振幅、アニメーションを直接操作した。Razor の特徴的なプリセットの多くは紛れもなく非調波である——鐘のような、金属的な、グリッチ風のテクスチャ——そのビン格子は基音の単純な整数倍ではない。

Razor が広く画期と受け取られたのは、数学が新しかったからではない——それは数十年前から知られていた——FM 時代から続く「パッチ」「ウェーブテーブル」「グレイン」抽象の下に隠すのではなく、ユーザーインターフェースがついにビン直接アドレスを主要メタファーとしたからである。FM 合成と共に育った作曲家は、自分が FM 用語では明確化できないことをしている自分に気づいた——彼らはもはや FM のビンパターン空間の薄切りに制約されていなかったからである。

Razor はビン直接アドレスのインターフェース論を実証した。実証しなかった（できなかった）のは、スケールにおけるハードウェア論である。Razor は CPU 上で動作し、ボイスあたり 320 パーシャルが上限である。ソフトウェア加算合成としては顕著な数だが、たとえばピアノ弦やマリンバ・バーのスペクトル解析が完全再構築のために要求するレベルからは数桁低い。

Razor は、公正な UI を与えられればビン直接アドレスが勝つことを示した。残された問いは：公正なハードウェアを与えられたら何が起こるか、だった。

2010 年代以降 — 幾何合成の静かな復興

ポリゴナル合成（とそのベッセル係数一般化）。小規模な文献が、波が「回転するポリゴン」——頂点数と回転速度がスペクトルを決定する仮想的な回転形——によって生成された場合に何が起こるかを探究した。数学は FM に直接戻る仕方でベッセル関数を含むことが判明する。ポリゴナル合成は事実上、より一般的な変調器構造を持つ FM であり、それ自体がベッセル重みを持つ調波スタック側波帯を生み出す。

これらはビン直接パラダイムとして認識可能である。これらはおおむね学術的またはブティック的にとどまってきた——なぜなら、それらをフルスペクトル分解能で実時間レンダリングするのに必要なハードウェア——サブ Hz 周波数分解能を持つ数千の独立オシレータ——が日常的には利用可能でなかったから。

FPGA Spectrum Engine の系譜上の位置

本プロジェクトに記述される FPGA Spectrum Engine は、意図的設計により、上記すべてのパラダイムを同時にスケールで実現できる最初の汎用ハードウェアである。

10,240 オシレータ、各々 0.001 Hz 周波数分解能、各々独立にプログラム可能な振幅と位相、48 kHz で 1 サンプル遅延でコヒーレントに総和される。アーキテクチャは最も妥協のない意味でビン直接である：ビンが何をすべきかについての組み込み前提は存在しない。ユーザー——あるいは、より頻繁には上流の抽象層——が選ぶ。

これが具体的に意味するもの：

エンジン上の FM 合成はビンパターン 周波数 = [ωc ± n·ωm], 振幅 = [Jₙ(β)]。DX7 パッチを再生するには、その側波帯スペクトルを計算してビンに書き込む。完了。

加算合成はビンパターン 周波数 = [k·f₀], 振幅 = [aₖ]。加算パッチを再生するには、整数倍周波数を任意の振幅で書き込む。完了。

ポリゴナル/ベッセル合成は、周波数 [(kN+1)·ω₀ - n·ωₘ]、cₖ(N)·Jₙ(kNβ) で重み付けされた振幅——ベッセル係数一般化——のビンパターン。完了。

ウェーブテーブルは、ウェーブテーブルの単一周期を FFT して得られる調波スペクトルを書き込んだビンパターン。完了。

スペクトラル・フラクタルは、Cantor 集合位置あるいは 1/fᵅ 間隔周波数のビンパターン。完了。

Shepard トーン、スペクトル形式の物理モデル、グラニュラーの平均スペクトル、音響楽器の生計測スペクトル——すべて対応するビンパターンを書き込むことで完了する。

このエンジンは正確な意味で普遍的である：ビンパターンとして表現できず本ハードウェア上にレンダリングできない既知の合成技術は、私の知る限り、存在しない。以前にどの技術がどのハードウェアに収まるかを決めていた制約——分野に世紀規模の「パラダイム」連続を与えていた制約——は解消される。

ハードウェア制約が取り除かれると何が変わるか

上記の歴史は簡潔に再話できる：合成のあらゆる「パラダイム」は、利用可能なハードウェアの部分集合に普遍ビンパターン問題を投影する巧妙な方法だった。FM はそれを 1 つのオシレータと周波数変調に投影した。加算はそれを調波格子とエンベロープジェネレータに投影した。ウェーブテーブルはそれを保存された単一周期に投影した。各投影は名前、語彙、正典的パッチ集合、文化を持っていた。

投影がもはや必要ないとき、問いが変わる。もはや「どのパラダイムを使うか」ではない。問いは「どのビンパターンが欲しいか」になる。 その問いへの答えはもはやシリコンに収まるものに制約されない；制約するのは、人間の作曲家か上流のアルゴリズムが明確化できることのみである。

これが FPGA Spectrum Engine が利用可能にすべく設計されたシフトである。エンジン自体は普遍的である。興味深い仕事は上流に移る——ビンパターンを決める抽象層へ。PC 層の言語、ARM HPS のシーン展開器、ビンパターン生成器——これらが新しい作曲語彙が発明される場所である。

Build Log #4 との連結 — なぜこれが Open Prompt にとって重要か

このエンジンが投影制約を取り除く最初のハードウェアであるなら、その設計知識に何が起こるかは重要になる。過去の合成パラダイム——FM、ウェーブテーブル、ベクター——はそれぞれ特定の商業企業内で開発された。それらの社内ノウハウはおおむね失われたか専有的だった。Yamaha は DX7 のアルゴリズム木がゲートレベルでどう実装されたかを公表しなかった——そして誰もそれを尋ねる必要がなかった。問いが興味深くなる頃には、FM の文化的瞬間はすでに過ぎていたから。

FPGA Spectrum Engine は別様に公開されている。アーキテクチャ、その背後の推論、サンプル実装は、Build Log #4 で記述された Open Prompt の三層スキームによりパブリックコモンズに置かれている。これが意味するのは：有能な言語モデル協働者を持つ任意のエンジニアが、任意の合理的な FPGA プラットフォーム上で、任意の時点で、このエンジンを再生成でき、そして設計空間は私の特定の実装選択によって閉じられるのではなく、彼らの革新のために開かれたままである、ということ。

これが重要である理由は、エンジンの価値は現在の実装にあるのではなく、その上に成長するビンパターン的作曲語彙にあるからだ。それらの語彙は、根底のエンジンが広くアクセス可能で広く理解されている場合に最も繁茂する可能性が高い。Open Prompt はその広いアクセス可能性を、単に意図されたものではなく構造的に必然なものにする配布機構である。

換言すれば：技術的系譜と配布パラダイムは同じプロジェクトを異なる角度から見たものである。エンジンはビンパターン問題に公正なハードウェアが与えられた時に可能になるもの。Open Prompt は工学プロジェクトに LLM 時代の公正な配布が与えられた時に可能になるもの。両者とも、歴史が自然なものとして扱ってきた制約の除去である。

私が楽しみにしていること

この議論が正しければ、合成の次の十年は新しい「パラダイム」によってよりも——ビン直接の普遍性に達した後には新しいパラダイムは存在しない——普遍エンジンの上に構築される新しい作曲語彙によって、より少なく定義される。ビンパターン代数で直接作曲することはどう聞こえるか？ ビン分布上の進化的アルゴリズムでは？ 人間が言葉を持たなかった知覚的特性に最適化された機械学習発見ビンパターンでは？

私には分からない。驚くことを期待している。エンジンを Open Prompt として公開する目的は、見つけ出す者が私だけにならないようにするためである。

次回予告

本ログは初期の 4 Build Log シリーズを閉じる。今後の Build Log は具体的な発展を追う：

• DE10-nano 移植進展、GbE プロトコル、10,240 ビン検証
• Open Prompt リポジトリ保守と発展する Layer 2 アーカイブ
• ビンパターン作曲言語と PC 層抽象
• 能動センシング応用（触覚、材質識別、触覚ロボティクス）のための iDFT/SDFT 混合モード動作
• エンジン上に構築される STEAM 教育カリキュラム設計

Companion interactive page: https://dsohnaka.github.io/FPGA_Spectrum_Engine/ Open Prompt repository: https://github.com/dsohnaka/FPGA_Spectrum_Engine_OpenPrompt

Open Prompt — a knowledge-sharing paradigm for the LLM era

This is the log I have been pointing toward in every previous one.

The FPGA Spectrum Engine is being released under a knowledge-sharing scheme I call Open Prompt. This log is the formal declaration: what Open Prompt is, what it is not, why it exists, what it shares, and how others can adopt it for their own projects.

It is also, by necessity, a log about how engineering knowledge propagates in a world where capable engineers and capable language models collaborate as a matter of course. That world is already here. The question is whether our knowledge-sharing conventions have caught up with it.

Why a new paradigm is needed

For four decades, open source has been the dominant model for sharing engineering knowledge. It works by distributing source code under a license that permits — and structures — its reuse, modification, and redistribution. The code is the artifact. The license is the social contract. Forking, attribution, and copyleft are the operational mechanisms.

Open source is one of the most successful intellectual movements in modern history. Nothing here is meant to diminish it.

But open source was designed in a world where the source code was the bottleneck. Producing source code took human time measured in days, weeks, and years. Sharing it meant sharing the scarcest resource. The license structure exists because the artifact was hard-won.

That world is changing. In a world where a capable engineer with a capable language model can regenerate functional source code from an architectural description in hours, the source code is no longer the bottleneck. What was scarce becomes abundant. What was abundant — clarity of architecture, precision of reasoning, transparency of design intent — becomes scarce.

Open source distributes the abundant resource and licenses around its scarcity. We need a paradigm that distributes the scarce resource and lets the abundant one regenerate freely.

That paradigm is what I am calling Open Prompt.

What Open Prompt is

Open Prompt distributes engineering knowledge in three layers:

Layer 1 — Architectural Specification

The mathematics, the constraints, the structural decisions, the invariants. Written for a competent engineer to read directly. Sufficient — in combination with current language model capabilities — for that engineer to regenerate a working implementation.

For the FPGA Spectrum Engine, Layer 1 includes:

• The 11th-order Maclaurin truncation and its error bound
• The 3-layer hardware architecture (PC / ARM HPS / FPGA)
• The bin-direct addressing principle
• The iDFT/SDFT duality
• The synthesis paradigm unification (FM, additive, fractal, polygonal as bin patterns)

This layer is the commons. It is in the public domain. Anyone may read it, redistribute it, build on it, write derivative explanations of it, teach it.

Layer 2 — Reasoning Trace

The actual design conversations and decision logs that led from constraints to implementation. This layer is what is genuinely new in the LLM era.

Engineering decisions are rarely fully reconstructible from the specification alone. "Why this and not that" lives in the process of arriving at the specification. Historically, that process was lost — preserved only in scattered notebooks, mailing list threads, and the memories of the engineers involved.

In the LLM era, however, a substantial portion of engineering reasoning takes place as dialogue with language models. Those dialogues are literally exportable as text. They can be saved, versioned, shared, and replayed. A reader who replays such a dialogue with their own language model collaborator does not just read the reasoning — they can resume it.

For this project, Layer 2 includes:

• Architectural design dialogues (with myself, with collaborators, with LLM partners)
• Recorded decision rationale at branching points
• Build Log conversations that produced the published Build Logs themselves

These traces are made available as paired Markdown (for human reading) and JSON (for direct ingestion by language models). A future engineer regenerating their own implementation can begin not from a blank page but from the pre-loaded context of the original reasoning, accelerated to the present.

Layer 3 — Sample Implementations

The actual source code, schematics, MAX patches, scripts, and similar concrete artifacts that I personally produce in the course of building the engine.

This layer is illustrative, not normative. It is one possible implementation, made by one engineer (me), in one set of constraints, on one set of devices, at one moment in time. Other engineers regenerating from Layers 1 and 2 will produce different implementations. Their implementations are not derivatives of mine. They are independent answers to the same question.

Sample implementations are released under a permissive open-source license (specifics in the project repository). They serve as reference points for engineers who want to compare their own regenerated work against an existing example, and for educators who want concrete material to teach with.

What is shared, what is not, and what is everyone's

The three-layer structure produces a clean ownership distribution:

Layer	Status	Owner
Layer 1: Architectural Specification	Commons (public domain)	No one / everyone
Layer 2: Reasoning Trace	Commons (public domain)	No one / everyone
Layer 3: Sample Implementations (mine)	Open-source license (permissive)	Me, as author
Layer 3: Implementations regenerated by others	At each author's discretion	The regenerator

Critically, an implementation regenerated from Layers 1 and 2 by another engineer is not a derivative work of my Layer 3 sample. It is an independent answer to the architectural specification, produced by a different engineer with a different process. The regenerator owns it outright. They may license it however they choose — open source, commercial, kept private. That choice is theirs.

This is the structural difference from open source. Under traditional open source, an implementation derived from my code inherits the license obligations of my code. Under Open Prompt, an implementation regenerated from my architecture inherits nothing from my code, because it does not descend from my code. It descends from the specification, which is the commons.

Why this works in 2026 specifically

Open Prompt would not have been a viable paradigm five years ago. The mechanism that makes it work — that an architectural specification, combined with a reasoning trace, is sufficient input for a competent engineer plus a capable language model to regenerate working source code — depends on the language models being capable enough.

That threshold has been crossed. As of 2026, a working engineer collaborating with a frontier-class language model can routinely move from a precise architectural specification to functional source code in time scales that were previously occupied by source-code authorship itself.

This shifts where the slow, careful work happens. The slow, careful work is now in the specification and the reasoning, not in the typing of code. The typing of code is increasingly the regenerable, abundant phase. The thinking that produces a clean specification — the part that is genuinely hard, that takes decades of experience, that cannot be automated — is the part worth distributing.

Open Prompt makes that distribution explicit.

A note on prompt engineering

When language models first became broadly accessible, "prompt engineering" emerged as a discipline focused on crafting one-shot inputs that would elicit desired outputs. Benchmarks and tutorials accumulated around the question of what to put in a single prompt.

That phase is largely over. The current understanding among practitioners is that prompting is a multi-turn dialogue, not a one-shot incantation. The skill that matters is sustaining a productive collaborative thinking process across many turns — clarifying, course-correcting, reformulating, resuming. A single-shot prompter is increasingly recognized as an early-stage user.

This shift is what makes Layer 2 (Reasoning Trace) sensible to share. A one-shot prompt is not interesting to share — it is just a sentence. A multi-turn design dialogue, however, is a record of how a complex engineering problem was thought through. It is the modern equivalent of a laboratory notebook. Sharing it is sharing the most valuable kind of engineering knowledge there is.

The repository structure

To make Open Prompt a concrete and reproducible distribution format, I propose the following repository structure as a template:

ProjectName_OpenPrompt/
├── README.md                          # Project overview and navigation
├── LICENSE_OpenPrompt.md              # The Open Prompt declaration for this project
│
├── 01_Architecture/                   # Layer 1 — Specification (commons)
│   ├── overview.md
│   ├── core_mathematics.md
│   ├── system_architecture.md
│   ├── design_constraints.md
│   └── ... (project-specific)
│
├── 02_Reasoning_Traces/               # Layer 2 — Dialogues (commons)
│   ├── README.md                      # How to read, how to resume
│   ├── 2026-04-design-dialogue.md     # Human-readable conversation log
│   ├── 2026-04-design-dialogue.json   # LLM-ingestible conversation log
│   └── ... (chronological, append-only)
│
├── 03_Sample_Implementations/         # Layer 3 — Reference code (author-licensed)
│   ├── README.md                      # What is here, what is not, what license
│   ├── horner_pipeline_verilog/
│   ├── max_patches/
│   ├── bin_pattern_generators/
│   └── ... (project-specific)
│
└── CONTRIBUTING.md                    # How others can contribute (Layer 1/2 only)

A repository following this layout is, by structure alone, an Open Prompt distribution. The structure itself becomes the social contract — analogous to how a LICENSE file at the root of a repository communicates open-source intent.

The FPGA Spectrum Engine repository will be published in this exact structure, at a URL announced in a follow-up Build Log.

What Open Prompt is not

Open Prompt is not anti-open-source. It includes open source. Layer 3 (sample implementations) is released under a permissive open-source license. Anyone who wants to fork the sample, modify it, and redistribute it under standard open-source rules may do so. What Open Prompt adds is a parallel path — for engineers who want to regenerate from the architecture itself rather than fork from the sample. Both paths are legitimate.

Open Prompt is not a license. It is a structural distribution scheme. Layers 1 and 2 are placed in the public domain explicitly. Layer 3 carries whatever license the original author chooses for it. The novelty is in the layering, not in any new legal instrument.

Open Prompt is not LLM-dependent. A competent engineer, working without any language model, can still read Layer 1 and Layer 2 and regenerate an implementation from them. The LLM accelerates the regeneration; it does not enable it. Open Prompt would still be a coherent paradigm in a world without language models — it would just be slower.

Open Prompt is not a claim that source code is unimportant. Source code remains the executable artifact. Open Prompt simply observes that, in 2026 and onward, source code is no longer the bottleneck in knowledge transfer. The bottleneck has moved upstream, and Open Prompt is an attempt to distribute knowledge at the new bottleneck.

Open Prompt is not yet standardized. This declaration is one project's adoption of a paradigm I believe should exist. Whether that paradigm becomes broadly adopted — whether the three-layer structure crystallizes into convention, whether the repository template becomes a recognizable signal, whether other projects adopt it — depends on the community.

This declaration is an invitation, not a fait accompli.

Adoption — for projects that want to follow

Other engineers who wish to release projects as Open Prompt are welcome to use this scheme. The adoption procedure is simple:

1. Structure the repository in the three-layer template above (or a clearly-derived variant).
2. Place Layer 1 and Layer 2 in the public domain, explicitly. A standard CC0 dedication works for both layers.
3. License Layer 3 as you choose. Permissive open-source licenses are recommended but not required.
4. Include an Open Prompt declaration in the repository — referencing this Build Log, or your own equivalent declaration, is sufficient.
5. Maintain the reasoning trace as you go. Layer 2 is not a one-time export at project end; it accumulates throughout the project's life. New design conversations are appended chronologically.

That is the entire protocol. There is no central registry, no certifying body, no required attribution beyond what each contributing engineer chooses for their own Layer 3.

What I am asking of readers

If you are an FPGA engineer and you regenerate this architecture into your own implementation: publish your reasoning trace. Even if you keep your final source private, the trace of how you got there belongs to the commons. Your dialogue with your language model — about why you chose Horner over accumulate-and-multiply, about what polynomial degree fit your constraints, about how you partitioned your error budget — is exactly the material that future engineers will need.

If you are a researcher or educator: the architecture and reasoning traces are yours to teach with, write about, build on, criticize, refine. No permission needed. Attribution welcome but not required.

If you are an engineer working on something completely different — robotics, networking, mechanical design, anything: consider whether your project would benefit from this structure. The three-layer division is not specific to FPGA work or to digital signal processing. It is a general scheme for knowledge sharing in a world where regeneration from specification is cheaper than transfer of source code.

Closing — and a return to the project

The FPGA Spectrum Engine is a real engineering project with concrete goals: 10,240 oscillators, 1-sample latency, 0.001 Hz resolution, real-time spectral synthesis on a Cyclone V SoC. The Build Logs in this series document its design, its history, and its current status as a working compute substrate awaiting the new abstraction layer.

Open Prompt is the form in which this project is released. It exists because I want this engineering knowledge to outlive the source code it temporarily inhabits. Code is ephemeral; the knowledge architecture is the commons.

Forty years of FPGA practice taught me that the lasting contribution is never the bitstream. It is always the way of seeing the problem that produced the bitstream. Open Prompt is my attempt to share the way of seeing.

What the readers do with it is no longer mine to determine. That, finally, is the point.

Coming next

• Build Log #3 — Synthesis paradigm lineage: from Chowning's 1973 FM equation to the spectral fractal direction, and where this engine sits on that timeline. (Now to be read in the Open Prompt frame: a historical Layer-1-style document.)

Project repository (Open Prompt structure): announced in a follow-up Build Log Companion interactive page: dsohnaka/FPGA_Spectrum_Engine_OpenPrompt

---

▼ Build Log 本文（日本語版・併記用）

オープンプロンプト — LLM 時代の知識共有パラダイム

これは、これまでのすべての Build Log が指し示してきたログである。

FPGA Spectrum Engine は、私がオープンプロンプトと呼ぶ知識共有方式のもとに公開される。本ログはその正式な宣言である：オープンプロンプトとは何か、何でないか、なぜ存在するのか、何を共有するのか、そして他者が自身のプロジェクトのためにどう採用できるか。

本ログは同時に、必然的に、有能なエンジニアと有能な言語モデルが当然のように協働する世界における工学知識の伝播に関するログでもある。その世界はすでに到来している。問題は、私たちの知識共有の慣習がそれに追いついているかどうかである。

なぜ新しいパラダイムが必要か

40年にわたって、オープンソースは工学知識を共有する支配的モデルだった。それはソースコードを、再利用・改変・再配布を許容し構造化するライセンスのもとに配布することで機能する。コードが成果物。ライセンスが社会的契約。フォーク、帰属表示、コピーレフトが運用機構。

オープンソースは現代史における最も成功した知的運動の一つである。ここで述べることは何一つそれを貶めるものではない。

しかし、オープンソースはソースコードがボトルネックだった世界のために設計された。ソースコードの生成には日・週・年単位の人間時間がかかった。それを共有することは、最も希少な資源を共有することだった。ライセンス構造が存在するのは、成果物が苦労して獲得されるものだったからである。

その世界が変わりつつある。有能なエンジニアと有能な言語モデルが、アーキテクチャ記述から動作するソースコードを数時間で再生成できる世界では、もはやソースコードはボトルネックではない。希少だったものが豊富になる。豊富だったもの——アーキテクチャの明晰さ、推論の精密さ、設計意図の透明性——が希少になる。

オープンソースは豊富な資源を配布し、その希少性の周りでライセンスを構築する。私たちは希少な資源を配布し、豊富な資源を自由に再生成させるパラダイムを必要としている。

そのパラダイムが、私がオープンプロンプトと呼ぶものである。

オープンプロンプトとは何か

オープンプロンプトは工学知識を3つの層で配布する：

第1層 — アーキテクチャ仕様

数学、制約、構造的決定、不変量。有能なエンジニアが直接読めるように書かれる。現代の言語モデル能力との組み合わせにより、そのエンジニアが動作する実装を再生成するに十分なもの。

FPGA Spectrum Engine の第1層には以下が含まれる：

• 11次マクローリン打ち切りとその誤差上界
• 3層ハードウェアアーキテクチャ（PC / ARM HPS / FPGA）
• ビン直接アドレス原理
• iDFT/SDFT 双対性
• 合成パラダイム統一（FM、加算、フラクタル、ポリゴナルがビンパターンとして）

この層は共有財産である。パブリックドメインに置かれる。誰でも読み、再配布し、その上に構築し、派生説明を書き、教えてよい。

第2層 — 推論軌跡

制約から実装へと導いた実際の設計対話と決定記録。この層こそが LLM 時代において真に新しいものである。

工学的決定は、仕様だけからは完全には再構成できないことが多い。「なぜこれであってあれでないか」は仕様に到達する過程に宿る。歴史的にはその過程は失われた——散在するノート、メーリングリストのスレッド、関わったエンジニアの記憶のなかにのみ保存された。

しかし LLM 時代において、工学的推論のかなりの部分が言語モデルとの対話として行われる。それらの対話は文字どおり、テキストとしてエクスポート可能である。保存し、版管理し、共有し、再生できる。そのような対話を自身の言語モデル協働者と再生する読者は、推論を読むだけではない——それを再開できる。

本プロジェクトでの第2層には以下が含まれる：

• アーキテクチャ設計対話（自己との、協働者との、LLM パートナーとの）
• 分岐点における決定根拠の記録
• 公開された Build Log そのものを生成した対話

これらの軌跡は、人間が読むための Markdown と、言語モデルが直接取り込むための JSON のペアとして提供される。自身の実装を再生成する未来のエンジニアは、白紙からではなく、元の推論の事前ロード済みコンテクストから、現在まで加速された地点から始めることができる。

第3層 — サンプル実装

エンジン構築の過程で私個人が生成する、実際のソースコード、回路図、MAX パッチ、スクリプト、その他の具体的成果物。

この層は例示的であり規範的ではない。それは一人のエンジニア（私）が、ある制約集合のもとで、ある一連のデバイス上で、ある一時点で行った、一つの可能な実装である。第1層と第2層から再生成する他のエンジニアは異なる実装を生み出す。彼らの実装は私の派生物ではない。同じ問いに対する独立した答えである。

サンプル実装は寛容なオープンソースライセンス（詳細はプロジェクトリポジトリで規定）のもとに公開される。自身の再生成成果物を既存の例と比較したいエンジニア、教えるための具体的素材を欲する教育者にとってのリファレンスポイントとして機能する。

何が共有され、何が共有されず、何が万人のものか

3層構造は綺麗な所有権分布を生み出す：

層	状態	所有者
第1層：アーキテクチャ仕様	共有財産（パブリックドメイン）	誰でもなく / 全員
第2層：推論軌跡	共有財産（パブリックドメイン）	誰でもなく / 全員
第3層：サンプル実装（私のもの）	オープンソースライセンス（寛容）	私（著者として）
第3層：他者により再生成された実装	各著者の判断	再生成者

重要な点として、他のエンジニアが第1層と第2層から再生成した実装は、私の第3層サンプルの派生物ではない。それは異なるエンジニアが異なる過程で生み出した、アーキテクチャ仕様への独立した答えである。再生成者がそれを完全に所有する。彼らはそれを好きなようにライセンスできる——オープンソースで、商用で、非公開で。その選択は彼らのものである。

これがオープンソースとの構造的差異である。伝統的オープンソースのもとでは、私のコードから派生した実装は私のコードのライセンス義務を継承する。オープンプロンプトのもとでは、私のアーキテクチャから再生成された実装は私のコードから何も継承しない——私のコードから降りてきていないからである。それは仕様から降りてきており、仕様は共有財産である。

なぜこれが特に2026年に機能するのか

オープンプロンプトは5年前には実現可能なパラダイムではなかった。それを機能させる機構——アーキテクチャ仕様と推論軌跡の組み合わせが、有能なエンジニアと有能な言語モデルが動作するソースコードを再生成する入力として十分であること——は、言語モデルが十分に有能であることに依存する。

その閾値は越えられた。2026年現在、フロンティア級言語モデルと協働する実働エンジニアは、精密なアーキテクチャ仕様から動作するソースコードへ、かつてはソースコード執筆そのものに費やされた時間スケールで日常的に移動できる。

これは慎重な作業がどこで行われるかを変える。慎重な作業はもはやコードのタイピングではなく、仕様と推論にある。コードのタイピングは、ますます再生成可能で豊富な段階となる。清潔な仕様を生み出す思考——本当に難しい部分、何十年もの経験を必要とし、自動化できない部分——こそが、配布する価値のある部分である。

オープンプロンプトはその配布を明示化する。

プロンプトエンジニアリングについての注

言語モデルが広く利用可能になり始めたとき、「プロンプトエンジニアリング」は望ましい出力を引き出すワンショット入力を作る規律として現れた。ベンチマークやチュートリアルが、単一プロンプトに何を入れるかという問いの周りに蓄積された。

その段階はおおむね終わった。実践者の現在の理解は、プロンプティングはマルチターンの対話であり、ワンショットの呪文ではないということである。重要な技能は、多くのターンにわたって生産的な協働思考プロセスを維持すること——明確化、軌道修正、再定式化、再開——である。ワンショットプロンプターはますます初期段階のユーザーとして認識される。

この変化こそが、第2層（推論軌跡）を共有することを意義あるものにする。ワンショットプロンプトは共有して興味深いものではない——ただの一文である。マルチターンの設計対話は、しかし、複雑な工学問題がどう考え抜かれたかの記録である。それは現代における実験ノートの等価物である。それを共有することは、存在する最も価値ある種類の工学的知識を共有することである。

リポジトリ構造

オープンプロンプトを具体的で再現可能な配布形式とするため、以下のリポジトリ構造をテンプレートとして提案する：

ProjectName_OpenPrompt/
├── README.md                          # プロジェクト概要とナビゲーション
├── LICENSE_OpenPrompt.md              # 本プロジェクトのオープンプロンプト宣言
│
├── 01_Architecture/                   # 第1層 — 仕様（共有財産）
│   ├── overview.md
│   ├── core_mathematics.md
│   ├── system_architecture.md
│   ├── design_constraints.md
│   └── ... （プロジェクト固有）
│
├── 02_Reasoning_Traces/               # 第2層 — 対話（共有財産）
│   ├── README.md                      # 読み方、再開の仕方
│   ├── 2026-04-design-dialogue.md     # 人間可読の対話ログ
│   ├── 2026-04-design-dialogue.json   # LLM 取り込み可能な対話ログ
│   └── ... （時系列、追記のみ）
│
├── 03_Sample_Implementations/         # 第3層 — リファレンス実装（著者ライセンス）
│   ├── README.md                      # 何があるか、何がないか、ライセンス
│   ├── horner_pipeline_verilog/
│   ├── max_patches/
│   ├── bin_pattern_generators/
│   └── ... （プロジェクト固有）
│
└── CONTRIBUTING.md                    # 他者がどう貢献できるか（第1/2層のみ）

このレイアウトに従うリポジトリは、構造のみによってオープンプロンプト配布である。構造そのものが社会的契約となる——リポジトリのルートにある LICENSE ファイルがオープンソース意図を伝えるのと同様に。

FPGA Spectrum Engine リポジトリは、まさにこの構造で公開される——URL は後続の Build Log で告知する。

オープンプロンプトは何ではないか

オープンプロンプトはオープンソース反対ではない。それはオープンソースを包含する。第3層（サンプル実装）は寛容なオープンソースライセンスのもとに公開される。サンプルをフォーク、改変、標準的なオープンソース規則のもとで再配布したい者は誰でもそうできる。オープンプロンプトが追加するのは並行する経路——サンプルをフォークするのではなくアーキテクチャそのものから再生成したいエンジニアのため。両経路とも正当である。

オープンプロンプトはライセンスではない。それは構造的配布スキームである。第1層と第2層は明示的にパブリックドメインに置かれる。第3層は元の著者が選んだライセンスを伴う。新規性は層構造にあり、新しい法的道具にはない。

オープンプロンプトは LLM 依存ではない。言語モデルなしで作業する有能なエンジニアも、第1層と第2層を読んで実装を再生成できる。LLM は再生成を加速する；可能にするのではない。言語モデルなしの世界においてもオープンプロンプトは首尾一貫したパラダイムであっただろう——ただ遅かっただけで。

オープンプロンプトはソースコードが重要でないとの主張ではない。ソースコードは依然として実行可能成果物のままである。オープンプロンプトは単に、2026 年以降においてはソースコードがもはや知識転送におけるボトルネックではない、と観察するだけである。ボトルネックは上流に移動した。オープンプロンプトはその新しいボトルネックにおいて知識を配布する試みである。

オープンプロンプトはまだ標準化されていない。本宣言は、私が存在すべきだと信じるパラダイムへの、一プロジェクトによる採用である。そのパラダイムが広く採用されるか——3層構造が慣行に結晶化するか、リポジトリテンプレートが認識可能なシグナルとなるか、他のプロジェクトが採用するか——はコミュニティ次第である。

本宣言は招待状であり、既成事実ではない。

採用方法 — 後続を望むプロジェクトへ

オープンプロンプトとして自身のプロジェクトを公開したい他のエンジニアは、本スキームを利用してよい。採用手順は単純である：

1. リポジトリを上記の3層テンプレート（または明確に派生した変種）に従って構造化する
2. 第1層と第2層を明示的にパブリックドメインに置く。両層に対し標準的な CC0 dedication で十分
3. 第3層を任意のライセンスにする。寛容なオープンソースライセンスが推奨されるが必須ではない
4. オープンプロンプト宣言をリポジトリに含める——本 Build Log への参照、または自身の同等宣言で十分
5. 進捗とともに推論軌跡を維持する。第2層はプロジェクト終了時の一回限りのエクスポートではない；プロジェクトの全期間にわたって蓄積する。新しい設計対話は時系列で追加される

これがプロトコル全体である。中央レジストリも、認証団体も、各貢献エンジニアが自身の第3層に対して選ぶもの以外の必須帰属表示もない。

読者への問いかけ

あなたが FPGA エンジニアで、本アーキテクチャを自身の実装に再生成するなら：推論軌跡を公開してほしい。最終的なソースを非公開のまま保つにしても、そこに到達した道筋の軌跡は共有財産に属する。あなたの言語モデルとの対話——なぜ Horner を選び累積積算を選ばなかったか、どの多項式次数があなたの制約に適合したか、誤差予算をどう分配したか——こそが、未来のエンジニアが必要とするまさにその素材である。

あなたが研究者または教育者なら：アーキテクチャと推論軌跡はあなたが教える、書く、その上に構築する、批判する、洗練するためのものである。許可は不要。帰属表示は歓迎するが必須ではない。

あなたがまったく異なるもの——ロボティクス、ネットワーキング、機械設計、その他何でも——に取り組むエンジニアなら：自身のプロジェクトがこの構造の恩恵を受けるかどうか考えてほしい。3層分割は FPGA 仕事やデジタル信号処理に特有のものではない。それは仕様からの再生成がソースコードの転送より安価な世界における、知識共有の一般的スキームである。

プロジェクトリポジトリ：dsohnaka/FPGA_Spectrum_Engine_OpenPrompt 

2020 Prototype — from first sound to Dirichlet kernel, and the wrong turn that taught me everything

Before describing the current architecture in detail, I want to walk through what was actually built and running five years ago — in four stages, in the order they happened.

This is the proof-of-concept record. It is also the record of how the design philosophy of the current engine was forged through a sequence of experiments, two of which succeeded for the wrong reasons and one of which succeeded for reasons I did not appreciate until much later.

Stage 1 — First sound (November 2020)

[Tektronix display with 1 kHz sine, C5G board on the workbench]

This photograph captures the moment the C5G prototype produced its first sound. The Tektronix oscilloscope shows a clean 1 kHz sine wave; the small Terasic Cyclone V GX board on the cutting mat is the source. Behind the soldering equipment, the parts bins, and the everyday clutter of an electronics bench, something unprecedented was happening: 10,240 independent oscillators, all set to the same frequency, were summing into a single tone.

The test setup, in full, was the following:

• All 10,240 bins set to 1 kHz
• All bins set to phase = 0
• All bins set to maximum amplitude
• Reset held high; output muted

I will admit that I held my breath when I released reset. Mathematically, the output should have been a single 1 kHz sine at full scale — 10,240 unit-amplitude sinusoids, all coherent, all at the same frequency, summing to a single coherent tone scaled by the count. But "mathematically should" and "actually does, on real silicon, on the first try" are two different statements. There was a real possibility that I would hear a click, a burst of broadband noise, or nothing at all — any of which would have meant a fundamental error somewhere in the pipeline that would have taken weeks to find.

What I heard instead was a clean, sustained "piiiiiiiii——" at 1 kHz. The oscilloscope confirmed it visually. No transient. No artifact. Just the tone the mathematics predicted.

It took me a moment to register what had just happened. Then it took me longer to register what it meant. If 10,240 phase-coherent oscillators all sum cleanly into one tone, then the entire compute pipeline — every Maclaurin evaluation, every NCO accumulator, every adder in the 10,240-input adder tree — is working correctly, simultaneously, in real time. The single coherent output was, paradoxically, the strongest possible test signal: any error anywhere in any of the 10,240 bins would have shown up immediately as decoherence.

The boring tone on the oscilloscope was a complete proof of life.

Stage 2 — Dirichlet kernel (November 18, 2020)

Once the basic compute pipeline was confirmed, the obvious next test was to break the coherence on purpose, and see whether the bins behaved as 10,240 independent oscillators rather than as one big oscillator pretending to be many.

I picked a single 2,048-bin pipeline module (one of the five that make up the full engine) and detuned its 2,048 oscillators across a narrow frequency range:

• 2,048 sinusoidal oscillators, all phase-coherent, all equal amplitude
• Frequencies spaced from 996 Hz to 1004 Hz, in steps of 1/256 Hz
• All bins at maximum amplitude that did not clip the sum (97% of full scale)

What you hear is not a synthesizer "patch." It is a direct physical realization of a Dirichlet kernel — the closed-form sum of 2,048 equal-amplitude phase-coherent sinusoids spaced uniformly in frequency. The mathematics predicts a sharp main lobe at the geometric center, followed by gradually decaying side lobes whose mutual beating creates a slow envelope at frequencies determined by the detune step.

What it sounds like

I had expected a click. A burst. Possibly something noisy.

It is none of those.

It begins with a clear "piiiiinnnn——————" — a sustained tone at the centroid frequency, with no transient onset whatsoever. Then, over several seconds, it gently undulates a few times per second, the side-lobe beating pattern slowly walking through its own envelope. And then it descends, gradually and unhurriedly, into silence — like something sinking through clear water.

It is, unexpectedly, beautiful.

The waveform

[ The stereo capture showing main lobe and decaying side lobes]

Stereo capture via analog audio interface. The original FPGA output is bit-perfect mono; the small left/right asymmetry visible above is from the analog re-capture path, not from the synthesis itself.

The shape is the textbook Dirichlet envelope: a tall narrow main lobe at t=0, followed by exponentially-decreasing side lobes whose zero-crossings sit exactly where the mathematics predicts them. 2,048 phase-coherent oscillators, generating their own envelope through interference alone. No amplitude modulation. No envelope generator. Just the sum of 2,048 sine waves placed at the right frequencies.

The video

[Insert YouTube embed: "FPGA Spectrum Engine — 2,048 oscillators detuned by 1/256 Hz (2020 prototype)"]

The video shows the static waveform display; the audio is the actual recording. Headphones recommended for the descent into silence.

What this proved (that the first-sound test could not)

The first-sound test confirmed that the compute pipeline was internally correct. The Dirichlet test confirmed something else: that the bin parameters — frequency, phase, amplitude — could be set independently per bin, with the precision required to place each oscillator on a 1/256 Hz grid. The main lobe arrived exactly at the centroid; the side-lobe zeros arrived exactly where the mathematics put them. The frequency resolution claim of the engine was, at this point, no longer theoretical.

Together, the two tests — first sound and Dirichlet — bound the architecture from both directions. Coherent sum: every bin computes the same tone the same way. Coherent detune: every bin computes its own tone independently. The compute substrate of the engine was, by these two experiments, validated.

Stage 3 — The wrong turn (80-voice polyphony)

The Dirichlet test was, in retrospect, a diagnostic experiment. It was not the original goal of the C5G prototype. The original goal was something quite different and considerably less interesting: a conventional 80-voice polyphonic additive synthesizer, with 128 partials per voice (80 × 128 ≈ 10,240 — the same total bin budget, organized differently).

I built it. It worked. There’s even a video of me trying to control the keyboard using an RTL-implemented MIDI interface and pressing as many keys as possible at once, only to end up knocking the MIDI keyboard off the desk.

["FPGA Additive Synth — 80-voice polyphonic stress test (2020, C5G prototype)"]

The keyboard itself was somehow unharmed, but although I happened to press several keys at once, due to a fault with the MIDI interface, the notes weren’t being turned off and just kept playing. You can probably guess how many notes were sounding simultaneously from that rather silly video of me—someone with no perfect pitch—trying to find each key one by one to send a Note Off signal.

A video showing efforts to press as many keys as possible simultaneously with my elbow, whilst fixing a very basic issue inherent in the MIDI interface implemented in RTL on an FPGA. Although the sound is stable across the entire range from high to low notes, I’ve gradually begun to suspect that 10,240 pins might not be the best use of resources for this particular sound.

[ "80-voice polyphonic Stress testing following MIDI I/F debugging (2020, 17 December C5G prototype)"]

Then while playing it, I gradually realized something uncomfortable: the voice-allocation abstraction was the wrong abstraction. It made the system act like a conventional polyphonic synth, which means it could only do what conventional polyphonic synths do. The 10,240 bins were organized into 80 boxes of 128, each box behaving like one note. Beautiful, but artificially constrained.

["Vivaldi 'Smmer' Allegro non molto on FPGA additive synth — Performance from a DAW (2020)"]

(This piece is the first movement of Vivaldi’s ‘Summer’ (RV 315, ‘L’estate’, Allegro non molto))

What the Dirichlet test had shown — almost by accident — was the alternative: don't allocate voices. Address bins directly. A "note" is just a particular bin pattern. A "chord" is just a different bin pattern. A "noisy texture," a "comb-filtered impulse," an "evolving spectral cloud" — all the same hardware, all just bin patterns.

The 2020 architecture had the compute power. It just had the wrong API on top of it.

Stage 4 — The Vivaldi clue

Around the same time, I made a different recording: playing the third movement of Vivaldi's Winter (RV 297, "L'inverno", Allegro non molto) on the C5G prototype, controlled from MAX/MSP via MIDI, while moving slider faders to add and subtract individual harmonics in real time during the performance.

["Vivaldi 'Winter' Allegro non molto on FPGA additive synth — harmonic slider performance (2020)"]

This was meant as a musical demo. In retrospect, it was the second clue. If I could move harmonics with sliders during a Vivaldi performance, then those harmonics weren't really "harmonics" — they were just bins I happened to have placed at integer multiples of the fundamental. Nothing in the hardware required them to be there. I could have placed them anywhere.

The implication, once I let it land: every synthesis paradigm is a bin-placement problem. FM, additive, polygonal, fractal, Cantor-spectrum, Shepard tones, physical models — all of them. The current project is what happens when you take that observation seriously.

What I'm building now, and why these old proofs matter

The DE10-nano build now in progress is not a successor of the 2020 polyphonic synth. It is a deliberate abandonment of the voice-allocation abstraction, replaced by a 3-layer architecture in which the FPGA does nothing but address bins, the ARM HPS expands abstract scene descriptions into bin assignments, and the PC layer holds the high-level musical/sensing language.

The four 2020 experiments are the foundation:

• First sound validates the compute pipeline's internal correctness.
• Dirichlet kernel validates the per-bin parameter independence and frequency resolution.
• 80-voice polyphony documents the failed abstraction layer that taught me what not to do.
• Vivaldi with sliders is the moment the right abstraction first became visible, even if I did not yet know how to name it.

The compute substrate is real. Only the abstraction layer is being rebuilt.

A note on Open Prompt

This Build Log is descriptive, not prescriptive — I am documenting what was built, not handing over a blueprint to copy. The full architectural and mathematical description, sufficient for any capable engineer (with or without an LLM as a collaborator) to regenerate their own implementation, will appear in Build Log #4 as the Open Prompt declaration.

For now: Open Prompt does not exclude open source. It includes it, and reframes it. I will publish sample source code as I produce it — Verilog skeletons, MAX patches, bin-pattern generators — as reference implementations. Anyone who regenerates their own implementation from the architecture is free to publish or not publish their version, by their own judgment. The architecture is the commons; each implementation is its author's own. More on this in #4.

A small but illustrative example of how this works in practice: the C5G prototype used a particular polynomial evaluation strategy that suited its constraints at the time. The Build Log #1 description of an 11th-order Maclaurin series evaluated by Horner's method is a different implementation of the same mathematics, suited to a different set of constraints. Both are correct. Both are derivable from the same architectural specification. This is what Open Prompt looks like when it works: the same specification regenerating into different implementations, each owned by its author.

Coming next

• Build Log #1 (already posted) — Why 11th-order Maclaurin, not CORDIC and not LUT: the mathematical and pipeline-architectural reasoning.
• Build Log #3 — Synthesis paradigm lineage: from Chowning's 1973 FM equation to the spectral fractal direction, and where this engine sits on that timeline.
• Build Log #4 — Open Prompt: a knowledge-sharing paradigm for the LLM era.

Companion interactive page: https://dsohnaka.github.io/FPGA_Spectrum_Engine/

---

▼ Build Log 本文（日本語版・併記用）

2020年プロトタイプ — 初出音から Dirichlet カーネル、そしてすべてを教えてくれた誤った方向

現在のアーキテクチャを詳述する前に、5年前に実際に作って動いていたものを4つの段階で——起こった順序で——辿りたい。

これは実証記録である。同時に、現エンジンの設計思想がどのように一連の実験を通じて鍛えられたかの記録でもある——そのうち2つの実験は誤った理由で成功し、1つの実験は私が後になるまで気づかなかった理由で成功した。

第1段階 — 初出音（2020年11月）

[ここにオシロスコープ写真挿入 — Tektronix の表示に1kHz正弦波、作業台上のC5Gボード]

この写真は、C5Gプロトタイプが最初の音を出した瞬間を捉えている。Tektronix オシロスコープには綺麗な1kHz正弦波；カッティングマット上の小さなTerasic Cyclone V GXボードがその発生源。ハンダ付け機材、部品箱、電子工作机の日常的な雑然さの背後で、何か前例のないことが起きていた：10,240本の独立したオシレータが、すべて同一周波数に設定された状態で、単一のトーンに総和されていたのである。

完全なテスト構成は以下の通り：

• 全10,240ビンを 1 kHz に設定
• 全ビンを 位相 = 0 に設定
• 全ビンを 最大振幅 に設定
• リセット High 維持、出力ミュート

リセットを解除する瞬間、息を止めていたことを認めなければならない。数学的には、出力はフルスケールの単一1kHz正弦波になるはず——10,240本の単位振幅正弦波がすべてコヒーレントに、すべて同一周波数で、本数倍のスケールで単一のコヒーレントトーンに総和される。だが「数学的にはなるはず」と「実シリコン上で初回試行で実際になる」は別の主張である。クリック音、広帯域ノイズ、あるいは何も聞こえない可能性は現実的にあった——いずれもパイプラインのどこかにある根本的なエラーを意味し、発見に何週間もかかる類のものになる。

代わりに聞こえたのは、清潔で持続する1kHzの「ピーーーーー——」だった。オシロスコープが視覚的に確認した。過渡なし。アーチファクトなし。ただ数学が予測したそのままのトーン。

何が起きたかを認識するのに少し時間がかかった。それが何を意味するかを認識するにはもっと時間がかかった。10,240本の位相コヒーレントなオシレータが綺麗に1つのトーンに総和されるなら、計算パイプライン全体——全マクローリン評価、全NCOアキュムレータ、10,240入力加算木の全加算器——は同時に、実時間で、正しく動作している。 単一のコヒーレント出力は、逆説的に、最も強力なテスト信号だった：10,240ビンのいずれかにエラーがあれば、即座にデコヒーレンスとして現れたはずである。

オシロスコープに映る退屈なトーンが、完全なる生命の証だった。

第2段階 — Dirichlet カーネル（2020年11月18日）

基本的な計算パイプラインが確認された後、次の明白なテストは意図的にコヒーレンスを破壊し、ビンが10,240本の独立したオシレータとして振る舞うか——それとも多数のフリをした1つの巨大オシレータとして振る舞うのか——を見ることだった。

5つのパイプラインモジュール（フルエンジンを構成する5つのうちの1つ）の単一2,048ビンモジュールを選び、その2,048本のオシレータを狭い周波数範囲に分散させた：

• 2,048本の正弦波オシレータ、すべて位相コヒーレント、すべて同振幅
• 周波数を996 Hz から 1004 Hz まで、1/256 Hz 刻みで分散
• 全ビンを総和でクリップしない最大振幅（フルスケールの97%）に設定

聴こえるのは「シンセのパッチ」ではない。これは Dirichlet カーネル——周波数軸上に等間隔配置された2,048本の同振幅・位相コヒーレント正弦波の閉形式総和——の直接的な物理実現である。数学は予測する：幾何中心に鋭い主ローブ、続いて徐々に減衰する副ローブ、それらが互いにビートしてデチューン間隔で決まる周波数のゆっくりした包絡線を作る。

実際の音

私はクリック音を予想していた。バーストか、ノイズめいた何か。

そのいずれでもなかった。

「ピィンーーーーーーー………」という、立ち上がり過渡をまったく持たない、中心周波数の持続音から始まる。それが秒に数回、副ローブのビートパターンが自身の包絡線をゆっくり歩きながら、穏やかにうねる。そして緩やかに、急がず、静寂の中へ降りていく——透明な水の中に何かが沈んでいくように。

意外にも、美しい音だった。

波形

[ここに波形スクリーンショット挿入 — 主ローブと減衰副ローブを示すステレオ録音]

アナログオーディオインターフェース経由のステレオ録音。FPGA の元出力はビット完全モノラルであり、上の波形に見える左右の微妙な差はアナログ再録音経路に由来する。合成自体には差はない。

形状は教科書通りの Dirichlet 包絡：t=0 に高く狭い主ローブ、続いて指数的に減衰する副ローブ群、ゼロ交差点はすべて数学が予測する位置にある。2,048本の位相コヒーレントなオシレータが、干渉だけで自身の包絡線を生成している。 振幅変調なし。エンベロープジェネレータなし。ただ正しい周波数に配置された2,048本の正弦波の総和のみ。

動画

[YouTube埋め込み挿入：「FPGA Spectrum Engine — 2,048 oscillators detuned by 1/256 Hz (2020 prototype)」]

動画は静止波形表示だが、音声は実録音である。終盤の静寂への降下はヘッドホンを推奨。

これが証明したこと（初出音テストでは証明できなかったこと）

初出音テストは計算パイプラインが内部的に正しいことを確認した。Dirichlet テストは別のことを確認した：ビンパラメータ——周波数、位相、振幅——をビンごとに独立して、各オシレータを 1/256 Hz グリッドに配置できる精度で、設定できることを。主ローブは中心に正確に到達した；副ローブのゼロは数学が置いた場所に正確に到達した。本エンジンの周波数分解能の主張は、この時点で、もはや理論ではなくなった。

両者を併せて——初出音と Dirichlet——アーキテクチャを両側から境界した。コヒーレント総和：全ビンが同じトーンを同じ方法で計算する。コヒーレントデチューン：全ビンが各自のトーンを独立に計算する。 本エンジンの計算基盤は、この2つの実験により、検証された。

第3段階 — 誤った方向（80音ポリフォニー）

Dirichlet テストは、振り返ると診断実験だった。それは C5G プロトタイプの本来の目標ではなかった。本来の目標はかなり別物で、しかも遥かに興味の薄いもの——標準的な80音ポリフォニック加算合成シンセサイザー、1音あたり128倍音（80 × 128 ≈ 10,240——現在と同じ総ビン予算を異なる仕方で組織したもの）。

作ってみた。ちゃんと動いた。RTLで実装したMIDIインターフェースを使ってキーボードを操作し、できるだけ多くのキーを同時に押そうとしたところ、結局MIDIキーボードを机から落としてしまったという動画まである。

[YouTube埋め込み挿入：「FPGA Additive Synth — 80-voice polyphonic stress test (2020, C5G prototype)」]

キーボード本体はなぜか無傷だったが、たまたま複数のキーを同時に押してしまったところ、MIDIインターフェースの不具合により、音符がオフにならず、ただ鳴り続けてしまった。絶対音感のない私が、一つずつキーを探してノートオフ信号を送ろうとしている、あの少々滑稽な動画を見れば、どれだけの音が同時に鳴っていたか推論していただけるだろう。

FPGA上のRTLで実装されたMIDIインターフェースに内在するごく基本的な問題を修正しつつ、肘を使ってできるだけ多くのキーを同時に押そうとする様子を収めた動画である。高音から低音までの全音域で音は安定してるが、この特定の音作りに10,240本ものピンを割くのは、リソースの最適な活用とは言えないのではないかと、次第に疑い始めていた。

[YouTube埋め込み挿入：「80-voice polyphonic Stress testing following MIDI I/F debugging (2020, 17 December C5G prototype)」]

そして演奏しているうちに、居心地の悪い気づきが徐々に育っていった：ボイスアロケーションという抽象が、間違った抽象だった。 これはシステムを従来型ポリシンセのように振る舞わせる——つまり、従来型ポリシンセができることしかできなくさせる。10,240ビンが80個の128ビンの箱に組織され、各箱が1音のように振る舞う。美しいが、人為的に拘束されている。

[YouTube埋め込み挿入：「Vivaldi 'Smmer' Allegro non molto on FPGA additive synth — Performance from a DAW (2020)」]

(This piece is the first movement of Vivaldi’s ‘Summer’ (RV 315, ‘L’estate’, Allegro non molto))

Dirichlet テストが——ほとんど偶然に——示したのは別の道筋だった：ボイスを割り当てるな。ビンを直接アドレスせよ。 「音」は単に特定のビンパターン。「和音」は別のビンパターン。「ノイジーなテクスチャ」「櫛形フィルタインパルス」「進化するスペクトル雲」——すべて同じハードウェア、すべて単なるビンパターン。

2020年のアーキテクチャは計算能力を持っていた。間違っていたのはその上に乗っていた API だった。

第4段階 — ヴィヴァルディの手がかり

ほぼ同時期に別の録音を作っている：MAX/MSP から MIDI 制御で C5G プロトタイプ上にヴィヴァルディ「冬」第三楽章（RV 297, "L'inverno", Allegro non molto）を演奏させながら、スライダーフェーダーで個々の倍音を演奏中にリアルタイムに加減した記録。

[YouTube埋め込み挿入：「Vivaldi 'Winter' Allegro non molto on FPGA additive synth — harmonic slider performance (2020)」]

これは音楽デモのつもりだった。後から振り返ると、第二の手がかりだった。もしヴィヴァルディ演奏中に倍音をスライダーで動かせるなら、それらの倍音は本当の意味で「倍音」ではない——たまたま基音の整数倍位置に置いたビンに過ぎない。ハードウェア上、そこに置く必然性はない。どこにでも置けたはずなのだ。

その含意を引き受けたとき：あらゆる合成パラダイムはビン配置問題である。 FM、加算、ポリゴナル、フラクタル、Cantor スペクトル、Shepard トーン、物理モデル——すべて。現プロジェクトはこの観察を真剣に引き受けたときに何が起きるかである。

いま作っているもの、そしてこれらの古い証拠が重要である理由

進行中の DE10-nano ビルドは、2020年ポリシンセの後継機ではない。ボイスアロケーション抽象を意図的に放棄し、3層アーキテクチャに置き換えたもの——FPGA はビンをアドレスすること以外何もせず、ARM HPS は抽象シーン記述をビン割当に展開し、PC 層が高水準の音楽的・センシング的言語を保持する。

2020年の4つの実験が基礎である：

• 初出音は計算パイプラインの内部的正しさを検証する
• Dirichlet カーネルはビンごとのパラメータ独立性と周波数分解能を検証する
• 80音ポリフォニーは何をすべきでないかを教えてくれた失敗した抽象層を文書化する
• スライダー付きヴィヴァルディは正しい抽象が初めて見えた瞬間である——まだ名付け方を知らなかったとしても

計算基盤は実在する。再構築されているのは抽象層だけだ。

オープンプロンプトについての注

この Build Log は記述的であって規範的ではない——作ったものを記録しているのであり、コピー用設計図を渡しているのではない。完全なアーキテクチャ的・数学的記述——LLM を協働者として（あるいは伴わずに）有能なエンジニアが各自の実装を再生成するに足るもの——は Build Log #4 にてオープンプロンプト宣言として登場する予定である。

差し当たり：オープンプロンプトはオープンソースを排除しない。包含し、その位置づけを変える。 私自身が生み出すサンプルソースコード——Verilog スケルトン、MAX パッチ、ビンパターン生成器——はリファレンス実装として公開していく。アーキテクチャから自身の実装を再生成した者は、その版を公開するもしないも、自身の判断で自由に選択できる。アーキテクチャは共有財産、各実装はその作者自身のもの。詳細は #4 にて。

オープンプロンプトが実際にどう機能するかを示す小さくも示唆的な例：C5G プロトタイプは当時の制約に適した特定の多項式評価戦略を用いていた。Build Log #1 で記述された Horner 法による11次マクローリン級数の評価は、同じ数学の異なる実装であり、異なる制約集合に適している。両者とも正しい。両者とも同じアーキテクチャ仕様から導出可能である。これがオープンプロンプトが機能するときの姿である：同一仕様が異なる実装に再生成され、各々が作者に所有される。

次回予告

• Build Log #1（既掲載） — なぜ11次マクローリンか、CORDIC でなく LUT でもない理由：数学的・パイプラインアーキテクチャ的根拠
• Build Log #3 — 合成パラダイムの系譜：Chowning の1973年 FM 方程式から、スペクトラルフラクタルへの方向性、そしてこのエンジンがそのタイムライン上のどこに位置するか
• Build Log #4 — オープンプロンプト：LLM 時代の知識共有パラダイム

Companion interactive page: https://dsohnaka.github.io/FPGA_Spectrum_Engine/

Why 11th-order Maclaurin? Not CORDIC, not LUT — and why the implementation is an open arena

When you tell someone "I generate 10,240 sinusoids on FPGA," the first response is almost always one of two questions: "CORDIC?" or "big lookup table?"

Neither. Every bin in this engine generates its sine value through direct evaluation of an 11th-order Maclaurin series, computed on a fixed-latency DSP pipeline. One result per clock, per pipeline. Five pipelines in parallel. 10,240 sines per sample period at 48 kHz.

This log is about why that choice — direct polynomial evaluation — was forced by the architecture. It is also about something more interesting: once that choice is made, the actual evaluation strategy on silicon is wide open. The mathematics is fixed. The implementation is an arena.

The mathematics

The Maclaurin series for sine is one of the first things you meet in calculus:

sin(x) = x − x³/3! + x⁵/5! − x⁷/7! + x⁹/9! − x¹¹/11! + ···

Truncating at the x¹¹ term, the remainder bound is:

|R₁₁(x)| ≤ |x|¹³ / 13!

For input range |x| ≤ π/2, the worst-case error is about 1.3 × 10⁻⁷, which corresponds to roughly 23 bits of effective precision — enough headroom for a 24-bit DAC with a few bits of guard against accumulated quantization noise downstream.

Range reduction is trivial. A standard quadrant-fold reduces the input to [0, π/2], which costs one comparator and at most one subtraction at the head of the pipeline. Range reduction is not the interesting part of this design.

Reason 1 — Verifiability

The coefficients in the polynomial are 1/n! — exactly. They are not the result of a Remez optimization. They are not table-fitted. They are not vendor-supplied IP block constants. They are mathematical necessities, computable from a textbook in two minutes.

This matters because the entire engine is being distributed as Open Prompt (more on this in Build Log #4). Anyone who wants to regenerate this implementation, with or without LLM assistance, can derive the coefficients themselves. There is no opaque parameter that has to be transferred along with the architecture description. The mathematics is the specification.

A CORDIC implementation has the same property in principle (the rotation angles are arctan(2⁻ᵏ)), but in practice CORDIC implementations on FPGAs come with a thicket of magic numbers — gain compensation factors, micro-rotation orderings, scaling adjustments — that do not survive translation across architectures cleanly. A polynomial sine survives translation perfectly, because the polynomial is the answer.

Reason 2 — Pipeline-natural

Direct polynomial evaluation maps onto a fixed-latency DSP pipeline with one new sine result emerging from the end of the pipeline every clock cycle. The exact structure of that pipeline is an implementation choice (more on this below), but every reasonable structure shares the same property: the polynomial degree determines the pipeline depth, not the throughput. Throughput is one result per clock, period.

This is the property that makes 2,048 bins per pipeline viable. At 100 MHz, a single pipeline produces 100M sines per second. At 48 kHz output rate, that is 2,083 samples worth of throughput per output sample — which I round down to a clean 2,048 bins per module, leaving headroom for control overhead. Five modules give 10,240.

CORDIC also pipelines well, but each CORDIC iteration produces only a partial-precision result; you need 16–20 iterations for 24-bit precision, each with its own pipeline stage, each consuming a DSP block or its equivalent in logic. The DSP-block budget on a Cyclone V — 112 blocks total — is the hard limit on how many bins fit, and direct polynomial evaluation uses that budget more efficiently than CORDIC for the precision target I needed.

Reason 3 — No memory contention

Lookup tables are the obvious alternative. A 16-bit-input, 24-bit-output sine table is 64K × 24 bits = 192 KB, which fits comfortably in M10K block RAM on a Cyclone V. So why not just use it?

Because 2,048 bins all need to read the table simultaneously, every clock cycle.

Block RAM on Cyclone V has two read ports, not 2,048. Time-multiplexing 2,048 reads through two ports means stretching one output sample period across hundreds of clocks per bin, which collapses the throughput target. Replicating the table 1,024 times to feed 2,048 readers consumes more on-chip memory than the device has.

You can use clever interpolation schemes (smaller table + linear or quadratic interpolation) to soften this, but every softening reintroduces a quantization that direct polynomial evaluation simply does not have. The polynomial pipeline has no memory accesses at all. It takes phase in at the front, produces sine out at the back, and consumes nothing but DSP blocks and a small amount of register file space along the way.

This is the property that, more than any other, made the architecture possible. Memory bandwidth was the rate-limiting resource. Removing it from the equation removed the limit.

Reason 4 — Phase precision preserved

In a lookup-table design, you index the table by quantizing your phase to the table's address width. If your table has 16-bit address space, your phase precision is 16 bits at the point of sine evaluation, regardless of how many bits you carried through the upstream NCO (numerically-controlled oscillator) accumulator.

This engine carries 32 bits of phase through the NCO accumulator, and all 32 bits feed directly into the polynomial. No quantization at the boundary. The 0.001 Hz frequency resolution claim — which is the claim that makes this engine interesting for material analysis and SDFT applications, not just music — depends on this property.

A polynomial does not care how many bits you give it. The accuracy is bounded by the truncation order of the series, not by the input precision. Give it 32 bits, give it 48 bits, give it whatever fits in your DSP block — the polynomial just consumes them and returns the corresponding sine.

This is the most subtle of the four reasons, but for a system whose central differentiator is fine frequency resolution, it is also the most consequential.

The Implementation Arena

The four reasons above force the choice of direct polynomial evaluation. They do not force the evaluation strategy. This is where the arena opens.

The 2020 C5G prototype used a particular evaluation strategy that suited the constraints of the time. The current DE10-nano build uses Horner's method as a reference implementation. Other engineers approaching this architecture, with or without LLM collaborators, will land on yet other strategies. All of them can be correct. The selection criteria — DSP-block efficiency, latency, fixed-point error budget, scalability of the polynomial degree — are the variables. The mathematics is the constant.

A few of the open dimensions, in no particular order:

Dimension A — How is x decomposed?

For phase input x = 2π · (ft mod 1), the constant 2π can be absorbed into the polynomial coefficients themselves. A coefficient table of (2π)ⁿ/n! (each pre-shifted to fit the DSP block input width) lets the pipeline operate on the fractional part of (ft) directly, with no upfront multiplication by 2π.

This is the strategy the 2020 C5G prototype used. It saves a DSP block at the cost of a slightly larger coefficient table. It also opens an interesting variant: if (ft) is treated as a fixed-point value with leading-zero detection, the pipeline can adopt a simplified floating-point approach — selecting from a few pre-shifted coefficient sets according to the leading-zero depth of (ft). The result is precision that is preserved across the full input dynamic range without paying full floating-point hardware cost.

Dimension B — Horner, or accumulate-and-multiply?

Horner's method evaluates the polynomial as nested multiply-adds, working inward from the highest-order term:

sin(x) ≈ x · (1 − x²/6 · (1 − x²/20 · (1 − x²/42 · (1 − x²/72 · (1 − x²/110)))))

Each Horner stage is one DSP block. Total: roughly 7 blocks per pipeline (including x² precomputation and the outer ·x).

The accumulate-and-multiply form evaluates the polynomial as a sum of independently-scaled terms, computing successive powers of x by repeated squaring or chaining, and accumulating the scaled results. This form parallelizes the term computations differently and may reach lower latency at the cost of more DSP blocks, depending on the multiplier topology of the target FPGA.

Neither is universally better. The right choice depends on whether the target device's DSP-block-to-LUT ratio is constraining, and on whether latency or area is the dominant cost.

Dimension C — What polynomial degree?

11th-order is what I chose. It hits 23-bit effective precision under the truncation bound, matching a 24-bit DAC with one guard bit.

But:

• 9th-order sacrifices ~3 bits of precision in exchange for ~2 fewer DSP blocks per pipeline. For applications where the DAC is 16-bit, this is the better trade.
• 15th-order gains ~7 bits of precision, which is wasted on a 24-bit DAC but might matter in a sensing application where the polynomial output feeds directly into a digital signal chain with no early DAC quantization.
• 21st-order is mathematically extravagant, but on a future FPGA with 1000+ DSP blocks and a high-resolution sigma-delta output, it might become the right answer.

There is also a tantalizing possibility of adaptive degree selection — picking the polynomial depth at runtime based on the bin's amplitude or the spectral region's importance. A bin contributing 0.01% to the output sum does not need 23 bits of sine precision. Hardware that detects this and routes such bins through a shorter pipeline would save power without measurable audible cost. I have not explored this. Someone reading this might.

Dimension D — How is the error budget partitioned?

Final output precision is bounded by the worst of these noise sources:

1. Polynomial truncation (controlled by degree)
2. Coefficient quantization (controlled by coefficient bit-width)
3. Intermediate fixed-point rounding (controlled by datapath bit-width)
4. Phase input quantization (controlled by NCO width)

Each costs hardware. The interesting design choice is not "make all four very precise" — that overpays — but balance them so all four contribute roughly equal noise floors. There is no unique solution; different implementers will solve this allocation problem differently, and their choices will visibly differ in DSP-block budget and total error.

Dimension E — What about x² precision uplift?

Horner's method computes x² once and reuses it. The bit-width chosen for x² directly affects the precision of every downstream Horner stage. Should x² carry the same number of bits as x, or more? Carrying more bits costs a wider DSP block on that single multiplier; carrying fewer caps the precision of the entire polynomial regardless of degree. There is a non-obvious sweet spot here that depends on the target DSP block's input width.

These five dimensions are not exhaustive. They are the ones I have thought about. There are dimensions I have not seen yet. That is precisely what makes this an arena rather than a textbook problem.

The mathematics is the commons. The implementations are the contributions. An implementation is not a derivative of mine; it is your own answer to the same question.

What this is not

This log is not an attack on CORDIC or on lookup tables. Both are excellent techniques for the right context. CORDIC is unbeatable when you need sine and cosine and arbitrary rotation in one block. LUTs with interpolation are unbeatable when you have plentiful memory bandwidth and modest bin counts.

What this log is, instead, is a record of why direct polynomial evaluation — a technique that is conventionally treated as the boring textbook answer — turns out to be the right answer when your constraint is 2,048 bins per pipeline, one result per clock, no memory accesses allowed. The constraint forced the choice. The choice happened to be the most mathematically transparent option available, which is why I describe it as fortunate rather than clever.

And because the choice is mathematically transparent, the strategy for implementing it is not. That is the arena.

Open Prompt — what is being shared, and how

A reference Verilog skeleton implementing the Horner variant described here will be published as part of the Open Prompt sample set. The skeleton is one implementation, not the implementation. Other engineers regenerating this architecture will produce their own — using different decompositions, different polynomial degrees, different error budgets, different evaluation orders. Those implementations are theirs to publish or not publish, by their own judgment.

What is shared, in three layers:

1. The architectural specification — the mathematics, the constraints, the reasoning that selects direct polynomial evaluation. This log is part of that layer.
2. The reasoning trace — the actual design dialogues (with LLM collaborators, with myself, with future readers) that led from the constraints to the implementation. These will be archived as conversation logs.
3. Sample implementations — the Verilog skeletons, MAX patches, and bin-pattern generators that I personally produce. Reference points, not blueprints.

The full Open Prompt declaration, including the formal three-layer structure and the GitHub repository template, is the subject of Build Log #4.

Coming next

• Build Log #2 (already posted) — 2020 prototype: from first sound to Dirichlet kernel, and the wrong turn that taught me everything.
• Build Log #3 — Synthesis paradigm lineage: from Chowning to spectral fractal.
• Build Log #4 — Open Prompt: a knowledge-sharing paradigm for the LLM era.

Companion interactive page: https://dsohnaka.github.io/FPGA_Spectrum_Engine/

---

▼ Build Log 本文（日本語版・併記用）

なぜ11次マクローリンか？ CORDIC でも LUT でもない理由 — そして実装はオープンなアリーナである理由

「FPGA で正弦波を10,240本生成する」と言うと、最初に返ってくる質問はほぼ決まって2つのうちのどちらかである：「CORDIC ですか？」あるいは「大きな LUT ですか？」

どちらでもない。本エンジンの全ビンは11次マクローリン級数の直接評価によって正弦値を生成する——固定レイテンシ DSP パイプライン上で計算される。1パイプラインあたり毎クロック1出力。5パイプライン並列。48 kHz サンプル周期あたり10,240の正弦波。

このログはなぜその選択——直接多項式評価——がアーキテクチャによって強制されたかについて述べる。同時に、より興味深い別の事柄についても述べる：いったんその選択がなされると、シリコン上での実際の評価戦略は大きく開かれている。数学は固定されている。実装はアリーナである。

数学的基礎

正弦のマクローリン級数は微積分の最初に出会うものの一つ：

sin(x) = x − x³/3! + x⁵/5! − x⁷/7! + x⁹/9! − x¹¹/11! + ···

x¹¹ 項で打ち切ったときの剰余項の上界：

|R₁₁(x)| ≤ |x|¹³ / 13!

入力範囲 |x| ≤ π/2 において、最悪誤差は約 1.3 × 10⁻⁷、これは有効精度約23ビットに相当する——24ビット DAC に対して、下流の量子化雑音蓄積に対する数ビットの余裕を持って十分な精度。

範囲縮小は自明。標準的な象限折り返しで入力を [0, π/2] に縮約する——パイプライン先頭で1個の比較器と最大1回の減算で済む。範囲縮小は本設計の興味深い部分ではない。

根拠1 — 検証可能性

多項式の係数は 1/n!——正確に。これは Remez 最適化の結果ではない。テーブルフィッティングでもない。ベンダー供給 IP ブロックの定数でもない。これらは数学的必然であり、教科書から2分で計算できる。

これが重要である理由は、本エンジン全体がオープンプロンプトとして配布されるからである（詳細は Build Log #4）。本実装の再生成を望む者は誰でも——LLM 補助の有無を問わず——係数を自身で導出できる。アーキテクチャ記述と一緒に転送しなければならない不透明なパラメータが存在しない。数学そのものが仕様である。

CORDIC 実装は原理的には同じ性質を持つ（回転角は arctan(2⁻ᵏ)）が、実践において FPGA 上の CORDIC 実装はマジックナンバーの茂みを伴う——ゲイン補償係数、マイクロ回転の順序、スケーリング調整——これらはアーキテクチャ間の翻訳に綺麗には生き残らない。多項式正弦は翻訳に完璧に生き残る——なぜなら多項式そのものが答えだからである。

根拠2 — パイプライン親和性

直接多項式評価は、パイプライン末端から毎クロック新しい正弦値が出てくる固定レイテンシ DSP パイプラインに対応する。そのパイプラインの正確な構造は実装選択である（後述）が、あらゆる合理的な構造が共通して持つ性質がある：多項式の次数はパイプラインの深さを決めるが、スループットは決めない。スループットは毎クロック1結果、それだけである。

これがパイプラインあたり2,048ビンを実現可能にする性質である。100 MHz では単一パイプラインが秒間1億の正弦値を生成する。48 kHz 出力レートでは出力サンプルあたり2,083サンプル分のスループット——これを切り下げて1モジュール2,048ビンとし、制御オーバーヘッドの余裕を残す。5モジュールで10,240。

CORDIC もパイプライン化はできるが、各 CORDIC 反復は部分精度の結果しか生成しない；24ビット精度には16〜20反復が必要で、各反復に独自のパイプライン段、各段に DSP ブロック1つまたは同等の論理リソースを消費する。Cyclone V の DSP ブロック予算——合計112ブロック——が「何ビン搭載できるか」のハード上限であり、直接多項式評価はこの予算を私が必要とした精度目標に対して CORDIC より効率的に使う。

根拠3 — メモリ競合の回避

LUT は明白な代替案である。16ビット入力・24ビット出力の正弦テーブルは 64K × 24bit = 192 KB、Cyclone V の M10K ブロック RAM に余裕で収まる。なぜ単に使わないのか？

2,048ビンが全員、毎クロック、同時にテーブルを読む必要があるからである。

Cyclone V のブロック RAM は読みポートが2つ、2,048ではない。2,048の読みを2ポートで時分割すると、ビンあたり1出力サンプル周期を数百クロックに引き伸ばすことになり、スループット目標が崩壊する。テーブルを1,024複製して2,048の読み手に対応させるとデバイス搭載量を超えるオンチップメモリを消費する。

賢い補間方式（小さなテーブル＋線形または二次補間）でこれを和らげることもできるが、和らげるたびに直接多項式評価には存在しない量子化が再導入される。多項式パイプラインはメモリアクセスを一切行わない。先頭から位相が入り、末尾から正弦が出る、その間に消費するのは DSP ブロックと少量のレジスタファイル空間だけである。

これが他のどの理由よりも、本アーキテクチャを可能にした性質である。メモリ帯域がレート制限資源だった。それを方程式から除去することで、制限が消えた。

根拠4 — 位相精度の保存

LUT 設計では、テーブルのアドレス幅まで位相を量子化してテーブルにインデックスする。テーブルが16ビットアドレス空間なら、正弦評価点における位相精度は16ビット——上流の NCO アキュムレータで何ビット運んできたかには無関係に。

本エンジンは32ビットの位相を NCO アキュムレータで運び、32ビット全てを多項式に直接入力する。境界における量子化なし。0.001 Hz 周波数分解能の主張——音楽だけでなく材質分析や SDFT 応用に対して本エンジンを興味深いものにする主張——はこの性質に依存する。

多項式は何ビット与えるかを気にしない。精度は級数の打ち切り次数で決まるのであり、入力精度では決まらない。32ビット与えても、48ビット与えても、DSP ブロックに収まる任意のビット数を与えても——多項式はそれを消費して対応する正弦を返す。

これは4つの根拠の中で最も微妙だが、細かな周波数分解能を中心的差別化要因とするシステムにとっては、最も重大でもある。

実装のアリーナ

上記の4つの根拠は、直接多項式評価の選択を強制する。それらは評価戦略を強制しない。ここでアリーナが開かれる。

2020 年の C5G プロトタイプは当時の制約に適した特定の評価戦略を用いていた。現行の DE10-nano ビルドは Horner 法をリファレンス実装として用いている。本アーキテクチャに取り組む他のエンジニアたちは——LLM 協働者の有無を問わず——さらに別の戦略にたどり着くだろう。それらすべてが正しくあり得る。選択基準——DSP ブロック効率、レイテンシ、固定小数点誤差予算、多項式次数のスケーラビリティ——が変数である。数学は定数である。

開かれている次元のいくつかを、順不同で：

次元A — x をどう分解するか

位相入力 x = 2π · (ft mod 1) について、定数 2π は多項式係数自体に吸収できる。(2π)ⁿ/n! の係数表（それぞれが DSP ブロック入力幅に収まるよう事前シフト済み）を持てば、パイプラインは (ft) の小数部に対して直接動作でき、2π を事前に乗じる必要がない。

これは 2020 C5G プロトタイプが用いた戦略である。係数表が若干大きくなる代わりに DSP ブロックを1個節約する。さらに興味深い変種を開く：もし (ft) を先行ゼロ検出付きの固定小数点値として扱えば、パイプラインは簡易浮動小数点アプローチを採用できる——(ft) の先行ゼロ深度に応じて、いくつかの事前シフト済み係数セットから選択する。結果として、入力ダイナミックレンジ全域で精度が保持され、しかもフル浮動小数点ハードウェアのコストを払わずに済む。

次元B — Horner か、累積積算か

Horner 法は多項式を入れ子の積和として評価する——最高次項から内側へ向けて：

sin(x) ≈ x · (1 − x²/6 · (1 − x²/20 · (1 − x²/42 · (1 − x²/72 · (1 − x²/110)))))

各 Horner 段が DSP ブロック1個。合計：パイプラインあたり約7ブロック（x² 事前計算と外側の ·x を含む）。

累積積算形式は多項式を独立にスケールされた項の総和として評価し、x の累乗は反復二乗または連鎖で計算し、スケールされた結果を累積する。この形式は項計算を異なる仕方で並列化し、対象 FPGA の乗算器トポロジに依存して、より多くの DSP ブロックを犠牲にして低レイテンシに到達し得る。

どちらが普遍的に優れているということはない。正解は対象デバイスの DSP ブロック対 LUT 比が制約となるか、レイテンシと面積のどちらが支配的コストかに依存する。

次元C — 多項式次数はいくつか

11次は私が選んだ次数である。打ち切り上界の下で23ビット有効精度に届き、24ビット DAC にガードビット1つ分の余裕で適合する。

しかし：

• 9次 は精度を約3ビット犠牲にする代わりにパイプラインあたり DSP ブロックを約2個削減する。DAC が16ビットの応用ではこちらの方が良いトレードオフである。
• 15次 は約7ビット精度を獲得する——24ビット DAC では無駄になるが、多項式出力が早期 DAC 量子化なしに直接デジタル信号チェーンへ入る感知応用では意味があり得る。
• 21次 は数学的には贅沢だが、1000以上の DSP ブロックを持つ将来の FPGA と高分解能シグマデルタ出力を組み合わせるなら、それが正解になる可能性がある。

さらに魅惑的な可能性として、適応的次数選択がある——ビンの振幅やスペクトル領域の重要度に基づいて、実行時に多項式深度を選ぶ。出力総和に 0.01% しか寄与していないビンは23ビットの正弦精度を必要としない。これを検出してそのようなビンをより短いパイプラインに振り分けるハードウェアは、可聴コストなしに電力を節約するだろう。私はこれを探索していない。これを読む誰かが探索するかもしれない。

次元D — 誤差予算をどう分配するか

最終出力精度は以下の雑音源のうち最悪のものに支配される：

1. 多項式打ち切り（次数で制御）
2. 係数量子化（係数ビット幅で制御）
3. 中間固定小数点丸め（データパスビット幅で制御）
4. 位相入力量子化（NCO 幅で制御）

各々がハードウェアコストを伴う。興味深い設計選択は「四つすべてを非常に精密にする」ではない——それは過剰投資である——ではなく、4つすべての雑音床がほぼ等しく寄与するようバランスを取ることである。一意解は存在しない；異なる実装者はこの配分問題を異なる仕方で解き、その選択は DSP ブロック予算と総誤差に視覚的に異なって現れる。

次元E — x² の精度上昇問題

Horner 法は x² を一度計算し再利用する。x² に選んだビット幅は下流の全 Horner 段の精度に直接影響する。x² は x と同じビット数を運ぶべきか、それとも多くか？ 多く運べばその単一乗算器のために幅広い DSP ブロックが必要になる；少なく運べば次数に関係なく多項式全体の精度が頭打ちになる。ここには対象 DSP ブロックの入力幅に依存する自明でない sweet spot がある。

これら5つの次元は網羅的ではない。私が考えてきたものに過ぎない。まだ私が見ていない次元がある。それこそが、これを教科書問題ではなくアリーナにしている。

数学は共有財産である。実装は貢献である。実装は私の派生物ではない；それは同じ問いに対するあなた自身の答えである。

これは何ではないか

このログは CORDIC や LUT への攻撃ではない。両者とも、適切な文脈においては優れた技術である。CORDIC は正弦かつ余弦かつ任意回転を一つのブロックで必要とするときには敵なしである。補間付き LUT はメモリ帯域が潤沢でビン数が控えめな場合には敵なしである。

このログがそうではなく何であるかといえば、直接多項式評価——慣習的に退屈な教科書解答として扱われる技法——が「パイプラインあたり2,048ビン、毎クロック1結果、メモリアクセスは禁止」という制約のもとでは正しい解答であった、という記録である。制約が選択を強制した。その選択がたまたま入手可能な選択肢の中で最も数学的に透明なものだった——これが、私がこの選択を「賢い」ではなく「幸運だった」と表現する理由である。

そして選択が数学的に透明であるがゆえに、それを実装する戦略はそうではない。それがアリーナである。

オープンプロンプト — 何が、どう共有されるか

ここに述べた Horner 変種のリファレンス Verilog スケルトンはオープンプロンプトのサンプルセットの一部として公開する予定である。このスケルトンは「一つの」実装であり、「この」実装ではない。 本アーキテクチャを再生成する他のエンジニアは各自の実装を生成するだろう——異なる分解戦略、異なる多項式次数、異なる誤差予算、異なる評価順序を用いて。それらの実装は各自のものであり、公開するもしないも各自の判断である。

共有されるものを3層に整理すると：

1. アーキテクチャ仕様 — 数学、制約、直接多項式評価を選択する推論。このログはその層の一部である
2. 推論軌跡 — 制約から実装へと導いた実際の設計対話（LLM 協働者との、自己との、未来の読者との対話）。会話ログとしてアーカイブされる
3. サンプル実装 — 私が個人的に生成する Verilog スケルトン、MAX パッチ、ビンパターン生成器。リファレンスポイントであり設計図ではない

完全なオープンプロンプト宣言——形式的な3層構造と GitHub リポジトリのテンプレートを含む——は Build Log #4 の主題である。

次回予告

• Build Log #2（既掲載） — 2020年プロトタイプ：初出音から Dirichlet カーネル、そしてすべてを教えてくれた誤った方向
• Build Log #3 — 合成パラダイムの系譜：Chowning からスペクトラルフラクタルへ
• Build Log #4 — オープンプロンプト：LLM 時代の知識共有パラダイム

Companion interactive page: https://dsohnaka.github.io/FPGA_Spectrum_Engine/