Edit in IP Packager에서 코드 수정 후 IP 수정하면 simulation에서 수정된 코드로 작동이 안됩니다

안녕하세요 🙂이 문제는 Edit in IP Packager에서 수정한 코드가 Vivado 프로젝트의 시뮬레이션 경로에 제대로 반영되지 않아서 생기는 현상입니다. 핵심은 IP를 수정하고 update IP만 한 것으로는 simulation source 경로가 자동으로 갱신되지 않는다는 점 입니다.Vivado의 시뮬레이션은 기본적으로 “project 내에 복사된 simulation용 wrapper 파일”을 바라보고 동작합니다. 즉, IP Packager 안에서 코드를 수정해도, update IP를 한 뒤에 generate output products → generate simulation sources를 다시 해줘야 Vivado가 수정된 파일을 simulation 경로로 반영합니다.그래서 아래 순서로 정리드릴게요.Edit in IP Packager에서 수정 후 저장Packager 창 닫을 때 반드시 “Package IP → update repository”까지 완료Vivado로 돌아가서 해당 IP 선택 후오른쪽 클릭 → “Regenerate Output Products”다시 오른쪽 클릭 → “Generate Simulation Sources”그 뒤 simulation을 다시 실행이렇게 해야 Vivado가 기존 simulation 디렉토리 안의 .v 파일을 새로 덮어씁니다.만약 그래도 반영이 안 된다면, simulation 폴더(sim_1/simulations/ip_name)를 직접 삭제한 후 위 단계를 다시 하면 됩니다. Vivado가 새로 복사하면서 최신 IP 코드로 시뮬레이션을 돌립니다.그리고 이런 문제를 반복해서 겪지 않으려면, IP를 수정할 때마다 Vivado에서 Tools → Report IP Status로 확인하세요. “Out of date”가 표시되는 IP는 반드시 regenerate를 해야 simulation이 정상 반영됩니다.정리하면, update IP만으로는 simulation 쪽이 갱신되지 않고, generate output + generate simulation sources 두 단계를 꼭 수행해야 수정된 코드로 동작합니다.즐공하세요!

mobaxterm 완전 삭제법

안녕하세요 🙂외부 툴과 관련된 이슈는 AI 나 구글링이 좋을 것 같은데요.AI 인턴이 말해준 방법을 시 해보시겠어요?

메모리의 형태가 전체설계에 미치는 영향이 궁금합니다.

안녕하세요 🙂AI 인턴이 기초적인 답을 잘 달아줘서, 기본적인 이론 내용은 참고하시면 될 것 같아요.제 추가 답변은 다음과 같습니다.FPGA 내에는 Primitive cell 이라고 부르는, 이미 chip 안에 존재하는 로직들이 존재합니다.FPGA 에서의 Verilog 코드 동작은 바로 이 로직들을 Verilog 코드로 만든 IP 가 사용하게 하는 것이겠죠.PnR 과정을 거쳐서요.Primitive bram 이 chip 내에 존재하고요. 해당 메모리 shape 이 어떻게 생겼는지를 이해해보면, 더 많은 Bram 용량을 사용할 수 있습니다.이해를 돕기위해서 극단적으로 예를들어보면, 사용하시는 FPGA 내에 BRAM이 RAMB18E1 만 있다고 가정해보죠. https://docs.amd.com/r/en-US/ug953-vivado-7series-libraries/RAMB18E1(사진)Din/Dout 은 16 bits 입니다.만약에 width 를 1로 사용한다면, 15 만큼의 빈공간 (안쓰는 영역) 이 생기겠죠.즉 한정된 자원 중에서 1/16 만큼만 사용하게 되는 불상사? 가 발생합니다.사용하시는 FPGA Chip set 내에 BRAM 의 shape 을 잘 파악하시고, memory size 를 설계하시면 Area 효율적인 설계가 가능하실꺼에요.즐공하세요 🙂

디스코드 멤버쉽 등업 관련 문제

앗 이런!!오늘 저녁에 확인해보겠습니다.쪼금만 기다려주셔요!!

BRAM의 Read / Write를 다 수행했는지 확인할 때 사용되는 num_cnt / i_num_cnt 관련 질문

안녕하세요!!추석연휴라서 답변이 조금 밀렸네요 ㅠ질문 요지는 “왜 i_num_cnt를 바로 쓰지 않고 레지스터 num_cnt에 캡처하느냐”로 이해했습니다. 결론부터 말하면, 비교 기준을 트랜잭션 단위로 고정하고 타이밍을 안정화하려는 의도입니다. 항목별로 답드리겠습니다.맞습니다. num_cnt를 레지스터로 두면 플립플롭 자원이 들고, i_run에 캡처되는 시점만큼 한 사이클의 지연이 생깁니다. 다만 이 비용은 보통 폭만큼의 FF(예: AWIDTH비트)라서 매우 작고, 시스템 타이밍 측면에선 이득이 더 큽니다.장점은 세 가지가 핵심입니다.원자성 보장: i_num_cnt가 트랜잭션 도중 바뀌어도, 캡처된 num_cnt는 끝날 때까지 값이 고정됩니다. done 비교 기준이 흔들리지 않습니다.타이밍/글리치 차단: 상위 로직의 조합 경로가 길거나 글리치가 있어도 FF에서 한번 끊어 주므로 비교 경로가 짧고 깨끗해집니다(타이밍 클로저 유리).리셋·상태 경계 명확화: 코드처럼 o_done에서 0으로 클리어하면 트랜잭션 경계가 분명해집니다. 차기 트랜잭션 시작 전에 기준값이 남아있어 생기는 스파이크를 예방합니다.addr_cnt_read == i_num_cnt-1로 바로 비교해도 합성은 됩니다. 다만 권하지 않습니다. 이유는트랜잭션 중 i_num_cnt가 변하면 완료 펄스가 앞당겨지거나 사라질 수 있습니다.상위에서 오는 조합경로가 길어지면 크리티컬 패스가 그쪽으로 누수됩니다.i_num_cnt==0일 때 i_num_cnt-1은 언더플로로 전비트 1이 되어 오동작 위험이 큽니다(레지스터도 마찬가지라서 보통 i_num_cnt>0 전제·assert나 가드 로직을 둡니다).정리하면, num_cnt를 레지스터로 캡처하는 건 “리소스 소모 대비 안정성/재현성/타이밍 이득”이 확실합니다. 실무에선 입력을 그대로 쓰기보다 트랜잭션 시작에 캡처해서 쓰는 패턴을 기본으로 가져가시면 안전합니다. 필요하면 i_run과 o_done 사이의 경계에서만 업데이트되도록 한 사이클 더 파이프라이닝하는 것도 좋습니다.즐공하세요!

