EDA playground axi_lite simulation

안녕하세요, 답변 남겨드립니다.셋팅하실때 Aldec으로 했는지, EPWave 뷰어를 클릭했는지 확인해보시겠어요?셋팅하신것도 캡쳐해서 올려주시면 좀더 정밀하게 확인해드리겠습니다!

한글 주석

안녕하세요, 답변 남겨드립니다.아래 내용을 한번 확인해보시기 바랍니다. 혹시 안되시면 다시 알려주세요!1) Quartus 내부 에디터 폰트부터 지정한글이 안 보이는 경우가 가장 흔히 걸리는 지점이 Text Editor(HDL/Tcl/SDC 등) 폰트입니다.Quartus 실행 → Tools → Options좌측에서 Text Editor(또는 유사 항목) 선택Font(글꼴) 을 한글 지원 폰트로 변경Windows: 맑은 고딕(Malgun Gothic), 굴림, 나눔고딕, D2Coding 등적용 후 Quartus 재실행이 조치로 “코드 주석/문자열/메모” 쪽 한글 깨짐은 대부분 해결됩니다.2) Windows에서 한글 폰트/로캘 문제 점검 (가장 효과 큼)A. 한글 폰트가 실제로 설치돼 있는지 확인맑은 고딕이 기본으로 있어야 합니다.없다면 “한국어 언어 팩/글꼴”을 추가 설치하세요.B. “UTF-8(베타)” 옵션이 켜져 있으면 꺼서 개선되는 경우가 있습니다Qt 기반 구형 툴(Quartus 20.1 포함)에서 이 옵션 때문에 글꼴/문자 표시가 꼬이는 사례가 있습니다.제어판 → 국가 또는 지역 → 관리자 옵션시스템 로캘 변경…하단의 “전 세계 언어 지원을 위해 Unicode UTF-8 사용(베타)” 체크가 켜져 있으면 해제재부팅 후 Quartus 재실행C. (부가) 시스템 로캘이 너무 특이한 설정이면 “한국어(대한민국)”로 맞춰 테스트위와 같은 메뉴에서 시스템 로캘을 한국어(대한민국) 로 바꾼 뒤 재부팅 → 표시가 좋아지는지 확인

tb 오류 (iff)

안녕하세요, 답변 남겨드립니다.결론부터 말씀드리면, 지금 에러의 본질은 iff 문법 자체라기보다는 “테스트벤치(.sv)를 Quartus 합성(synthesis)에 넣어서 돌리셨기 때문”인 경우가 대부분입니다. @(posedge clk iff cond) 형태의 iff는 SystemVerilog의 “조건부 이벤트 컨트롤(conditional event control)”로, 시뮬레이터에서는 잘 쓰이지만 합성 툴(특히 Quartus Synthesis)이 지원하는 합성 가능(SystemVerilog synthesizable subset) 문법에 포함되지 않는 경우가 흔합니다. 테스트벤치는 원칙적으로 합성 대상이 아니고, 시뮬레이션 전용으로 ModelSim/Questa 쪽에서 컴파일/실행하셔야 정상입니다.현업 플로우 관점으로 정리하면, RTL(설계 파일)은 Quartus에 넣어 합성/피팅/타이밍을 보고, TB(검증 파일)는 ModelSim에서만 컴파일해서 파형을 봅니다. 예를 들어 AXI-Lite 검증에서 TB는 드라이버/모니터 성격이라 #delay, wait, fork-join, 조건 이벤트(iff) 같은 “시간/이벤트 기반 시뮬레이션 문법”을 적극 사용합니다. 반대로 합성은 클럭에 동기된 레지스터/조합논리로 하드웨어를 만들기 때문에, TB 문법을 합성기에 넣으면 지금처럼 문법 에러 혹은 합성 불가 경고가 나는 것이 정상에 가깝습니다.그래도 “Quartus 컴파일이 꼭 돌아가야 한다”는 상황이 있으니, 해결책을 두 갈래로 드리겠습니다. 첫 번째는 가장 권장되는 방법으로, 테스트벤치를 Quartus 합성 대상에서 제외하는 것입니다. Quartus 프로젝트에 TB 파일이 추가되어 있으면, 해당 파일을 “컴파일 제외(Exclude from compilation)” 처리하시거나, 애초에 Quartus에는 RTL만 추가하고 TB는 ModelSim 프로젝트(do 파일)에서만 관리하시는 방식이 안전합니다. 실무에서도 이 방식이 90% 이상 표준입니다. 이렇게 하면 iff를 유지해도 상관없고, 시뮬레이터에서 의도한 대로 파형을 그대로 확인할 수 있습니다.두 번째는 “문법을 Quartus가 알아먹는 형태로 바꿔서도 동작을 동일하게 만들기”입니다. 지금 코드의 의도는 AXI 핸드셰이크 타이밍을 맞추는 것이고, AXI(-Lite)에서 핸드셰이크는 한 클럭 에지에서 HANDSHAKE = VALID & READY가 1이 되는 순간으로 정의하는 게 일반적입니다. 즉 주소 채널이면 AR_HANDSHAKE = s_axi_arvalid & s_axi_arready, 읽기 데이터 채널이면 R_HANDSHAKE = s_axi_rvalid & s_axi_rready 같은 식입니다. @(posedge clk iff s_axi_arready);는 “s_axi_arready가 1인 클럭 에지까지 기다린다”는 의미인데, Quartus가 iff를 못 받으니 아래처럼 “클럭을 기준으로 루프를 돌면서 조건을 만족할 때까지 대기”로 바꾸시면 됩니다.예를 들어 주소 핸드셰이크를 정확히 기다리려면 READY만 보지 말고 VALID까지 포함해서 다음처럼 쓰는 편이 더 안전합니다. 왜냐하면 실무에서 READY는 미리 1로 올라와 있는 슬레이브도 많고, 반대로 VALID를 내리는 타이밍과 섞이면 한 사이클 오해가 생기기 쉽기 때문입니다.// ARVALID를 올린 뒤, ARVALID&ARREADY가 1이 되는 posedge까지 대기 s_axi_arvalid = 1'b1; do begin @(posedge clk); end while (!(s_axi_arvalid && s_axi_arready)); // 핸드셰이크가 일어난 직후(같은 에지 이후) ARVALID 내림 s_axi_arvalid = 1'b0; 읽기 데이터 채널도 동일하게 바꾸시면 됩니다.// RVALID&RREADY가 1이 되는 posedge까지 대기 do begin @(posedge clk); end while (!(s_axi_rvalid && s_axi_rready)); 만약 원래 코드가 s_axi_rready를 항상 1로 두는 구조라면 조건은 s_axi_rvalid만 봐도 되지만, 현업에서는 마스터가 백프레셔를 주는 케이스(예: RREADY를 0으로 몇 사이클 내렸다가 다시 올리는 케이스)를 검증 항목에 넣는 경우가 많아서, 가능하면 VALID & READY로 기다리는 습관이 버그를 줄입니다. 정량적으로 말씀드리면, 단순 READY만 보고 대기하는 TB는 백프레셔 테스트를 추가하는 순간에 1~2사이클 타이밍 미스가 나서 “가끔씩만 깨지는” 형태의 재현 어려운 버그로 번지는 비율이 체감상 꽤 높습니다.추가로 한 가지 체크 포인트를 꼭 말씀드리면, 질문에서 “testbench 파일을 synthesis 돌리니”라고 하셨는데, TB를 합성하는 것은 목적 자체가 맞지 않습니다. TB는 하드웨어가 아니라 검증용 소프트웨어(시뮬레이션 프로그램에 가까운 코드)라서, 합성을 통과시키는 방향으로 고치기 시작하면 오히려 검증 품질이 떨어질 가능성이 큽니다. 실무에서는 “합성 통과”가 목표가 아니라 “시뮬레이션에서 프로토콜 위반을 얼마나 많이 잡아내는가”가 목표이고, 그래서 TB 쪽은 합성 친화 문법을 일부러 피하고 시뮬레이션 친화 문법을 적극 씁니다.정리하면, 가장 좋은 해결은 TB를 Quartus 합성 대상에서 빼고 ModelSim/Questa에서만 돌리시는 것이고, 부득이하게 Quartus 컴파일 에러를 없애야 한다면 @(posedge clk iff cond)를 do @(posedge clk); while(!cond); 또는 더 안전하게 while(!(VALID && READY)) @(posedge clk); 형태로 바꾸시면 됩니다.

