① PS(C코드): 멀티톤 신호 합성
       ↓
② PS: DDR에 입력 배열 저장
       ↓
③ DMA MM2S: DDR → AXI-Stream → FIR S_AXIS (입력)
       ↓
④ FIR IP: 필터링 + 데시메이션 (M=2)
       ↓
⑤ DMA S2MM: FIR M_AXIS → AXI-Stream → DDR (출력 배열 저장)
       ↓
⑥ PS(C코드): DDR에서 결과 읽기 → UART 출력

DMA는 채널이 2개

• MM2S (Memory-Mapped to Stream): DDR → FIR 방향
• S2MM (Stream to Memory-Mapped): FIR → DDR 방향

생성하려는 block design

bd_fir_dma: custom fir ip와 PS ip, DMA ip를 붙인 block design

Block Design: bd_fir_dma
├── ZYNQ7 Processing System   ← IP 1
├── AXI DMA                   ← IP 2
└── fir_decimator_n43_axis    ← IP 3 (우리 것)

Vivado가 "Run Connection Automation" 시 자동으로 추가하는 IP 2개:

1. Vivado Block Design 생성

GUI에서 IP들을 배치하고 연결하는 것:

• Zynq PS7 IP — ARM 코어, HP0 포트 활성화
• AXI DMA IP — DDR ↔ AXI-Stream 브리지
• Custom FIR IP (fir_decimator_n43_axis) — 커스텀 IP로 패키징해서 삽입

연결:

AXI DMA MM2S → (AXI-Stream) → FIR S_AXIS (입력)
AXI DMA S2MM ← (AXI-Stream) ← FIR M_AXIS (출력)
AXI DMA ↔ PS7 HP0 (DDR 직접 접근)

2. 비트스트림 생성 + XSA 내보내기

Block Design → Synthesize → Implement → Generate Bitstream → Export Hardware (.xsa)

Vivado GUI로 Block Design 완성하기

진행 순서

1. 새 프로젝트 생성 (Board: Zybo Z7-20)
2. Create Block Design
3. IP 추가: ZYNQ7 Processing System
4. IP 추가: AXI DMA
5. IP 추가: 우리 FIR (커스텀 IP 패키징 먼저 필요)
6. Create HDL Wrapper
7. Generate Bitstream
8. Export Hardware

1. 새 프로젝트 생성

1. Create Project 클릭
2. Project name: fir_decimator_trans_n43
3. Project location: 원하는 경로 설정
4. Project type: RTL Project Sources 추가할 때 RTL 파일들 넣기:
   • rtl/transposed_form/n43/fir_decimator_n43_axis.v ← 최상위 top
   • rtl/transposed_form/decimator_m2_phase0.v
   • rtl/transposed_form/n43/fir_decimator_n43.v
   • rtl/transposed_form/n43/fir_n43.v
5. constraint file은 포함하지 말기! 나는 실수로 포함시킴
6. Default Part에서 Board 탭 → Zybo Z7-20 선택
7. finish

2. Create Block Design

Module Reference 방식

Vivado 좌측 Flow Navigator에서:

1. IP INTEGRATOR → Create Block Design 클릭
2. Design name: bd_fir_dma

3. IP 추가: ZYNQ7 Processing System

1. 캔버스 우클릭 → Add IP → 검색창에 zynq 입력 → ZYNQ7 Processing System 더블클릭
2. PS 설정하기 블록 더블클릭 이후 수정할 두 가지 항목 확인

1. 포트 활성화 PS-PL Configuration → HP Slave AXI Interface → S AXI HP0 Interface 체크

• HP0: PL(DMA)이 PS(CPU)의 DDR에 접근하는 유일한 경로, 기본 비활성화이므로 활성화 해주기

2. 클럭 확인 Clock Configuration → PL Fabric Clocks → FCLK_CLK0 가 100MHz인지 확인

4. IP 추가: AXI DMA

1. 캔버스 우클릭 → Add IP → 검색창에 axi dma 입력 → AXI Direct Memory Access 더블클릭
2. DMA 설정하기

블록 더블클릭 이후 확인/수정할 항목 확인

상단

Read Channel (MM2S) — DDR → FIR 방향

Write Channel (S2MM) — FIR → DDR 방향

하단

5. IP 추가: Custom FIR

1. 캔버스 우클릭 → Add Module → fir_decimator_n43_axis 선택

2. 캔버스 상단 초록색 배너 "Run Connection Automation" 클릭

3. 모든 항목 체크 : Vivado가 SmartConnect, Processor System Reset을 자동 생성하고 연결합니다

6. 자동 생성된 IP:AXI Interconnect

"Run Connection Automation"으로 자동 생성된 AXI Direct Memory Access 더블클릭

• Number of Slave Interfaces → 2

7. FIR 모듈 수동 연결

포트 연결 요약:

PS GP0 → SmartConnect → DMA S_AXI_LITE     (PS가 DMA 제어)
DMA M_AXI_MM2S → PS HP0                    (DMA가 DDR 읽기)
DMA M_AXI_S2MM → PS HP0                    (DMA가 DDR 쓰기)
DMA M_AXIS_MM2S → FIR S_AXIS               (DDR → FIR)
FIR M_AXIS → DMA S_AXIS_S2MM               (FIR → DDR)

첫 번째: aclk 연결

FIR 블록의 aclk 포트 → PS 블록의 FCLK_CLK0 포트로 드래그

두 번째: aresetn 연결

FIR 블록의 aresetn 포트 → rst_ps7_0_100M 블록의 peripheral_aresetn 포트로 드래그

aresetn : FIR IP의 active-low 리셋 포트

세 번째: DMA → FIR 입력 연결

axi_dma_0 블록의 M_AXIS_MM2S 포트 → FIR 블록의 s_axis 포트로 드래그

네 번째: FIR → DMA 출력 연결

FIR 블록의 m_axis 포트 → axi_dma_0 블록의 S_AXIS_S2MM 포트로 드래그

다섯 번째: Run Block Automation 클릭 상단 녹색 배너의 Run Block Automation 클릭

** 여섯 번째: 검증하기** 단축키 F6를 눌러 Validate Design 진행 Digilent 보드 파일을 쓰는 Zybo 설계에서는 항상 뜨는 경고라고 합니다. 실제 DDR 동작에 문제 없다고 합니다.

8. Create HDL Wrapper

Sources 탭에서 Block Design 파일(bd_fir_dma) 우클릭 → Create HDL Wrapper → Let Vivado manage wrapper and auto-update 선택

9. Generate Bitstream

Synthesis → Implementation → Generate Bitstream

error 1

비트스트림 생성 실패

error 1 해결

로그 첫 줄:synth_design -top fir_decimator_n43_axis

두 가지 문제가 동시에 존재했다.

문제 1: 합성 Top 모듈 오설정

합성 Top 모듈이 bd_fir_dma_wrapper가 아닌 fir_decimator_n43_axis로 설정되어 있었다. 이는 Block Design 생성 이전에 FIR IP 단독 검증을 위해 fir_decimator_n43_axis를 Top으로 설정해 두었던 상태가 그대로 남아 있었기 때문이다. Block Design Wrapper가 아닌 FIR 모듈 단독으로 합성을 시도하니 DMA, PS 등 나머지 연결이 전혀 없는 불완전한 설계가 합성 대상이 되었다.

→ Sources 패널에서 bd_fir_dma_wrapper를 우클릭 → Set as Top으로 변경

문제 2: 불필요한 XDC 파일 활성화

로그에서 zybo_n43.xdc가 포함되어 있었다. 이 XDC 파일은 FIR IP를 단독으로 합성할 때 사용하던 핀 제약 파일로, fir_decimator_n43_axis의 포트를 물리 핀에 직접 매핑하는 내용이 담겨 있었다. Block Design 기반 설계에서는 FIR 포트가 내부적으로 DMA에 연결되므로 물리 핀 매핑이 필요 없는데, 이 XDC가 여전히 활성화되어 있어 잘못된 핀 제약이 적용되고 있었다.

→ Sources 패널 → Constraints 폴더 → zybo_n43.xdc 우클릭 → Disable File

두 문제를 모두 수정한 뒤 다시 시도했다.

9-1. Generate Bitstream 다시 시도

드디어 성공

IMPLEMENTATION → Open Implemented Design → Report Timing Summary

• WNS = +1.332ns — Step 4의 +0.278ns보다 오히려 더 여유가 생겼음
• TNS = 0.000ns (타이밍 위반 없음)
• Failing Endpoints = 0

10. Export Hardware

File → Export → Export Hardware → Include bitstream 체크 지정한 디렉토리에 xsa 파일을 export하는 과정입니다. XSA (Xilinx Support Archive): Vivado가 만드는 하드웨어 설명 패키지 파일

11. TCL 스크립트 추출

Block Design은 Vivado 프로젝트 파일(.xpr) 안에만 존재합니다. 프로젝트가 유실되거나 다른 환경에서 재현해야 할 때를 대비해 write_bd_tcl로 Block Design 전체를 TCL 파일로 추출해 레포에 보관합니다.

추출 명령어

Block Design이 열린 상태에서 Vivado TCL Console에서 실행:

write_bd_tcl -force /home/young/dev/10_zynq-fir-decimation-ip/vivado/bd_fir_dma.tcl

추출 결과: /home/young/dev/10_zynq-fir-decimation-ip/vivado 디렉토리안에 bd_fir_dma.tcl 스크립트 저장

포함 내용

write_bd_tcl이 추출하는 정보:

• 모든 IP 정보 (버전 포함: processing_system7:5.5, axi_dma:7.1 등)
• IP 파라미터 설정 전체 (stream width=16 등)
• 모든 배선 연결 (AXI, AXI-Stream, 클럭, 리셋)
• 주소 할당 (assign_bd_address)
• 마지막에 validate_bd_design 자동 호출

재현 방법

다른 머신에서 Block Design을 재현하려면:

1. Vivado 2024.2 + Zybo Z7-20 보드 파일 설치
2. RTL 소스 4개가 포함된 Vivado 프로젝트 생성 (1 참고)
3. Vivado TCL Console에서:

source vivado/bd_fir_dma.tcl

RTL 소스 없이 sourcing하면 fir_decimator_n43_axis 모듈을 찾지 못해 실패한다.

error 정리

** 합성 Top 오설정 + XDC 충돌** — 합성 Top이 bd_fir_dma_wrapper가 아닌 fir_decimator_n43_axis로 남아 있었고, 단독 합성용 zybo_n43.xdc가 활성화되어 잘못된 핀 제약이 적용됨 → Top 모듈 변경 및 XDC 비활성화

마무리하며

Validate Design 성공과 비트스트림 생성 성공은 다르다는 걸 이번 작업에서 체감했습니다. Vivado가 "연결에 문제없다"고 판정해도, 합성 Top이 잘못 설정되어 있거나 프로젝트 초기에 넣어둔 XDC 파일이 남아있으면 비트스트림 단계에서 막힙니다. 에러 메세지를 읽고 원인을 역추적하는 과정이 번거롭긴 했지만, 덕분에 Block Design의 외부 포트 개념과 Vivado 프로젝트 상태 관리 방식을 제대로 이해하게 됐습니다. 다음 단계는 생성된 .xsa를 Vitis에서 열어 DMA를 제어하는 C 코드를 작성하는 것입니다.

Clocking Wizard IP

먼저 clk_wiz는 Vivado의 Clocking Wizard IP로, Zybo Z7-20 보드에서 들어오는 125 MHz 기준 클럭을 원하는 주파수의 클럭으로 변환할 때 사용하는 블록입니다.

1. Clocking Wizard 선택

1. IP Catalog 열기
   

2. Clocking Wizard 검색

3. 더블클릭해서 추가
   

2. Clocking Options 탭

• Clock Monitor

  • 입력 클럭 이상을 감시하는 기능입니다.

• Primitive

  • MMCM (Mixed-Mode Clock Manager)
    • PLL 기능에 더해 위상 이동, Duty 조절, 다중 출력 제어 등 더 다양한 클럭 제어 기능을 제공합니다.
  • PLL (Phase-Locked Loop)
    • 입력 클럭에 위상과 주파수를 맞춰 다른 주파수의 안정적인 클럭을 만들어내는 회로입니다.
    • 단순한 클럭 배수/분주 용도에 적합하며 설정도 비교적 단순합니다.

• Clocking Features

  • Frequency Synthesis
    • 주파수 변환 기능입니다.
    • 원하는 출력 클럭을 만들 때 사용합니다.
  • Minimize Power
    • 전력 절약 위주 설정입니다.
    • 보통은 체크하지 않아도 됩니다.
  • Phase Alignment
    • 위상 정렬 관련 기능입니다.
    • 일반적인 실습에서는 기본값으로 두어도 무방합니다.
  • Dynamic Reconfig
    • 동작 중 클럭 설정을 바꾸는 기능입니다.
  • Safe Clock Startup
    • 클럭이 안정적으로 시작되도록 돕는 옵션입니다.

• Jitter Optimization

  • Balanced
    • 기본 권장 옵션입니다.
  • Minimize Output Jitter
    • 출력 지터를 최소화하는 쪽으로 최적화합니다.
  • Maximize Input Jitter Filtering
    • 입력 지터를 더 강하게 필터링합니다.

• Dynamic Reconfig Interface Options

  • AXI나 DRP를 통한 런타임 재설정 기능입니다.

• Input Clock Information

  • Primary의 Input Frequency (MHz)는 clk_in1에 들어오는 입력 클럭 주파수입니다.
  • Zybo Z7-20 기준으로 125MHz에 맞춰 설정하면 됩니다.
  • Secondary는 보조 입력 클럭을 쓰지 않으면 체크하지 않아도 됩니다.
  • Port Name은 기본값인 clk_in1을 그대로 사용해도 됩니다.
  • Input Jitter는 특별한 이유가 없다면 기본값을 사용합니다.

3. Output Clocks 탭

• Output Freq (MHz)의 Requested 값을 원하는 출력 주파수로 변경합니다.
• Phase (degrees), Duty Cycle (%), power_down 등은 위상 조정, 펄스 폭 조정, 고급 피드백, 저전력 제어와 관련된 고급 기능입니다.
• 일반적인 실습에서는 기본값으로 두고 주파수만 바꿔도 충분합니다.

4. PLLE2 Settings 탭

이 탭은 Vivado가 계산한 PLL 내부 파라미터를 요약해서 보여주는 화면입니다.

• CLKIN1_PERIOD = 8.000

  • 입력 클럭 주기가 8ns라는 뜻이며, 주파수로는 125MHz입니다.

• CLKFBOUT_MULT = 7

  • 입력 클럭을 내부 VCO 기준으로 7배 올리는 설정입니다.
  • 내부 VCO 주파수 계산에 사용됩니다.

• DIVCLK_DIVIDE = 1

  • 입력 쪽 추가 분주가 없다는 뜻입니다.

• clk_out1

  • Divide = 125
  • Duty Cycle = 0.500
  • Phase = 0.000

즉, 입력 125MHz를 내부에서 7배한 뒤 125로 나누므로 최종 출력은 7MHz가 됩니다.

5. Generate

설정을 마쳤다면 Generate를 눌러 IP를 생성하면 됩니다.

Block Memory Generator IP

Block Memory Generator는 FPGA 내부의 BRAM(Block RAM)을 손쉽게 RAM이나 ROM 형태로 구성할 수 있게 해주는 IP입니다. 간단한 데이터 저장, 계수 테이블 저장, LUT 대체 용도 등에서 자주 사용합니다.

1. Block Memory Generator 선택

1. IP Catalog 열기

2. Block Memory Generator 검색

3. 더블클릭해서 추가
   

2. Basic 탭

특별히 바꿔야 하는 옵션이 없다면 기본값을 사용해도 됩니다.

3. Port A Options 탭

현재 화면의 의미

1. 한 주소에 저장되는 데이터 폭이 8비트입니다.
2. 8비트 데이터를 8개 주소까지 저장할 수 있습니다.
3. BRAM은 Always Enabled 상태로 두고 주소와 write enable로 제어합니다.
4. 출력 레지스터는 사용하지 않습니다.

