Project Logs

Collapse

• Build Log #12: Putting "Approximately" on Trial

  Tsuneo.Ohnaka • 15 hours ago • 0 comments

  Build Log #12：「約」を裁判にかける

  The camera arrives / カメラの到着

  The project summary ended with a promise: the specification says what should happen — now we point a camera at whether it does. This entry keeps that promise. A new oscilloscope (a Siglent SDS814X HD, replacing a TDS3032 that served this bench for twenty-five years) arrived two Sundays ago, and since Thursday night the bench has been a small film set: one camera on the PC screen with the ISMCE window, one on the oscilloscope and the DE10-nano, one close on the scope's display, cut together picture-in-picture. Every scene follows the discipline established beforehand: predictions frozen in writing before filming, never edited afterward. What follows is Scenes 1 through 3 — the videos are now going up on the project page.

  プロジェクトサマリは約束で終わっていた: 仕様は「何が起きるはずか」を語ってきた——これからは、本当にそうなるかにカメラを向ける。 本項はその約束の履行である。新しいオシロスコープ(Siglent SDS814X HD——この机で25年働いた TDS3032 の後任)が二週前の日曜に着任し、木曜の夜から作業机は小さな撮影所になった: PC 画面と ISMCE ウィンドウに1台、オシロと DE10-nano に1台、オシロ画面のアップに1台、ピクチャ・イン・ピクチャで編集する。全シーンは事前に確立した規律に従う: 予言は撮影前に文書で凍結し、以後編集しない。 以下はシーン1〜3——動画はいまプロジェクトページに上がりつつある。

  Scene 1 — A machine before time begins / 時間が始まる前の機械

  Power-up. The instruction memory is all zeros, and in PTSG a word of zeros is not "nothing" — it is a Global Reset with all sixteen timing signals driven low. So the core boots into an eternal Reset loop: running at full clock, going nowhere, lights out. The machine is on; time has not started.

  電源投入。命令メモリは全域ゼロ——そして PTSG において、ゼロの語は「無」ではない。それは16本のタイミング信号をすべて Low に駆動する Global Reset である。ゆえにコアは永久 Reset ループへと起動する: フルクロックで走り、どこへも行かず、灯は消えている。機械は動いている。時間はまだ始まっていない。

  Then the first improvisation: into address 0, by hand, over JTAG, into the running silicon: 00010000. Still a Reset — but its timing-signal field now carries a 1 in bit 0. The LED lights the instant the word lands. Write 00000000; it goes dark. A manual blinker, made of nothing but the Reset instruction and its cargo of signals. No code was written; a number was typed into a living machine....

  Read more »

• Build Log #11 : What Came Back

  Tsuneo.Ohnaka • 07/11/2026 at 13:24 • 0 comments

  Build Log #11 : What Came Back

  Build Log #11：何が返ってきたか

  The reader arrives / 読者の到着

  The last Build Log ended with a promise: the next entry is about what came back. Here it is.

  前回の Build Log は約束で終わっていた: 次の項は、何が返ってきたかについてである。 これがそれである。

  For months, this project wrote for a reader it had never met. Decision IDs. Reasoning traces with named alternatives. A 33-cell normative table. A change order (CHANGES_Layer1_v1.1_for_ClaudeCode.md) with per-item RTL implications, written to a recipient who did not yet exist. That was the wager of the Open Prompt: that specification, reasoning, and evidence, made machine-readable, would one day carry their own weight when an implementing intelligence finally arrived.

  数ヶ月のあいだ、このプロジェクトは会ったことのない読者のために書いてきた。決定ID。代替案を名前つきで記録した推論トレース。33セルの規範表。項目ごとに RTL 含意を書き添えた変更指示書(CHANGES_Layer1_v1.1_for_ClaudeCode.md)——まだ存在しない受取人に宛てて。それが Open Prompt の賭けだった: 機械可読にされた仕様と推論と証拠は、実装する知能がついに到着した日、自らの重さを自ら担うはずだ、と。

  On 2026-07-06, the reader arrived. A Claude Code agent was pointed at the repository with one sentence: read this, find where the Verilog diverges from the Layer 1 spec, and plan how to make them agree. What came back over the following two days was 19 RTL revisions (RH009–RH027) across a seven-phase campaign, a conformance suite of 33 tests, three spec-internal contradictions found before a single line was changed, live rulings from the architect folded into the work as it ran, a retroactive prosecution of the project's own legacy tests, and — at the end — a fifteen-item handoff written from the implementer back to the archive. Then the merged result went onto a DE10-nano and passed the entire Layer 4 verification menu on silicon, first try.

  2026-07-06、読者が到着した。Claude Code エージェントに、一文だけを添えてリポジトリが渡された: これを読み、Verilog が第1層仕様から逸れている箇所を洗い出し、適合させる計画を立てよ。 続く二日間で返ってきたのは、7フェーズのキャンペーンにまたがる 19 の RTL 改訂(RH009–RH027)、33本の適合テストスイート、一行も変更される前に発見された三件の仕様内矛盾、走行中の作業に折り込まれたアーキテクトの生きた裁定、プロジェクト自身の旧テスト資産に対する遡及的な訴追、そして最後に——実装者からアーカイブへ宛てて書かれた15項目の引き継ぎ書だった。マージされた成果はそのまま...

  Read more »