Active load differential amp 질문

안녕하세요, 답변 남겨드립니다.첫 번째 질문인 CMRR에서 phase가 영상과 다르게 나오는 게 정상인지에 대해서는, 지금처럼 LTspice에서 V(vout_dm)/V(vout_cm)로 CMRR을 구성하시면 위상이 다르게 보이는 경우가 충분히 정상 범주입니다. CMRR은 원래 주파수에 따른 복소비로 정의되어 CMRR(jw) = Ad(jw) / Ac(jw) 이고, Ad와 Ac가 각각 폴/제로를 갖는 전달함수이기 때문에 CMRR도 크기와 위상을 동시에 가집니다. 다만 현업에서 “CMRR 스펙”이라고 말할 때는 거의 항상 |CMRR|만 dB로 관리하고 위상은 스펙 항목으로 두지 않는 경우가 대부분이라, 학습 단계에서는 phase가 영상과 다르다고 해서 곧바로 비정상이라고 보지 않습니다. 특히 active-load differential pair는 공통모드 경로(Ac)가 차동 경로(Ad)와 다르게 테일 전류원 ro, 미러의 ro와 기생 C, 입력쌍 소스 노드 임피던스 변화를 강하게 타면서 추가 폴/제로가 생기기 쉬워서, 같은 magnitude 감소 타이밍이라도 phase가 더 빨리(또는 더 늦게) 돌아가는 현상이 흔합니다. 또 한 가지 실무적으로 자주 보이는 현상은, 분모인 V(vout_cm)가 어떤 대역에서 매우 작아지거나 위상이 급격히 변하면(거의 0에 가까워지거나 notch처럼 보이는 구간) 비의 위상이 90도~180도 이상 크게 휘어 보일 수 있다는 점인데, 이건 “비를 취하는 수학적 결과”로도 충분히 발생합니다. 결론적으로 CMRR의 phase는 “볼 수는 있지만” 보통 합격/불합격을 가르는 1차 기준은 아니고, |CMRR|이 저주파에서 충분히 높고 주파수에 따라 어떻게 떨어지는지가 핵심입니다. 예를 들어 저주파에서 |CMRR|이 60 dB 이상이고, 1 MHz에서 40~50 dB 이상 유지되는지 같은 식으로 정량 목표를 잡는 방식이 일반적입니다(목표 수치는 제품군마다 다릅니다).두 번째 질문인 “ADM/ACM을 gain이 아니라 voltage로 구해도 되나”는, 지금처럼 V(vout_dm)/V(vout_cm)로 보는 방식 자체는 괜찮지만, 딱 한 가지 조건이 충족될 때만 “전압비가 곧 CMRR”이 됩니다. 그 조건은 dm 실험에서의 입력 차동 진폭 Vdm과 cm 실험에서의 입력 공통모드 진폭 Vcm을 동일하게 정규화하는 것입니다. 일반식으로 보면 V(vout_dm)/V(vout_cm) = (AdVdm)/(AcVcm) 이라서, Vdm=Vcm=1일 때만 Ad/Ac가 됩니다. 여기서 가장 흔한 함정이 dm을 VINP=AC 1, VINN=AC -1로 두는 경우인데, 이때 Vdm의 AC 진폭은 2가 됩니다. 반면 cm을 VINP=AC 1, VINN=AC 1로 두면 Vcm은 1이어서, 결과적으로 전압비로 만든 CMRR이 실제보다 2배 커지고 dB로는 20*log10(2)=6.02 dB 과대평가됩니다. 그래서 현업에서는 dm을 VINP=+0.5, VINN=-0.5로 줘서 Vdm=1로 맞추고, cm을 VINP=1, VINN=1로 줘서 Vcm=1로 맞춘 뒤, 그때의 V(vout_dm)/V(vout_cm)를 CMRR로 해석하는 방식을 많이 씁니다. 질문에 적어주신 “AC 1/-1이 아닌 1/0으로 해서 Vout을 gain으로 보려던 것 같다”는 접근은 단일 입력 자극이어서 차동/공통모드가 섞이기 쉽고, CMRR 측정 정의를 깔끔하게 만들기 어렵기 때문에 권장되지는 않습니다. 정리하면, 전압으로 구하셔도 되지만 Vdm과 Vcm을 1로 맞춰서 “전압이 곧 전달함수”가 되게 만들어 주셔야 수치가 정확해집니다.세 번째 질문인 slew rate가 지나치게 가파르게 나오는 게 정상인지에 대해서는, 출력 부하 조건이 거의 없으면 그렇게 보이는 것이 오히려 정상에 가깝습니다. slew rate는 1차적으로 SR = Imax / Cload로 정해지는데, 출력에 명시적으로 Cload를 달지 않으면 기생 커패시턴스(수 fF~수십 fF 수준)만 남아서 SR이 비현실적으로 커지기 쉽습니다. 예를 들어 출력으로 밀어줄 수 있는 전류가 10 uA 수준이고 Cload가 10 fF라면 SR = 10e-6/10e-15 = 1e9 V/s = 1000 V/us가 되어 파형이 거의 수직처럼 보일 수 있습니다. 반대로 Cload를 1 pF만 걸어도 SR = 10e-6/1e-12 = 1e7 V/s = 10 V/us로 현실적인 숫자가 됩니다. 그래서 실무에서는 slew rate를 평가할 때 Cload를 목표 환경으로 고정해서 봅니다. 예를 들어 “센서 프론트엔드 내부 노드”면 1 pF 전후, “패드/버퍼 근처”면 수 pF~수십 pF까지도 가정하는 식으로 시나리오를 정하고, 그 조건에서 dv/dt를 10%~90% 구간의 기울기로 재서 SR을 정량화합니다. 그리고 입력 스텝도 너무 크게 주면 출력이 레일 근처로 포화되면서 “slew”가 아니라 “포화 후 회복(settling with saturation)”을 보게 되니, 소신호 settling(예: 입력 10 mV~50 mV)과 대신호 slew(예: 입력 수백 mV)를 분리해서 보는 것이 안전합니다. “가파르면 안 좋은가”는 그 자체로 나쁘다기보다, 그 가파름이 어떤 Cload에서도 유지되는지, 그리고 그 과정에서 오버슈트/링잉이 커지지 않는지(안정도)가 더 중요합니다. 예를 들어 Cload=5 pF에서 SR이 2 V/us 이상 나오면서도 링잉이 ±5% 이내로 정착하면 좋은 설계라고 보는 식의 판단을 합니다.네 번째 질문인 ICMR을 시뮬레이션 안 하는지에 대해서는, 단일 active-load differential amp라도 ICMR은 보는 것이 맞고, 실무에서도 기본 체크 항목입니다. 방법은 차동 입력을 0으로 두고(VINP=VINN=VCM), VCM을 DC로 스윕하면서 모든 소자가 포화(saturation)를 유지하는 구간과 그 구간에서의 이득/동작점을 같이 확인하는 것입니다. 개략적으로 NMOS 입력쌍 구조에서 하한은 VCM_min ≈ VSS + VGS(in) + VDSsat(tail)로 잡히는 경우가 많고, 상한은 PMOS 로드의 헤드룸과 출력 노드 전압 범위에 의해 제한됩니다. 현업에서 빠르게 감을 잡을 때는 오버드라이브를 Vov≈0.2 V 정도로 두고, 입력쌍과 테일에 각각 약 0.2 V 헤드룸이 필요하다고 보면 하한은 VSS+0.4 V 근처부터 열리는 그림이 자주 나오며, 상한은 로드의 VSDsat와 출력 스윙 한계가 맞물려 결정됩니다. 이건 공정/모델/바이어스에 따라 크게 달라지므로, 실제로는 VCM을 예를 들어 0.2 V에서 2.0 V까지 1 mV 스텝으로 올려가며 각 트랜지스터의 Vds가 Vdsat보다 큰지(즉 Vds > Vov 조건)와 출력 DC 레벨이 어디까지 따라오는지를 동시에 보는 방식이 가장 확실합니다. 이렇게 하면 “어느 소자가 먼저 선형영역으로 떨어져 ICMR 한계를 만드는지”가 수치로 바로 드러나고, 그에 맞춰 W/L이나 바이어스 전류를 어떻게 조정해야 하는지도 설계 의사결정이 쉬워집니다.요약해서 말씀드리면, LTspice에서 V(vout_dm)/V(vout_cm)로 CMRR을 보는 방식은 실무적으로도 많이 쓰는 편이고, phase가 영상과 달라지는 것 자체는 충분히 정상일 수 있습니다. 다만 전압비가 정확한 CMRR이 되려면 dm과 cm 입력 AC 진폭을 반드시 동일하게 정규화해서 6.02 dB 같은 스케일 오차가 안 생기게 만드는 것이 핵심이고, slew rate는 Cload를 명시하지 않으면 과장되어 보이기 쉬우며, ICMR은 반드시 VCM sweep으로 포화 조건과 동작 범위를 확인하시는 게 맞습니다.

