Close

Build Log #10 — Thirty-Three Small Boxes

A project log for PTSG — Programmable Timing Sequence Generator

A tiny FPGA-resident programmable sequencer that controls time and space directly

tsuneoohnakaTsuneo.Ohnaka 07/08/2026 at 13:360 Comments

Build Log #10 — Thirty-Three Small Boxes

ビルドログ #10 — 三十三の小さな枠

The "one large thing" I promised at the end of #9. Before handing the core to an implementing agent, I sat down and filled in a table — and the table, in return, redesigned a corner of my architecture.
/ #9 の末尾で約束した「大きな仕事」。コアを実装エージェントに手渡す前に、私は腰を据えて一枚の表を埋めた——そして表はお返しに、私のアーキテクチャの一角を設計し直したのだ。

Why a table, and why now / なぜ表か、なぜ今か

The verification campaign had defined command behavior the way verification always does: point by point, as each test demanded. NOP in the foreground — verified. A queued Jump — verified. But between the verified points lay gaps: what does a Base Set do if it appears in the foreground? Can a Prog End be queued? What, exactly, is a background Stay? I had opinions about some of these and had never even asked others.

検証キャンペーンは、検証がいつもそうするやり方で——テストが要求するたびに、点ごとに——コマンドの挙動を定義してきた。前景の NOP——検証済み。Que の Jump——検証済み。だが検証された点と点のあいだには隙間があった: Base Set が前景に現れたら何をするのか。Prog End は Que できるのか。そもそも背景の Stay とは正確には何なのか。いくつかには持論があったが、いくつかは問うたことすらなかった。

Here is the danger: I am about to hand this core to an implementing agent. An agent does not leave gaps — it fills them, by inference. And inferred semantics can quietly violate the very principles this project has spent months making explicit. So before the handoff, every cell of the plane — eleven commands, three execution phases, every state quantity — had to be either defined or declared illegal. My amanuensis prepared an empty grid (I tried to fill the Markdown version by hand and my heart broke; the Excel version saved me). Thirty-three small boxes, each demanding an
answer.

危険はここにある: 私はこのコアを実装エージェントに手渡そうとしている。エージェントは隙間を放置しない——推論で埋めるのだ。そして推論された意味論は、このプロジェクトが数ヶ月かけて明示してきた原則そのものを、静かに破り得る。
だから手渡しの前に、面の全セル——11コマンド、3実行フェーズ、全状態量——が定義済み違法と宣言済みかのいずれかでなければならなかった。祐筆が空の格子を用意してくれた(Markdown 版を手で埋めようとして心が折れた; Excel 版に救われた)。三十三の小さな枠が、各々答えを要求した。

The table asked better questions than I did / 表は私より良い問いを発した

I expected to record decisions. Instead the table generated them. An empty cell cannot be overlooked the way an unasked question can, and several cells, once stared at, refused every answer I already had. Two big things came out of that staring.

決定を記録するつもりだった。ところが表は決定を生成した。空のセルは、発されなかった問いのようには見過ごせない。そして幾つかのセルは、睨んでみると、私が既に持っていたどの答えも拒んだ。その睨み合いから、大きなものが二つ出てきた。

First: the foreground learned to say no. Filling the illegal cells one meaning at a time was exhausting — and worse, every invented meaning was one more thing a programmer would have to learn.
So I stopped inventing. The principle that emerged: Global commands do not execute in the foreground, except three with stated reasons — Reset (the will to return to the origin, even at the cost of continuity), Stay Set (it controls the phase transition itself), NOP (the immediate voiding of anything). Everything else — Base Set, Return, Call, Loop, Prog End — lives behind the window, and if one strays onto the time axis, the machine does not improvise. It halts, raises an error flag, and preserves the scene. A halted PTSG is not a dead PTSG: the flag can trigger
SignalTap or the insertion mechanism, and because behavior lives in instruction memory, ISMCE can patch the offending word over JTAG and carry on. Stop where it broke; fix the memory in place.

第一に、前景が「否」の言い方を学んだ。 違法なセルに一つずつ意味を発明していくのは消耗だった——そしてもっと悪いことに、発明された意味の一つ一つが、プログラマの学ぶべき事柄を一つ増やす。だから発明をやめた。立ち上がった原則: Global コマンドは前景実行しない。例外は理由を明記した三つ——Reset(連続性を犠牲にしてでも起点へ戻る意志)、Stay Set(フェーズ移行そのものの制御)、NOP(あらゆるものの即時無効化)。それ以外——Base Set・Return・Call・Loop・Prog End——は窓の裏に住み、もし一つでも時間軸に迷い出れば、機械は取り繕わない。停止し、エラーフラグを揚げ、現場を保存する。停止した PTSG は死んだ PTSG ではない: フラグは SignalTap やインサーション機構のトリガになり、挙動が命令メモリに住んでいるからこそ、ISMCE が JTAG 越しに問題の一語をパッチして続行できる。
壊れた場所で止まり、メモリをその場で直すのだ。

The bonus I did not see coming: with state control banished from the foreground, a disciplined program's foreground reads as a bare list of Stay durations. The timing chart is the program text. And a long-standing ambiguity — is D16–D31 an operand or a timing-signal field? — simply dissolved, because every extended-operand command now lives only in bands where the timing signals are held. The banding itself resolved it.

