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

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으로 선언한 이유

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