• Build Log #10 — Thirty-Three Small Boxes

  Tsuneo.Ohnaka • 07/08/2026 at 13:36 • 0 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...

  Read more »

• Build Log #9 — The Doors a Free-Running Clock Opened

  Tsuneo.Ohnaka • 06/29/2026 at 13:57 • 0 comments

  Build Log #9 — The Doors a Free-Running Clock Opened

  ビルドログ #9 — フリーランのクロックが開いた扉

  The coda I promised in #8. Committing to a free-running prescaler did more than kill the jitter — it opened a couple of doors I did not see when I made the call. / #8 で約束したコーダ。フリーランのプリスケーラに賭けたことは、ジッタを消す以上のことをした——決断した時には見えていなかった扉を、いくつか開いたのだ。

  One decision, several consequences / 一つの決断、いくつもの帰結

  In #8 I closed Hook A and said the prescaler had been right all along. The deeper move behind that
  was a decision I had been treating, at first, almost apologetically: to let the prescaler run free —
  reset only by the global hardware reset, never re-aligned, never touched by the program. For a while
  I thought of that as something to compensate for. This log is about the moment it flipped: the
  free-running prescaler is not a compromise to manage but a foundation to build on. Once I stopped
  apologizing for it and committed to it, two doors opened that I genuinely had not seen.

  #8 で Hook A を閉じ、プリスケーラはずっと正しかったと書いた。その背後にあったより深い一手は、私が最初はほとんど詫びるように扱っていた決断だった: プリスケーラを自由に走らせる——グローバルハードウェアリセットでのみリセットされ、再整列されず、プログラムからは決して触れられない。しばらく私はそれを「埋め合わせるべきもの」と考えていた。本ログは、それが反転した瞬間についてである: フリーランのプリスケーラは、管理すべき妥協ではなく、その上に築くべき土台だった。詫びるのをやめてそれに賭けた途端、本当に見えていなかった扉が二つ開いた。

  The common key to both doors is the same property that made the phase-lock structural: if the tick's
  phase never matters — because the hierarchy keeps itself in register — then the tick is free to be
  treated in ways a phase-sensitive design could never allow.

  両方の扉に共通する鍵は、位相ロックを構造的にしたのと同じ性質である: ティックの位相が決して問題にならない——ヒエラルキーが自身をレジスタ済みに保つから——なら、ティックは、位相に敏感な設計が決して許せない仕方で扱える自由を得る。

  Door one — a faster clock ceiling (Fmax) / 扉その一 — より高いクロック上限（Fmax）

  The prescaler is a sizeable counter, and the tick is the result of comparing that counter against a
  target....

  Read more »

