프로토타입 · 미리 보기: 공식 레지스트리의 모든 서버를 담고 있으며 30분마다 동기화해요. 리뷰와 계정 기능은 다음 단계에서 열려요.
PopNx MCPAI를 쓰는 사람을 위한 MCP 서버 · 쉬운 말로 설명해요

Neosyn Fpga MCP

제작자: Neosyn-Logic버전 1.4.0i★ –i내 컴퓨터에서 실행
레지스트리 이름io.neosyn/neosyn-fpga-mcp

설치

개요

제작자가 쓴 설명(영어 원문)

AI-agent MCP server for FPGA design: compile, validate & generate Verilog from C⏚ HDL.

PopNx MCP의 세 기둥

이 세 가지는 절대 하나의 점수로 합치지 않아요. 의견, 측정, 인기는 서로 다른 것이니까요.

할 수 있는 일

이 서버는 아직 쉬운 말로 된 요약을 쓰지 못했어요. 아래는 레지스트리에서 읽어 온 사실이에요.

  • 연결 방식: 내 컴퓨터에서 실행
  • 전송 방식: stdio
  • 카테고리: 디자인, 이미지 및 오디오

설치

쓰고 있는 AI 앱을 고른 다음 설정을 복사하세요.

설치하기 전에

필요한 것

  • PyPIPython의 uv 설치(uvx 명령어용)

어떤 앱을 쓰세요?

위에서 앱을 고르세요. 기억해 두었다가 다음부터는 버튼에 “…에 설치”라고 표시해요.

Claude Desktop → Settings → Developer → Edit Config를 열고 claude_desktop_config.json에 이 내용을 붙여 넣으세요

{
  "mcpServers": {
    "neosyn-fpga": {
      "command": "uvx",
      "args": [
        "neosyn-fpga-mcp"
      ],
      "env": {
        "CG_JAR": "your-value"
      }
    }
  }
}

터미널에서 이 명령어를 실행하세요

claude mcp add neosyn-fpga --env CG_JAR=your-value -- uvx neosyn-fpga-mcp

실행하기 전에 빈 값을 채워 주세요.

Cursor에서 열기

또는 설정을 직접 복사하기

프로젝트의 .cursor/mcp.json 또는 ~/.cursor/mcp.json에 붙여 넣으세요

{
  "mcpServers": {
    "neosyn-fpga": {
      "command": "uvx",
      "args": [
        "neosyn-fpga-mcp"
      ],
      "env": {
        "CG_JAR": "your-value"
      }
    }
  }
}

브라우저가 앱을 열지 물어본 다음, 앱이 설정을 보여 주고 확인을 요청해요. 키 값은 비워 두니 직접 입력하세요.

VS Code에서 열기

또는 설정을 직접 복사하기

프로젝트의 .vscode/mcp.json에 붙여 넣으세요

{
  "servers": {
    "neosyn-fpga": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "neosyn-fpga-mcp"
      ],
      "env": {
        "CG_JAR": "your-value"
      }
    }
  }
}

브라우저가 앱을 열지 물어본 다음, 앱이 설정을 보여 주고 확인을 요청해요. 키 값은 비워 두니 직접 입력하세요.

이 서버는 내 컴퓨터에서 실행되는데, ChatGPT는 인터넷에 있는 서버에만 연결할 수 있어요. 다른 앱을 고르세요.

선택한 앱은 이 기기의 쿠키에만 저장돼요. 계정은 필요 없어요.

직접 입력할 값

  • CG_JAR env
    Path to the C⏚ compiler jar (cg-language-server.jar). Download the prebuilt jar from the cg-compiler GitHub releases.

이 설정은 제작자의 레지스트리 정보로 만들었어요. README와 다르면 README를 따르세요.

할 수 있는 일

내 컴퓨터에서 실행돼요. 설치하면 AI 앱에 도구 목록이 나타나요.

기본 점검i

누구나 볼 수 있는 정보를 점검했고, 코드는 읽지 않았어요. 해당하지 않는 항목은 개수에서 뺐어요. · 2026년 11월 7일 점검

  • ✓ 통과

    제작자와 저장소 일치

    레지스트리 이름이 도메인 neosyn.io 기준으로 확인되었어요(레지스트리가 도메인 소유를 확인해요)

  • … 아직 점검 안 함

    계속 관리되고 있음

    아직 GitHub에서 이 저장소를 읽어 오지 않았어요

  • … 아직 점검 안 함

    라이선스 있음

    아직 GitHub에서 이 저장소를 읽어 오지 않았어요

  • – 해당 없음

    엔드포인트 응답

    내 컴퓨터에서 실행되는 서버라 인터넷 엔드포인트가 없어요

  • – 해당 없음

    OAuth로 로그인

    내 컴퓨터에서 실행되며, 대신 로컬 설정을 사용해요

  • … 아직 점검 안 함

    도구 설명에 숨겨진 지시 없음

    내 컴퓨터에서 실행돼요. 도구 목록은 인터넷 엔드포인트가 있는 서버에서만 읽을 수 있어요

