From Processor Customizations To HLS

HLS

성능 올리려면 이제 비용이 너무 커짐. 다이 사이즈부터 전력까지.
- 그래서 가성비가 중요해짐
- 임베디드에서는 바이너리 컴패티빌리티도 안 중요
  - 걍 회로를 합성하자
ISE ( Instruction Set Extension )
- 자주 쓰이는 복잡한 명령어 걍 하나의 Ad-hoc 명령어로 만들기
- HW 특징을 활용하면 cycle 수 단축 가능.
HW 특징
- Spatial Computation
  - 간단하게 패럴리즘 구현 가능
- No clock quantization
  - 빨리 끝나면 다음 클럭 기다리지 않고 바로 다음 작업 실행
- Constant propagation, precision tuning, arithmetic optimization
  - 비트연산들 와이어링으로 대체 가능
  - 숫자 비교도 필요한 비트만

이제는 C로 작성 (젠3, 베릴로그 다음)
스케쥴링 문제. VLIW랑 비슷하지만 다름
- 정확한 리소스 제한이 없음. 뭐 게이트 수 제한 정도? VLIW처럼 explicit하게는 없음
- clock cycle과 pipelining 도 확실치 않음
- Register File은 없지만 Ad-hoc으로 연결
다양한 최적화 기법 (# pragma HLS ~~~~)
한계
- 결국 메모리 디펜던시 같은 컴파일 타임에는 확실하지 않은 것들이 문재
- 그리고 최적화를 유저한테 다 맡겨버리는 것도 문제
- 프로그래밍 언어
  - C/C++를 지원하지만 다 지원하는 건 아님
    - 당연히 시스템콜, dynamic allocation 지원 안 됨
    - 리커전도 지원 안 됨
  - 툴마다 다름

런타임에서 디펜던시를 해결 가능하니 dynamically scheduled hls는 저런 한계들을 해결 가능
Async와 Sync
synthesis
- 마치 RS와 ROB 같이 FIFO BUFFER 들 넣어서 최적화
- Load /Store Queue로 메모리 디펜던시 해결
- speculation 위해 save /commit 분리

Variable Latency
- static hls 는 최악의 latency 가정하고 만들어짐
- dynamic hls 는 한 단계가 빨리 끝나면 바로바로 다음 것 하지만, 그렇다고 빈 공간이 없어지는 건 아님
- 슈퍼스칼라에서는 그냥 할 수 있는 모든 계산 꽉 꽉 채워서 진행. 하지만 dependency는 남아있음
- 이걸 hls에서 잘 분석하면 완전히 최적화도 가능
Memory and Caches
- Access / Execute decoupling
  - access 미리 해서 값 저장한다음 execution 해도 됨
  - out of order로 값 처리하게 만들 수도 있음
Nested Loops
- variable loop bound
  - 안 쪽 루프가 언제 끝날지 모를 때도?
  - 그러면 그거 확인하고 다음 루프 진행해야 해져서 느려짐
  - 결국 speculate 하고 out of order로 처리

HLS 는 충분히 연구된 분야.
FPGA한테만 매력적. ASIC은 RTL로 완전 빡시게 최적화 잡음
그렇다고 소프트웨어 엔지니어들한테 FPGA 하라 하는 건 아님
FPGA에 irregular parallelism 적용하는 건 천천히 연구중
Caveat 들
- reconfigure 어려운 만큼 그만큼 더 효율적이어야 함
- 메모리 디펜던시 해결 매우매우 어려움
- HLS는 빡시게 최적화 안 해줌 RTL 해야함