• Memory Size

  • Write Width
    • 한 번 쓸 때 사용하는 데이터 폭입니다.
    • 값이 8이면 한 주소에 8비트를 씁니다.
  • Read Width
    • 한 번 읽을 때 사용하는 데이터 폭입니다.
    • 값이 8이면 한 주소에서 8비트를 읽습니다.
  • Write Depth
    • 몇 개 주소에 데이터를 쓸 수 있는지입니다.
    • 값이 8이면 8개의 주소를 사용할 수 있습니다.
  • Read Depth
    • 몇 개 주소에서 데이터를 읽을 수 있는지입니다.
    • 보통 Write Depth와 동일하게 설정합니다.

• Enable Port Type

  • Use ENA Pin
    • BRAM에 ena 포트가 추가됩니다.
    • ena = 1일 때만 해당 클럭에서 읽기/쓰기 동작을 수행합니다.
  • Always Enabled
    • BRAM이 항상 활성화된 상태입니다.
    • 주소를 넣으면 읽고, we = 1이면 해당 주소에 데이터를 씁니다.

• Port A Optional Output Registers

  • Primitives Output Register
    • BRAM 내부 출력에 레지스터를 하나 추가합니다.
    • 타이밍은 더 좋아질 수 있지만 읽기 지연이 1클럭 늘어날 수 있습니다.
  • Core Output Register
    • BRAM 바깥에 출력 레지스터를 하나 더 추가합니다.
    • 이 경우에도 출력 지연이 늘어날 수 있습니다.
  • SoftECC Input Register
    • ECC를 사용할 때 관련되는 옵션입니다.
    • 이번 설정처럼 No ECC라면 크게 신경 쓰지 않아도 됩니다.
  • REGCEA Pin
    • 출력 레지스터의 clock enable 핀입니다.
    • 출력 레지스터를 사용할 때 의미가 있습니다.

• Port A Output Reset Options

  • RSTA Pin
    • BRAM 출력 레지스터에 reset 핀을 추가합니다.
  • Output Reset Value (Hex)
    • reset 시 출력값을 지정합니다.
  • Reset Memory Latch
    • 출력 래치나 레지스터 reset과 관련된 옵션입니다.
  • Reset Priority
    • reset과 CE가 동시에 들어왔을 때 어떤 신호를 우선할지 정하는 옵션입니다.

• READ Address Change A

  • 읽기 주소가 바뀔 때 출력 동작과 관련된 고급 옵션입니다.
  • 일반적인 단순 BRAM 사용에서는 기본값을 유지해도 됩니다.

4. Generate

설정을 마쳤다면 Generate를 눌러 IP를 생성하면 됩니다.

ILA IP

ILA (Integrated Logic Analyzer)는 FPGA 내부 신호를 실시간으로 관찰할 수 있게 해주는 디버깅용 IP입니다. 시뮬레이션에서는 보이지 않는 실제 보드 동작을 확인할 때 매우 유용합니다.

1. ILA 선택

1. IP Catalog 열기

2. ILA 검색

3. 더블클릭해서 추가
   

2. General Options

• Monitor Type

  • Native
    • 일반 RTL 신호를 직접 관찰하는 모드입니다.
  • AXI
    • AXI 버스를 분석할 때 사용하는 전용 모드입니다.

• Number of Probes

  • ILA에 몇 개의 probe 포트를 둘지 정하는 옵션입니다.

• Sample Data Depth

  • 파형을 몇 샘플까지 저장할지 정하는 값입니다.
  • 숫자가 클수록 더 긴 구간을 볼 수 있지만 FPGA 자원을 더 사용합니다.
  • 1024 정도의 기본값이면 보통 충분합니다.

• Same Number of Comparators for All Probe Ports

  • 모든 probe 포트에 같은 수의 trigger comparator를 적용할지 정하는 옵션입니다.
  • 보통 체크한 상태로 둡니다.
  • comparator는 probe 값이 설정한 조건을 만족하는지 비교하는 장치입니다.

• Number of Comparators

  • 각 probe 포트에 comparator를 몇 개 둘지 정하는 값입니다.

• Trigger Out Port

  • ILA가 트리거를 발생시켰을 때 외부로 신호를 내보내는 기능입니다.
  • 여러 디버그 IP를 연동할 때 사용합니다.

• Trigger In Port

  • 외부 신호를 받아 ILA 캡처를 시작하게 하는 기능입니다.
  • 고급 디버깅에서 사용합니다.

• Input Pipe Stages

  • ILA 입력 앞에 파이프라인 레지스터를 몇 단계 둘지 설정하는 기능입니다.

• Trigger and Storage Settings

  • Capture Control
    • 언제부터, 어떤 방식으로 저장할지 세밀하게 제어하는 옵션입니다.
  • Advanced Trigger
    • 복잡한 조건식으로 트리거를 걸 수 있는 기능입니다.
    • 예를 들어 특정 값이 나온 뒤 다른 값이 이어질 때만 캡처하도록 설정할 수 있습니다.

3. Probe Ports(0..1)

• Probe Width
  • 각 probe에 연결할 신호의 비트폭을 결정하는 화면입니다.

현재 화면에서는 다음과 같이 설정되어 있습니다. probe0 : 40비트 신호 연결 가능 probe1 : 1비트 신호 연결 가능

• Probe Trigger or Data
  • DATA AND TRIGGER
    • 파형 데이터로도 보고 트리거 조건에도 쓸 수 있음
      • DATA
    • 파형으로는 볼 수 있고 트리거 조건으로는 못 씀
      • TRIGGER
    • 트리거 조건으로만 쓰고 파형 데이터로는 못 봄

4. Generate

설정을 마쳤다면 Generate를 눌러 ILA IP를 생성하면 됩니다.

마무리하며

이번 글에서는 Zybo Z7-20 보드에서 자주 사용하게 되는 Clocking Wizard, Block Memory Generator, ILA IP를 정리하였습니다.

1. 프로젝트 종류 선택

64-bit adder RTL 합성에서는 보통 RTL Project 선택을 합니다.

** 1. RTL Project**

• 가장 일반적인 HDL 설계용.
• Verilog/VHDL 소스 추가, 합성, 구현, 타이밍 분석까지 가능

추가 체크박스( RTL Project 아래 ):

• Do not specify sources at this time: 지금은 소스 안 넣고 빈 프로젝트만 생 성.
• Project is an extensible Vitis platform: Vitis 플랫폼 개발용(일반 RTL 합성 에서는 보통 체크 안 함).

** 2. Post-synthesis Project**

• RTL이 아니라 이미 합성된 결과물(netlist/DCP) 기준으로 여는 프로젝트
• 디바이스 리소스/배치/타이밍 분석 용도
• 보통 초반 설계 단계에서는 잘 안 씀

** 3. I/O Planning Project**

• 소스 없이 핀맵/패키지(I/O) 계획만 먼저 할 때 사용
• XDC 핀 배치 준비 용도

** 4. Imported Project**

• Synplify 같은 외부 툴 프로젝트를 Vivado로 가져올 때 사용
• 일반 RTL 직접 작성 과제에서는 거의 안 씀

** 5. Example Project**

• Vivado 예제 템플릿으로 시작
• 학습용/샘플 확인용

2. 프로젝트 소스 등록

이미 rtl 설계 파일이 있으니 Add Files을 눌러 파일(*.v)을 추가합니다. 물리/타이밍 제약 사항을 넣는 페이지입니다. Next 눌러줍니다.

3. 보드 선택

가장 많이 이용하는 Basys3 보드를 선택했습니다. Finish 눌러줍니다.

4. Run Synthesis

합성할 모듈이 Top 모듈인지 확인하고 좌측에서 Run Synthesis를 눌러줍니다. XDC(제약 사항)가 없는 합성이었기에 Open Synthesized Design을 선택합니다.

5. 결과 확인

1. 로그 확인

24 Infos, 1 Warnings, 0 Critical Warnings and 0 Errors encountered.

synth_design completed successfully

2. Report Utilization으로 사용 LUT/IOB 확인

LUT: 108/20800 IOB: 193/ 106 (Top 포트가 a(64)+b(64)+sum(64)+c_out(1)=193비트라 Basys3 가용 I/O(106)를 초과합니다.)

3. Open Elaborated Design 확인

rca_32bit 모듈 두 개를 사용하여 계층적으로 모델링 된 것과 입출력 포트가 제대로 합성된 것을 확인할 수 있습니다.

4. Device View 확인

1. [Run Synthesis] 버튼을 눌러 실제 합성을 진행합니다.
2. Open Synthesized Design를 눌러 합성된 결과물을 확인합니다.

중앙의 흰 사각형/분홍 점 : 현재 배치된 셀, 즉 합성 결과물이 올라간 위치

상태 해석: 중앙에 배치된 셀이 매우 적고(흰 사각형 몇 개) 대부분의 칩 면적이 비어 있습니다. 이는 64비트 가산기 회로가 LUT 사용량이 낮아 칩의 극히 일부만 점유하고 있다는 것을 시각적으로 보여줍니다. I/O가 193비트로 핀 수를 초과했기 때문에 IOB 쪽에는 제대로 매핑이 되지 않은 상태로 보입니다.

5. 데이터 패스 지연 시간 확인

1. Tcl console 창에 report_timing -from [get_ports a[*]] -to [get_ports sum[*]] -setup 해당 명령어를 입력합니다.
2. 해당 명령어는 Netlist을 그래프로 인식하고, 지정된 시작점($a$)에서 끝점($sum$)까지의 모든 경로 중 가장 느린 최악의 경로를 찾아 지연 시간을 합산합니다. 최악의 경로

• 시작점 : a[2]
• 끝점 : sum[61]
• Data Path Delay : 19.706ns(logic delay 6.708ns, route delay 12.998ns)
• Logic Levels : 28 (신호가 통과한 소자의 개수)
• 최대 주파수 : $1 / 19.706ns \approx 50.74MHz$

결론 : Half adder에서부터 RCA 64-bit adder까지의 계층적 구조적 한계, 즉 Ripple Carry 구조에서는 carry가 LSB에서 MSB 방향으로 직렬 전파되기 때문에 비트 수에 비례해 critical path가 길어지는 문제로 인해 net delay가 19.706ns 중 12.998ns를 차지할 만큼 배선 지연이 압도적으로 커졌습니다. 이로 인해 최대 동작 주파수가 약 50.74MHz에 그쳐 고속 설계 요구사항을 만족하기 어려우므로 하드웨어적 보완이 필요합니다.

해결 :

• 게이트 레벨 모델링 대신 데이터 플로우 모델링(assign 할당문)으로 재합성하여, 합성 툴이 carry look-ahead 등 최적화된 내부 구조를 자동으로 선택할 수 있도록 한다.
• carry chain의 중간에 pipeline register를 삽입해 critical path를 절반으로 단축한다.

마무리하며

합성은 에러 없이 완료되었고, LUT 사용량도 낮은 수준으로 확인되었습니다. 다만 Top I/O가 193비트로 Basys3의 가용 I/O(106핀)를 초과하여 그대로 구현하기는 어려운 상황이며, 실제 FPGA에 올리려면 I/O 수를 줄이는 설계 수정이 선행되어야 합니다. 또한 이번 실습에서는 XDC 제약을 적용하지 않았기 때문에 타이밍 리포트는 참고 수준으로만 해석하였습니다.

다음 실습에서는 XDC 제약을 적용하여 실제 타이밍 에러를 직접 확인하고 디버깅하는 과정을 진행할 예정입니다.

설치 전 OS 버전 확인

fastfetch 프로그램으로 확인했을 때 OS 버전은 Ubuntu 24.04.4 LTS x86_64입니다.

1. AMD 회원가입 및 로그인

2. 2024.2 버전 설치

AMD 공식 다운로드 페이지에 접속해 2024.2 버전을 선택합니다. https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/vivado-design-tools/2024-2.html 스크롤을 내려 Linux용 설치 파일을 선택합니다.

3. 무결성 확인

해당 파일이 있는 디렉토리로 이동 후 아래의 명령어를 입력해 파일의 해시값을 추출합니다.

md5sum FPGAs_AdaptiveSoCs_Unified_2024.2_1113_2356_Lin64.bin

# 32자리의 16진수 값 출력
6be7a694bc631e02862e173f94165f88

출력된 값을 AMD 공식 홈페이지에 명시된 해시값과 비교해 일치 여부를 확인합니다. 일치함을 확인할 수 있습니다.

4. 파일 실행

아래의 명령어를 순서대로 입력해 설치 파일을 실행합니다.

# 작업 디렉토리를 파일이 설치된 곳으로 이동
cd ~/Downloads

# 실행 권한 부여
young@young-PC:~/Downloads$ chmod +x FPGAs_AdaptiveSoCs_Unified_2024.2_1113_2356_Lin64.bin

# 파일 실행
./FPGAs_AdaptiveSoCs_Unified_2024.2_1113_2356_Lin64.bin

실행 권한 부여: chmod(Change Mode) 명령어에 +x(eXecute) 옵션을 주어 해당 파일에 실행 권한을 부여합니다.

파일 실행: 리눅스는 보안상 현재 디렉토리에 있는 파일을 파일명만으로 실행할 수 없습니다. 현재 위치를 나타내는 ./를 앞에 붙여야 합니다.

5. 설치 과정

1. Continue 선택

Zynq-7000(Pynq-Z2)이나 Artix-7(Basys 3) 같은 7 Series 칩을 사용하는 경우, 2024.2와 2025.2 간의 성능 차이는 사실상 없습니다. 굳이 최신 버전을 고집하기보다는 어느 정도 검증된 2024.2 버전을 사용하는 것이 안정성 면에서 더 낫습니다.

2. 로그인

3. Download and Install Now 선택

필요한 파일만 선택적으로 다운로드할 수 있게하는 옵션입니다.

4. Vivado 선택

5. Vivado ML Standard 선택

무료 버전입니다. 타겟으로 하는 Pynq-Z2(Zynq-7000 계열)와 Basys 3(Artix-7 계열)는 모두 이 범주에 들어갑니다.

6. Design Tools (설계 도구)

• Vivado와 Vitis HLS 기본 선택 유지

• Vitis Networking P4: 데이터센터 스위치 라우터에서 패킷을 처리하는 특수 언어(P4)를 컴파일하는 엔진입니다. 일반적인 FPGA 설계와는 완전히 무관합니다.

• Vitis Model Composer: MATLAB에서 블록 다이어그램을 그리면 하드웨어 코드로 자동 변환해 주는 도구입니다.

  • Vitis Embedded Development: Zynq 칩 내부의 ARM 프로세서에서 돌아갈 소프트웨어(펌웨어)를 C/C++로 개발하기 위한 통합 개발 환경(IDE)입니다. Pynq-Z2 보드에 미리 컴파일된 리눅스를 올리고 웹브라우저(Jupyter)에서 파이썬으로 보드를 제어할 것이면 필요 없습니다.

• Power Design Manager (PDM): 칩이 소모하는 전력을 계산하는 도구인데, 주로 최신 공정(UltraScale+, Versal)을 타겟으로 하므로 구형인 7 Series 칩에는 거의 쓰이지 않습니다.

• DocNav: PDF 문서 모음집입니다. 필요한 문서는 Xilinx 공식 사이트나 구글에서 직접 검색하는 편이 더 효율적입니다

7. Devices

타겟으로 하는 장치만 선별적으로 선택합니다.

• Zynq-7000: Pynq-Z2 보드에 탑재된 칩입니다. ARM CPU(프로세서)와 FPGA(프로그래머블 로직)가 하나의 칩 안에 통합된 SoC(System-on-Chip) 구조로, 하드웨어 가속기를 구현하고 제어할 때 핵심적인 역할을 합니다.

• Artix-7 : Basys 3 보드에 탑재된 칩입니다. 가격 대비 성능이 우수해 전 세계 대학의 디지털 논리 회로 실습에서 가장 널리 사용되는 칩입니다.

• Kintex-7, Virtex-7: Artix-7보다 규모가 크고 고성능인 칩들로, 주로 통신 기지국이나 방송 장비 등 전문 산업 분야에서 활용됩니다.

• UltraScale, UltraScale+, Versal ACAP: 7 Series 이후 세대의 칩들로, 데이터센터 AI 가속이나 5G 통신 인프라처럼 고성능·대규모 처리가 요구되는 환경에서 사용됩니다. 가격은 수백만 원에서 수천만 원대에 이릅니다.