予期していなかった副産物: 状態制御が前景から追放されると、規律あるプログラムの前景は Stay 時間の裸のリストとして読める。タイミングチャートプログラムテキストなのだ。そして長年の曖昧さ——D16–D31 はオペランドかタイミング信号フィールドか?——は、あっさり消滅した。拡張オペランドを使うコマンドはすべて、タイミング信号が保持される帯域にしか住めなくなったからだ。帯域設計そのものが解決した。

Second: an empty cell handed me a register. The queued Base Set cell asked: base := what? A queued loop repeats a stay period, not an instruction position — and nothing in the machine could name a period's origin. So now something can: when Stay Set executes, its own State Number is latched into a small new register, Stay Start State, and a queued Base Set reads it. The jewel that falls out: a stay period can loop on itself.

第二に、空のセルが私にレジスタを一つ手渡した。 Que の Base Set のセルが問うた: base := 何か? Que のループが反復するのはステイ期間であって命令位置ではない——そして機械の中に、期間の起点を名指せるものが何もなかった。
いまはある: Stay Set が実行されると自身の State Number が小さな新レジスタ Stay Start State にラッチされ、Que の Base Set がそれを読む。零れ落ちた宝石: ステイ期間が自分自身をループできるのだ。

StaySet → ProgEnd → BaseSet(Q) → Loop-65536(Q) → Stay-4096

Five instructions. A 12-bit Stay times a 16-bit Loop: 2^28 clocks — about 5.4 seconds at 50 MHz — of exact, prescaler-free timing. No 28-bit counter was built; two small ones composed through the queue. It makes you want to program this thing with a piano-roll GUI. (I said that out loud. It is now on a list.)

命令五語。12bit の Stay × 16bit の Loop: 2^28 クロック——50 MHz で約 5.4 秒——の正確な、プリスケーラ不要のタイミング。 28bit のカウンタは作っていない; 小さな二つがキュー越しに合成された。ピアノロールの GUI でこいつをプログラムしたくなってくる。(口に出してしまった。いまやリストに載っている。)

Twice, the artifact was ahead of the sentences
/ 二度、成果物が文より先を行った

I owe you two corrections, because this log series has promised honesty about process.

二つの訂正を報告せねばならない。このログ・シリーズはプロセスへの正直さを約束してきたからだ。

The specification said the stay counter "begins counting at Prog End." Cross-checking the table against the RTL showed that sentence was wrong — the source I revised weeks ago counts from Stay Set onward, on prescaler ticks, straight through the window, and the silicon had verified exactly that. The sentence was my amanuensis's transcription slip, carried with a silicon-confirmed label.
And then, filling the table, I made the mirror-image mistake myself: I described the new register as long-lived, surviving many stay periods until its Loop — conflating it with the Base register's old job. My own table had it right: the register hands its value to Base within the same cycle and is done. Twice in one job, the artifact — RTL once, the table once — was correct before the prose describing it. The lesson I keep re-learning: diff every sentence against the thing itself before carving it as fixed. Both corrections are recorded openly in the reasoning traces, mistakes and all. That, too, is the Open Prompt.

仕様書は、ステイカウンタは「Prog End でカウントを開始する」と書いていた。表を RTL と突き合わせると、その一文が誤りだった——数週間前に私自身が改修したソースは Stay Set からプリスケーラティックで数え始め、窓を貫いて数え続けており、実機はまさにそれを検証済みだった。あの一文は祐筆の転記の滑りで、実機確認済みのラベルを付けたまま運ばれていた。そして表を埋めながら、今度は私自身が鏡写しの誤りを犯した: 新レジスタを、対応する Loop まで多数のステイ期間を生き延びる長寿命のものと説明したのだ——Base レジスタの古くからの仕事との混同だった。私自身の表は正しく書いていた: レジスタは同一サイクル内で値を Base に引き渡し、それで用済みになる。一つの仕事の中で二度、成果物——一度は RTL、一度は表——が、それを記述する散文より先に正しかった。私が学び直し続けている教訓:
どの文も、確定として刻む前に、実物と突き合わせよ。 二つの訂正はどちらも、過ちごと推論トレースに公に記録されている。それもまた Open Prompt なのだ。

Tonight / 今夜

The repository updates tonight: the corrected chapters, the normative table, two new reasoning traces, and a change order that tells an implementing agent exactly what to verify and what to build. Then the whole thing — specification, traces, table, evidence — goes to Claude Code, and we find out whether an Open Prompt can do what it was designed to do: let an AI regenerate the implementation from the reasoning. Thirty-three small boxes asked their questions. The next entry is about what came back.

今夜、リポジトリが更新される: 訂正済みの各章、規範表、二本の新しい推論トレース、そして実装エージェントに何を検証し何を作るべきかを正確に告げる変更指示書。それから全部——仕様、トレース、表、エビデンス——が Claude Code に渡り、Open Prompt が設計どおりのことをできるのか——AI が推論から実装を再生成できるのか——が分かる。三十三の小さな枠がそれぞれの問いを発した。次の項は、何が返ってきたかについてである。

Architecture and decisions: Tsuneo Ohnaka. Drafting and consistency monitoring by Claude (Anthropic), serving as amanuensis. The command × phase table, both corrections, and the reasoning behind the FG-Global exclusion principle, the Error HALT mechanism, and the Stay Start State register are archived as CC0 Layer 2 traces in the PTSG-Core repository.
/ アーキテクチャと決定:
大中庸生。起草と整合性監視は祐筆として Claude (Anthropic)。コマンド×フェーズ表、二つの訂正、そして FG-Global排除原則・Error HALT 機構・Stay Start State レジスタの背後にある推論は、PTSG-Core リポジトリに CC0 の Layer 2トレースとして保管されている。

Discussions