안녕하세요. 올려주신 내용과 에러 메시지를 종합해 보면 원인이 하드웨어 연결 및 보드 세팅 쪽으로 좁혀집니다. 가장 먼저 말씀드릴 부분은 첨부해 주신 장치 관리자 이미지의 9600 bps 설정은 원인이 아니라는 점입니다. 윈도우 장치 관리자 포트 설정 탭의 기본값이 9600으로 보일 뿐, 실제 동작 시에는 보드(Zynq PS)에 올라가는 저희 프로그램 코드(BSP)가 UART 속도를 115200으로 강제 초기화합니다. 따라서 Vitis Serial Terminal은 9600이 아니라 반드시 115200 으로 다시 맞춰주셔야 합니다. 현재 겪고 계신 진짜 문제는 가끔 뜬다고 하신 "Could not find ARM device on the board for connection 'Local'" 에러입니다. 이 에러가 발생했다는 것은 PC와 보드 간의 JTAG 연결이 불안정해서, 작성하신 프로그램 자체가 보드의 ARM 코어로 아예 다운로드되지 않았다는 뜻입니다. 프로그램이 보드에 안 올라갔으니 당연히 터미널 출력도 없고 TX LED도 반응하지 않는 것입니다. 소프트웨어 세팅(경로 이동 등)은 이미 잘 해주셨으니, 다음 세 가지 물리적인 하드웨어 상태를 꼭 확인해 보시기 바랍니다. 보드의 Boot Mode Jumper 확인: 보드에 있는 부팅 모드 점퍼가 반드시 JTAG (또는 Cascaded JTAG)으로 꽂혀 있는지 확인해 주세요. SD나 QSPI 등 다른 모드로 점퍼가 꽂혀 있으면 Vitis에서 ARM 코어를 정상적으로 찾지 못하고 에러를 뱉어냅니다. USB 케이블 및 포트 교체: 선을 뺐다 꽂으면 에러가 사라진다는 건 USB 물리적 연결이 몹시 불안정하다는 뜻입니다. 현재 쓰시는 케이블이 전원 전용이거나 단선이 의심되니, 데이터 통신이 확실히 되는 다른 마이크로 USB 케이블로 교체해 보세요. PC 전면 포트보다는 메인보드 뒷면 포트에 직접 연결하는 것이 좋습니다. 프로그램 다운로드 재확인: 케이블과 점퍼를 확인하신 후, 보드 전원을 껐다 켜고 Vitis에서 기존 Run Configuration을 지운 뒤 다시 Run As -> Launch on Hardware 로 실행해서 에러 없이 다운로드가 끝나는지 확인해 주세요. JTAG 연결만 안정적으로 맺어져서 프로그램이 정상적으로 Run 되면 터미널 출력은 바로 나올 겁니다. 즐공하세요!
안녕하세요 :) 보내주신 파형 보니까 전혀 문제없는 정상 동작입니다. 질문자님이 "VALID를 띄우기 전에 데이터를 먼저 준비해 둬야 하는 거 아닌가?"라고 생각하신 건 AXI 프로토콜의 기본 개념을 아주 잘 파악하고 계신 겁니다. 다만, 지금 보시는 파형이 지연 정보가 없는 RTL 기능 시뮬레이션(Zero-delay)이라서 오해가 생기신 거예요. 노란 커서 바로 전 사이클을 보면 이미 RVALID=1 , RREADY=1 로 핸드셰이크 조건이 들어맞아 있었고, 이때 슬레이브가 준비해서 띄워두고 있던 데이터는 00000000 이었습니다. 그러다가 노란 커서가 찍히는 그 클럭 에지(Rising Edge) 순간에, 마스터는 미리 준비되어 있던 00000000 을 정확하게 샘플링해서 읽어갑니다. 즉, 핸드셰이크(데이터 전송)는 이 클럭 에지 순간에 완벽히 완료된 거죠. 그리고 마스터가 데이터를 성공적으로 가져갔기 때문에, 슬레이브는 바로 다음 사이클 전송을 위해서 데이터를 00000001 로 갱신한 겁니다. RTL 시뮬레이션에서는 Gate나 Wire의 딜레이가 전부 0 으로 처리되기 때문에, 시뮬레이터 파형 상에서는 "이전 데이터 수신"과 "다음 데이터로의 전이"가 같은 클럭 에지에서 동시에 일어나는 것처럼 보일 뿐입니다. 실제 하드웨어나 P&R 후 타이밍 시뮬레이션에서는 Flip-Flop의 (Clock-to-Q Delay) 때문에 클럭이 뛰고 아주 미세하게 몇 ps~몇 ns 뒤에 데이터가 바뀌게 됩니다. 즉, 클럭이 뛰는 그 순간에는 변하기 전 데이터( 00000000 )가 Setup/Hold 타임을 만족하면서 안전하게 넘어가는 게 맞으니 안심하셔도 됩니다. 즐공하세요!
안녕하세요. 맛비입니다. 질문자님이 짚으신 이유가 핵심입니다. 코드가 복잡해졌을 때 디버깅과 추적성이 급격히 떨어지는 것이 가장 큰 이유입니다. 추가로 실무에서 이 방식을 쓰지 않는 대표적인 이유를 정리해 드립니다. FSM 3-Step 분리 이유 (1-Always 구조를 피하는 이유) 설계 명확성 : State 업데이트(Sequential)와 Next State 계산(Combinational), Output 제어를 분리해야 HW 구조가 한눈에 들어옵니다. 의도치 않은 Latency 방지 : always @(posedge clk) 안에서 조합논리 조건까지 한 번에 처리하면, 원하는 시점보다 1 클락 늦게 동작하거나 의도치 않은 F/F이 생기기 쉽습니다. localparam과 연산자( +1 ) 미사용 이유 가독성과 디버깅 : Waveform 분석 시 숫자( 0 , 1 )보다 S_IDLE , S_RUN 같은 이름이 직관적입니다. FSM 확장성 및 최적화 : 상태는 순차적으로만 넘어가지 않고 분기(Branching)하는 경우가 많습니다. c_state + 1 구조는 예외처리가 어렵고, 합성 툴(Synthesis Tool)이 One-hot 같은 FSM 최적화를 수행하는 데 걸림돌이 됩니다. 간단한 예제에서는 직관적으로 보일 수 있지만, 확장성과 유지보수를 위해 강의에서 다룬 표준 3-Step 방식과 localparam 사용을 권장합니다. 즐공하세요.
안녕하세요. 윈도우즈라고 못하는건 아닙니다. 해당 강의가 Linux 기반으로 촬영이 되었는데요. OS 의 차이이지 주어진 소스코드의 차이는 발생하지 않습니다. 다만 환경차이로 인한 시뮬레이션 환경 부분은 직접 해결을 하셔야 할 것 같아요. 개인적인 조언으로는 현재 회사에서 윈도우즈가 주력이라고 하지만, 리눅스를 사용하는 회사가 더 많더라고요. 이번 기회에 리눅스와도 친숙해지시는 것도 추천드려요. 즐공하세요!
안녕하세요. Arty Z10, 과 Zybo Z10 은 같은 Zynq 칩을 기반으로 합니다. 따라서 불가능 하지 않다고 판단이 됩니다. 해당 ‘설계독학의 임베디드 리눅스 & FPGA: 반도체 설계 완성편' 강의의 제작 당시 Zybo 를 사용했었고, 파란님이 Arty 를 갖고 있지는 않아요. 그래서, 모든 보드에 대해서 지원을 해드리는 것은 어려운 문제라는 생각이 드네요. 이 부분은 감안을 하셔서 수강여부를 판단해 주시면 감사하겠습니다. 감사합니다!
안녕하세요, 반갑습니다. 질문해주신 내용을 보니 파이프라인을 적용하기 전과 후의 개념에서 "왜 이전 상태에서는 Clock Speed(주기)가 25일 때 감당이 안 되는가?"에 대해 헷갈리시는 것 같네요. 차분하게 핵심만 짚어서 설명해 드릴게요. 결론부터 말씀드리면, 데이터가 가야 하는 길(Path)의 실제 물리적인 시간 과 우리가 강제로 인가하는 클럭의 주기(Clock Period)를 비교해 보시면 바로 이해가 가실 겁니다. 1. 파이프라인 적용 전 (왼쪽 그림) 실제 데이터가 통과해야 하는 시간 (Worst Path): 입력 $X$에서 출력 $P(X)$까지 가려면 가장 긴 경로를 거쳐야 합니다. 위쪽 길은 $15 + 25 = 40$이고, 아래쪽 길은 $20 + 25 = 45$이죠. 즉, 물리적으로 아무리 빨라도 데이터가 끝까지 도달하는 데 최소 45 라는 시간이 필요합니다. 인가하고자 하는 클럭 주기 ($t_{CLK}$): 우리가 시스템에 25 라는 주기를 가진 클럭을 주었다고 가정해 봅시다. 여기서 모순이 발생합니다. 클럭 주기가 25라는 것은, 매 25마다 새로운 데이터를 받아들이고 처리해서 내보내겠다는 뜻입니다. 하지만 실제 회로(Combinational Logic)는 결과를 내는 데 45가 걸립니다. 25라는 시간이 흘렀을 때, 데이터는 아직 목적지에 도달하지 못하고 길 중간(대략 25 위치)에 머물러 있겠죠? 이 상태에서 다음 클럭 엣지가 쳐버리면 제대로 된 데이터를 캡처하지 못하므로 Timing Violation 이 발생하는 것입니다. 즉, 파이프라인 레지스터가 없는 상태에서는 반드시 가장 느린 경로인 45보다 클럭 주기가 길어야만($t_{CLK} \ge 45$) 정상 동작합니다. 2. 파이프라인 적용 후 (오른쪽 그림) 경로의 분할: 중간에 레지스터를 콕 집어넣어 주면서, 이제 데이터가 한 번에 가야 하는 길이 두 단계로 쪼개졌습니다. Stage 1: 입력에서 중간 레지스터까지 (최대 20) Stage 2: 중간 레지스터에서 출력 레지스터까지 (최대 25) 클럭 주기 ($t_{CLK} = 25$): 이제 각 Stage에서 가장 긴 시간은 25입니다. 클럭 주기를 25로 주더라도, Stage 1(20 소요)과 Stage 2(25 소요) 모두 클럭 주기인 25 이내에 데이터 도달을 완료할 수 있습니다. 따라서 이때는 Violation 없이 정상적으로 동작하게 되는 것이죠. (전체 처리 시간인 Latency는 50으로 늘어나지만, 더 빠른 클럭을 쓸 수 있게 됩니다.) 요약하자면, 레지스터가 없을 때는 처음부터 끝까지 한 번에 가야 해서 45가 필요 한데, 클럭 주기를 25로 줘버리니 시간이 부족해서 터지는(Violation) 상황이라고 이해하시면 됩니다. 즐공하세요!!
안녕하세요. 🙂 결론부터 말씀드리면, 작성해주신 내용이 정확히 맞습니다. 완벽하게 이해하고 계십니다. UART(Universal Asynchronous Receiver-Transmitter)의 역할 UART는 두 하드웨어 장치 간에 데이터를 직렬(Serial)로 주고받기 위한 표준 통신 방식입니다. 우리가 사용하는 Zynq 보드 환경에서는 주로 보드의 PS(Processing System)와 호스트 PC 간에 텍스트나 데이터를 주고받는 통로 역할을 합니다. 4장의 경우: C 코드로 작성한 printf 문자열을 PC 화면(Vitis Serial Terminal)에 출력하거나, PC에서 입력한 값( scanf )을 보드로 전달해야 했기 때문에 UART 통신이 필수적이었습니다. 5장의 경우: 보드 내부의 HW/SW 동작만으로 LED를 제어하고 눈으로 점멸 상태만 확인하는 실습이었으므로, PC 쪽으로 데이터를 보낼 필요가 없었습니다. 따라서 UART를 비활성화해도 실습에 전혀 문제가 없었던 것입니다. UART는 터미널이 필요할 때만 사용하는가? 현재 진행하시는 강의와 같은 기초 개발/디버깅 환경에서는 "동작 상태 확인을 위한 로그(printf) 출력 및 명령어 입력" 목적이 가장 크기 때문에, 말씀하신 대로 시리얼 터미널을 사용할 때 주로 활성화합니다. 하지만 그 외에도 실무에서는 PC뿐만 아니라 블루투스 모듈, GPS 센서, 또는 다른 외부 마이크로컨트롤러(MCU) 등 UART 통신 인터페이스를 지원하는 다양한 외부 장치와 데이터를 주고받을 때 범용적으로 아주 많이 사용 됩니다. RX/TX 두 선만 가지고 통신할 수 있는 저속의 통신 방법이고요. 저희가 사용해본 UART 는 하나의 예라고 생각하시면 될 것 같아요. 즐공하세요.