• Engineering Sample (ES) Devices: 정식 출시 전 검증 목적으로 일부 기업에만 제공되는 프로토타입 칩입니다. 일반 사용자가 접할 일은 거의 없습니다.

8. 용량 확인

필요한 옵션만 선택해도 설치 용량이 60.97GB에 달합니다. 불필요한 옵션까지 포함하면 100~200GB를 쉽게 넘길 수 있으니, 선택 항목을 다시 한번 확인하고 설치 전 디스크 여유 공간을 점검해 두세요.

9. 약관 동의

10. 설치 경로 설정

기본 설치 경로인 /tools/Xilinx는 루트 디렉토리 하위에 있어 sudo 권한이 필요합니다. 설치 프로그램을 일반 권한으로 실행했기 때문에 이 경로에는 설치할 수 없습니다.

사용자 홈 디렉토리 아래에 Xilinx 폴더를 생성하고 설치 경로를 해당 폴더로 변경합니다.

11. 환경 변수 등록

설치 후 터미널에서 vivado 명령어를 사용하려면 환경 변수를 등록해야 합니다.

# 설치 경로 확인
ls -l /home/young/Xilinx/Vivado/2024.2/settings64.sh

# .bashrc 파일 끝에 환경 변수 추가
echo "source /home/young/Xilinx/Vivado/2024.2/settings64.sh" >> ~/.bashrc

# 변경사항 즉시 적용
source ~/.bashrc

12. 실행

# 터미널로 실행 가능
vivado

성공!

마무리하며

이것으로 Vivado 설치가 완료되었습니다. 다음 글에서는 Vivado 기본 사용법과 간단한 RTL 합성 과정을 다뤄보겠습니다.

Half Adder를 첫 예제로 고른 이유는 간단합니다. 로직 자체가 단순해서 설계보다 "내가 만든 게 정말 맞게 동작하는지 어떻게 확인하지?" 라는 검증의 흐름에 집중하기 좋기 때문입니다. 처음 RTL을 접했을 때 Verilog 문법이나 시뮬레이터 사용법부터 막막하게 느껴졌습니다. 이 글이 같은 고민을 하고 있는 분들께 조금이나마 도움이 됐으면 좋겠습니다.

RTL 설계 및 검증 프로세스

RTL(Register Transfer Level) 설계는 단순히 코드를 짜는 것에 그치지 않고, 의도한 대로 동작하는지 증명하는 과정이 핵심입니다. 일반적인 순서는 다음과 같습니다.

1. RTL 작성 (Design): 하드웨어 로직 구현

2. 테스트벤치 작성 (Testbench): 입력 시나리오 및 검증 로직 작성

3. 컴파일 (Compilation): 설계 및 테스트벤치 코드의 문법 체크 및 실행 파일 생성

4. 검증 (Verification): 파형(Waveform) 분석 또는 로그 확인

1. RTL 작성 (Design): Half Adder

반가산기는 가장 기본적인 산술 연산 블록으로, 2진수 1비트 두 개를 더해 합(Sum)과 올림수(C_out)를 출력합니다.

`timescale 1ns / 1ps

module half_adder (
    input  a, b,
    output c_out, sum
);
  // XOR 게이트를 이용한 Sum 구현
  xor g1 (sum, a, b);
  // AND 게이트를 이용한 Carry 구현
  and g2 (c_out, a, b);
endmodule

2. 테스트벤치(Testbench) 작성

테스트벤치는 설계한 모듈(DUT, Design Under Test)에 가상의 입력을 넣어주는 실험 환경입니다. 여기서는 두 가지 방식을 비교합니다.

A. Directed Testbench (수동 검증)

입력값을 하나하나 직접 인가하고, 터미널의 로그나 파형을 보고 눈으로 직접 결과를 확인하는 방식입니다.

• 장점: 직관적이며 소규모 회로의 동작을 빠르게 확인할 때 유리합니다.

• 단점: 입력 조합이 많아질수록 누락되는 케이스가 생기기 쉽고, 하나하나 확인하기 번거롭습니다.

// directed testbench for half adder
`timescale 1ns / 1ps

module test_half_adder ();
  reg t_a, t_b;
  wire t_c_out, t_sum;
  half_adder uut (
      .a(t_a),
      .b(t_b),
      .c_out(t_c_out),
      .sum(t_sum)
  );

  initial #100 $finish;
  initial begin
    $dumpfile("sim/build/output/iverilog/test_half_adder.vcd");
    $dumpvars(0, test_half_adder);
    $display("a b | c_out sum");
    $display("-------------");
    t_a = 0;
    t_b = 0;
    #10;
    $display("%b %b | %b     %b", t_a, t_b, t_c_out, t_sum);
    t_a = 0;
    t_b = 1;
    #10;
    $display("%b %b | %b     %b", t_a, t_b, t_c_out, t_sum);
    t_a = 1;
    t_b = 0;
    #10;
    $display("%b %b | %b     %b", t_a, t_b, t_c_out, t_sum);
    t_a = 1;
    t_b = 1;
    #10;
    $display("%b %b | %b     %b", t_a, t_b, t_c_out, t_sum);

  end
endmodule

B. Self-checking Testbench (자동 검증)

입력값을 랜덤으로 인가하거나 모든 조합을 돌리면서, Reference Model(정답지)과 실제 출력값을 비교하여 자동으로 PASS/FAIL을 판정하는 방식입니다.

• 눈으로 직접 확인하는 대신, 코드 내부의 if문과 ref_model이 결과를 실시간으로 대조합니다.
• repeat 문을 통해 수천 번의 랜덤 테스트를 수행할 수 있어, 설계자가 예상치 못한 코너 케이스(Corner Case)를 잡기에 유리합니다.
• seen 변수 등을 활용해 모든 입력 조합이 한 번씩은 들어갔는지(Coverage)를 확인할 수 있습니다.

보통 6개의 블럭으로 구성됩니다.

1. DUT 연결 (u_dut)

2. 입력 인가 (apply stimulus)

3. 기대값 계산 (reference model)

4. 자동 비교 (if (got !== exp))

5. 에러 카운트/최종 PASS-FAIL