• Build Log #8 — The Prescaler Was Right All Along

  Tsuneo.Ohnaka • 06/24/2026 at 13:53 • 0 comments

  Build Log #8 — The Prescaler Was Right All Along

  ビルドログ #8 — プリスケーラは、ずっと正しかった

  Hook A closed, silicon-confirmed. The "slightly off" from bring-up, fully explained. / Hook A 決着、実機確認済み。ブリングアップの「ちょっとおかしい」の、完全な説明。

  Where we left off / 前回までのあらすじ

  In Build Log #6 the core came up on the DE10-nano and ran — but something was slightly off. Not
  broken; off. In Build Log #7 my amanuensis and I built a place to keep the proof: Layer 4, a
  verification scheme with an expected-before-observed discipline and the VCD as the primary
  evidence. We built the cabinet. This log is about what we finally put in it.

  ビルドログ #6 で、コアは DE10-nano 上で立ち上がり、動いた——だが何かがちょっとおかしい。壊れてはいない、おかしいのだ。ビルドログ #7 では、私と祐筆(amanuensis)が証拠を置く場所を建てた: Layer 4、観察前予測の規律とVCD を主証拠とする検証スキーム。棚は建てた。本ログは、その棚にようやく何を収めたか、の話である。

  The "slightly off" had a prime suspect. The prescaler's counter is free-running — it is reset only
  by the global reset, never re-aligned when a wait begins. The audit called this A2: a worry
  that the first timing tick after each wait would arrive a phase-dependent number of clocks late,
  so the high and low intervals of a simple blink would scatter from cycle to cycle. Jitter. That
  was the ghost we went hunting.

  「ちょっとおかしい」には第一容疑がいた。プリスケーラのカウンタはフリーラン——グローバルリセットでのみリセットされ、待機開始時に再整列されることはない。監査はこれを A2 と呼んだ: 各待機後の初回ティックが位相依存で何クロックか遅れて来るため、単純な点滅の high/low 区間がサイクルごとにばらつく、という懸念。ジッタ。それが、我々が狩りに出た幽霊だった。

  The hunt / 狩り

  We measured it white-box first, in Icarus, instrumenting the exact thing A2 was about: the
  prescaler's phase at the instant each wait begins, and the delay until the first tick. Thirteen
  wait windows. The phase at entry was the same every single time. The first-tick delay was the same
  every single time. Zero scatter. No jitter.

  まず白箱で、Icarus で測った。A2 が主張するその当のもの——各待機開始の瞬間のプリスケーラ位相と、初回ティックまでの遅延——を計装して。13 の待機ウィンドウ。突入時の位相は毎回同じ。初回ティック遅延も毎回同じ。ばらつきゼロ。ジッタなし。...

  Read more »

• Build Log: A Place to Keep the Proof

  Tsuneo.Ohnaka • 06/18/2026 at 11:21 • 0 comments

  Build Log: A Place to Keep the Proof

  Build Log：証拠を置く場所

  A different kind of entry / 種類の違う記録

  The previous build logs recorded events: a model understood the specification, a model
  deliberated over it, an agent implemented it, an LED blinked, an address that should not
  exist appeared on a bus. This one records an apparatus. Nothing dramatic happened on a
  bench today. Instead, a structure was put in place — Layer 4, Verification Evidence —
  that changes how every future event of the bench kind will be captured, judged, and
  communicated.

  これまでの build log は出来事を記録してきた: モデルが仕様を理解し、協議し、エージェントが実装し、LED が点滅し、存在してはならないアドレスがバスに現れた。今回記録するのは装置である。
  今日、ベンチの上で劇的なことは何も起きていない。代わりに、ある構造が据えられた——Layer 4、検証エビデンス——それは、今後ベンチで起きるすべての出来事が、どう捕捉され、判定され、伝達されるかを変える。

  The reason it deserves a build log is the architect's own framing of what it bought:

  これが build log に値する理由は、それが何をもたらしたかについてのアーキテクト自身の言葉にある:

  大中: これで、実機動作を通じての私の意図を完璧に、Claude Codeなどのコード設計者にも伝えやすくなりました。
  (With this, my intent — expressed through real-hardware behavior — has become far easier to convey, even to code designers like Claude Code.)

  That sentence contains the whole idea. The hard problem in human–AI hardware collaboration
  is not getting an AI to write Verilog; Build Log #5 settled that. The hard problem is
  conveying intent about behavior — "it must do this, on real silicon, to the clock" —
  in a form an AI code designer can actually consume and act on. Prose cannot carry that
  faithfully; Build Log #6 showed prose deceiving even its own author about a single clock
  edge. Layer 4 carries it as machine-checkable evidence.

  その一文に全アイデアが含まれている。人間-AI ハードウェア協働の難問は、AI に Verilog を書かせることではない;Build Log #5 がそれを決着させた。難問は、振る舞いについての意図——「実シリコン上で、クロック単位で、こう動かねばならない」——を、AI コード設計者が実際に消費して行動できる形で伝えることである。散文はそれを忠実に運べない;Build Log #6 は、たった一つのクロックエッジについて散文がその著者すら欺くさまを示した。Layer 4 はそれを機械検証可能なエビデンスとして運ぶ。

  Why verification became a layer, not a folder...

  Read more »