Vitis 코드 작성

안녕하세요 :)Vitis에서 header file은 말씀하신 것처럼 툴이 자동으로 만들어주는데, 그 안에 있는 함수들은 결국 Xilinx에서 제공하는 드라이버 API들이라서, 제가 직접 따로 구현한 건 아닙니다. 제가 한 일은 그 함수들의 역할을 이해하고, 제 main.c 코드 안에서 적절히 불러다 쓰는 것이죠.그럼 그 함수들의 기능은 어디서 배우느냐 하면, 기본적으로는 Xilinx 공식 문서를 참고했습니다. 예를 들어 각 IP별로 xparameters.h, xil_io.h, 그리고 x.h 같은 헤더가 생성되는데, 거기에 대응되는 드라이버 설명이 Vitis Document나 Xilinx Wiki에 잘 정리되어 있습니다. https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841745/Baremetal+Drivers+and+Libraries 처음엔 데이터시트와 드라이버 예제 코드를 그대로 따라 해보고, 함수 이름과 동작을 연결하면서 자연스럽게 익히게 됐습니다.즉, 의 cin, cout을 배우듯이, Xilinx에서 제공하는 예제 코드와 API 문서를 보면서 함수의 역할을 익혔다고 보시면 됩니다. 직접 다 외우기보다는 필요한 기능이 있을 때 예제를 찾아보고, 반복해서 사용하면서 몸에 익히는 식으로 공부했습니다.즐공하세요!

Ubuntu 에서 옆에 라인 수 보는 방법

안녕하세요 🙂vim editor의 라인 넘버는 vim 내부 키워드로 확인할 수 있습니다.vim editor 사용방법은 별도로 책이 나올 정도로 방대하긴 한데요. 저도 자주 쓰는것만 알아요. 하핫 일반적으로 :set number 명령어를 입력하면 왼쪽에 줄 번호가 표시되고, :set nonumber로 다시 끌 수 있습니다. 만약 상대적인 라인 번호가 필요하다면 :set relativenumber를 쓰면 현재 커서를 기준으로 위아래 줄의 상대적 위치가 표시됩니다. 이 두 옵션은 같이 쓸 수도 있어서, 절대 번호와 상대 번호를 동시에 확인하는 것도 가능합니다. 자주 쓰신다면 .vimrc에 set number를 추가해두면 vim을 열 때마다 기본으로 라인 넘버가 켜지게 됩니다. 즐공하세요!

o_done만 reg type으로 선언한 이유

안녕하세요 🙂코딩 스타일의 차이 이고요.여러가지 코딩 스타일을 보여드리려고 했어요. 유사 질문이 있어서 남겨드려요.즐공하세요!(사진)

vivado 및 vitis 리눅스 환경 설치 관련 질문드립니다.

안녕하세요 🙂FPGA 를 리눅스에서 사용하시지 않으실꺼라면, vivado 만 있으셔도 됩니다. 그리고 리눅스 용으로 설치하시면 됩니다. 리눅스 상에서는 Vivado sim 을 위주로 사용해요. 다만 Xilinx 에서 설치 파일을 Vitis 를 super set 으로 제공하고 있어서 vitis 를 설치했습니다. (나중에 확장성이 있을 수 있고요) 리눅스 환경에 적응하시는 것을 적극 추천드릴께요. 추가질문의 답은FPGA 강의를 제작할 당시에 WSL 에서 진행하면 좋았으나, 설치시 드라이버 이슈로 인하여 Windows 를 선택하였습니다. 이런 상황에서 WSL 에서 드라이버 이슈를 해결하고 FPGA 강의를 진행하신 분도 계시는데요. 필요하시면 다음링크 확인해보시면 좋을 것 같아요. https://inf.run/zC27f 즐공하세요 🙂

21강의 DUT 질문 있습니다.

안녕하세요 🙂그림에서 보시면, (사진)캡쳐해주신 코드는 Combinational Logic 파트입니다. (파란색 부분)코드에서 1 cycle 변경 부분은, 다음 그림에서 빨간색 부분이 되겠습니다.빨간색 박스 내의 코드를 보시면, clk edge 에 맞추서, c_state 이것이 1 cycle delay 를 만들어 냅니다.따라서 "S_DONE일 경우 n_state를 S_IDLE 로 바꾸는데요" 이 반영된 내용은 1 cycle 뒤에 c_state 로 반영됩니다. 따라서 질문주신"wave form에서는 바로 바뀌지 않고, 1cycle 정도 후에 바뀌나요?"이것은 코드에서 의도한 동작입니다.즐공하세요 🙂