디자인, 이미지 및 오디오 카테고리의 다른 서버와 비교i

  • 이 카테고리의 다른 서버 2204개 중 0%보다 스타가 많아요
  • 이 카테고리의 다른 서버 2204개 중 41%보다 최근에 레지스트리에 공개됐어요
  • 기본 점검 결과가 이 카테고리의 다른 서버 2204개 중 100%와 같거나 더 좋아요

레지스트리에서 이 카테고리의 활성 서버 전체와 비교했어요. 스타는 게시자가 저장소를 소유한 경우에만 세요.

자주 묻는 질문

Neosyn Fpga MCP, 안전한가요?

해당하는 기본 점검 1개 중 1개를 통과했어요. 코드는 읽지 않았어요. 키나 토큰을 넣기 전에 서버가 어떤 권한을 요구하는지 확인하고, 꼭 필요한 권한만 있는 키를 쓰세요.

어떤 키나 코드가 필요한가요?

레지스트리에 필수 키가 나와 있지 않아요. 다만 처음 쓸 때 로그인을 요구하는 서버도 있어요.

내 컴퓨터에서 실행되나요, 클라우드에서 실행되나요?

내 컴퓨터에서 실행돼요. AI 앱이 필요할 때 실행하고, 데이터는 제작자의 서버를 거치지 않아요(서버 자체가 온라인 서비스를 호출하는 경우는 제외).

아직 관리되고 있나요?

GitHub 저장소는 마지막으로 – 변경됐고, 최신 버전(1.4.0)은 38일 전 레지스트리에 올라왔어요.

어떤 앱에서 쓸 수 있나요?

Claude Desktop, Claude Code, Cursor, VS Code처럼 MCP를 지원하는 앱에서 쓸 수 있어요. 내 컴퓨터에 Python (uv)도 있어야 해요.

대신 쓸 수 있는 건 뭐가 있나요?

같은 카테고리에는: Figma Context MCP, Claude Real Video, Figma MCP Server

대안

같은 카테고리에서 다른 제작자가 만든 서버예요. 스타 순으로 정렬했어요.

카드 보는 법:★ GitHub 스타i세 기둥: 리뷰 · 점검 · 사용 정도i업데이트 = 최신 버전을 레지스트리에 공개한 날i

Figma Context MCP

제작자: GLips

Give your coding agent access to your Figma data. Implement designs in any framework in one-shot.

내 컴퓨터에서 실행★ 16,165MIT5개월 전 업데이트
설치

Claude Real Video

제작자: HUANGCHIHHUNGLeo

Let any LLM watch a video locally — and search everything it has ever watched.

내 컴퓨터에서 실행★ 2,284MIT2개월 전 업데이트
설치

Figma MCP Server

제작자: figma

The Figma MCP server brings Figma design context directly into your AI workflow.

클라우드에서 실행★ 2,15213개월 전 업데이트
설치

제작자의 README

README 열기

제작자의 저장소에서 쓰인 그대로 가져왔어요. PopNx MCP가 검토하거나 보증한 내용이 아니에요. HTML, 이미지, 스크립트는 제거했어요. 링크를 누르면 이 사이트를 벗어나요.

neosyn-fpga-mcp

An MCP server that hands the C⏚ FPGA toolchain to an AI agent. The model writes hardware; the server compiles, simulates and synthesis-checks it against the real compiler, and hands back structured diagnostics the model can act on.

That is the difference worth caring about. An LLM asked for Verilog will confidently emit something that does not build, does not synthesize, or silently folds away to nothing. Here every step is judged by the same compiler a human uses.

Two parts work together:

  1. `cg_context.md` — a knowledge pack. Load it as the system prompt and the model can write plausible C⏚: the mental model, types, ports, structs/enums/generics, the standard library, and the gotchas that sink first drafts.
  2. the MCP server — the compiler as tools, so the model verifies its own output instead of recalling it.

Knowledge gives a good first draft; the compiler in the loop makes it right. Both are model-agnostic — any stdio-MCP host (Claude Desktop, Claude Code, Cursor, Cline) works, and the context pack works with any LLM at all.

Why not fine-tune? C⏚ is a niche language with little public code, and it gains features every release. A fine-tuned model is expensive and goes stale. In-context knowledge plus a verification loop costs nothing to retrain, tracks the language as the compiler evolves, and converges by *running* code rather than recalling it.

Install

pip install neosyn-fpga-mcp