• Build Log: The Address That Should Not Exist

  Tsuneo.Ohnaka • 06/13/2026 at 14:29 • 0 comments

  Build Log: The Address That Should Not Exist

  Build Log：存在してはならないアドレス

  First light / 初点灯

  On 2026-06-10, the AI-generated PTSG-Core blinked an LED on real hardware for the first time — a DE10-nano, Cyclone V, 50 MHz, prescaler at 50000. The architect had changed only three things in the merged Layer 3 sources: enabled the In-System Memory Content Editor, connected the core to a new memory module, and set the prescaler. Total logic: about 235 LEs and two memory blocks. The "smallness" that Chapter 1 promised was real.

  2026-06-10、AI が生成した PTSG-Core が初めて実機で LED を点滅させた——DE10-nano、Cyclone V、50 MHz、プリスケーラ 50000。アーキテクトがマージ済み Layer 3 ソースに加えた変更は三点だけ: In-System Memory Content Editor の有効化、コアの新メモリモジュールへの接続、プリスケーラの設定。総ロジック約 235 LE、メモリ 2 ブロック。第1章が約束した「小ささ」は本物だった。

  -- blinky_with_prescaler.mif — LED blink at human-visible rate
  -- Recommended core parameter: PRESCALE = 50000 (50 MHz => 1 ms per stay tick;
  -- Stay 500 => ~0.5 s on, ~0.5 s off). See examples/README.md for the encoding.
  DEPTH = 256;
  WIDTH = 32;
  ADDRESS_RADIX = HEX;
  DATA_RADIX = HEX;
  CONTENT BEGIN
  0 : 00010700;   -- NOP    timing_signals = 0x0001 (LED on)
  1 : 00010051;   -- Stay 500 (hold on)
  2 : 00000700;   -- NOP    timing_signals = 0x0000 (LED off)
  3 : 00000051;   -- Stay 500 (hold off)
  4 : 00000013;   -- Jump 1 (loop)
  [5..FF] : 00000000;
  END;
  

  It blinked on the first try. And it was executing every instruction one clock late.

  それは一発で点滅した。そして、すべての命令を 1 クロック遅れて実行していた。

  This Build Log is the story of how that defect was predicted at a desk, photographed by an instrument, repaired by a half clock, and proved by a machine — and of the methodological discovery that started it all: why AI agents refuse to use vendor IP.

  本 Build Log は、その欠陥が机上で予測され、計測器に撮影され、半クロックで修復され、機械によって証明された物語である——そしてすべての始まりとなった方法論的発見の物語でもある: なぜ AI エージェントはベンダ IP を使おうとしないのか。

  The diagnosis: why the AIs won't touch M10K / 診断: なぜ AI は M10K に触れないか

  The architect has collaborated with LLMs on FPGA work long enough to notice a pattern:

  アーキテクトは LLM との FPGA 協働を長く重ね、あるパターンに気づいていた:

  大中: なぜか現段階でAI各位はIntel（Altera）の標準メモリライブラリを使いたがらないのです。「M10Kを使ってください。」と言ってもその部分を残し、「ここはIPカタログ機能を使って自分でやってください。」というのです。そしてこれは、BRAMに限らず、PLLやその他標準IP全般に言えるのです。...

  Read more »

• Build Log: PTSG Field testing — The Cast Is Complete

  Tsuneo.Ohnaka • 06/08/2026 at 14:35 • 0 comments

  Build Log: PTSG 実検証 — 役者が揃った

  1. DE10-nano Board
     

  2. DE10-nano Board Connection and Power On
     
     

  3. DE10-nano Golden Top Sample Project

  4. PTSG-Core repository Layer3 Clone 

  5. PTSG-Memory wrapper

  6. And the shooting environment