6. 타임아웃(TIMEOUT) 종료

   시스템 베릴로그 문법을 사용하여 작성했습니다.

   // self-checking testbench for half_adder
   `timescale 1ns / 1ps
   module test_half_adder;
   reg t_a, t_b;
   reg [1:0] ref_out;
   wire t_c_out, t_sum;
   integer i;
   integer err_cnt;
   reg [3:0] seen;  // 입력 조합 관측 체크용
   // 1. DUT 연결
   half_adder u_dut (
    .a(t_a),
    .b(t_b),
    .c_out(t_c_out),
    .sum(t_sum)
   );
   
   // 3. reference model
   function [1:0] ref_half_adder;
   input a_i, b_i;
   begin
    ref_half_adder = a_i + b_i;  // {c_out, sum}
   end
   endfunction
   
   initial begin
   err_cnt = 0;
   seen    = 4'b0000;
   
   // ── 2. 입력 인가 ──
   repeat (50) begin
    t_a = $urandom_range(0, 1);
    t_b = $urandom_range(0, 1);
    #1;
    seen[{t_a, t_b}] = 1'b1;
    // ── 4. 자동 비교: 랜덤 50회 ──
    ref_out = ref_half_adder(t_a, t_b);
    if ({t_c_out, t_sum} !== ref_out) begin
      $error("Mismatch: a=%0b b=%0b got=%0b%0b exp=%0b%0b", t_a, t_b, t_c_out, t_sum, ref_out[1],
             ref_out[0]);
      err_cnt = err_cnt + 1;
    end
   end
   
   // ── 미커버 조합 강제 인가 (전수 커버리지 보장) ─────────
   for (i = 0; i < 4; i = i + 1) begin
    if (!seen[i]) begin
      {t_a, t_b} = i[1:0];
      #1;
      seen[{t_a, t_b}] = 1'b1;
      ref_out = ref_half_adder(t_a, t_b);
      if ({t_c_out, t_sum} !== ref_out) begin
        $error("Mismatch: a=%0b b=%0b got=%0b%0b exp=%0b%0b", t_a, t_b, t_c_out, t_sum,
               ref_out[1], ref_out[0]);
        err_cnt = err_cnt + 1;
      end
    end
   end
   
   // ── 5. 최종 판정 ──
   if (seen !== 4'b1111) $fatal(1, "FAIL: not all input combos covered, seen=%b", seen);
   
   if (err_cnt == 0) $display("PASS: self-checking random TB");
   else $fatal(1, "FAIL: err_cnt=%0d", err_cnt);
   
   $finish;
   end
   
   initial begin
   #1000;
   $fatal(1, "TIMEOUT");
   end
   

endmodule

## 3. 컴파일 (Compilation): iverilog 가이드
컴파일 단계에서는 iverilog를 사용합니다. 각 옵션의 의미를 정확히 아는 것이 중요합니다.

// iverilog 컴파일 명령어 예시 iverilog -g2012 -Wall -s test_half_adder -o sim/build/output/iverilog/test_half_adder.vvp
rtl/half_adder.v sim/test/test_half_adder.v

**옵션 상세 설명**
```-g2012```: iverilog가 사용할 Verilog 표준을 지정합니다. 
g2005, g2001 등 여러 버전이 있는데, -g2012는 IEEE 1800-2012(SystemVerilog) 표준으로 $urandom_range 같은 최신 시스템 함수를 사용하려면 이 옵션이 필요합니다. 
명시하지 않으면 iverilog 기본값으로 컴파일되어 최신 문법에서 에러가 날 수 있습니다.

```-Wall```: 모든 경고(Warning) 메시지를 출력합니다. 사소한 문법 실수나 포트 연결 누락처럼 에러는 아니지만 잠재적으로 문제가 될 수 있는 부분을 알려줍니다.

```-s test_half_adder```: 시뮬레이션의 최상위 모듈(Top-level module)을 지정합니다. 보통 테스트벤치 모듈 이름인 ```test_half_adder```가 들어갑니다.

```-o [출력파일경로]```: 컴파일 결과로 생성될 실행 파일의 경로와 이름을 지정합니다. iverilog의 출력물은 .vvp 확장자를 사용하며, 이후 vvp 명령어로 실행합니다. 경로를 지정하지 않으면 현재 디렉토리에 a.out으로 생성됩니다.

```소스 파일 나열```: 마지막에는 컴파일에 필요한 모든 .v 파일을 나열합니다. 설계 파일(```half_adder.v```)을 먼저, 테스트벤치 파일(```test_half_adder.v)```을 그 뒤에 적는 것이 일반적입니다. 파일을 빠뜨리면 "module not found" 에러가 발생하니 주의하세요.

## 4. 검증 (Verification)
컴파일이 성공했다면 vvp 명령어로 시뮬레이션을 실행합니다.

// 시뮬레이션 실행 vvp sim/build/output/iverilog/test_half_adder.vvp

// 출력 예시 PASS: self-checking random TB

### 결과 분석 방법

### 1. Directed Testbench 방식
- 터미널에 출력된 진리표로 직접 확인합니다.
![](https://velog.velcdn.com/images/young-0320/post/3b160ce2-6ae6-4ea7-83af-7639be32695e/image.png)
-  혹은 아래 명령어로 파형을 직접 확인할 수도 있습니다.
![](https://velog.velcdn.com/images/young-0320/post/dffdc6e5-27bd-4082-b22b-173dd5d0a831/image.png)

// gtkwave를 이용하여 파형 확인 gtkwave sim/build/output/iverilog/test_half_adder.vcd

### 2. Self-checking Testbench 방식
아래 메시지가 뜨면 모든 테스트를 통과한 것입니다.

PASS: self-checking random TB

![](https://velog.velcdn.com/images/young-0320/post/52496ee8-1d9a-4d63-9d78-1cde1aaca428/image.png)
만약 실패했다면 $error와 $fatal 메시지가 함께 출력됩니다. 
$error는 어떤 입력값에서 출력이 틀렸는지 알려주고, $fatal은 최종적으로 몇 개의 오류가 발생했는지 요약해줍니다. 로그를 위에서부터 읽으면서 첫 번째 ERROR가 찍힌 시점을 찾는 것이 디버깅의 시작입니다.

ERROR: Mismatch: a=1 b=1 got=01 exp=10 FAIL: err_cnt=1

## 마무리하며 
이번 포스팅에서는 Half Adder를 통해 RTL 설계부터 iverilog를 이용한 컴파일, 검증까지 전체 흐름을 정리해봤습니다. 단순한 회로지만 막상 직접 테스트벤치를 짜고 시뮬레이션을 돌려보면 생각보다 알아야 할 것이 많다고 느꼈습니다. 

다음 포스팅에서는 베릴레이터를 이용하여 64bit adder를 검증해 볼 예정입니다.

이번 포스팅에서는 Ubuntu 환경에서 uv를 설치하고, 가장 빠르고 안전하게 파이썬 개발 환경을 구축하는 방법을 정리했습니다.

왜 Poetry 대신 uv인가?

파이썬 프로젝트를 시작할 때 패키지 관리 도구로 가장 먼저 떠오르는 것은 Poetry입니다. 하지만 저는 이번 프로젝트에서 Rust 기반의 차세대 도구인 uv를 선택했습니다. 그 이유는 다음과 같습니다.

Poetry: 기존의 강력한 표준 의존성 관리, 패키징, 배포를 위한 올인원 도구로 오랫동안 사랑받아 왔습니다. 하지만 프로젝트 규모가 커질수록 의존성 해결 속도가 느려지는 단점이 있습니다.

uv: 압도적인 속도 Rust로 작성되어 기존 pip이나 pip-tools보다 10~100배 빠른 압도적인 속도를 보여줍니다.

단순히 패키지만 설치하는 것이 아니라, Python 버전 관리(pyenv 대체)부터 가상 환경 관리(venv 대체)까지 하나의 툴로 끝낼 수 있습니다.

"속도"와 "통합성"

• Rust 기반의 빠른 설치 및 해석 속도로 개발 생산성을 극대화할 수 있습니다.

  • pyenv로 파이썬 버전을 깔고, venv로 가상 환경을 만들고, pip으로 패키지를 설치하는 복잡한 과정 없이, uv 명령어 하나로 모든 환경 설정이 끝납니다.

uv 설치 가이드

1. 바이너리 파일 설치

# 공식 설치 스크립트
curl -LsSf https://astral.sh/uv/install.sh | sh

2. 설치 확인

uv는 자동으로 환경 변수를 설정하기에 단순히 터미널을 껐다 킨 뒤 uv --version 명령어로 버전을 확인합니다.

성공!

3. 실행

프로젝트의 루트 디렉토리로 이동해 uv init 명령어로 uv를 실행시킵니다.

생성되는 파일 목록:

• .gitignore : Git이 추적하지 않을 파일 혹은 폴더 지정
• .ptrhon-version : 파이썬 버전 명시
• main.py : 파이썬 프로그램 실행 진입점
• pyproject.toml : 프로젝트 통합 설정 파일
• README.md : 프로젝트 설명서

uv run python --version

명령어를 통해 적용되는 파이썬 버전을 확인할 수 있습니다.

이때 생성되는 파일:

• .venv :가상 환경 폴더. 파이썬 인터프리터와 라이브러리 저장
• uv.lock : 실제로 설치된 패키지들의 모든 정보가 기록

4. 사용법

패키지 관리

1. 설치

   # pyproject.toml, uv.lock에 기록
   uv add <라이브러리 명>

   또는 ,

   # 기록 없이 임시로 설치할 라이브러리
   uv pip install <라이브러리 명>

2. 삭제

   uv remove <라이브러리 명>

3. 패키지 환경 구성

   uv sync

   pyproject.toml 파일과 uv.lock 파일만 있다면 위의 명령어를 이용하여 완벽하게 동일한 가상 환경 폴더를 생성해 낼 수 있습니다.

다만 uv run <파일 명.py> 명령어를 입력하면 자동으로 uv sync를 실행시켜줍니다.

마무리하며

이제 더 이상 복잡한 가상 환경 활성화나 의존성 꼬임 문제로 시간을 낭비할 필요가 없습니다.

uv run 명령어 하나로 언제 어디서든 동일한 개발 환경을 재현할 수 있게 되었습니다.

1. 개발 환경 표준화

VS Code에서 CMake를 사용할 때 가장 먼저 해야 할 일은 빌드 환경을 고정하는 것입니다. CMakePresets.json을 프로젝트 최상위 경로에 작성하면, 팀원 간의 환경 차이나 Windows/Ubuntu 등 운영체제 변환 시에도 동일한 빌드 폴더 구조와 컴파일러 설정을 유지할 수 있습니다.

이 파일은 크게 빌드 환경을 세팅하는 configurePresets와 실제 컴파일 대상을 지정하는 buildPresets 두 부분으로 나뉩니다.

A. 구성 사전 설정 (configurePresets)

CMake가 빌드 파일(Makefile 등)을 어디에, 어떤 설정으로 생성할지 정의합니다. VS Code가 기본으로 생성해 주는 더미 템플릿은 삭제하고, 해당 프로젝트에 맞는 구조로 직접 작성합니다.

{
    "version": 3,
    "configurePresets": [
        {
            "name": "default-build",
            "displayName": "Default Build (Project Root)",
            "description": "프로젝트 최상위 루트에 build 폴더를 생성하는 표준 방식",
            "binaryDir": "${sourceDir}/build",
            "cacheVariables": {
                "CMAKE_BUILD_TYPE": "Debug",
                "BUILD_FIR_TESTS": "ON"
            }
        },
        {
            "name": "fir-1d-custom",
            "displayName": "1D FIR Filter (Sub-folder Build)",
            "description": "FIR 필터 시뮬레이션 관련 빌드 파일만 하위 폴더로 격리",
            "binaryDir": "${sourceDir}/fir_1d/sim/build",
            "cacheVariables": {
                "CMAKE_BUILD_TYPE": "Debug",
                "BUILD_FIR_TESTS": "ON"
            }
        }
    ],

default-build preset: 프로젝트 최상위 루트에 build 폴더를 만들고 모든 구성 파일을 이곳에 저장하는 가장 표준적인 방식입니다.

fir-1d-custom preset: 특정 하위 모듈(1D FIR 필터)의 시뮬레이션 및 검증만을 위해 독립적인 build 폴더를 구축하는 맞춤형 설정입니다.

• binaryDir: 빌드 산출물이 저장될 경로입니다. ${sourceDir} 매크로를 사용하여 절대 경로 하드코딩으로 인한 에러를 방지합니다.

전체 프로젝트를 제어하는 default-build와 달리, fir-1d-custom은 빌드 폴더를 fir_1d/sim/build로 깊게 지정하여 다른 모듈의 목적 파일(.o)과 섞이지 않도록 관리합니다.

B. 빌드 사전 설정(buildPresets)

앞서 만든 configurePreset를 바탕으로, 소스 코드 중 어떤 타겟(Target)을 컴파일할지 구체적인 대상을 지정합니다.

"buildPresets": [
        {
            "name": "build-all-default",
            "configurePreset": "default-build"
        },
        {
            "name": "build-test-fir-1d-default",
            "configurePreset": "default-build",
            "targets": [
                "test_fir_1d"
            ]
        },
        {
            "name": "build-test-fir-1d-custom",
            "configurePreset": "fir-1d-custom",
            "targets": [
                "test_fir_1d"
            ]
        }
    ]
}

build-all-default: default-build 프리셋을 사용합니다. 기본 디폴트 설정입니다.

build-test-fir-1d-default: default-build 폴더를 사용하되 targets를 test_fir_1d로 명시합니다. 해당 타겟만 빌드하므로, 컴파일 및 디버깅 속도가 상승합니다.

build-test-fir-1d-custom: fir-1d-custom 프리셋을 사용하여 격리된 빌드 디렉토리를 사용합니다. 마찬가지로 targets 명시를 통해 빠른 빌드와 검증 속도를 확보합니다.

C. 프리셋(Preset) 적용 및 타겟 제어

작성한 CMakePresets.json을 VS Code에 실제로 적용하는 단계입니다. CMake는 구성(Configure)과 빌드(Build)를 철저히 분리하여 관리하므로, 두 단계를 순서대로 진행해야 합니다.

1. Configure Preset 선택 (빌드 환경 선택)

Ctrl + Shift + P를 눌러 명령 팔레트를 열고 CMake: Select Configure Preset을 실행합니다.

이 단계는 "어떤 폴더에서, 어떤 컴파일러로 빌드 환경을 구성할 것인가?"를 결정하는 단계입니다.

2. Build Preset 선택 (컴파일 타겟 지정)

환경 구성이 끝났다면 CMake: Select Build Preset을 실행하여 실제 컴파일 대상을 고릅니다.

하나의 구성 항목 중 어떤 종류의 빌드 명령을 수행할지 선택하는 단계입니다. 즉, 어떤 타겟을 어떤 방식으로 컴파일할지 결정하는 설정입니다.

default preset (Default Build 선택 시)

custom preset (1D FIR Filter 선택 시)

원하는 프리셋을 선택하여 적용합니다.

2. CMake Tools 사이드바 활용하기

VS Code 좌측의 삼각형 아이콘(CMake)을 누르면 나타나는 사이드바의 핵심 기능을 정리합니다.

A. 프로젝트 상태 확인

현재 프로젝트의 상태를 시각적으로 보여줍니다. 현재 어떤 타겟이 '빌드' 및 '실행' 대상으로 설정되어 있는지 실시간으로 확인할 수 있습니다.

B. 타겟별 개별 제어(Build, Clean, Debug)

현재 선택된 타겟을 나타냅니다. 리스트의 특정 타겟에 마우스를 올리면 작은 아이콘들이 나타납니다.

빌드 타겟에 마우스를 올리면 나타나는 작은 아이콘을 통해 빌드 대상을 변경할 수 있습니다.

마찬가지로 해당 아이콘으로 실행 타겟도 변경할 수 있습니다.

사이드바에서 설정된 타겟은 하단 상태 표시줄의 망치 및 화살표 아이콘과 즉시 동기화됩니다. 덕분에 한 번 타겟을 잡아두면, 이후에는 단축키나 하단 버튼 클릭만으로 반복적인 컴파일과 실행을 빠르게 수행할 수 있습니다.

마무리하며

이번 글에서는 CMakePresets로 빌드 환경을 표준화하고, VS Code CMake Tools에서 Configure와 Build를 분리해 운영하는 흐름을 정리했습니다. 이렇게 세팅해두면 Windows와 Ubuntu를 오가더라도 동일한 절차로 빌드와 디버깅을 반복할 수 있습니다.

다음 글에서는 generator/toolchain/컴파일러를 preset에 명시적으로 고정하고, CTest preset까지 연결해 자동 검증 루틴을 완성해보겠습니다.

1. GitLens

Git 커밋 기록을 누가 언제 어떤 이유로 수정했는지를 코드 위에서 바로 보여주는 익스텐션입니다. 이런 식으로 코드 라인 끝에 회색 글씨로 누가, 언제, 왜 이 코드를 작성했는지를 보여줍니다.

해당 코드 라인에 마우스를 올리면 상세한 커밋 정보가 팝업으로 나타납니다.

사이드바의 GitLens 아이콘을 클릭하면

• 현재 파일의 모든 수정 기록
• 누가 몇 번 수정했는지
• 각 커밋에서 어떤 내용이 바뀌었는지

등을 시각적으로 확인할 수 있습니다.

2. Remote - Tunnels, Remote Explorer

인터넷만 있으면 어디서든 다른 컴퓨터의 VSCode에 접속할 수 있게 해주는 익스텐션입니다.

일반적인 원격 접속 방식은 방화벽 설정, 포트포워딩 등 복잡한 네트워크 설정이 필요하지만, Remote - Tunnels는 Microsoft 서버를 중간다리로 활용하는 방식이라 이런 번거로운 과정이 전혀 필요 없습니다.

집 데스크탑에 개발 환경을 구축해두고, 카페에서 노트북으로 접속해 마치 데스크탑 앞에 앉아있는 것처럼 작업할 수 있습니다. 노트북의 제한된 성능이 아닌 데스크탑의 강력한 성능을 그대로 활용할 수 있죠.

필수 설정 명령어

code tunnel service install

데스크탑을 원격 서버로 등록하는 명령어로, 이걸 실행해야 데스크탑이 백그라운드에서 항상 접속 대기 상태가 됩니다. 컴퓨터를 켜두기만 하면 언제든지 원격 접속이 가능해 집니다.

Remote Explorer Remote - Tunnels의 사이드바 UI 역할을 하는 익스텐션입니다.

주요 기능:

• 등록된 원격 컴퓨터 목록 표시
• 클릭 한 번으로 원격 접속
• 연결 상태 확인
• SSH, 터널, 컨테이너 등 다양한 원격 환경 관리

해당 이미지와 같이 사이드바에 UI가 나타나고 Microsoft나 GitHub에 등록된 터널로 접속할 수 있습니다. 하단 상태 표시줄 가장 왼쪽 버튼을 클릭하여 터널을 선택할 수도 있습니다.

3. Markdown extensions

A. Markdown All in one

마크다운 작성을 위한 도구 모음입니다.

주요 기능:

• 키보드 단축키로 빠른 서식 적용 (굵게, 기울임, 취소선 등)
• 자동 목차(TOC) 생성 및 업데이트
• 자동 리스트 넘버링
• 표 자동 정렬 및 포맷팅
• 섹션 번호 자동 매기기
• 미리보기 스크롤 동기화

  B. Markdown Preview Enhanced

  강력한 미리보기 및 내보내기 기능을 제공하는 익스텐션입니다.

주요 기능:

• 실시간 미리보기 (수학 수식, 다이어그램 지원)
• Mermaid, PlantUML 등 다이어그램 렌더링
• 코드 청크 실행 기능
• PDF, HTML, PNG 등 다양한 포맷으로 내보내기
• 프레젠테이션 모드
• 커스터마이징 가능한 CSS 스타일

C. Markdown PDF

마크다운 파일을 PDF로 간편하게 변환하는 익스텐션입니다.

4. Office Viewer

Microsoft Office 파일을 VSCode 내에서 직접 열람할 수 있는 익스텐션입니다.

주요 기능:

• Word(.docx), Excel(.xlsx), PowerPoint(.pptx) 파일을 VSCode에서 바로 보기
• PDF 파일도 함께 지원
• 별도의 Office 프로그램 실행 없이 파일 내용 확인 가능
• 편집 불가

5. Hex Editor

파일의 바이너리 데이터를 16진수(Hexadecimal)로 직접 보고 편집할 수 있는 익스텐션입니다.

주요 기능:

• 모든 파일을 바이트 단위로 16진수로 표시
• 바이너리 데이터 직접 편집 가능
• ASCII/UTF-8 텍스트와 16진수 동시 표시
• 파일 구조 분석 (이미지, 실행파일 등)
• 대용량 파일도 효율적으로 처리
• 특정 바이트 검색 및 이동

6. 가독성 향상

A. Material Icon Theme

파일과 폴더에 직관적이고 예쁜 아이콘을 적용해주는 테마입니다.

세부 설정 방법 기본 아이콘만으로도 충분하지만, 특정 폴더에 원하는 아이콘을 직접 지정할 수도 있습니다.

1. 설정 파일 열기

F1 또는 Ctrl+Shift+P를 눌러 명령 팔레트를 연 후, Preferences: Open User Settings (JSON)을 입력하고 선택합니다.

프로젝트별로 다르게 설정하고 싶다면 .vscode/settings.json 파일을 사용하세요.

2. 폴더 아이콘 매핑 추가

아래 코드를 settings.json 파일 안에 추가합니다. 이미 material-icon-theme.folders.associations 항목이 있다면, 그 안에 원하는 항목만 추가하면 됩니다.

# "rtl" 이름의 폴더 아이콘을 "core" 폴더 아이콘과 매칭
json"material-icon-theme.folders.associations": {
    "rtl": "core",
    "components": "component",
    "utils": "helper"
}

3. 저장 및 확인

Ctrl+S로 저장하면 즉시 아이콘이 변경된 것을 확인할 수 있습니다.

• 설정 적용 전
• 설정 적용 후

B. Verilog-HDL/SystemVerilog/Bluespec SystemVerilog

하드웨어 설계 언어(HDL)를 지원하는 VS Code 익스텐션입니다.

다만 이 익스텐션은 린터나 포매터 그 자체가 아니라, 외부 엔진을 VS Code에 연결해주는 프론트엔드(대시보드) 역할을 합니다. 따라서 익스텐션만 설치한다고 해서 자동 포맷이나 의미 있는 진단이 바로 동작하지는 않습니다.

제대로 활용하려면 프로젝트에 맞는 린터(Linter)와 포매터(Formatter)를 별도로 설치한 뒤, VS Code가 해당 바이너리를 정확히 호출할 수 있도록 경로와 옵션을 직접 설정해줘야 합니다.

• 린터(Linter): 소스 코드를 “컴파일러처럼” 읽어서 문법 오류, 잠재 버그를 잡아주는 검사기입니다.

• 포매터(Formatter): 코드의 기능은 바꾸지 않고 들여쓰기, 개행, 정렬, 공백 규칙같은 포맷을 맞춰주는 도구입니다.

세부 설정 방법 린터/포매터는 Verible을 선택했습니다.

1. GitHub 릴리즈 페이지에서 다운로드

https://github.com/chipsalliance/verible/releases

2. 릴리즈 파일 다운로드 및 압축 해제

Ubuntu 22.04 x86_64 환경에 맞는 tar.gz 파일을 선택해 다운로드합니다.

다운로드가 완료되면 ~/Downloads 디렉토리에서 압축을 해제합니다.

# 압축 해제
cd ~/Downloads
tar -xzf verible-*.tar.gz

3. 시스템 경로에 설치

압축 해제된 파일을 시스템 전역에서 사용할 수 있도록 /opt/verible 디렉토리를 생성하고 복사합니다.

sudo mkdir -p /opt/verible
sudo rsync -a --delete verible-*/ /opt/verible/

rsync -a 옵션은 파일의 권한·타임스탬프 등 속성을 그대로 유지하며 복사하고, --delete는 대상 디렉토리에 남아 있는 불필요한 구버전 파일을 자동으로 제거합니다. 덕분에 향후 버전을 업그레이드할 때도 동일한 명령어를 재사용할 수 있습니다.

4. 심볼릭 링크 설정

/usr/local/bin에 심볼릭 링크를 생성하여 터미널 어디서든 Verible 명령어를 바로 호출할 수 있도록 합니다.

sudo ln -sf /opt/verible/bin/verible-verilog-format /usr/local/bin/verible-verilog-format
sudo ln -sf /opt/verible/bin/verible-verilog-lint   /usr/local/bin/verible-verilog-lint
sudo ln -sf /opt/verible/bin/verible-verilog-ls     /usr/local/bin/verible-verilog-ls

-s는 심볼릭 링크 생성, -f는 동일한 이름의 링크가 이미 존재할 경우 덮어쓰기를 의미합니다. 버전 업그레이드 시 /opt/verible 내용만 교체하면 링크를 다시 만들 필요 없이 자동으로 새 버전을 가리키게 됩니다.

5. 설치 확인

아래 명령어로 설치가 정상적으로 완료되었는지 검증합니다.

which verible-verilog-format verible-verilog-lint verible-verilog-ls
readlink -f /usr/local/bin/verible-verilog-format
readlink -f /usr/local/bin/verible-verilog-lint
verible-verilog-format --version
verible-verilog-lint --version

which 명령이 /usr/local/bin/... 경로를 반환하고, readlink -f가 /opt/verible/bin/...로 실제 바이너리 경로를 추적하며, --version이 설치된 버전 문자열을 출력하면 정상 설치가 완료된 것입니다.

6. VS Code에서 세부 설정

6.1 Formatting 설정 Ctrl + ,로 익스텐션 설정 창을 열어 아래 항목들을 순서대로 설정합니다.

6.1.1 System Verilog(.sv) 포매터를 지정 Verilog > Formatting > SystemVerilog: Formatter → verible-verilog-format

6.1.2 바이너리 경로 지정 Verilog > Formatting > Verible Verilog Formatter: Path

경로란에는 verible-verilog-format을 입력합니다. 만약 이 방식으로 동작하지 않는다면 /usr/local/bin/verible-verilog-format과 같이 절대 경로를 직접 입력합니다.

6.1.3 Verilog HDL(.v) 포매터 지정 Verilog > Formatting > Verilog HDL: Formatter → verible-verilog-format

6.2 linting 설정 6.2.1 linter 지정 Verilog > Linting: Linter → verible-verilog-lint

6.3 Format On Save 활성화 Ctrl+S 저장 시 자동으로 포매팅이 실행되도록 VS Code 기본 설정에서 Editor: Format On Save(editor.formatOnSave)를 활성화합니다.

C. MIPS Support, Rainbow CSV

MIPS Support: MIPS 어셈블리 언어를 위한 익스텐션입니다.

Rainbow CSV: CSV 파일을 컬럼별로 다른 색으로 표시해주는 익스텐션입니다.

마무리하며

VSCode의 생산성을 높여주는 주요 익스텐션들을 소개했습니다.

처음부터 익스텐션들을 전부 설치할 필요는 없고, 자신의 작업 환경에 맞춰 필요한 것들만 골라 사용하면 됩니다.

Rust와 Zig 기반의 고성능 설계로 하드웨어 리소스를 효율적으로 사용하는 Ghostty, 그리고 네트워크만 연결되어 있다면 어떤 기기와도 즉시 연결되는 LocalSend입니다.

1. 터미널 선택

고성능 중심의 터미널

• Ghostty: 균형 잡힌 고성능 터미널
• Alacritty: 세상에서 가장 빠른 터미널을 표방

사용자 편의성 및 AI 통합 중심의 터미널

• Warp: AI 에이전트가 내장된 Rust 기반 터미널
• Wave: 오픈 소스 기반의 현대적 터미널

선택한 터미널 : Ghostty

텍스트 출력이 많은 작업을 하고 있고 렌더링 레이턴시가 적은 것을 선호하기에 해당 터미널을 선택했습니다. 또한 작업 환경이 원격 데스크탑에 접속하는 일이 잦기에 미세한 이질감을 줄여준다고 생각했습니다.

개발 환경 요약 : Ghostty + 5.3 Codex + 최소한의 도구

Ghostty 설치

Ghostty 다운로드 가이드 확인

공식 홈페이지 : https://ghostty.org/docs

다운로드 방식

• 소스 코드를 직접 zig로 빌드하여 사용
• 배포된 빌드 파일을 설치하여 사용

일반 사용자에게는 소스 코드를 직접 빌드하는 것이 권장되지 않기에 바이너리 파일을 설치하겠습니다.

홈페이지를 확인해 보면 우분투 24.04는 공식 바이너리 파일이 없어 GitHub 커뮤니티에서 만든 빌드 파일을 설치해야 합니다.

이미지에서 볼 수 있듯 공식 릴리즈가 아니므로 업데이트 시 호환성 이슈가 발생할 수 있습니다. 해당 깃허브 페이지에 방문하여 README를 읽어 설치 방법을 확인합니다. https://github.com/mkasberg/ghostty-ubuntu

Ubuntu 24.04 + x86_64 버전에 맞는 링크를 클릭해 설치해 줍니다.

sudo dpkg -i ghostty_1.2.3-0.ppa1_amd64_24.04.deb
sudo apt -f install

해당 명령어를 이용하여 설치를 완료해 줍니다.

설치 확인 성공!

*실행 *

ghostty

2. LocalSend

에어드롭의 크로스플랫폼 버전 프로그램입니다.

# 설치
sudo snap install localsend

# 실행
localsend

사용 방법

1. 우분투에서 LocalSend 실행

• 앱 메뉴에서 "LocalSend" 검색해서 실행 -또는 터미널에서 localsend 입력

2. 아이패드/아이폰에 앱 설치

• App Store에서 "LocalSend" 검색 후 설치
• 안드로이드는 Play Store에서 설치

3. 같은 WiFi에 연결

• 우분투와 아이패드가 같은 WiFi에 연결되어 있어야 함

4. 파일 전송

• 아이패드 → 우분투:

1. 아이패드에서 LocalSend 앱 실행
2. 근처 기기에서 우분투 컴퓨터가 보임
3. 보낼 파일 선택 → 우분투 선택 → 전송
4. 우분투에서 수락하면 다운로드됨 (기본 위치: ~/Downloads)

• 우분투 → 아이패드:

1. 우분투 LocalSend에서 파일 선택 또는 드래그 앤 드롭
2. 근처 기기 목록에서 아이패드 선택
3. 아이패드에서 수락

마무리하며

기본 터미널과 카카오톡 전송을 졸업하며 이제 세련된 고성능 터미널과 OS 간 장벽 없는 파일 전송 환경이 갖춰졌습니다. 불필요한 레이턴시와 연결의 번거로움을 덜어낸 이 미니멀한 셋업이, 앞으로의 개발 몰입도를 한 층 높여줄 것이라 생각합니다.

PSpice는 Cadence에서 제공하는 회로 시뮬레이션 도구입니다.

윈도우 사용자 이름 확인

PSpice 설치 전 윈도우 사용자 이름이 영문인지와 윈도우 버전을 확인해야 합니다.

1. Win + R 키를 누른 뒤 cmd를 입력하고 엔터를 칩니다.

2. 입력창에 whoami를 입력합니다.

3. 출력되는 이름이 한글이라면 문제가 발생할 확률이 높고, 영문이라면 안전합니다.

만약 사용자 이름이 한글인 경우: 기존 계정 이름을 바꾸는 것은 레지스트리 충돌 위험이 큽니다. 일반적으로 활용되는 해결 방법은 '설정 > 계정 > 다른 사용자'에서 영문 이름으로 된 새로운 로컬 계정을 하나 생성하여 툴 전용 계정으로 사용하는 것입니다.

윈도우 버전 확인

1. Win + R 키를 누른 뒤 cmd를 입력하고 엔터를 칩니다.

2. 입력창에 winver를 입력합니다.

3. 팝업창에 해당 Windows 버전(예: 22H2, 23H2)과 빌드 번호를 즉시 확인할 수 있습니다.

PSpice for TI 설치 가이드

1. TEXAS INSTRUMENTS의 공식 홈페이지에 방문하여 Request 버튼을 누릅니다.

공식 홈페이지 https://www.ti.com/tool/PSPICE-FOR-TI

2. 회원가입을 진행해줍니다.

3. 로그인 후 해당 정보들을 입력해줍니다.

3-1. Create an address

주소는 경희대학교 국제캠퍼스를 입력하였습니다. Company name: Kyung Hee University Company URL: www.khu.ac.kr 상세 주소를 입력해줍니다.

Address Line 1: 1732, Deogyeong-daero, Giheung-gu

City: Yongin-si

State/Province: Gyeonggi-do

Zip/Postal code: 17104

3-2. Create a checkout profile

단계 별로 진행해 줍니다. 마지막으로 Save를 눌러 저장을 합니다.

4. Request 창으로 돌아가서 Submit 버튼을 눌러줍니다.

이제 약 5~10분 이내에 가입 한 이메일로 28자리의 Access Key가 발송될 것입니다.

5. 메일을 확인해 줍니다.

메일에 포함된 링크를 클릭하여 페이지로 이동한 다음 로그인을 완료합니다.

6. PSPice를 설치해 줍니다.

Download 버튼을 클릭하여 설치를 진행합니다. 가입한 이메일과 메일로 전달받은 Access Key를 입력합니다. 이후 설치가 자동으로 진행됩니다. 설치가 완료되면 정상적으로 실행할 준비가 끝납니다. 성공!

마무리하며

이번 과정에서는 업계 표준 아날로그 회로 시뮬레이터 PSpice를 설치하고 설계를 진행할 수 있는 환경을 준비했습니다.

다음 포스팅에서는 VS Code에서 프로젝트를 설정하고, 보다 효율적으로 작업하기 위한 생산성 향상 방법들을 다뤄보겠습니다.

내 컴퓨터(Windows/VS)에서는 잘 돌아가는 코드가 서버(Linux/GCC)에서는 빌드조차 되지 않는 상황, 이 '환경의 파편화'를 해결하는 것이 바로 CMake의 존재 이유입니다.

1. CMake란 무엇인가?

CMake는 특정 IDE나 OS에 종속되지 않는 독립적인 빌드 환경을 구축하기 위한 '메타 빌드 시스템'입니다.

C/C++ 프로젝트를 빌드할 때는 전통적으로 Makefile을 작성해야 합니다. 하지만 개발자가 Makefile이나 Solution 파일을 직접 짜는 대신, 고수준의 설정 파일(CMakeLists.txt)만 작성하면 CMake가 타겟 환경에 맞는 빌드 파일을 알아서 빌드를 해줍니다.

또한 운영체제마다 다른 빌드 시스템(Linux의 Make, Windows의 Visual Studio 등)을 사용하기 때문에 OS별로 빌드 스크립트를 중복 관리할 필요가 없습니다.

소스 파일이 늘어나도 설정 파일의 변수나 와일드카드 기능을 통해 복잡한 의존 관계를 간단하게 업데이트할 수 있습니다.

2. CMake의 필요성

왜 CMake를 사용해야 할까요? 단순히 Visual Studio를 쓰기 싫어서가 아니라, 어떤 환경에서도 동작하는 지속 가능한 빌드 시스템이 필요하기 때문입니다.

전통적으로 Visual Studio 같은 IDE 없이 직접 코드를 빌드하기 위해서는 컴파일러 명령어를 터미널에 직접 입력해야 합니다.

# 1. 각 소스 파일(.c)을 컴파일하여 기계어인 목적 파일(.o)로 변환
gcc -c main.c   # main.c -> main.o 생성
gcc -c A.c      # A.c -> A.o 생성

# 2. 생성된 목적 파일들을 하나로 Link하여 최종 실행 파일(code.out) 생성
gcc -o code.out main.o A.o

파일이 2~3개일 때는 문제가 없지만, 소스 파일이 수십, 수백 개로 늘어난다면 이런 명령어를 매번 입력하는 것은 불가능에 가깝습니다.

이 과정을 자동화하기 위해 make가 등장했습니다. Makefile에 빌드 규칙을 한 번만 적어두면, make가 파일의 변경 사항을 감지하여 필요한 부분만 효율적으로 컴파일해 줍니다. 즉 모든 명령어를 입력할 필요 없이 make 입력 한번으로 끝납니다.

# Makefile 예시
code.out: main.o A.o
    gcc -o code.out main.o A.o

main.o: main.c
    gcc -c main.c

A.o: A.c
    gcc -c A.c

make는 훌륭한 도구이지만, 다음과 같은 한계가 있습니다.

1. 플랫폼 종속성: 리눅스에서 작성한 Makefile은 윈도우의 nmake나 Visual Studio 환경에서 그대로 사용할 수 없습니다. 운영체제마다 빌드 도구가 다르기 때문입니다.

2. 복잡한 문법: 프로젝트가 커질수록 Makefile 자체의 문법이 난해해져 유지보수가 어려워집니다.

3. IDE와의 연동성 부족: 현대 엔지니어링에서는 VS Code, CLion, Visual Studio 등 다양한 에디터를 사용하는데, 각 에디터에 맞는 프로젝트 파일을 수동으로 생성하는 것은 매우 비효율적입니다.

결국 CMake는 운영체제마다 다른 Makefile이나 프로젝트 파일을 자동으로 생성해 주는 메타 빌드 시스템으로서, 현대 C/C++ 개발 환경의 사실상 표준이 되었습니다.

3. CMake 문법

Cmake의 단계는 아래 이미지와 같습니다.

CMake 문법을 3단계로 나누어서 설명해 보겠습니다.

🟢 당장 프로젝트를 빌드하는 데 필요한 것(기초)

🟡 협업·확장 가능한 구조를 만드는 데 필요한 것(모듈화)

🔵 대형 프로젝트, 패키징, 자동화까지 다루는 영역(심화-생략)

CMake 문법 자체가 워낙 방대하고 어려운 부분도 있어 해당 포스팅에서는 2단계까지만 설명하겠습니다.

🟢 당장 프로젝트를 빌드하는 데 필요한 것(기초)

최소한의 빌드 환경 구축에는 다음과 같은 과정이 필요합니다.

해당 단계의 목표는 수동으로 gcc 명령어를 치던 과정을 CMakeLists.txt 파일로 대체하는 것입니다. 이때 파일 이름은 대소문자를 구분하여 생성해야 합니다.

1. 프로젝트 루트 디렉토리에 CMakeLists.txt 파일을 생성합니다.
2. 해당 파일 안에 다음과 같은 필수 코드들을 입력합니다.

• cmake_minimum_required(VERSION [버전]) : CMake의 최소 버전을 지정합니다.

• project([프로젝트 이름] VERSION [발전 단계] LANGUAGES [사용 언어]) : 프로젝트 정보들을 설정합니다.

• add_executable([실행파일 이름] [필요한 소스 파일들]) : 실행파일을 빌드할 때 [필요한 소스 코드들]을 컴파일하고 링크하여 [실행파일 이름]이라는 실행파일을 생성합니다.

• 최소 버전은 3.10으로 지정했습니다.
• 프로젝트의 이름은 CH11이고 버전은 0.1.0, 사용 언어는 C와 C++입니다.
• mycomplex.cpp와 mycomplex_test.cpp 소스 파일을 컴파일하고 링크하여 LAB11이라는 실행파일을 빌드합니다.

  # 폴더 구조
  Project_Root/
  ├── CMakeLists.txt
  ├── mycomplex.cpp
  └── mycomplex_test.cpp

  🟡 협업·확장 가능한 구조를 만드는 데 필요한 것(모듈화)

  프로젝트가 커지면 모든 소스를 한곳에 두는 것은 불가능합니다. CMake의 핵심은 물리적으로는 폴더(Directory)로 나누고, 논리적으로는 타겟(Target)으로 묶어 의존성을 관리하는 것입니다.

1. 물리적 계층 구조

add_subdirectory()를 사용하면 프로젝트를 기능 단위로 물리적으로 분리할 수 있습니다. 프로젝트의 파일 구조를 트리 형태로 조직화하여 관리의 편의성을 높이는 것입니다

폴더별로 CMakeLists.txt를 두어 해당 폴더 내의 소스들만 관리하게 함으로써 관심사를 분리합니다.

기본적으로 다음의 구조를 따릅니다.

# 폴더 구조
FIR-FILTER/
  ├── CMakeLists.txt                  # [Root] 프로젝트 전체 관리 정의
  ├── lib
  │   ├── CMakeLists.txt              # `mycomplex` 정적 라이브러리 타깃 정의
  │   ├── mycomplex.h                 # `MyComplex` 클래스 선언(헤더)
  │   └── mycomplex.cpp               # `MyComplex` 클래스 구현(소스)
  └── fir_1d
      ├── model
      │   └── cpp
      │       ├── CMakeLists.txt      # fir_1d_ref 정적 라이브러리 타겟 정의
      │       ├── fir_1d_ref.h        # 1D FIR 모델 인터페이스(클래스 선언)
      │       └── fir_1d_ref.cpp      # 1D FIR 모델 구현
      └── sim
          └── tests
              └── CMakeLists.txt      # 최종 실행 파일 타겟 정의

2. 단계별 구현

A. 최상위 CMakeLists.txt가 가장 먼저 호출되어 프로젝트를 정의하고 하위 작업을 지정합니다.

# Root CMakeLists.txt
cmake_minimum_required(VERSION 3.10)
project(FIR-FILTER VERSION 1.0 LANGUAGES C CXX)

# 하위 디렉토리 추가 (컴파일 순서 제어)
add_subdirectory(lib)

add_subdirectory(fir_1d/model/cpp)
add_subdirectory(fir_1d/sim/tests)

이때 하위 디렉토리는 명령어가 나열된 순서대로 탐색됩니다. 따라서 fir_1d와 같은 하위 디렉토리에서 lib의 결과물을 참조하여 빌드하려면, 반드시 lib을 먼저 추가하여 라이브러리 타겟이 먼저 정의되도록 해야 합니다.

B. 범용 라이브러리 모듈화 소스 코드를 재사용 가능한 이진 파일(Target)로 캡슐화하고, 컴파일에 필요한 헤더 경로를 외부에 전파합니다.

mycomplex라는 이름의 정적 라이브러리를 생성하고 이를 사용할 다른 타겟들에게 헤더 위치를 공개합니다.

# Lib CMakeLists.txt
# 라이브러리 생성
add_library(mycomplex 
    [STATIC|SHARED|MODULE] 
    mycomplex.cpp
)

• STATIC : 정적 라이브러리(.a, .lib). 컴파일 시 실행 파일에 포함됩니다. 용량이 증가하지만 배포가 간편하여 보통 기본값으로 사용됩니다.

• SHARED : 동적 라이브러리(.dll, .dylib). 실행 시 메모리에 로드됩니다. 실행 파일 용량은 줄어들지만, 실행 환경에 해당 라이브러리 파일이 함께 배포되어야 합니다.

• MODULE : 런타임에 동적으로 로드되는 플러그인 형식의 라이브러리입니다.

  # mycomplex가 사용할 헤더 파일 경로 지정
  target_include_directories(mycomplex 
    [PRIVATE|PUBLIC|INTERFACE] 
    ${CMAKE_CURRENT_SOURCE_DIR}
  )

• PRIVATE : 내부 구현용으로, 헤더 경로가 내(mycomplex) 빌드에만 필요함

• PUBLIC : 공개용으로, mycomplex 빌드에도 필요하고 나를 가져다 쓰는 상위 타겟(fir_1d_ref 등) 모두에게 필요함

• INTERFACE : 인터페이스 전용으로, 나를 빌드할 땐 필요 없지만 나를 쓰는 타겟은 반드시 알아야 할 때 사용합니다.

C. 소스 파일의 라이브러리화

fir_1d_ref 라이브러리를 생성하고, 자체 헤더 경로와 하위 의존성(mycomplex)을 모두 PUBLIC으로 설정하여 상위 타겟(test_fir_1d)으로 한 번에 전파하는 과정입니다.

add_library(fir_1d_ref STATIC fir_1d_ref.cpp)

# 상위 타겟에 라이브러리 전파
target_include_directories(fir_1d_ref
    PUBLIC 
        ${CMAKE_CURRENT_SOURCE_DIR}
)

# 범용 라이브러리(mycomplex)를 fir_1d_ref와 연결
target_link_libraries(fir_1d_ref PUBLIC mycomplex)

1. 타겟 생성 fir_1d_ref.cpp 소스 코드를 컴파일하여 정적 라이브러리(STATIC)로 만듭니다. 하나의 독립적인 모듈 블록을 생성하는 것입니다.

2. 헤더 경로 전파 (PUBLIC) target_include_directories를 PUBLIC으로 설정합니다. 이는 fir_1d_ref를 빌드할 때뿐만 아니라, 이 라이브러리를 가져다 쓰는 상위 실행 파일에게도 "내 헤더 파일은 이 폴더에 있어"라고 위치를 알려주는 역할을 합니다.

3. 라이브러리 체이닝 (의존성 상속) fir_1d_ref가 동작하려면 앞서 만든 mycomplex 라이브러리가 필요합니다. 이를 PUBLIC으로 링크하면, 나중에 최종 실행 파일이 fir_1d_ref 하나만 링크하더라도 하위의 mycomplex까지 자동으로 딸려와서 링크됩니다. 즉, 의존성이 체인처럼 연결됩니다.

참고: 하위 타겟 (Lower-level Target): 다른 모듈에 의존하지 않고 독립적으로 존재할 수 있는 기본 부품

• 예: mycomplex 라이브러리

상위 타겟 (Upper-level Target): 하위 부품들을 조립하여 더 복잡한 기능을 만드는 주체

• 예: fir_1d_ref 라이브러리나 test_fir_1d 실행 파일

D. 실행파일 및 라이브러리 연결 Modern CMake의 가장 강력한 기능입니다. 복잡한 헤더 경로를 일일이 추가할 필요 없이, 단순히 타겟을 link하는 것만으로 라이브러리의 모든 정보(헤더 경로, 컴파일 옵션 등)를 자동으로 상속받습니다.

# App CMakeLists.txt
# 실행 파일 생성
add_executable(test_fir_1d
    test_fir_1d_golden.cpp
  )

# fir_1d_ref가 PUBLIC으로 공개한 헤더 경로와 컴파일 옵션을 자동으로 상속받습니다.
target_link_libraries(test_fir_1d PRIVATE fir_1d_ref)

• PRIVATE : test_fir_1d는 최종 실행 파일이므로 다른 타겟이 이를 다시 링크하여 사용할 일이 없습니다. 따라서 상속받은 의존성을 더 이상 전파하지 않고 여기서 마무리하기 위해 PRIVATE을 사용합니다.
• PUBLIC : 실행 파일은 최상위 계층이며 다른 타겟이 이를 링크하지 않으므로, 의존성을 외부로 전파하는 PUBLIC을 사용할 필요가 없습니다.

마무리 : CMake 프로젝트 설계 흐름 요약

지금까지 다룬 내용을 바탕으로, 확장 가능한 프로젝트가 구성되는 단계별 흐름을 정리하면 다음과 같습니다.

1. 물리적 격리 (add_subdirectory): 소스 코드를 기능별 폴더로 분리하고 Root에서 순차적으로 호출하여, 빌드 시스템의 스코프(Scope)를 명확히 나눕니다.

2. 논리적 캡슐화 (add_library): 각 기능 모듈(예: mycomplex, fir_1d_ref)을 독립적인 타겟으로 묶어 재사용 가능한 블록으로 만듭니다.

3. 인터페이스 정의 (target_include_directories): 가시성(PRIVATE/PUBLIC/INTERFACE)을 설정하여 내부 구현은 숨기고, 외부 타겟과 결합할 때 필요한 헤더 경로만 선택적으로 전파합니다.

4. 의존성 체이닝 (target_link_libraries): 상위 타겟은 복잡한 경로 설정 없이 하위 타겟을 링크하는 것만으로 컴파일에 필요한 모든 정보를 자동으로 상속받아 최종 실행 파일(add_executable)을 완성합니다.

4. CMake의 사용

1. VS Code의 CMake Tools(GUI 방식)

마이크로소프트가 제공하는 CMake Tools 익스텐션을 사용하면, 복잡한 명령어를 버튼 클릭으로 대체할 수 있습니다.

• 1. 설치 : VS Code 마켓플레이스에서 CMake Tools 설치합니다.
• 2. 설정 : Command Palette의 CMake: Configure에서 컴파일러(Kit)를 선택하고, 빌드 시스템(Makefile 등)을 생성합니다.
• 3. 빌드 : 하단 상태 표시줄의 Build 버튼 클릭 혹은 F7으로 빌드합니다.
• 4. 실행 : 이후 하단 상태 표시줄의 화살표 버튼을 클릭하여 터미널에서 실행합니다.

2. 터미널 / CLI

A. Out-of-source 빌드 폴더를 생성합니다.

mkdir build
cd build

소스 코드와 빌드 결과물(.o, 실행 파일 등)이 섞이지 않도록 별도의 build 디렉토리를 생성하고 진입합니다.

B. 빌드 시스템을 구성(Configure)합니다.

cmake ..

현재 위치(build)에서 상위 디렉토리(..)에 있는 CMakeLists.txt를 읽어들여, 현재 OS와 컴파일러 환경에 맞는 빌드 시스템(Makefile 등)을 생성합니다. (Root 디렉토리로 이동하는 것이 아닙니다.)

C. 실제 빌드(Build)를 수행합니다.

cmake --build .

생성된 빌드 시스템을 이용해 소스 코드를 컴파일하고 타겟들을 링킹하여 최종 실행 파일을 만듭니다.

D. 프로그램을 실행합니다.

./fir_1d/sim/tests/test_fir_1d

최종 산출물은 Root의 build 폴더를 기준으로 CMakeLists.txt가 있던 계층 구조를 그대로 따라 생성됩니다.

표준 명령어 흐름

mkdir build && cd build          # 1. 빌드 폴더 격리
cmake ..                         # 2. 구성 (Configure)
cmake --build .                  # 3. 컴파일 및 링킹 (Build)
./fir_1d/sim/tests/test_fir_1d  # 4. 최종 실행 (Run)

마무리하며

단순히 언어의 문법을 넘어, 코드가 어떻게 시스템 위에서 실행 파일이 되는지 이해해야 합니다.

프로젝트의 규모가 커지고 리눅스 서버나 임베디드 보드 등 다양한 환경을 마주하게 되면, "어디서든 빌드되는 프로젝트"를 설계하는 능력은 코딩 실력만큼이나 중요한 핵심 역량이 됩니다.

오늘 다룬 CMake는 단순한 컴파일 도구가 아닙니다. 복잡한 의존성을 통제하고 자동화하는 엔지니어링의 기초입니다.

이 글이 IDE의 편리한 'Build 버튼' 뒤에 숨겨진 원리를 이해하고, 더 견고하고 확장 가능한 프로젝트를 설계하는 첫걸음이 되기를 바랍니다.

1. C++ 툴체인의 핵심 구성 요소

• 컴파일러 (g++)
• 빌드 시스템(CMake, make)
• 디버거(GDB)

1. g++

g++ --version

g++ version : 13.3.0

만약 설치가 안되어 있다면 아래의 명령어로 설치합니다.

sudo apt update
sudo apt install g++

2. cmake

cmake --version

설치가 되어 있지 않아 에러 코드 출력되었습니다. 설치 후 다시 버전 확인합니다.

cmake version : 3.28.3

3. make

make -v

make version : 4.3

4. GDB

gdb --version

gdb version : 15.0.50

2. C++ 툴체인의 추가 구성 요소

• 버전 관리 (Git)
• 가독성 향상 (clang-format)

1. Git

git version : 2.43.0

2. clang-format

sudo apt install clang-format

clang-format version : 18.1.3

3. 디지털 회로 설계 도구

시뮬레이션 및 검증:

• Icarus Verilog (RTL 시뮬레이터)
• Verilator (고성능 시뮬레이터)

분석 및 디버깅:

• GTKWave (파형 분석)

텍스트 에디터:

• Visual Studio Code (VS Code)
• Emacs
• Vi IMproved (Vim)

4. 해당 툴 설치

1. Icarus Verilog

# 버전 확인 
iverilog -v

# 설치되어 있지 않다면 
sudo apt update
sudo apt install iverilog

iverilog version : 12.0

2. Verilator

# 버전 확인 
verilator --version

# 설치되어 있지 않다면 
sudo apt install verilator

verilator version : 5.020-1

3. GTKWave

# 버전 확인 
gtkwave --version

# 설치되어 있지 않다면 
sudo apt install gtkwave

gtkwave version : 3.3.116

4. Visual Studio Code

# 버전 확인 
code --version

# 설치되어 있지 않다면 
sudo apt install code

# 실행
code .

vscode version : 1.109.0

5. Emacs

# 버전 확인 
emacs --version

# 설치되어 있지 않다면 
sudo apt install emacs

Emacs를 이용하여 메일 서비스를 사용할지를 묻는 단계입니다. 메일 서비스를 굳이 텍스트 에디터에서 쓸 이유는 없으니 거절해 줍니다.

<Ok> 선택 후 ENTER No configuration 선택 후 ENTER

emacs version : 29.3

6. vim

# 버전 확인 
vim --version

# 설치되어 있지 않다면 
sudo apt install vim

vim version : 9.1

5. VS Code에서 emacs, vim 호출해보기

vim와 emacs가 설치되어 있고 PATH에 정상적으로 등록됐음을 확인할 수 있습니다.

6. 개발 환경 구성

마무리하며

VS Code를 메인 개발 환경으로 사용하되, 필요에 따라 Vim과 Emacs를 통합 터미널에서 활용하는 하이브리드 워크플로우를 구성했습니다. 특정 도구에 종속되기보다는 각 도구의 강점을 상황에 맞게 선택할 수 있는 유연한 개발 환경이 이번 툴체인 구축의 목표였습니다.

이 포스팅에서는 pyenv 설치부터 원하는 Python 버전 설정까지 전 과정을 다룹니다.

1. Github 페이지 방문

pyenv의 깃허브 페이지(https://github.com/pyenv/pyenv)로 이동하여 README를 살펴봅니다.

2. pyenv 설치 전 빌드 의존성 설정

아래의 명령어를 입력하여 빌드 의존성을 해결합니다.

sudo apt update; sudo apt install make build-essential libssl-dev zlib1g-dev \
libbz2-dev libreadline-dev libsqlite3-dev curl git \
libncursesw5-dev xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev

약간의 수정 버전. wget와 llvm을 추가로 설치해 확장성을 높였습니다.

sudo apt update
sudo apt install -y make build-essential libssl-dev zlib1g-dev \
libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm \
libncursesw5-dev xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev

3. pyenv 설치

해당 페이지의 README에 따라 진행해줍니다.

curl -fsSL https://pyenv.run | bash

4. 환경 변수 설정

환경 변수가 설정되지 않아 발생하는 경고 문구입니다. 현재 상황에 따라 수정 파일을 선택하고, 설치 마지막에 출력되는 경로 코드를 복사하여 파일 맨 아래에 추가합니다.

export PYENV_ROOT="$HOME/.pyenv"
[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init - bash)"

# Restart your shell for the changes to take effect.
# Load pyenv-virtualenv automatically by adding
# the following to ~/.bashrc:

eval "$(pyenv virtualenv-init -)"

참고:

• ~/.bash_profile : 로그인 시 1회 실행되는 전역 환경 변수를 설정하는 파일입니다. 해당 파일이 존재하면 ~/.profile은 무시됩니다.

• ~/.profile : 로그인 시 1회 실행되는 Bash 전용 로그인 설정 파일입니다.

• ~/.bashrc : 터미널을 열 때마다(인터랙티브) 실행되는 작업 환경의 설정 파일입니다.

1. 명령어로 파일의 존재 여부를 확인합니다.

~/.profile 파일은 존재하고 ~/.bash_profile 파일은 존재하지 않습니다.

로그인 셸에서 자동 로드하려면: ~/.bash_profile 파일이 존재하면 해당 파일에, 없으면~/.profile 파일에 경로를 추가해줍니다.

인터랙티브 셸(비 로그인 셸)에서 자동 로드하려면: ~/.bashrc에 경로를 추가해줍니다.

2-1. 인터랙티브 셸(비 로그인 셸)에서 자동 로드하기

# 파일 열기
nano ~/.bashrc

# 파일의 맨 아래에 코드 추가
export PYENV_ROOT="$HOME/.pyenv"
[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init - bash)"
eval "$(pyenv virtualenv-init -)"

저는 절대 경로를 사용하여 경로 지정하였습니다.

CTRL + O, ENTER 그리고 CTRL + X를 눌러 파일을 저장하고 종료합니다.

2-2. 로그인 셸에서 자동 로드하기

# 파일 열기
nano ~/.profile

# 파일의 맨 아래에 코드 추가
export PYENV_ROOT="$HOME/.pyenv"
[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init - bash)"

# 파일 열기
nano ~/.bashrc

# 파일의 맨 아래에 코드 추가
export PYENV_ROOT="$HOME/.pyenv"
[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init - bash)"
eval "$(pyenv virtualenv-init -)"

CTRL + O, ENTER 그리고 CTRL + X를 눌러 파일을 저장하고 종료합니다.

3. 수정한 설정을 적용합니다.

# ~/.bashrc 파일을 수정했다면
source ~/.bashrc 

# ~/.bash_profile 파일을 수정했다면
source ~/.bash_profile

# ~/.profile 파일을 수정했다면
source ~/.profile

5. pyenv 설치 확인

모든 터미널을 완전히 껐다 킨 뒤 다음 명령어를 입력하여 pyenv가 정상적으로 설치되었는지 확인합니다.

pyenv --version

성공!

6. Python 설치

1. 설치 가능 Python 목록을 확인합니다.

pyenv install --list | grep " 3.1"

3.1.0부터 3.15t-dev까지 설치가 가능합니다.

2. Python 버전 선택

3.13.12 버전을 선택하였습니다.

이유는 다음과 같습니다:

*안정성 *

• 3.13.12는 이미 전 세계 엔지니어들이 검증을 끝낸 버전입니다.
• 주요 라이브러리들과의 안정적인 호환성이 확보되어 있습니다.

최신 버전의 위험성

• 3.14 혹은 3.15와 같은 최신 버전은 아직 충분한 실전 검증을 거치지 못했습니다.
• NumPy, SciPy 같은 수치 연산 라이브러리와의 예기치 않은 호환성 문제가 발생할 수 있습니다.
• 만약 미세한 부동소수점 연산 버그라도 있다면, '알고리즘 문제인지, 하드웨어 구현 문제인지, Python 환경 문제인지' 구분하기 어려운 디버깅 지옥에 빠질 수 있습니다.

3. Python 3.12.12 설치

# 3.13.12 버전 설치
pyenv install 3.13.12

# 전역 버전으로 변경
pyenv global 3.13.12

pyenv global 3.13.12 명령어는 시스템 Python을 직접 수정하지 않습니다. 대신 Shim(가로채기) 방식으로 동작합니다

• 시스템 Python(3.12.3)은 절대 경로에 그대로 유지됩니다.
• pyenv가 PATH 앞쪽에 위치하여 python 명령을 가로챕니다.
• OS의 핵심 도구들은 절대 경로로 시스템 Python을 실행하므로 영향을 받지 않습니다.

이는 시스템 Python을 직접 업데이트하는 것보다 훨씬 안전한 방식입니다.

7. Python 설치 확인

python --version
which python

'3.13.12'와 '/home/young/.pyenv/shims/python' 출력을 통해 버전과 경로가 제대로 설정됐음을 확인할 수 있습니다.

마무리하며

pyenv를 통해 안정적인 Python 개발 환경 구축을 완료했습니다. 시스템 Python을 건드리지 않으면서도 원하는 버전을 자유롭게 관리할 수 있게 되었습니다.

다음 포스팅에서는 VSCode에서 C++ 개발 환경을 구축하는 방법을 다뤄보겠습니다. 컴파일러 설정부터 디버깅 환경까지, 효율적인 C++ 개발을 위한 설정을 다루겠습니다.

1. 고정 마운트 설정

자동 마운트의 문제점:

• 파일 탐색기에서 디스크를 클릭해야만 마운트되어 디스크에 접근할 수 있음
• 마운트 경로가 고정되어 있지 않아 매번 달라질 수 있음 (예: /media/young/xxxxx)
• 터미널이나 스크립트에서 일관된 경로로 접근하기 어려움

현재 디스크 인식 상태 확인

lsblk

명령어로 Block Device 인식 상태를 확인합니다.

현재 물리적으로는 5개의 디스크(sda, sdb, sdc, nvme0n1, nvme1n1)가 인식되지만, 실제로 읽고 쓸 수 있는 상태로 마운트된 것은 일부뿐입니다.

• nvme0n1: 우분투가 설치된 시스템 디스크
• nvme1n1: 윈도우가 설치된 시스템 디스크(부분 마운트 중)
• sdb, sdc: 임시로 마운트된 디스크

나머지 디스크들은 인식은 되지만 아직 마운트되지 않아 접근할 수 없는 상태입니다. 이러한 문제점을 해결하기 위해 고정 마운트 설정을 진행하겠습니다. 고정 마운트를 설정하면 부팅 시 자동으로 지정된 경로에 디스크가 마운트되어, 언제든 일관된 경로로 접근할 수 있습니다.

1. 각 디스크의 고유 식별자(UUID) 확보

sudo blkid

명령어로 각 디스크의 UUID를 확보합니다.

/dev/sda1: LABEL="Archive" UUID=982E35F32E3xxxx /dev/sdb2: LABEL="Workspace" UUID=0ECE-xxxx /dev/sdc2: LABEL="ToolBox" UUID=960EBAE30EBAxxxx /dev/nvme1n1p3: LABEL="Windows" UUID=04DC4011DC40xxxx dev/nvme0n1p2: UUID=07b2f762-a6a8-4fcf-bc0a-8adca4abxxxx

2. 마운트 포인트 생성

각 디스크가 연결될 빈 폴더를 생성합니다.

sudo mkdir -p /mnt/workspace
sudo mkdir -p /mnt/toolbox
sudo mkdir -p /mnt/archive
sudo mkdir -p /mnt/windows

/mnt를 사용하는 이유 : /mnt는 리눅스에서 외부 디스크를 마운트할 때 관례적으로 사용하는 디렉토리입니다. /media는 자동 마운트용, /mnt는 수동/고정 마운트용으로 구분합니다.

3. fstab 백업 파일 생성

fstab 파일은 부팅 시 디스크 마운트를 설정하는 핵심 파일입니다. 잘못 수정하면 시스템이 부팅되지 않을 수 있으므로, 반드시 백업 후 신중하게 작업하세요.

sudo cp /etc/fstab /etc/fstab.bak
sudo nano /etc/fstab

uid/gid=1000 : 일반 사용자가 sudo 없이 파일을 읽고 쓸 수 있게 권한을 부여합니다. nofail : 디스크가 연결되지 않아도 우분투 부팅이 멈추지 않게 합니다. ro (Read-only): 윈도우 시스템 파일을 보호합니다.

파일을 수정하기 전 터미널에 아래의 명령어를 입력하여 해당 정보들을 다시 한번 더 확인합니다.

blkid /dev/sdXX : UUID 다시 확인 id : uid와 gid 다시 확인 ls /mnt : 마운트 포인트가 있는지 다시 확인

*fstab 파일의 맨 아랫줄에 다음 내용을 추가합니다. *

Archive (ntfs): UUID=982E35F32E35xxxx /mnt/archive ntfs defaults,uid=1000,gid=1000,nofail 0 0

Workspace (exfat): UUID=0ECE-xxxx /mnt/workspace exfat defaults,uid=1000,gid=1000,nofail 0 0

ToolBox (ntfs): UUID=960EBAE30EBAxxxx /mnt/toolbox ntfs defaults,uid=1000,gid=1000,nofail 0 0

Windows (ntfs): UUID=04DC4011DC40xxxx /mnt/windows ntfs defaults,uid=1000,gid=1000,ro,nofail 0 0 (안전을 위해 읽기 전용 ro 추천)

저장(CTRL + O, ENTER) 이후 편집기를 종료(CTRL + X)합니다.

4. 설정 적용 및 검증

sudo mount -a
lsblk -f

/mnt/toolbox와 같이 고정 마운트가 된 것을 터미널 창에서 확인합니다.

이제 모든 디스크가 외장 하드가 아닌 시스템 구성 요소로 인식되어 독바에서 사라집니다.

예외 상황

1. 마운트 경로 불일치 sudo mount -a를 입력했을 때 아래와 같은 문구가 출력될 수 있습니다. 해당 내용은 임시 자동 마운트와 새로운 고정 마운트 경로가 불일치하는 경우 출력됩니다.

mount: (hint) your fstab has been modified, but systemd still uses
       the old version; use 'systemctl daemon-reload' to reload.
Mount is denied because the NTFS volume is already exclusively opened.
The volume may be already mounted, or another software may use it which
could be identified for example by the help of the 'fuser' command.

아래의 명령어로 fstab 파일을 동기화 한 뒤 임시 마운트 경로를 해제 후 다시 마운트합니다.

# 1. 내부 설정을 다시 읽어 동기화합니다.
sudo systemctl daemon-reload 

# 2. 기존의 임시 마운트를 해제합니다.
sudo umount /dev/sdb2

# 3. 수정한 fstab 설정대로 다시 마운트를 시도합니다.
sudo mount -a

# 4. 결과를 확인합니다.
lsblk -f

2. 부팅 불가 fstab 구문 오류 혹은 UUID 오타 발생 시 부팅이 불가능(검은 화면)할 수도 있습니다. Emergency Mode에서 fstab을 백업본으로 복구 하여 해당 오류를 해결합니다.

# 복구 모드로 진입
sudo cp /etc/fstab.bak /etc/fstab
sudo reboot

2. 심볼릭 링크 생성

윈도우의 바로가기(Shortcut)와 유사하지만, 운영체제 커널 수준에서 경로를 치환해주는 더 강력한 기능입니다.

ln -s [원본 디렉토리의 절대 경로] [내가 만들 바로가기 이름]

예시

# workspace 연결
ln -s /mnt/workspace ~/ws

# toolbox 연결
ln -s /mnt/toolbox ~/tool

# archive 연결
ln -s /mnt/archive ~/archive

연결 확인

ls -l ~

해당 명령어를 입력했을 때 아래의 이미지와 같이 폴더 이름 옆에 화살표(->)와 같이 절대 경로가 출력되면 성공입니다.

마무리하며

5개의 물리 디스크를 우분투 시스템의 일부로 연결시켰습니다. /etc/fstab을 통한 고정 마운트와 심볼릭 링크를 활용한 경로 추상화는 개발 환경의 재현성과 안정성을 확보하는 핵심적인 작업입니다. 이제 재부팅을 하거나 장치를 재연결해도 빌드 스크립트와 시뮬레이션 경로는 절대 깨지지 않을 것입니다.

다음 포스팅에서는 Python 환경과 신호처리 및 시스템 프로그래밍을 위한 C++, 그리고 반도체 설계를 위한 Verilog 도구들의 설치에 대해 다루겠습니다.

1. VS Code 설치

1. 이번에는 터미널이 아닌 웹 브라우저를 통해 다운로드하는 방법을 알아보겠습니다. 다운로드 페이지(https://code.visualstudio.com/download)에 접속한 후, Ubuntu용 .deb 파일을 다운로드합니다. 여기서 주의할 점은 큰 버튼을 바로 클릭하는 대신, .deb x64 버전을 선택해 정확한 버전을 설치하는 것이 안정성 측면에서 더 좋습니다.
2. 다운로드가 완료되면 터미널을 열어 다운로드 폴더로 이동합니다.

   cd Downloads/

   참고: 리눅스(우분투)는 대소문자를 구분하므로 downloads가 아닌 Downloads로 정확하게 입력해야 합니다.
3. ls 명령어로 다운로드 폴더에 있는 VS Code 파일명을 확인합니다.

   ls

   확인한 파일명을 아래 명령어에 입력하여 설치를 진행합니다.

   sudo dpkg -i code_1.109.0-1770171879_amd64.deb

   이때 code까지만 입력 후 Tab 키를 누르면 자동완성됩니다.

Yes를 눌러 설치를 완료해줍니다. 4. 아래의 명령어를 입력하여 VS Code 실행해줍니다.

code

2. VS Code 동기화 설정

이미 윈도우에서 VS Code를 사용 중이었기 때문에, 기존에 설정해둔 글꼴과 테마를 우분투에서도 그대로 사용하기 위해 동기화 작업을 진행했습니다.

동기화 순서:

1. 좌측 하단의 톱니바퀴 클릭
2. Backup and Sync Settings... 선택
3. Profiles와 Prompts and Instructions 체크 해제
4. Sign in 클릭 이렇게 설정하면 테마, 글꼴, 확장 프로그램만 동기화되고, 컴파일러 경로 같은 OS별 설정은 각각 독립적으로 관리할 수 있습니다.

3. Git 설치

아래의 명령어로 Git을 설치합니다.

sudo apt update
sudo apt install git -y

설치가 완료되면 Git 버전을 확인하여 정상적으로 설치되었는지 확인할 수 있습니다.

git --version

이후 사용자 정보를 설정해줍니다.

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

이후 기본적인 설정들을 완료해줍니다.

1. 기본 브랜치 이름 설정

git config --global init.defaultBranch main

master라는 브랜치 대신 main으로 브랜치 이름을 변경해줍니다.

2. 줄바꿈 문자 설정

git config --global core.autocrlf input

윈도우와 리눅스는 줄바꿈 문자를 다르게 처리합니다.

• 윈도우: 줄바꿈을 CRLF (\r\n)로 저장
• 리눅스/맥: 줄바꿈을 LF (\n)로 저장

듀얼 부팅 환경에서 양쪽 OS를 오가며 작업할 때, 이 차이로 인해 Git이 파일을 변경된 것으로 잘못 인식할 수 있습니다.

autocrlf input :

• 체크아웃 : 줄바꿈 변환 하지 않음 (LF 유지)
• 커밋 : CRLF → LF 자동 변환

이렇게 설정하면 Git 저장소에는 항상 LF로 통일되어 저장되며, 윈도우와 우분투 간 원활한 협업이 가능합니다.

3. 컬러 출력 설정

git config --global color.ui auto

Git 명령어 결과를 컬러로 표시하여 가독성을 높여줍니다.

4. 설정 확인

git config --list

마무리하며

개발을 위한 기본적인 소프트웨어 설정을 하였습니다. 하지만 더욱 중요한 것은 설치 목록이 아니라 자원을 다루는 방식에서 나옵니다. 여러 디스크가 공존하는 환경에서는 경로의 일관성이 곧 안정성입니다. 다음 포스팅에서는 시스템의 기본이 되는 디스크 고정 마운트와 접근성을 극대화하는 심볼릭 링크 설정을 통해, 안정적인 개발 환경을 만들어 보겠습니다.

1. Chrome 설치

• 파일 다운로드

  wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb

• 패키지 설치

  sudo apt install ./google-chrome-stable_current_amd64.deb

설치 파일 제거 Chrome 설치가 완료되면 설치 파일은 더 이상 필요하지 않습니다. Home 디렉토리에 남아있는 google-chrome-stable_current_amd64.deb 파일을 우클릭하여 Move to Trash를 선택해 삭제합니다.

2. Notion 설치

sudo snap install notion-snap-reborn

3. Claude 및 Claude Code 설치

• Claude 설치 현재 Anthropic은 Windows와 macOS용 데스크탑 앱만 제공하며, Linux/Ubuntu용 네이티브 앱은 아직 출시되지 않았습니다. 대신 Chrome 브라우저의 앱으로 설치 기능을 활용하여 Claude를 PWA(Progressive Web App) 형태로 설치할 수 있습니다.

오른쪽 상단의 점 세개 -> Cast, save, and share -> Install Claude...

• Claude Code 설치 공식 홈페이지의 명령어를 입력합니다.

curl -fsSL https://claude.ai/install.sh | bash

• curl 설치 터미널 메세지를 확인해보니 Claude Code 설치를 진행하기 전에 curl이 필요합니다. 다음 명령어로 curl을 설치합니다.

  sudo apt install curl -y

• Claude Code 설치 명령어 재입력 curl 설치가 완료되면 이전에 실행했던 Claude Code 설치 명령어를 다시 입력합니다.

• 환경 변수 설정 터미널 메세지의 추천 명령어를 입력합니다.

  echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc && source ~/.bashrc

  

• claude code 초기 설정

  claude

  명령어를 입력하여 초기 설정을 해줍니다.

1. Claude 요금제를 구독 중인 경우에 선택해줍니다.
2. API 키를 발급받아 사용하는 방식입니다.
3. 클라우드 플랫폼을 통해 사용하는 방식입니다.

4. Mirage 설치

간단한 이미지 편집 툴입니다.

sudo apt update
sudo apt install mirage -y

다만 이미지 Crop 기능이 별로 좋지는 않습니다...

5. btop++ 설치

btop(btop++)는 CPU, 메모리, 디스크, 네트워크 및 GPU의 상태를 터미널에서 실시간으로 시각화하고 관리할 수 있는 모니터링 툴입니다. 아래의 명령어로 설치를 진행합니다.

sudo apt install btop -y

아래의 명령어로 실행시켜줍니다.

btop

6. stress-ng 설치

CPU 표준 스트레스 테스터입니다. 논리 프로세서(Thread) 모두에 100% 부하를 원하는 시간 동안 가합니다. 연산 오류 여부와 시스템 안정성을 확인하기에 가장 강력한 도구입니다. btop++와 함께 사용하여 CPU의 성능을 모니터링합니다.

아래의 명령어로 설치를 진행합니다.

sudo apt install stress-ng -y

아래의 명령어를 입력하여 사용합니다. 60초 동안 16 Thread에 100% 부하를 가합니다.

stress-ng --cpu 16 --timeout 60s --metrics-brief

CPU load가 1%에서 100%가 된 것과 클럭이 3.1GHz에서 5.4GHz까지 상승한 것을 확인할 수 있습니다. 또한 미리 설정해둔 PBO Set Thermal Point 값인 85∘C를 넘지 않는 것을 확인할 수 있습니다.

-결과 해석 Bogo ops : 1분간 총 2,063,033번의 가상 연산(Bogo operations)을 수행했습니다. 연산 속도 : 초당 약 34,383.52 ops의 속도를 기록했습니다. stress-info : skipped와 failed가 0이므로 시스템의 안정성을 확인할 수 있습니다.

7. glmark2 설치

간단한 GPU 성능 테스트 툴입니다. 아래의 명령어로 설치를 진행합니다.

sudo apt install glmark2 -y

아래의 명령어로 실행합니다.

glmark2

GPU load가 4%에서 100%가 된 것을 확인할 수 있습니다.

-결과 해석 glmark2 Score : 10,881으로 사무용 PC에 비해 매우 높은 수치가 나옴을 알 수 있습니다. FPS : 초당 프레임수가 12,000대의 수치로 GPU가 아주 원활하게 작동하고 있음을 확인할 수 있습니다. GPU온도가 39°C로 평상시 작동 온도와 유사합니다. 해당 테스트가 GPU 성능에 비해 매우 낮은 부하를 주었거나, RTX 5060의 쿨링 성능이 우수하기 때문으로 보입니다.

마무리하며

Ubuntu 환경에서 기본 프로그램 설치부터 CPU/GPU 성능 벤치마크까지 기본 설정을 완료하였습니다. 다음 포스팅에서는 VS Code 및 Git 설정에 대해서 다루겠습니다. 감사합니다.

1. 윈도우와 우분투 시간 동기화

듀얼부팅 환경에서 윈도우로 시간 동기화를 해도, 우분투로 부팅한 후 다시 윈도우로 전환하면 시간이 일치하지 않는 문제가 발생했습니다. 윈도우는 하드웨어 시계를 로컬 시간으로 인식하는 반면, 우분투는 UTC(협정 세계시)로 인식합니다. 이 문제는 우분투 터미널에서 다음 명령어를 입력하여 해결할 수 있습니다.

timedatectl set-local-rtc 1 --adjust-system-clock

이 명령어는 우분투도 하드웨어 시계를 윈도우와 동일하게 로컬 시간으로 사용하도록 설정합니다.

2. 윈도우 빠른 시작 켜기 옵션 체크 해제

이전 포스팅에서 설명했듯, 윈도우의 빠른 시작 기능은 시스템 종료 시에도 커널 상태를 하드디스크에 저장하기 때문에 결과적으로 윈도우에 저장된 파일을 우분투에서 수정하거나 이동할 수 없게 됩니다. 또한 시스템이 완전히 초기화되지 않아 GRUB 메뉴가 제대로 표시되지 않거나 드라이버 충돌이 발생할 수도 있기에 해당 기능은 필수적으로 비활성화해야 합니다.

제어판->하드웨어 및 소리->전원 옵션->전원 단추 작동 설정에서 빠른 시작 켜기를 체크 해제

3. 공유 드라이브 마운트 경로 확인

기본적으로 우분투는 다른 저장장치를 자동 마운트 방식으로 처리합니다. 해당 드라이브를 클릭하면 그때그때 자동적으로 마운트되는 방식입니다.

현재 시스템에 연결된 저장장치의 정보는 다음 명령어로 확인할 수 있습니다.

lsblk -f 

출력 결과에서 각 드라이브의 UUID를 확인할 수 있습니다. 이번 현재 사용 중인 공유 드라이브는 다음과 같습니다: Archive (ntfs) : 982E35F32E35xxxx

Workspace (exfat) : 0ECE-xxxx

ToolBox (ntfs) : 960EBAE30EBAxxxx

4. 드라이버 설치 및 설치 확인

4-1. NVIDIA 드라이버

nvidia-smi

그래픽카드 정보가 출력되면 제대로 설치된 것입니다.

4-2. CPU 마이크로코드 Ryzen 9700X를 사용 중이므로 다음 명령어를 입력합니다.

sudo apt install amd64-microcode -y

이미 최신 버전이 설치되어 있음을 확인할 수 있습니다.

4-3 메인보드 및 주변기기 인식 확인

lspci -nnk | grep -i vga -A 3

PCI 버스에 연결된 모든 하드웨어 장치 목록을 보여주는 명령어입니다. 메인보드가 NVIDIA 외장 GPU와 AMD 내장 GPU를 모두 정상적으로 인식하고 있음을 확인할 수 있습니다.

해당 시리즈를 마무리하며

지금까지 5편에 걸쳐 AI 가속기 & SoC 개발용 워크스테이션의 구축 과정을 다루었습니다.

하드웨어 선택부터 조립, 그리고 물리적 SSD 분리를 통한 안정적인 OS의 설치와 GRUB 설정, 그리고 이번 편의 시간 동기화, 빠른 시작 기능 비활성화, 공유 드라이브 경로 확인, 각종 드라이버 설치 확인까지 완료했습니다. 하나의 워크스테이션에서 윈도우와 우분투를 안정적으로 사용할 수 있는 환경이 갖춰졌습니다.

해당 시리즈는 여기서 마무리하도록 하겠습니다. 감사합니다.

이제 CMake를 도입하여 보다 전문적인 C++ 개발 환경을 구축해보겠습니다. 참고: Visual Studio Code 공식 유튜브 채널의 영상을 참고하여 작성했습니다. (https://www.youtube.com/watch?v=_BWU5mWqVA4&t=87s)

사전 준비: 이전 설정 정리

참고 : C/C++ Compile Run 확장을 굳이 삭제하지 않아도 CMake 환경 설정에는 문제가 없습니다. 필요에 따라 두 방식을 병행할 수도 있습니다. 1. 확장프로그램 삭제 : 기존에 사용하던 C/C++ Compile Run(danielpinto8zz6) 확장을 제거합니다. 2. 프로젝트 내부 폴더 삭제 : 프로젝트 루트의 .vscode 폴더를 삭제합니다. 이전 설정이 남아있을 경우 새로운 설정과 충돌할 수 있기 때문입니다. 3. 레지스트리 복구 : 레지스트리의 Autorun 파일에 등록한 chcp 65001 명령어를 삭제합니다.

1. C/C++ 확장 프로그램 설치

아래의 확장 프로그램을 다운받습니다.

1. C/C++ VS Code에서 C++ 개발을 위한 핵심 엔진입니다.

*2. C/C++ Extension Pack * 사용자의 편의를 위해 여러 확장을 하나로 묶어놓은 확장 팩입니다. C/C++, C/C++ Themes, CMake, CMake Tools 등을 한 번에 설치합니다.

3. C/C++ Themes C++ 코드의 예약어, 변수, 함수 등을 더 명확하게 구분해 주는 전용 색상 테마를 제공합니다.

2. C/C++ Edit Configuration 설정

1. Command Palette(CTRL + SHIFT + P)를 열어 C/C++: Edit Configurations(UI)를 클릭합니다.

2. Compiler Path에 해당 컴파일러 경로(C:/msys64/mingw64/bin/g++.exe)를 입력합니다.

3. IntelliSense Mode도 GCC(windosw-gcc-x64)로 수정합니다.

3. CMake 설치

1. CMake 공식 홈페이지(https://cmake.org/download/)에서 Windows x64 Installer를 다운로드하여 설치합니다.

2. Add CMake to the PATH environment variable 옵션을 체크합니다. 이 옵션을 체크 해야 윈도우 시스템 전체에서 cmake라는 명령어를 인식할 수 있습니다.

3. 기본 경로 그대로 설치합니다.

4. CMake 기본 설정

1. Command Palette의 CMake: Quick Start메뉴를 선택합니다.
2. 프로젝트 이름을 입력합니다.
3. Executable를 선택합니다.(CMake의 기본 구성 코드를 자동 생성해주는 기능)

5. Ninja 설치

1. MSYS2 MinGW64 터미널 창을 엽니다.
2. 아래의 명령어를 입력하여 Ninja를 설치합니다.

   pacman -S mingw-w64-x86_64-ninja

   

6. Kit 선택

GCC 15.2.0 x86_64-w64-mingw32 (mingw64) 키트를 선택합니다.

어떤 컴파일러를 사용할지 선택하는 단계입니다.

• MSVC (Visual Studio): 윈도우 환경에 가장 최적화된 컴파일러

• GCC (MinGW/MSYS2): 리눅스 표준과 가깝고 가벼운 컴파일러

7. CMake Tools

CMake Tools는 CMakeLists.txt 파일을 해석하여 컴파일러 구성, 빌드 자동화, 디버깅, 그리고 IntelliSense 연결을 GUI 기반으로 통합 관리해 주는 확장 프로그램입니다.

또한 사이드바와 하단 상태표시줄에 CMake 전용 영역이 생겨 더욱 편리하게 CMake를 사용할 수 있습니다. 사이드바에 CMake가 생긴 모습을 확인할 수 있습니다.

하단 상태 표시줄에도 편의성 버튼이 생겼습니다.

8. 테스트 코드 생성

9. CMakeLists.txt 생성

해당 파일은 프로젝트의 구성, 빌드 대상 및 컴파일러와 같은 빌드 방식을 CMake에 알려주는 핵심 구성 파일입니다. 파일 이름을 CMakeLists.txt라고 지정하여 생성합니다.

cmake_minimum_required(VERSION 4.2) CMake 소프트웨어의 최소 버전을 명시하는 코드입니다. 시스템에 설치된 CMake 버전이 이보다 낮으면 빌드를 중단힙니다.

cmake --version

해당 명령어를 이용해 현재 cmake version을 확인할 수 있습니다.

project(CH9 VERSION 0.1.0 LANGUAGES C CXX) CH9 (Project Name): 프로젝트의 고유 이름입니다. VERSION 0.1.0: 연구의 진행 단계를 기록합니다. LANGUAGES C CXX: 이 프로젝트가 C와 C++(CXX) 언어를 사용함을 알립니다.

add_executable(LAB_9.1 LAB_9.1.cpp) 어떤 소스를 엮어 어떤 실행 파일을 만들지 결정합니다. LAB_9.1 (Target Name): 생성될 실행 파일의 이름. 빌드 성공 시 LAB_9.1.exe라는 실행 파일이 생성됩니다. LAB_9.1.cpp (Source Files): 실행 파일을 만드는 데 필요한 코드입니다.

10. 테스트 코드 실행

VS Code의 하단 상태 표시줄의 망치 모양 빌드를 클릭 후 화살표 버튼을 클릭하면 파일이 실행됨을 확인할 수 있습니다. 성공!

11. 빌드 및 실행 대상 선택하기

사이드바의 CMake 영역에서 빌드 대상 및 실행 대상을 선택할 수 있습니다.

또는 Command Palette에서 CMake: Set Launch/Debug Target이나 CMake: Set Build Target을 통해 원하는 대상을 선택할 수 있습니다.

마무리하며

이로써 Windows 환경에서 VS Code와 CMake를 활용한 C++ 개발 환경 구성을 마쳤습니다.

물론 가장 쉬운 선택은 Visual Studio를 사용하는 방법입니다. 그럼에도 CMake와 Ninja를 직접 구성한 이유는 단 하나, 환경의 연속성에 있습니다. 앞으로 마주하게 될 많은 프로젝트와 리눅스 기반 개발 환경에서는 이러한 빌드 방식이 표준이 되기 때문입니다.

이제 코드를 실행하는 단계를 넘어, 프로젝트를 스스로 빌드하고 운영할 수 있는 체계를 갖추었습니다. 이 환경을 바탕으로 더 큰 규모의 개발로 확장해 나가겠습니다.

1. 파이썬 홈페이지(https://www.python.org/downloads/release/python-31311/)에서 Windows Installer (64-bit) 다운로드

2. 설치 항목 선택

• Use admin privileges when installing py.exe
  • 관리자 권한으로 파이썬을 설치. 윈도우 시스템 수준에서 파이썬 실행 파일들이 올바르게 등록되며, 추후 라이브러리 설치 시 발생할 수 있는 권한 오류를 사전에 방지 가능
• Add python.exe to PATH
  • Git Bash나 VS Code의 터미널에서 python 명령어를 입력했을 때 컴퓨터가 파이썬을 찾지 못함. 경로의 수동 설정을 피하기 위해 반드시 체크

Customize installation 선택

3. Optional Features 설정

default 설정 그대로

4. Advanced options 설정

파이썬 설치 경로 : C:\Program Files\Python313

5. Disable path length limit 설정

Disable path length limit 선택. 파일 경로의 최대 길이 제한 해제 옵션. 필수적으로 선택

6. Python 인식 확인

vscode에서 python 설치 확인

정상 설치!

1. Git 홈페이지(https://git-scm.com/)에서 Windows용 설치

2. 다운로드 경로

기본 다운로드를 그대로 유지

3. 구성요소 선택

a. Additional icons : 바탕화면에 바로가기를 생성 할지 여부 b. Windows Explorer Integration :      - Open Git Bash here : 우클릭 메뉴(컨텍스트 메뉴)에 Git Bash를 연결할지 여부      - Open Git GUI here : 우클릭 메뉴(컨텍스트 메뉴)에 Git GUI를 연결할지 여부 * c. Git LFS(Large File Support)** : 대용량 파일 지원 여부 **d. Associate .git configuration files with the default text editor* : .git 구성 파일을 기본 텍스트 편집기와 연결 e. Associate .sh files to be run with Bash : 확장자가 .sh인 쉘 스크립트 파일을 Git Bash를 통해 실행하도록 연결 f. Check daily for Git for Windows updates : Windows 용 Git 업데이트를 매일 확인 할지 여부 g. Add a Git Bash Profile to Windows Terminal : Windows 터미널에 Git Bash 프로필 추가. 즉 터미널 내에서 새 탭으로 Git Bash를 즉시 호출 가능 h. Scalar (Git add-on to manage large-scale repositories) : 대규모 저장소에서 Git 작업 속도를 높여주는 도구

4. 스타트 메뉴 폴더

Git Bash를 직접 실행해야할 때 편리함

5. vim 언어 사용

VsCode가 더 편함. 하지만 Vim 언어는 리눅스 환경에서 필수적으로 사용되고, 윈도우지만 리눅스 환경에 익숙해지기 위해 Vim 선택

6. branch 이름 설정

branch명을 내가 지정한 main으로 변경

7. 환경 변수 설정

두 번째를 선택해야 Git이 PATH에 등록된 경로를 즉각적으로 인식할 수 있음

8. 기본 제공 ssh.exe를 사용

암호화 통신 방식에서 굳이 외부 프로그램을 사용할 필요는 없음

9. 네트워크 통신 규격 설정

우분투에서 사용되는 것과 동일하게 구성

10. 줄바꿈 설정

a. Checkout Windows-style, commit unix-style line endings. : Git에 커밋할 때는 자동으로 우분투 줄바꿈 방식인 LF로 변경, 체크아웃을 할 때는 자동으로 윈도우 줄바꿈 방식인 CRLF로 변경 b. Checkout-as-is, commit Unix-style line encodings. : Git에 커밋할 때는 CRLF, 체크아웃할 때는 어떤 변환도 수행하지 않고 그대로 c. Checkout as-is, commit as-is. : Git은 커밋하거나 체크아웃할 때 줄 바꿈 변환을 수행하지 않음

11. 터미널 설정

더 나은 가독성과 리눅스 스타일의 터미널 조작을 위해 첫 번째 선택

12. 1. Git의 pull 동작 방식 설정

1. Fast-forward or merge : 원격 저장소의 최신 커밋과 내 로컬 작업물의 충돌이 없다면 단순히 Fast-forward하고, 두 곳에서 작업이 동시에 발생하면 merge commit(병합)함 2. Rebase : 내 로컬 브랜치의 커밋들을 원격에서 새로 가져온 최신 브랜치 끝부분에 '다시 배치(Rebase)'함 3. Only ever fast-forward : 커밋을 그대로 이어 붙일 수 있을 때만 pull을 허용. 이외의 상황에선 에러 발생

→윈도우/우분투 듀얼 부팅 상황에선 rebase가 더 적절하다고 판단.

Rebase : 원격 작업을 먼저 깔고 로컬 작업을 그 뒤에 붙임 → 원격의 상태는 과거로, 로컬 작업은 최근 상태로 인식. 즉 로컬 작업이 항상 최신 상태로 유지

merge : 로컬 작업과 원격 내용을 병렬적으로 붙임

Git에 익숙하지 않은 나는 소스코드의 무결성과 이력이 꼬였을 때 복구하기가 더 용이한 첫 번째 옵션을 선택

13. 자격 증명 manager

첫 번째 옵션이 더 편리함

14. 추가적인 옵션 선택

첫 번째 옵션 선택 시 상당한 성능 향상 제공

15. 설치 완료!

16. 기본적인 명령어 적용