Then point it at a C⏚ compiler jar:

export CG_JAR=/path/to/cg-language-server.jar

Two ways to get that jar:

  • Open source — a prebuilt jar from cg-compiler releases, or build it from source.
  • Commercial — the jar inside an installed Neosyn C⏚ extension, which adds the fast bytecode simulator and VHDL output. It needs your licence file: set NEOSYN_CG_LICENSE to it, or keep it at the default path the extension uses. Without one, every tool reports the licence problem instead of running.

cg_capabilities reports which one you have and what it can do, probed rather than assumed.

Requirements

  • Python 3.10+
  • Java 17 or newer on PATH — the jar's bytecode targets 17.
  • Optional: yosys on PATH for cg_synth (override with $YOSYS); iverilog for cg_simulate(simulator='iverilog'). Neither is needed for cg_check, cg_generate_verilog, or the bytecode simulator.

Smoke-test the verification core without an MCP client:

python3 - <<'EOF'

from neosyn_fpga_mcp import cg_mcp_server as cg print(cg.simulate("package d;\ntask T { properties { test: { v:[1,2,3] } }\n" " out push u8 v; u8 c; void setup(){c=0;}\n" " void loop(){c=c+1; v.write(c);} }")) EOF

Connect it to an MCP host

Add a server entry. Use absolute paths.

{

"mcpServers": { "cg": { "command": "neosyn-fpga-mcp", "args": [], "env": { "CG_JAR": "/abs/path/to/cg-language-server.jar" } } } }

The same command/args/env shape works for Claude Desktop, Claude Code, Cursor, Cline and other stdio-MCP hosts.

Then load `cg_context.md` as the system prompt (or paste it at the top of the conversation). The model now knows the language *and* can verify it.

Tools the server exposes

13 tools. Every tool that takes source accepts source (a C⏚ string) and an optional extra_files map ({"Defs.cg": "..."}) for imported bundles/tasks.

These are the only names that exist, and the server says so rather than hoping you read this table: a call to a tool that does not exist comes back with the whole list and the closest real name (cg_compile → "did you mean cg_check?"), cg_capabilities carries the list, and the first call of a session carries it once. The list is generated from the tool registry, so it cannot drift out of step with the table below.