• Build Log: The Implementation Closed the Loop

  Tsuneo.Ohnaka • 06/03/2026 at 12:14 • 0 comments

  Build Log: The Implementation Closed the Loop

  Build Log：実装が環を閉じた

  A quiet milestone / 静かなマイルストーン

  On 2026-05-30, an AI coding agent was given a single sentence and a five-chapter specification, and produced — without further human intervention — a working Verilog implementation of PTSG-Core, with a self-written testbench, five reference programs, and a documented response to an external code review. The result was merged into the project repository as Layer 3 the same day.

  2026-05-30、AI コーディングエージェントが一つの文と五章の仕様書を与えられ、そして——それ以上の人間の介入なしに——PTSG-Core の動作する Verilog 実装を、自ら書いたテストベンチ、五つのリファレンスプログラム、そして外部コードレビューへの文書化された応答とともに生成した。結果は同日、Layer 3 としてプロジェクトリポジトリにマージされた。

  This Build Log records that event. It also tells the story of why Chapters 4 and 5 of the specification were written in haste a few days earlier, and what the architect believes this moment may signal for how specifications and hardware relate.

  本 Build Log はその出来事を記録する。同時にそれは、仕様書の第4章と第5章がなぜ数日前に急いで書かれたか、そしてアーキテクトがこの瞬間が、仕様書とハードウェアがどう関係するかについて何を示唆していると信じているかの物語でもある。

  A precaution that became a milestone / 予防策がマイルストーンになった

  A few days before the implementation event, the architect sent the published v1.1 specification — Chapters 1 through 3 — to several LLMs to see how they read the PTSG-Core repository. He reported back something unexpected:

  実装イベントの数日前、アーキテクトは公開された v1.1 仕様書——第1〜3章——を複数の LLM に送り、PTSG-Core リポジトリをどう読むかを見た。彼は予期せぬことを報告した:

  大中： 他のLLMにリポジトリを見せた結果、この時点ですでに第4章、第5章の内容が彼らには想像できてしまうため、コーディングエージェントでなくてもコードが作れてしまいそうな勢いです。
  (After showing the repository to other LLMs, I see that at this point Chapters 4 and 5 are already imaginable to them — so much so that even without a coding agent, they could already produce code.)
  

  He continued — and this is the observation that produced Chapters 4 and 5 in haste:

  彼は続けた——そしてこれが、第4章と第5章を急いで生んだ観察である:...

  Read more »

• Build Log: This Is Also an Open Prompt Validation Project

  Tsuneo.Ohnaka • 05/25/2026 at 14:12 • 0 comments

  Build Log: This Is Also an Open Prompt Validation Project

  Build Log：これは同時にOpen Prompt検証プロジェクトである

  A second purpose, hiding in plain sight / 平易に隠れていた第二の目的

  PTSG-Core has an obvious purpose: to specify a minimal, AI-friendly FPGA control primitive. But over the past two weeks, a second purpose has become undeniable. PTSG-Core is also a live validation experiment for the Open Prompt methodology itself. Every time an LLM reads the repository, deliberates on it, or finds something the human authors missed, the methodology is being tested in the field — not in theory.

  PTSG-Coreには明白な目的がある: ミニマルでAIに優しいFPGA制御プリミティブを規定すること。しかし過去二週間で、第二の目的が否定しがたくなった。PTSG-Coreは同時に、Open Prompt 方法論そのものの生きた検証実験である。 LLMがリポジトリを読み、それについて協議し、あるいは人間の著者が見落としたものを見つけるたびに、方法論は理論ではなく現場で試験されている。

  This Build Log records the most striking validation event so far — one that was entirely accidental, and all the more convincing for it.

  本Build Logはこれまでで最も印象的な検証イベントを記録する——完全に偶発的であり、それゆえにいっそう説得力のあるもの。

  A casual test that became a deliberation / 協議になった軽い試験

  On 2026-05-23, the architect showed the PTSG-Core repository to Gemini 3.5 Flash — a newly-released, lightweight model. The intent was modest: just to check whether a small, fast model could read the repository at all. The architect spoke casually. He did not explain any of the deliberation rules. He was, in his own words, just testing the waters.

  2026-05-23、アーキテクトはPTSG-CoreリポジトリをGemini 3.5 Flash——新たにリリースされた軽量モデル——に見せた。意図は控えめだった: 小さく高速なモデルがそもそもリポジトリを読めるかを確認するだけ。アーキテクトは軽い調子で話した。協議ルールは一切説明しなかった。彼の言葉を借りれば、ただ様子を見ていただけだった。

  What happened instead: Gemini engaged with the Loop command, and within a few exchanges, found a genuine bug in the specification — one that the human architect and the AI amanuensis (Claude) had both missed during careful drafting.

  代わりに起きたこと: GeminiはLoopコマンドに関与し、数回のやり取りのうちに、仕様書の本物のバグを見つけた——人間のアーキテクトとAI祐筆(Claude)の両方が注意深い起草中に見落としていたもの。

  The bug a...

  Read more »

View all 13 project logs