Project Logs

Collapse

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

  Tsuneo.Ohnaka • 3 hours ago • 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 • 5 days ago • 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 »

• Build Log: A Specification Deliberation Experiment — Chapter 2/3 and 13 Open Decisions

  Tsuneo.Ohnaka • 05/22/2026 at 13:40 • 0 comments

  Build Log: A Specification Deliberation Experiment — Chapter 2/3 and 13 Open Decisions

  Build Log：仕様書協議実験 — 第2章/3章と13個の未決事項

  What just happened / 直前に起きたこと

  Chapters 2 and 3 of the PTSG-Core Layer 1 specification have been drafted. Together they cover the full static and dynamic instruction-set surface of PTSG-Core: the 32-bit instruction word, the four opcodes, the internal-control sub-opcodes, the Stay-window concept, the two background-execution modes, the minimum-stay-count constraint, the internal information-holding register, the external stack memory protocol, the insertion (interrupt) mechanism, and the loop counter resource model.

  PTSGコア第1層仕様の第2章と第3章が起草されました。両章合わせて、32ビット命令語、4オペコード、内部制御サブオペコード、Stayウィンドウ概念、裏実行の二モード、最低ステイカウント制約、内部情報保持レジスタ、外部スタックメモリプロトコル、挿入(割り込み)機構、ループカウンタリソースモデルを含む、PTSGコアの全静的・動的命令セット表面をカバーします。

  Across both chapters, decisions were classified into three grades:

  両章を通じて、決定は三段階に分類されました:

  Status	Chapter 2	Chapter 3	Total
  Fixed (F) — architectural commitments / アーキテクチャ的コミットメント	10	14	24
  Convention (V) — could in principle be reconsidered / 原則として再考可能	4	3	7
  Tie (T) — genuinely open, alternatives recorded / 真に開かれた未決事項、代替案記録済み	4	9	13

  The 13 Ties are the load-bearing material of what follows.

  13個のTieが、以下に述べることの荷重を支える素材です。

  The dialogue that led to this Build Log / 本Build Logに至った対話

  The following is the architect–amanuensis exchange that occurred immediately after Chapter 3 was drafted, presented as close to verbatim as the Build Log format permits. It is included here because the decision reached has methodological implications for the PTSG ecosystem beyond this specific instance.

  以下は第3章の起草直後に起きた、アーキテクト–祐筆の会話であり、Build Log の形式が許す限り逐語に近い形で掲載する。ここに含めるのは、到達した決定が今回の事例を超えて、PTSGエコシステムに対する方法論的含意を持つためである。

  The architect's proposal / アーキテクトの提案

  大中: これはかつて私が見た中でも、最も優れた仕様書です。そして特に、「協議前仕様書」として、これほど有用なものは初めて見るものです。...

  Read more »

• Build Log: First Echo from the Field — A Non-Anthropic LLM Reads PTSG-Core

  Tsuneo.Ohnaka • 05/21/2026 at 13:27 • 0 comments

  Build Log: First Echo from the Field — A Non-Anthropic LLM Reads PTSG-Core

  Build Log：現場からの最初の応答 — 非Anthropic LLMによるPTSG-Core読解

  TL;DR

  Following the "Cast Is Complete" Build Log, the PTSG-Core repository was tested in the field. A dialogue with Google Gemini — given only the public PTSG-Core repository, with no PTSG-specific training — produced a sustained engagement covering instruction-list construction, boundary-calculation reasoning, sub-opcode discipline, and the Quartus tool-chain persistence workflow. The dialogue is archived as the first contributed Layer 2 trace at 02_Reasoning_Traces/contributed/dsohnaka/2026-05-20_ptsg-comprehension-by-gemini.md/.json. It demonstrates that Open Prompt's scope boundaries are observably visible to LLMs, that the AI-affinity claim has independent cross-provider support, and that abstract principles in the published documents can be developed into concrete practical workflows by readers with their own LLM collaborators.

  「役者揃いました」Build Logの後、PTSG-Coreリポジトリは現場で試験されました。Google Geminiとの対話——公開されたPTSG-Coreリポジトリのみが与えられ、PTSG特有の訓練はなし——は、命令リスト構築、境界計算による推論、サブオペコード規律、Quartusツールチェーン永続化ワークフローを含む持続的な関与を生み出しました。対話は 最初の貢献された第2層軌跡 として 02_Reasoning_Traces/contributed/dsohnaka/2026-05-20_ptsg-comprehension-by-gemini.md/.json にアーカイブされました。これは、Open Promptのスコープ境界がLLMに観察可能に可視であること、AI親和性主張が独立したクロスプロバイダ支持を持つこと、公開文書中の抽象原理が自身のLLM協働者を持つ読者によって具体的実践的ワークフローに発展可能であることを実証します。

  What happened / 何が起きたか

  The architect provided Gemini with the public PTSG-Core repository (Layer 1 Chapter 1, both Layer 2 inaugural traces, README, LICENSE, CONTRIBUTING) and posed an opening question. The dialogue then progressed through eleven phases, each more probing than the last:

  アーキテクトはGeminiに公開されたPTSG-Coreリポジトリ(第1層第1章、第2層最初の両軌跡、README、LICENSE、CONTRIBUTING)を与え、開始質問を提起しました。対話はそれから11の段階を、各々前段より深く探究的に進みました:

  • Construct a 1-second L-chika program from the architecture. Gemini constructed the canonical three-state program; when prompted with "shouldn't State 1's Stay be reduced by Jump's one clock?", it correctly performed clock-cycle-accurate arithmetic (25,000,000 + 24,999,999 + 1 = 50,000,000). 

  • アーキテクチャから1秒Lチカプログラムを構築する。...

  Read more »