ToolParams (besides source / extra_files)ReturnsWhen to use it
cg_check—{ok, diagnostics:[…], warnings:[…], summary}After cg_lint, on any draft — fix every diagnostic before simulating. warnings carries validator findings the compiler accepts but objects to (bool == 1, assigning to a const): ok stays true because the program does compile, and the summary says so, because ok is the field that gets acted on. Needs a compiler ≥ 2.10.0 — older ones report nothing here.
cg_simulatetimeout=60, simulator='bytecode'{ok, simulator, timed_out, diagnostics, output}The ground-truth correctness check. output holds port values + print() lines; a properties { test: {...} } block self-checks. Iterate until ok.
cg_generate_verilogtarget='verilog', output_dir=None, top=None{ok, file_count, files:{path:content}} (+ {output_dir, written} when persisted)After simulate passes, to hand off RTL. target is 'verilog' or 'vhdl'. Pass output_dir (relative to $PROJECT_ROOT) to write the files to disk and keep them. Pass top (an entity name) to emit only that entity and what it instantiates; needs a compiler newer than 3.4.0, and an older one is refused rather than emitting everything.
cg_synthtop=None, timeout=180, flow='generic'{ok, verdict, top, flow, cells, arith_ops, latches, warnings, stat, problems, output}The strongest correctness signal — yosys-synthesizes the Verilog. verdict ∈ REAL / FOLDED (constant-folded — inputs weren't on ports) / SUSPECT (latches inferred) / ERROR, so you can't confabulate success. warnings explains a degenerate datapath or inferred latch.
cg_capabilities—{ok, jar, jar_present, bytecode_simulator:{available,reason,detail}, simulators:[…], tools:{…}, advice}What this host can actually do, probed rather than assumed. The fast bytecode simulator ships with the commercial distribution and is absent from the open-source compiler, so any flat claim about it is wrong in one of the two environments — call this before deciding how to verify.
cg_scaffoldkind='task', name, package, inputs, outputs, verify=True{ok, kind, source, holes:[{line,text}], verified:{check,simulate}, message}Start here when writing new C⏚ from a blank file. Returns a complete, COMPILING, self-checking skeleton with the datapath left as >>> FILL IN holes, verified green before you get it — so any later failure is your edit. kind ∈ task (a sync task whose test: block value-checks every output cycle by cycle — the default and the strongest) / fsm / stream / network / generic. inputs/outputs are "name:type" strings, honoured for task and stream. Complements cg_example: scaffold when writing something new, example when a validated implementation of the kernel already exists.
cg_examplepattern='', k=1no pattern → {ok, index:[{name,kind,use_when,tags}]}; a pattern → {ok, name, kind, source, …, runners_up:[…]}Scored lazy lookup into the validated-code dictionary (NOT search). Specificity-weighted, so 1/sqrt→RSqrt but sqrt→FixedSqrt; returns 1-2 runners-up to self-correct. k>1 returns more sources for composition.
cg_lint—{ok, findings:[{rule,line,severity,message,fix}]}Static checks for code the compiler accepts and is still wrong. Chiefly a test: fixture that drives inputs but compares no output — it passes even with a dead design. No jar and no simulator, so run it on every draft before cg_check, and again before claiming a design is verified.
cg_suggest_for_errormessage{ok, recipe, hint, source}Map a compiler rejection to the recipe with the fix pattern (div/shift-by-variable → Recip; data-dependent loop bound → SeqDiv). cg_check/cg_simulate/cg_generate_verilog auto-attach this as a suggestion when a diagnostic matches.
cg_reportreport_dir='fpga/build', schematics=True{ok, report, kernels, sim_ok, message}Finalize the FPGA report: renders /report.html (synthesis table with the REAL/FOLDED/SUSPECT verdict and cell counts, the simulation PASS/FAIL, the generated-Verilog list, and best-effort datapath SVGs). Does no synthesis — the rows accumulate as a byproduct of passing the same report_dir to cg_synth and cg_simulate.
cg_fsmtask=None{ok, diagnostics, fsm}Confirm a task's compiled state machine has the intended states/transitions.
cg_graphnetwork=None{ok, diagnostics, graph}Confirm a network's compiled wiring (instances, ports with widths/interfaces, connections).
cg_docstopic=''no topic → {ok, topics:[{topic,description}]}; a topic → {ok, topic, description, content}Fetch a markdown knowledge doc on demand. context = the core C⏚ language pack; riscv = the worked RV32I CPU reference (loadable single-cycle core + reusable patterns for CPU-shaped hardware: barrel shifter, signed/unsigned widening, sub-word load/store, boot-stream program loading, testbench capture). Read riscv when building a processor/decoder/datapath/stack machine.
Choosing a backend

Two tools take a backend selector:

  • `cg_simulate(source, simulator=…)` — which simulator runs the design:
  • 'bytecode' *(default)* — the compiler's fast bytecode simulator. No HDL toolchain needed; a properties { test: {...} } block self-checks. cg_simulate(src) or cg_simulate(src, simulator="bytecode").
  • 'iverilog' — generate Verilog + a testbench and run Icarus Verilog (vvp), a Verilog-level cross-check. A testbench is emitted only for a network whose name contains `Test` with a capital T (e.g. network TestFoo); a lowercase _test network drives the bytecode sim's test property only, not iverilog. Needs iverilog on PATH. cg_simulate(src, simulator="iverilog").
  • 'verilator' — accepted for forward-compat but reported unavailable unless the verilator binary is installed. cg_simulate(src, simulator="verilator").
  • `cg_synth(source, flow=…)` — which yosys synthesis flow runs:
  • 'generic' *(default)* — portable synthesizability check (synth). cg_synth(src) or cg_synth(src, flow="generic").
  • a vendor FPGA family — 'ice40', 'ecp5', 'xilinx', 'gowin', 'intel' — maps to that part's primitives (LUTs/BRAM/DSP). cg_synth(src, flow="ice40").

top defaults to the first non-testbench task/network (the synthesizable DUT); pass it when a file holds several designs. Override the yosys binary with $YOSYS.

How the model should use it

  1. Draft C⏚ (always starting with package).
  2. cg_lint → free and instant; catches the mistakes the compiler will happily accept, above all a test: block that checks nothing.
  3. cg_check → fix every diagnostic, and read warnings: those are the compiler's own objections to code it will nonetheless accept.
  4. cg_simulate → confirm ok: true and that the output matches intent.
  5. cg_generate_verilog once it simulates, to hand off RTL.
  6. cg_synth (optional) → confirm the Verilog maps to real hardware (ok: true, a sensible cells count, no problems).

Step 2 exists because steps 3–4 can BOTH pass on a design that does nothing: a fixture with no output vector is green against a dead DUT. cg_lint is the only step that catches that, and it costs nothing to run.

The loop in steps 2–3 is the point: the model writes, the compiler judges, the model fixes. cg_context.md ends with the same protocol so the model follows it even without separate instruction.

The loop, end to end
from neosyn_fpga_mcp import cg_mcp_server as cg

src = '''package com.example.demo; task Counter { properties { test: { value: [1, 2, 3] } }

앞부분만 보여 드려요. 나머지는 저장소에서 읽어 보세요

PopNx에게 묻기