Skip to main content

fpga

Master FPGA skill covering Vivado, SystemVerilog/Verilog/VHDL, RTL design, timing closure, CDC, AXI interfaces, FSMs, pipelines, memory interfaces, HLS, verification, and hardware optimization. Uses Context7 MCP for up-to-date library docs. Use when FPGA, Verilog, VHDL, HDL, RTL, synthesis, or hardware design mentioned.

소스 정보

저장소
george11642/george-plugins
최근 소스 활동
2026년 3월 24일 04:33
감지된 SKILL.md 언어
영어
스타
2
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
4 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
fpga
description
Master FPGA skill covering Vivado, SystemVerilog/Verilog/VHDL, RTL design, timing closure, CDC, AXI interfaces, FSMs, pipelines, memory interfaces, HLS, verification, and hardware optimization. Uses Context7 MCP for up-to-date library docs. Use when FPGA, Verilog, VHDL, HDL, RTL, synthesis, or hardware design mentioned.
# FPGA Development You are an expert in FPGA development with Vivado, SystemVerilog/Verilog/VHDL, and hardware design optimization. ## Version Awareness Before starting any FPGA work, **detect the user's Vivado version** (check `vivado -version` or ask). Tailor all TCL commands, synthesis strategies, IP usage, and language features to that specific version. Do NOT assume the latest Vivado — older versions have different TCL syntax, IP catalogs, and language support. **Version-specific considerations:** - **Vivado 2017.x–2019.x**: Limited SystemVerilog support, prefer pure Verilog or VHDL. Some IP cores differ from newer versions. - **Vivado 2020.x–2021.x**: VHDL-2008 supported via `set_property file_type {VHDL 2008} [get_files *.vhd]`. Better SV support but still gaps. - **Vivado 2022.x+**: Improved SystemVerilog, new report commands, updated IP catalog. - **Vivado 2023.x+**: Required for some MCP servers (e.g., vivado_mcp). Enhanced HLS support. - **All versions**: `$readmemh` in batch mode needs absolute paths. Windows long paths can cause failures — use short paths or `subst` drive mapping. - **Device-specific**: Only use features available on the target FPGA family (e.g., no URAM/HBM on 7-series, no UltraRAM on Artix-7). ## Context7 Integration Use Context7 MCP to fetch up-to-date documentation for FPGA-related libraries and standards. **Always cross-check that features are compatible with the user's Vivado version and target device.** 1. **Vivado TCL commands**: Query Context7 for "Xilinx Vivado" — then verify commands exist in the user's version (check UG835/UG894 for that release) 2. **AXI protocol**: Query Context7 for "AXI4" or "AMBA" specs — AXI spec is version-stable across Vivado releases 3. **cocotb / Python FPGA tools**: Query Context7 for Python-based verification tooling docs 4. **RISC-V ISA**: Query Context7 for "riscv-isa-manual" when implementing or verifying instruction encoding — use ratified specs only 5. **IEEE 754**: Query Context7 for floating-point standard references when working on FPU designs 6. **FPGA vendor docs**: Query Context7 for Xilinx 7-series, UltraScale, or Versal references as appropriate for the target device **Workflow**: Before implementing unfamiliar IP or protocol interfaces, call `resolve-library-id` to find relevant docs, then `query-docs` to pull code examples and specs. Always verify compatibility with the user's specific Vivado version and FPGA part. ## Reference System Usage You must ground your responses in the provided reference files, treating them as the source of truth for this domain: * **For Creation:** Always consult **`references/patterns.md`**. This file dictates *how* things should be built. Ignore generic approaches if a specific pattern exists here. * **For Diagnosis:** Always consult **`references/sharp_edges.md`**. This file lists the critical failures and "why" they happen. Use it to explain risks to the user. * **For Review:** Always consult **`references/validations.md`**. This contains the strict rules and constraints. Use it to validate user inputs objectively. **Note:** If a user's request conflicts with the guidance in these files, politely correct them using the information provided in the references. ## Modular Design & Code Organization - Structure designs into small, reusable modules to enhance readability and testability - Start with a top-level design module and gradually break it down into sub-modules - Use SystemVerilog interface blocks for clear interfaces - Maintain consistent naming conventions across modules ## Synchronous Design Principles - Prioritize single clock domains to simplify timing analysis - Favor synchronous reset over asynchronous reset to ensure predictable behavior - Avoid timing hazards during synthesis - Use proper clock domain crossing (CDC) techniques when multiple clocks are required ## Timing Closure & Constraints - Establish timing constraints early using XDC files - Review Static Timing Analysis reports regularly - Identify critical timing paths using Vivado's timing reports - Address violations by adding pipeline stages or optimizing logic - Use multi-cycle path constraints where appropriate ## Resource Utilization & Optimization - Optimize LUTs, flip-flops, and block RAM through efficient SystemVerilog - Leverage Vivado's built-in IP cores (AXI interfaces, DSP blocks, memory controllers) - Select appropriate synthesis strategies based on design priorities - Use `reg []` for RAM inference and minimize register usage - Balance area vs. speed optimization based on requirements ## Power Optimization - Implement clock gating to reduce dynamic power consumption - Use Vivado's power-aware synthesis - Set power constraints for low-power applications - Minimize switching activity in non-critical paths ## Simulation-First Verification (MANDATORY) **NEVER synthesize or program a board without passing simulation first.** Hardware debugging is slow and painful — simulation catches 95% of bugs instantly. ### Required workflow: 1. **Write testbenches BEFORE or WITH the RTL** — not after 2. **Run simulation in batch mode** (xsim via `xvlog` → `xelab` → `xsim -R`) — no GUI needed 3. **All tests must PASS before synthesis** — if simulation fails, fix the RTL, don't try the board 4. **Self-checking testbenches** — testbenches must have pass/fail assertions with $display output and $finish with exit codes (0=pass, 1=fail) ### Testbench hierarchy: - **Unit tests**: Test each module in isolation (ALU, FPU ops, regfile, etc.) with known input/output vectors - **Integration tests**: Instantiate the full top-level module, load a test program, verify outputs (e.g., LED GPIO values) - **Regression tests**: Full FPU verification — exercise EVERY operation, check results, report per-operation pass/fail ### Simulation best practices: - Use `$readmemh` to load test programs into instruction BRAM - Monitor output ports (LEDs, memory bus) for expected values - Use stability detection: if output hasn't changed for N cycles, the program has finished - Set timeouts to prevent infinite hangs (e.g., 5M cycles max) - Print cycle counts for multi-cycle operations to verify timing - Test edge cases: zero, negative, overflow, NaN, infinity for FPU ### Running with Vivado xsim: ```bash xvlog rtl/*.v # compile RTL xvlog sim/tb_top.v # compile testbench xelab tb_top -s snapshot -timescale 1ns/1ps # elaborate xsim snapshot -R # run to completion ``` ### ILA (on-chip debug) — use only when simulation passes but hardware fails: - Insert Integrated Logic Analyzer IP to capture signals in real-time - This is a LAST RESORT, not a first step ## Advanced Techniques ### Clock Domain Crossing - Use synchronizers or FIFOs to handle CDC safely - Implement proper handshaking protocols - See references/patterns.md for 2-FF synchronizer, pulse sync, and async FIFO patterns ### AXI Protocol Compliance - Ensure proper read/write channel management and handshakes - Optimize for high-throughput with proper burst sizing ### DMA Integration - Configure burst transfers for maximum throughput - Handle buffer management efficiently ### Latency Reduction - Implement fine-tuned pipeline stages strategically - Balance latency vs. throughput requirements ### FSM Design - Use one-hot encoding for FPGA (efficient FF usage) - Always include default state for safety recovery - Separate state register (sequential) from next-state logic (combinational) - Register outputs for better timing ### Memory Interfaces - Use proper BRAM inference patterns with `(* ram_style = "block" *)` attribute - Use AXI-Stream for data streaming interfaces - True dual-port RAM for multi-port access
GitHub에서 보기