Project Logs

Collapse

• Build Log: The Address That Should Not Exist

  Tsuneo.Ohnaka • 8 hours ago • 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 • 5 days ago • 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 7 project logs