• Build Log: PTSG — The Cast Is Complete

  Tsuneo.Ohnaka • 05/20/2026 at 14:08 • 0 comments

  Build Log: PTSG — The Cast Is Complete

  Build Log：PTSG — 役者が揃いました

  TL;DR

  The PTSG-Core repository is now sufficiently populated to be used. Layer 1 Chapter 1 (Scope and Design Philosophy) and both inaugural Layer 2 reasoning traces are in place. From this point onward, an outside engineer with an LLM collaborator has everything they need to engage with PTSG-Core meaningfully — to read it, replay its design dialogues, regenerate an implementation, or design a new Formation.

  PTSG-Coreリポジトリが利用可能な状態に達しました。第1層第1章(スコープと設計哲学)と、第2層の最初の二つの推論軌跡が出揃いました。本日以降、LLM協働者を伴う外部エンジニアは、PTSG-Coreに実質的に関与するために必要なすべて——読む、設計対話を再生する、実装を再生成する、新しいフォーメーションを設計する——を手にしています。

  What is now in place / 揃ったもの

  Layer 1 — Architectural Specification:

  • 01_Architecture/PTSG_Core_Layer1_Chapter1_Scope_and_Design_Philosophy.md — establishes what PTSG-Core is, the four essential design properties (time/space-axis separation, externalization of Condition, background execution during Stay, AI-affinity as a primary design property), the educational origin (counter-Lチカ as the wrong starting point for FPGA introduction), the Core-Formation separation pattern, and the relationship with the parent FPGA Spectrum Engine project. CC0. 

  •  PTSG-Coreとは何か、4つの本質的設計特性(時間／空間軸分離、Conditionの外部化、Stay中の裏実行、一次設計属性としてのAI親和性)、教育的起源(FPGA入門の誤った起点としてのカウンタLチカ)、コア-フォーメーション分離パターン、親プロジェクトFPGA Spectrum Engineとの関係を確立する。CC0。

  Layer 2 — Reasoning Traces:

  • 02_Reasoning_Traces/2026-05-12_ptsg-emancipation-from-wpms-session.md/.json — the technical-emancipation trace, recording the dialogue within FPGA Spectrum Engine's WPMS Chapter 3 drafting in which PTSG was recognized as too general-purpose to remain inside WPMS. Covers the four foundational decisions: the periodicity-layer framework, the Upper/Lower split, the spin-off, and the session-separation discipline. 

  •  技術的解放軌跡、PTSGがWPMS内に留めるには汎用すぎると認識されたWPMS第3章起草内の対話を記録。4つの基礎的決定(周期レイヤーフレーム、Upper/Lower分割、暖簾分け、セッション分離規律)をカバー。
  • 02_Reasoning_Traces/2026-05-13_ptsg-strategic-positioning.md/.json — the strategic-positioning trace, recording the dialogue one day later in a separate session in which PTSG's broader significance crystallized. Covers the three-layer engagement model, the Webapp simulator vision, the Core-Formation separation pattern, and the "is binary compatibility important in the AI era?" question. 
  • 戦略的位置づけ軌跡、一日後に別セッションで行われ、PTSGのより広い意義が結晶化した対話を記録。三層関与モデル、Webappシミュレータ構想、コア-フォーメーション分離パターン、「AI時代におけるバイナリ互換性は重要か?」という問いをカバー。...

  Read more »

View all 10 project logs