핀 방향 설정 관련 질문드립니다

안녕하세요, 답변 남겨드립니다.글로벌 라벨의 “방향(화살표가 좌/우를 보는 것)”은 전기적으로는 넷 이름을 붙이는 표기일 뿐이라서, 실제 PCB 연결이나 동작을 바꾸지 않습니다. 현업에서는 이 방향을 “신호의 주된 흐름을 사람이 빠르게 읽기 위한 규칙”으로 정하고, 동시에 ERC(전기적 규칙 검사)에서 불필요한 에러가 나지 않도록 심볼의 핀 타입(입력/출력/양방향/패시브)을 함께 맞춰서 운용합니다. 즉, 라벨 방향은 데이터시트의 pin function을 참고하되, 최종 판단 기준은 “이 보드에서 그 넷을 누가 구동(driver)하고 누가 수신(receiver)하느냐”와 “리셋/부트 스트랩처럼 시간에 따라 역할이 바뀌는지”까지 포함하는 쪽이 실무적입니다.질문 주신 RX_DV가 데이터시트에는 output으로 되어 있는데, 어떤 회로도(심볼)에서는 bidirectional로 표시되는 대표적인 이유가 바로 “스트랩(strap) 기능” 때문입니다. 첨부하신 표에서도 RX_DV/CRS_DV 항목에 Reset: I, PD / Active: O / Strap10처럼 적혀 있는데, 이 의미는 리셋 시점에는 해당 핀이 입력으로 동작하면서 외부 풀업/풀다운 저항 상태를 샘플링해 부트 설정을 결정하고, 정상 동작(Active) 구간에는 PHY가 MAC 쪽으로 신호를 내보내는 출력으로 바뀐다는 뜻입니다. 그래서 심볼 제작자 입장에서는 “한 단어로 딱 잘라 Input 또는 Output이라고 정의하면, 둘 중 하나의 구간이 틀려지는” 핀이 되고, 이런 핀은 양방향(bidir) 또는 패시브로 두어서 ERC 충돌을 피하는 경우가 많습니다. 실제로는 정상 동작 중 RX_DV는 PHY->MAC 방향의 출력이 맞지만, 리셋 직후 수 us~수 ms 구간(칩마다 다르지만 strap 샘플링 윈도우가 짧게 존재합니다)에는 외부 저항 네트워크가 핀 전압을 “구동”하는 형태가 되기 때문에, 회로도 관점에서는 입력 성격도 동시에 갖습니다.정량적으로 왜 ERC가 꼬이기 쉬운지 예를 들어보겠습니다. 많은 PHY는 strap 핀에 내부 풀업/풀다운이 기본으로 걸려 있고(데이터시트에 “PU/PD”로 표기), 외부에서는 4.7 kOhm~10 kOhm 정도로 강하게 당겨서 원하는 논리값을 보장하는 구성을 자주 씁니다. 예를 들어 VDDIO=3.3 V, 입력 임계가 보수적으로 VILVDDIO=0.99 V, VIH>=0.7VDDIO=2.31 V라고 두고, 내부 풀다운이 50 kOhm 정도(전형적인 약한 풀)라고 가정하겠습니다. strap을 High로 만들려고 외부에 10 kOhm 풀업을 달면 분압으로 핀 전압은 Vpin = 3.3*(50k/(10k+50k)) = 2.75 V가 되어 2.31 V를 충분히 넘으니 High로 안정적으로 읽힙니다. 반대로 strap을 Low로 만들려고 10 kOhm 풀다운을 달고 내부 풀업이 50 kOhm이라면 Vpin = 3.3*(10k/(10k+50k)) = 0.55 V로 0.99 V보다 낮아 Low가 확실해집니다. 이때 ERC 관점에서는 “외부 저항이 리셋 구간에 핀을 특정 레벨로 만들어 주는 구동원 역할”을 하는데, 심볼을 Output으로 박아두면 “출력끼리 충돌” 또는 “출력에 외부에서 구동” 같은 경고가 날 수 있어서, 제작자가 bidirectional로 타협하는 경우가 많습니다. 즉, bidirectional 표기는 “정상 동작에서 양방향 데이터가 흐른다”는 뜻이 아니라, “시간/모드에 따라 입력과 출력 역할이 전환되는 멀티롤 핀이라서 ERC와 문서 가독성을 동시에 만족시키기 위한 표기”로 이해하시는 게 정확합니다.글로벌 라벨 방향을 무엇을 보고 정하느냐로 돌아가면, 데이터시트의 pin function에서 방향을 1차로 참고하는 건 맞지만, PHY처럼 모드(MII/RMII), 리셋 스트랩, 테스트 모드에 따라 핀 역할이 바뀌는 칩은 데이터시트 표에 “Reset/Active”가 분리되어 있는지를 반드시 같이 봐야 합니다. 그리고 보드 레벨에서는 MAC(예: STM32) 쪽 RMII_RXD[1:0], RMII_CRS_DV 같은 신호는 MCU 입장에서는 입력이고 PHY 입장에서는 출력이므로, 회로도를 좌에서 우로 읽는 팀 규칙을 쓴다면 PHY 블록에서 MCU 블록으로 향하는 방향으로 라벨을 두는 식으로 통일하는 게 리뷰 효율이 좋습니다. 반대로 MDC는 보통 MAC이 클럭을 내보내는 출력이고, MDIO는 양방향이므로, MDC는 MAC->PHY 방향, MDIO는 양방향 표기가 자연스럽습니다. 이런 식으로 “프로토콜 관점의 마스터/슬레이브 구동 관계”까지 포함해서 라벨 방향을 잡으면, 회로도만 봐도 누가 드라이버인지 바로 파악되어 디버깅 시간이 줄어듭니다.실무 예시를 하나 더 들면, RMII에서는 50 MHz REF_CLK가 보드에 따라 PHY가 출력(크리스털/PLL 기준 클럭 제공)일 수도 있고, MCU가 출력(외부 오실레이터/MCU MCO로 PHY에 공급)일 수도 있습니다. 같은 핀이라도 설계 선택에 따라 “누가 출력인지”가 바뀌기 때문에, 이런 넷은 데이터시트만 보면 착각하기 쉽고, 최종적으로는 레퍼런스 디자인/선택한 모드/클럭 트리 요구사항을 기준으로 심볼 핀 타입과 라벨 방향을 같이 결정하는 게 안전합니다. 예를 들어 MCU가 50 MHz를 공급하는 구조라면 PHY의 해당 핀은 입력으로 쓰이므로, 심볼을 무조건 Output으로 두면 ERC는 물론이고, 회로도 리뷰에서도 “클럭 소스가 어디냐”가 혼동되어 실수가 늘어납니다.정리하면, 글로벌 라벨 방향은 전기적 정답을 맞추는 행위라기보다 “신호 소유권과 흐름을 문서화하는 행위”이고, RX_DV가 bidirectional로 보이는 건 정상 동작의 RX_DV 출력 성격과 리셋 구간의 strap 입력 성격이 공존하기 때문인 경우가 대부분입니다.

