PYNQ 비전 연산자 배포
목표는 소프트웨어 배열, 하드웨어 인터페이스 및 검증 결과가 서로 대응되도록 하는 것입니다. 먼저 사용자가 새 연산자 배포, 기존 결함 분석, 또는 성능 최적화 중 어떤 작업을 수행하려는지 확인하고, 기존 권한 및 프로젝트 상태를 그대로 사용합니다. 모든 작업을 완전한 재훈련 또는 재구성으로 확장하지 않습니다.
최소 입력
알고리즘/전처리, 최소 한 세트의 황금 입력-출력, bit/HWH 또는 HLS 최상위 모듈, 실제 보드 및 PYNQ 환경이 필요합니다. 항목이 누락된 경우 먼저 제공된 자료로 가능한 오프라인 검사를 수행하고, 어떤 결론이 누락된 자료에 의존하는지 지적합니다.
마이그레이션 설명을 읽고 텐서 계약을 작성합니다. 예제는 일반적인 그레이스케일 텐서이며, 임의 보드에 직접 로드할 수 있는 하드웨어 구성이 아닙니다. 새 모델은 shape, dtype, layout, 색상, 스케일/패딩, 양자화 스케일, 반올림, 포화, 출력 디코딩 및 전송 바이트 수를 다시 결정해야 합니다. INT4와 같은 비트 수준 형식은 패킹 규칙을 별도로 작성해야 하며, 기존 계약 검사기는 패킹되지 않은 숫자 배열만 허용합니다.
검증 경로 선택
- 최초 연결: 계약 검사 → 고정 입력 정수 참조 → 단일 프레임 PL 원시 출력 → 연속 프레임 → 애플리케이션 정밀도 → 구간 타이밍.
- 결과 불일치: 전처리, 양자화 노드 및 PL 원시 텐서를 단계별로 저장하여 첫 번째 차이 지점을 찾습니다. 먼저 후처리 임계값을 수정하여 이전 단계 오류를 가리지 마십시오.
- 처리율 또는 지연 이상: 고정 입력 조건에서 동일한 클록 도메인의 프레임 번호 및 타임스탬프를 기록합니다. 타이밍 스크립트를 사용하여 큐잉, PL/DMA 및 후처리를 구분합니다.
- 보드 교체: DMA, 주소 폭, 캐시 일관성, 클록 리셋 및 인터럽트를 다시 식별합니다. 황금 참조와 비교 방법은 유지합니다.
재현 가능한 전체 프롬프트는 워크플로우에 있으며, 현재 작업에 해당하는 항목만 읽습니다.
하드웨어와 버퍼
먼저 표준 AXI DMA와 사용자 정의 HLS IODMA를 구분합니다. 표준 단순 모드는 어댑터 템플릿을 참조할 수 있습니다. 사용자 정의 인터페이스는 레지스터 및 고정 길이/TLAST 계약에 따라 구현해야 합니다. Python API 이름을 하드웨어 프로토콜로 간주하지 마십시오.
연속 버퍼는 소유권을 명확히 해야 합니다. CPU가 쓴 후 장치로 동기화하고, 하드웨어가 완료되고 더 이상 액세스하지 않은 후에 CPU로 다시 동기화합니다. 예외 발생 시 진행 중인 버퍼를 유지하며 finally에서 무조건 해제하지 않습니다. 자세한 내용은 DMA 생명주기를 참조하십시오.
HWH는 인터페이스 설명이며 디스크에 bit가 로드되었음을 증명하지 않습니다. 로드된 하드웨어를 바인딩할 때 로드 ID, 주소 및 참조 출력을 확인합니다. LCD와 추론이 PL을 공유하는 경우 두 개의 완전한 Overlay를 순차적으로 로드하여 결합된 하드웨어를 얻을 수 없습니다.
검증 및 최적화
정수 하드웨어 원시 출력은 원칙적으로 요소별로 정확히 일치해야 합니다. 부동 소수점 알고리즘은 사전에 지정된 절대 허용 오차를 사용하고 dtype 및 무한대/비정규 값을 기록합니다. 비교 스크립트를 사용하며 허용 오차를 확대하여 인터페이스 문제를 해결하지 마십시오. 양자화 모델 정확도와 구현 일관성은 별도로 평가합니다.
LUT, Slice, FF, BRAM, DSP, 타이밍 및 스트림 역압(backpressure)을 동시에 확인합니다. FIFO는 고정 가중치, 입력, 주파수 및 병렬 처리 수준과 비교합니다. 모델 변경 후 결과는 별도로 나열합니다. 처리율은 유효 완료 프레임 수를 실제 측정 창으로 나누어 계산하고, 지연은 동일한 프레임의 양 끝 시간을 기준으로 계산하며 각 단계의 중앙값을 더하지 않습니다.
계약, 원시 출력, 소스/bit/HWH ID, 검사 결과 및 측정 범위를 전달합니다. 일반적인 오류 및 방법 실패 조건은 문제 해결 목록을 참조하십시오. 프로젝트 효과 및 마이그레이션 가능 경계는 검증 설명을 참조하십시오.