fifo의 stall과 퍼포먼스 드랍

안녕하세요 🙂"앞단의 입력하는 모듈이 fifo에 write하는 속도가 뒷단의 모듈이 read하는 속도보다 빠른다면 full이 일어나지 않아 하드웨어 성능이 좋아진다 하셨습니다."적어주신 문장에서 맞지않는 부분이 있는 것 같은데요. 이런말을 한적이 있을까요?영상을 다시 봤는데, 이렇게 멘트를 한게 안보여서요.write 하는 속도가 read 하는 속도보다 빠르면, fifo 에 full 이 발생하고요. read 쪽에서 bottle neck 상황이 펼쳐져서, 결국 read 하는 속도로 performance 가 align 될 것 같은데, 다시 확인 부탁드릴께요.

보드 추가의 클릭창이 없습니다.

아.. AI 인턴이 해결을 해줬나 보군요.즐공하세요!!

FPGA 강의 보드 문의 드립니다.

안녕하세요! 아.. Zybo 가 단종인가요? ㅠㅠ 해외배송이 있긴 하던데..이게 수강생마다 전부 달라서 된다 안된다 를 답변드리기 어려운데, 기술적으로는 먼저 강의는 Arty Z7 10 으로도 충분히 따라올 수 있다고 생각이 들고요. (같은 칩 계열입니다.)다만 FPGA 를 정말로 처음 하시는 분이라면.. 그렇게 추천드리지는 않습니다.보드 단종은 너무 아쉽네요 ㅠㅠ즐공하세요!!

5장 DFF특성에 대한 질문

안녕하세요 🙂이해를 위해서, 코드를 다음과 같이 "_1" . "_2" 를 붙여서 두개의 F/F 을 추가로 pipeline 시켰습니다. (사진)다음 시뮬레이션을 보시면 아시다시피, reset 이라고 해서 특별하게 취급되는 것이 아닙니다. value 1 또한 reset 처럼 동일하게 pipeline 이 됩니다. 즉 reset 이라고 해서 posedge 과정에서 특별? 취급을 받는것이 아니라는 뜻입니다. (다음 그림을 보시면 이해가 되실꺼에요)(사진) 질문자님이 궁금해 하시는 포인트가, posedge 가 되자마자 바로 값이 반영되는 것인가? 를 궁금해 하시는거라면, 그것은 시뮬레이션 환경에서 아무런 delay 가 고려되지 않았기 때문입니다.즉 clock edge 상승과 동시에 바로 값이 반영된 것임으로 delay 의 느낌을 받지 못하고 있습니다.알고계시는 것처럼 최종 d_ff 의 output 은 1 cycle 밀린 값을 사용하는 것이 맞습니다. 이 것을 증명한게 "_1", "_2" 가 되겠습니다.즐공하세요 🙂

vivado linux 사용 이유.

안녕하세요 🙂Vivado 사용 환경에 대해 많이들 궁금해하시는 포인트라, 질문 주신 김에 정리해서 답변 드려보겠습니다.Vivado를 Linux에서 사용하는 이유결론부터 말씀드리면 필수는 아니고, 장단점의 선택에 가깝습니다.다만 제가 Linux 환경을 사용하는 이유는 다음 쪽에 가깝습니다.실제 현업 FPGA/ASIC 개발 환경이 Linux 서버 기반인 경우가 매우 많기 때문입니다.TCL 스크립트, Makefile, 배치 빌드, CI 자동화 등 툴을 ‘개발 도구’처럼 다루기에는 Linux가 훨씬 편합니다.대규모 프로젝트나 장시간 합성/구현 시 안정성도 Linux 쪽이 유리한 경우가 많습니다.그렇다고 해서 학습 단계에서 Windows가 틀렸다는 의미는 전혀 아닙니다.개인 학습·입문·소규모 실습은 Windows + Vivado도 충분히 좋은 선택입니다.강의에서 Linux를 쓰는 것은 “이런 환경도 있다”를 보여주기 위한 성격이 더 큽니다.Vivado 2020.2 Linux 설치 관련 (bin 파일 문제)Vivado는 버전별로 Windows용 / Linux용 설치 파일이 완전히 따로입니다.2020.2를 받으셨더라도, Windows Installer만 받으면 Linux용 bin 파일은 당연히 없습니다.따라서20.2 자체를 꼭 유지할 필요가 없다면 → 22.2 같은 최신 LTS 계열을 Linux용으로 새로 받는 것을 추천드립니다.강의나 기존 프로젝트 때문에 20.2가 필요하다면 → AMD 사이트에서 “Linux Installer”를 명시적으로 선택해서 다시 다운로드하셔야 합니다.기존 Windows용 20.2를 “삭제해야만” 하는 것은 아니고, 환경이 다르면 공존도 가능합니다.정리하면,Vivado는 Windows든 Linux든 상관없이 학습은 가능하고Linux는 장기적으로 설계 흐름을 깊게 가져가고 싶은 분들께 유리한 선택이며설치 문제는 대부분 OS별 설치 파일 선택 문제에서 발생합니다.너무 부담 갖고 한 번에 환경을 바꾸실 필요는 없고,지금 쓰시던 Windows 환경에서 강의 따라오시다가 여유 있을 때 Linux를 병행해 보셔도 충분합니다.강의와 동일한 환경을 갖추고 싶으시다면 WSL + Vivado 환경을 추천드립니다.즐공하세요!

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 사이의 경계에서만 업데이트되도록 한 사이클 더 파이프라이닝하는 것도 좋습니다.즐공하세요!