안녕하세요 강의 도중 궁금한 점 있어서 질문드립니다!

안녕하세요, 답변 남겨드립니다.결론부터 말씀드리면, 디코더나 카운터를 CMOS 트랜지스터 레벨로 “외워서” 즉시 그릴 정도까지는 대부분의 디지털 RTL 직무 면접에서 요구하지 않습니다. 대신 면접에서 자주 보는 포인트는 논리게이트 수준에서의 기능 이해, 불리언 대수로의 단순화, 타이밍 관점에서의 위험(글리치, 해저드), 그리고 그 회로를 Verilog로 안전하게 표현하는 능력입니다. NAND와 NOT을 “모든 논리의 기초”로 언급하는 것도, 실제로는 NAND로 모든 조합논리를 구성할 수 있다는 사실을 이용해 논리적 사고가 되는지를 보려는 성격이 강합니다.디코더나 카운터 같은 블록에 대해 어느 수준까지 해야 하느냐를 직무 관점으로 나누면 명확해집니다. RTL 설계/검증(Verilog/SystemVerilog) 중심이라면 디코더는 “n비트 입력이 들어오면 2^n개의 one-hot 출력이 나온다”, “enable이 있으면 출력이 모두 0이 될 수 있다”, “case 문으로 one-hot을 만들되 default를 명확히 한다” 같은 동작적 이해가 핵심이고, 카운터는 “동기식/비동기식 reset 차이”, “enable gating”, “rollover 조건”, “비트폭과 overflow”, “업/다운”, “Gray counter 같은 파생형” 정도를 정확히 말하고 코딩할 수 있으면 됩니다. 게이트 레벨로는 2:4 decoder 정도는 진리표를 바로 쓰고 논리식을 만들 수 있으면 좋고, 4비트 카운터는 “플립플롭 4개와 다음상태 논리”라는 구조를 설명할 수 있으면 충분한 경우가 많습니다. 반면 트랜지스터(CMOS) 레벨로 인버터, NAND, NOR 정도는 기본 소양으로 물을 수 있지만, “카운터 전체를 CMOS로 그려라” 같은 질문은 보통 아날로그/풀커스텀/표준셀 라이브러리 설계 쪽에서나 의미가 있고, RTL 채용에서 나오면 오히려 비정상적인 편입니다.다만 “논리기호로 바로 표현”은 케이스가 있습니다. 예를 들어 2:1 MUX, half adder/full adder, 2:4 decoder, priority encoder 같은 소규모 조합회로는 면접에서 구두로 설명하다가 손으로 블록 다이어그램 또는 간단한 게이트 조합을 그리게 하는 일이 있습니다. 여기서 기대치도 “정확히 최적 게이트 수로”가 아니라, 기능이 맞고 입력 조합에 대해 일관되게 동작하는 구조를 제시하는 수준인 경우가 많습니다. 정량적으로 말하면, 신입 기준으로 2~3분 안에 진리표를 쓰고, 5분 안에 간단한 논리식이나 게이트 구조를 제시할 수 있으면 충분히 경쟁력이 있습니다.두 번째 질문인 “취업을 위해 Verilog 구현 능력이 어느 정도여야 하냐”는 회사/포지션에 따라 차이가 있지만, 소프트웨어처럼 대규모 코딩테스트를 보는 형태는 상대적으로 덜 흔하고, 대신 짧은 RTL 문제를 화이트보드나 코딩 플랫폼에서 15~45분 정도 푸는 방식이 꽤 있습니다. 즉 “종이 한 장 주고 4비트 FA 코드를 적어봐라”는 형태가 실제로 나올 수 있습니다. 다만 여기서 말하는 코드는 대개 문법을 완벽히 외워서 한 번에 컴파일되게 쓰는 수준이라기보다는, 조합논리와 순차논리를 구분해서 always_comb/always_ff(또는 always @*)/(posedge clk)로 의도를 정확히 표현하고, latch가 생기지 않게 default를 주고, blocking/non-blocking을 올바르게 쓰는지 같은 “RTL 사고력”을 봅니다.면접에서 자주 나오는 “백지 코딩”의 난이도를 정량적으로 예시로 들면, 신입/주니어 RTL 기준으로 아래 정도는 외우다시피 즉시 작성하는 편이 안전합니다. 2:1 mux, 4:1 mux, decoder(2:4 또는 3:8), priority encoder(4:2), 1비트/4비트 adder(연쇄), DFF with reset/enable, up counter with enable and synchronous reset, simple FSM(traffic light 수준), 간단한 ready/valid 핸드셰이크 레지스터 슬라이스 정도입니다. 반대로 AXI 전체 채널을 백지에서 정확한 타이밍까지 다 적으라는 식의 문제는 신입 면접에서 비현실적이고, 오히려 개념 질문으로 “AW/W/B 채널이 독립인 이유”, “burst length/size 의미”, “backpressure 처리” 같은 걸 묻는 쪽이 일반적입니다.AI나 검색을 활용하는 방식에 대해서는, 현업에서는 당연히 활용합니다. 다만 면접은 “검색 없이도 최소한의 정확한 골격을 만들 수 있는지”를 보려고 하기 때문에, 뼈대(skeleton)조차 못 세우면 불리해집니다. 현실적인 목표는 “빈 종이에서도 70~80%는 맞는 RTL을 작성하고, 문법 자잘한 부분(예: sensitivity list 디테일, 타입 선언, 일부 키워드)은 약간 틀릴 수 있지만 의도는 명확히 설명 가능” 정도입니다. 특히 조합회로는 always @* 또는 always_comb에서 모든 출력에 default를 주는 습관, 순차회로는 non-blocking(현업적인 예시를 하나 들면, 4비트 FA를 “구현”하라고 했을 때 단순히 assign으로 “sum = a + b + cin”을 쓰는 것도 기능은 맞지만, 면접관이 보고 싶은 포인트가 “carry chain을 이해하는가”라면 generate로 1비트 FA를 4개 연결하거나, 최소한 {cout,sum} = a + b + cin 형태로 캐리와 합이 어떻게 나뉘는지 보여주는 답을 선호할 수 있습니다. 반대로 검증 관점이면 “랜덤 벡터 1000개를 넣어 reference 모델(a+b+cin)과 비교하는 self-checking TB를 10분 내로 짜라” 같은 식으로 형태가 바뀝니다. 결국 요구 역량은 “코드량”보다 “의도 표현과 검증 가능성”에 더 가깝습니다.마지막으로 준비 전략을 정량적으로 추천드리면, 매일 30분씩 2주만 투자해도 체감이 크게 올라갑니다. 하루에 미니 문제 1개를 정하고, 10분 안에 진리표/상태도, 10분 안에 RTL, 10분 안에 간단한 테스트(예: for 루프로 2^n 전수 또는 랜덤 200~1000패턴)를 만드는 훈련을 하시면, “백지 공포”가 상당히 줄어듭니다. 면접에서 요구되는 건 대개 이 정도 속도감과 정확도입니다.

kicad ERC footprint library 경고

안녕하세요, 답변 남겨드립니다.올려주신 ERC 창의 “The current configuration does not include the footprint library '' ” 경고는, 심볼의 Footprint 필드가 “라이브러리 닉네임:풋프린트이름” 형태로 연결되어 있지 않아서 발생하는 경우가 가장 많습니다. 화면을 보면 심볼 옆에 [CAP_0.1uF-50V-10%-0805] 같은 식으로 풋프린트가 들어가 있는데, 이 값이 KiCad 풋프린트 라이브러리 테이블(fp-lib-table)에 등록된 “닉네임”을 포함하지 않으면 KiCad는 라이브러리 닉네임을 빈 문자열로 해석하고, 그 결과가 바로 라이브러리 이름이 ''(빈 값)인 풋프린트를 참조한다고 판단하여 해당 경고를 띄웁니다. 즉, 라이브러리를 Preferences에서 추가해 두셨더라도, 심볼이 가리키는 Footprint 문자열이 그 라이브러리 닉네임과 매칭되지 않으면 경고는 그대로 남습니다.이 이슈를 빠르게 판별하는 방법은 심볼 속성에서 Footprint 필드에 콜론(:)이 있는지 확인하는 것입니다. 정상적인 KiCad 기본 풋프린트 지정은 예를 들어 “Capacitor_SMD:C_0805_2012Metric”처럼 반드시 “라이브러리닉네임:풋프린트명” 구조를 갖습니다. 반면 “CAP_0.1uF-50V-10%-0805”처럼 콜론 없이 단일 이름만 들어가 있으면, 라이브러리 닉네임이 없기 때문에 지금 같은 경고가 거의 100% 재현됩니다. 정량적으로 말하면, 현재 창에서 Warnings 25개가 전부 같은 문구로 반복되고 있고(여러 심볼에 공통 발생), 이는 개별 라이브러리 설정 문제라기보다 “풋프린트 지정 문자열 포맷/매핑” 문제일 확률이 높습니다.해결은 “풋프린트를 올바른 라이브러리 닉네임을 포함한 형태로 다시 할당”하는 쪽이 가장 깔끔합니다. 실무적으로는 Tools의 Assign Footprints(풋프린트 할당 툴)를 열고, 각 심볼에 대해 실제 존재하는 풋프린트 라이브러리(예: KiCad 기본의 Capacitor_SMD.pretty, Resistor_SMD.pretty, Package_QFP.pretty 등)에서 대응 풋프린트를 선택해 매칭시키는 방식이 안정적입니다. 예를 들어 0.1uF 0805 디커플링이면 “Capacitor_SMD:C_0805_2012Metric”으로, 100k 0603이면 “Resistor_SMD:R_0603_1608Metric”처럼 표준 풋프린트를 지정하는 식입니다. 그러면 ERC의 “라이브러리 '' 미포함” 경고는 즉시 사라지는 것이 정상입니다.만약 강의에서 커스텀 풋프린트 라이브러리를 만들어 쓰는 흐름이었다면, 그 경우에는 먼저 Preferences의 Manage Footprint Libraries에서 해당 .pretty 폴더를 “Global” 또는 “Project”로 추가하고, 추가할 때 지정한 “닉네임”이 무엇인지가 핵심입니다. 예를 들어 닉네임을 “MY_HW”로 등록했다면, 심볼의 Footprint 필드는 반드시 “MY_HW:CAP_0805_0.1uF” 같은 형태여야 합니다. 여기서 라이브러리를 경로로만 추가해 놓고 닉네임을 다르게 쓰거나, 심볼에는 닉네임 없이 풋프린트명만 넣어두면, 라이브러리는 존재해도 ERC는 못 찾습니다. 현업에서 외주 라이브러리(회사 공용 .pretty)를 붙일 때도 이 “닉네임 불일치”가 가장 흔한 실수이고, 증상이 지금과 동일하게 경고가 부품 수만큼 우르르 뜹니다.또 한 가지 실무에서 자주 만나는 케이스는 “라이브러리를 Global로만 추가해 놓고, 프로젝트를 다른 PC/다른 환경에서 열었을 때 Project fp-lib-table이 비어 있거나 경로 변수가 깨진 상태”입니다. 이 경우도 경고가 뜨는데, 이때의 경고는 보통 라이브러리 이름이 ''이 아니라 “MY_HW” 같은 닉네임 자체가 표시되면서 “해당 닉네임 라이브러리가 현재 구성에 없다”로 나오기 쉽습니다. 지금은 ''로 보이므로, 경로 깨짐보다는 풋프린트 문자열 자체에 닉네임이 없는 쪽을 우선 의심하시는 게 시간 대비 효율이 좋습니다.참고로, 캡처에 Errors 2개로 보이는 “Input Power pin not driven by any Output Power pins”는 footprint 경고와는 별개로, 전원 네트에서 구동원(파워 아웃풋 핀)이 없다고 ERC가 판단한 것입니다. 예를 들어 3.3V를 레귤레이터가 만들고 있는데 레귤레이터 심볼의 출력 핀이 Power output으로 정의돼 있지 않거나, 단순히 전원 심볼(+3V3)이 Power input으로만 존재하면 이 에러가 발생합니다. 가장 빠른 해결은 해당 전원 레일마다 PWR_FLAG를 하나씩 추가해서 “이 전원은 외부에서 공급/구동된다”를 명시하는 방법이고, 더 정석은 레귤레이터/전원 소스 부품의 출력 핀 타입을 Power output으로 올바르게 쓰는 것입니다. 실무에서는 PWR_FLAG는 테스트/초기 설계 단계에서 많이 쓰고, 최종 라이브러리 정리 단계에서는 전원 소스 심볼의 핀 타입을 정정해서 PWR_FLAG 의존도를 줄이는 편입니다. 현재는 에러가 2개로 적기 때문에, 3.3V와 5V(또는 VBAT 등) 같은 주요 레일 2개에만 PWR_FLAG가 필요할 가능성이 큽니다.정리하면, 지금의 footprint library 경고 25개는 “라이브러리를 추가했는데도”가 아니라 “심볼이 가리키는 풋프린트 지정 방식이 라이브러리 닉네임과 연결되어 있지 않아서” 생길 확률이 높고, Tools의 Assign Footprints로 풋프린트를 “닉네임:풋프린트명” 형태로 재할당하면 정상적으로 해소되는 경우가 대부분입니다.

32강 debugging pin 설계 강의 관련 질문 드립니다.

안녕하세요, 답변 남겨드립니다.질문 주신 “JTMS_F407을 PB14, PB12에, NTRST_F407을 PB13에, JTCLK_F407을 PB0에 연결”은, 해당 핀들이 SPI나 USART 같은 주변장치 통신을 하려고 “그 기능을 쓰기 위해” 선택됐다기보다는, 디버깅 인터페이스(JTAG/SWD) 신호를 보드 안에서 “어느 GPIO로 내보낼지”를 정한 설계 선택으로 보는 게 더 정확합니다. STM32F4 계열의 경우 디버그 포트는 Arm의 SWJ-DP(Serial Wire/JTAG Debug Port)이고, JTAG의 TMS/TCK는 SWDIO/SWCLK와 핀을 공유하며 2선(SWD) 또는 5선(JTAG)으로 디버깅이 가능하다는 점이 데이터시트에도 명시돼 있습니다.여기서 핵심은 “타깃 MCU(예: STM32F407) 쪽의 SWDIO/SWCLK 같은 디버그 핀은 사실상 고정(기능적으로 강하게 규정)”인 반면, “보드 내 디버깅용 MCU(예: STM32F103 등) 쪽에서 그 신호를 구동/샘플링하는 핀은 설계자가 비교적 자유롭게 정할 수 있다”는 점입니다. 즉, 디버깅용 MCU가 타깃 MCU를 프로그래밍/디버깅하는 역할(일종의 ST-LINK 류 역할)을 한다면, 디버깅용 MCU의 특정 GPIO들을 TMS/SWDIO, TCK/SWCLK, nRESET(nTRST/NRST 계열) 같은 선에 매핑해서 쓰게 되는데, 이때 그 GPIO가 “SPI2_MISO가 될 수 있다/USART가 될 수 있다” 같은 표기는 단지 대체기능(AF) 후보일 뿐이고, 실제로는 그냥 GPIO로 써도 됩니다. 인프런 커뮤니티의 유사 Q&A에서도 “데이터시트의 단순 핀명만 보고 끝내기보다, 디버그 신호의 의미를 라벨로 명확히 해서 회로 가독성과 호환성을 높이려는 관례”라는 취지로 설명하고 있습니다.그렇다면 왜 하필 PB12, PB13, PB14, PB0 같은 조합이 나왔느냐는 부분은 “전기적/펌웨어적/PCB 배치적 실용성” 쪽 이유가 큽니다. 현업에서 디버그 라인 핀을 고를 때는 보통 첫째, 부팅 스트랩(BOOT0/BOOT1), 크리스털, 리셋 등 보드 생존에 치명적인 핀을 피합니다. 둘째, 다른 핵심 인터페이스(Ethernet RMII, USB, 고속 ADC/DAC 등)와 충돌 가능성이 낮은 핀을 고릅니다. 셋째, 같은 GPIO 포트에 몰아두면 펌웨어에서 한 번의 레지스터 접근으로 여러 신호를 동시에 토글/샘플링할 수 있어 타이밍 스큐를 줄이고 속도를 올리기 유리합니다. 예를 들어 TMS, TCK, TDI를 모두 GPIOB에 몰아두면, GPIOB->BSRR 한 번(32bit write 1회)로 여러 핀을 동시에 set/reset할 수 있어서, 개별 핀을 순차적으로 건드릴 때 생기는 수십 ns 단위의 상대 지연을 줄일 수 있습니다. Cortex-M에서 GPIO 토글이 루프당 수십~수백 ns 수준으로 동작한다고 보면, 이런 “같은 포트 집중”은 SWD 클록을 1 MHz에서 2~4 MHz 수준으로 끌어올릴 때 체감 차이가 나오는 편입니다(보드 배선 길이, 프로브, 시리즈 저항 유무에 따라 달라집니다). 또 PB12~PB15는 STM32F1에서 SPI2가 걸려 있는 대표적인 핀 묶음이라, 나중에 “JTAG 비트뱅잉을 SPI 하드웨어를 부분적으로 활용해 가속” 같은 확장 아이디어를 남기는 설계도 실제로 있습니다(예: SCK=TCK, MOSI=TDI, MISO=TDO처럼 데이터/클록 경로를 하드웨어로 보내고 TMS만 GPIO로 제어). 다만 이 케이스에서 JTCLK가 PB0로 간 점은, 보드 내 다른 용도(예: PB13을 LED/인터럽트/다른 라인으로 이미 사용)나 라우팅 편의 때문에 클록 라인을 다른 위치로 빼는 타협이 있었을 가능성이 큽니다. 이 부분은 회로도에서 “PB13이 다른 넷과 겹치는지”, “PB0가 커넥터/저항 네트워크 근처인지”를 보면 설계 의도가 더 명확해집니다.질문하신 “PB14, PB12가 아니라도 통신 방식에 맞게 데이터시트를 보고 골라도 되느냐”에 대해서는, 디버그 라인 관점에서는 “네, 원칙적으로는 된다”가 맞습니다. 단, 조건이 있습니다. 그 핀들이 디버깅용 MCU 펌웨어에서 실제로 GPIO로 구동/입력 가능해야 하고, 부팅 직후부터 외부에 이상 레벨을 강하게 내보내서 타깃을 오동작시키지 않아야 하며, 보드 제작/검증 관점에서 표준 ARM 10핀(SWD) 헤더 같은 외부 디버거 연결 경로와 충돌하지 않게 구성돼야 합니다. 현실적인 가이드로는, 보드 안 SWD/SWCLK 라인 배선 길이가 5 cm 이내이고(왕복 리턴패스 포함), 22~47 ohm 시리즈 저항을 클록/데이터에 넣고, 그라운드 레퍼런스를 가까이 두면 2~4 MHz 정도는 비교적 안정적으로 나오는 경우가 많습니다. 반대로 10 cm 이상 길어지거나 커넥터/케이블이 길어지면 링잉이 커져서 1 MHz 이하로 낮춰야 안정화되는 사례도 흔합니다. 이런 정량 값은 “절대 규격”이라기보다, 현장에서 디버그 안정성 튜닝할 때 자주 나오는 경험치 범위로 이해하시면 좋습니다.추가로 한 가지 짚고 넘어가실 게, 질문에서 “글로벌 라벨로 JTMS_F407을 PB14, PB12에 연결”이라고 하셨는데, KiCad/OrCAD에서 같은 글로벌 라벨을 두 군데에 붙이면 그 둘은 전기적으로 같은 넷(쇼트)입니다. 따라서 PB14와 PB12가 “같은 MCU의 두 핀”에 동시에 같은 라벨로 직결돼 있다면 일반적으로는 권장되지 않습니다(한쪽이 출력일 때 충돌 위험). 보통은 PB14는 디버그 MCU 핀, PB12는 커넥터나 점퍼/0옴 저항을 지난 다른 지점처럼 “서로 다른 부품의 핀”인 경우가 많습니다. 이 구조는 실무에서 디버그 신호를 “외부 디버거로도 빼고, 온보드 디버거로도 연결”하려고 점퍼(0 ohm, solder bridge, 2:1 mux 등) 옵션을 주는 패턴에서 자주 나옵니다.정리하면, 해당 핀 선택은 SPI/USART 통신을 하려는 목적이라기보다 디버깅 신호를 어떤 GPIO로 구성할지(그리고 라우팅/포트 집중/확장성까지) 고려한 설계 선택일 가능성이 높고, 다른 핀으로 바꿔도 되지만 부팅 안정성, 포트 충돌, 디버그 신호 품질(배선 길이/시리즈 저항/그라운드 리턴)까지 함께 만족하도록 고르시는 게 핵심입니다.

수강기간 변경 문의드립니다.

안녕하세요,문의주셔서 감사합니다.해당 강의는 무제한으로 바뀌었고, 공지를 한번 드리긴 했었는데기존 수강생 분들도 물론 무제한으로 바꿔드리고 있습니다!반영해드렸으니 확인해보시고 또 궁금한 점은 편히 문의주세요!

수강기간 변경관련

안녕하세요,문의주셔서 감사합니다.해당 강의는 무제한으로 바뀌었고, 공지를 한번 드리긴 했었는데기존 수강생 분들도 물론 무제한으로 바꿔드리고 있습니다!반영해드렸으니 확인해보시고 또 궁금한 점은 편히 문의주세요!