시스템 반도체(SoC) : SoC's combine a processing core, memory, and logic on a single chip
아날로그, 디지털로 나눠짐
디지털 SOC 설계 과정이 수업의 주요 내용임.
주요 내용 : Back-end (P&R)
목적 : 시스템 반도체 취업
RTL coding : 하드웨어를 논리 구조로 코딩(가상)
Verification(Function Simulation) : Function을 검증
Synthesis : 시놉시스 사 Design Compiler (가격이 10억, 표준화됨), 게이트 위주로 function 기능
Logic verification : gate level simulation (두가지 검증 - 1. timing 2. function 검증)
나눈 이유 : STA = Prime Time 이라는 Tool >>> 얘가 표준화가 됨 (시놉시스가 돈 버는 이유)
회사 입장 : 성능도 중요하지만, 빠른 출시도 중요
검증하는 시간이 너무 오래 걸림
그렇기에 검증을 나누는 거임
이번 교육에는 STA 즉, 시간을 진행
그럼 function 검증은?
앞에서 했지만 시놉시스도 버그가 있기에
Equivelent check : formal verification 이라는 tool 잘 검증이 되었는데
Formal verification 즉
여기까지 프루낸드 디자인? fronend disign
cell의 두가지 종류
stardard cell(기본) - 자동 배치
Place&Route >> Auto
마코로 cell - 수동 배치
시놉시스는 비쌈
삼성전자가 시놉시스 사고 라이센스를 삼
인력이 부족하니 파트너 회사 고용
TR : 증폭, 스위치
시스템 반도체는 스위치 역할
공정에서는 피지컬cell을 거의 비슷하게 만듦
시스템 반도체는 logic cell을 사용
Gate Drive Strength Example(GDSE)
x2는 TR의 정공과 전자가 많으니 더 빨라짐
Fast (<>slow)
strong cell (<> weak cell)
소비 전력이 크기에
High cell (<>low cell)
피지컬 적으로는 큼
Upsizing cell (<>downsizing cell)
prime time은 Tool이다.
//i-6
signoff ; 검증한다
반도체 만드는 회사에서 제일 많이 사용하는 TOOL임
//i-7
cadence는 음악용어 > 그래서 음악 용어 고유명사로 함
sysnsis는 우주 > 그래서 우주 용어를 고유 명사로 사용함 (ex- Galaxy)
prime time은 타이밍의 변화가 생길 때마다 검사를 함
Back end는 NET DELAY 중요
IC compiler
공정으로 넘기기 전에 검사를 많이 한다 정도
//i-8
STA가 뭔지
function, logic 시뮬 안함
장점 : 타이밍에서 발생한 큰 문제를 "빠르게" 찾을 수 있다.
모든 업체가 다 이걸 사용하고 있음.
//i-9
이걸 이해하기 전 위 그림에서 어디서 동작할까 1,2,3
(해설) latch는 enable에서 1,2번 사이에서 열림
1,2일 때 동작하고 3번으로 갈 때 문이 닫혀서 안됨
즉, 문이 닫히기 전까지만 데이터가 오면 됨
D-latch 동작은 Gate가 high 신호일 때, D 값이 출력됨.
그리고 Gate가 LOW 이면 이전 값을 유지하게 됨
만약 latch가 F/F으로 바뀌면 1번만 동작
즉, 얘는 문이 열렸다가 바로 닫힘(1,2번사이 Edge) 그래서 문 앞에 기다리는 데이터만 보내줌
FF의 다음 상태는 바로 직전 상태에만 의존함
FF은 클럭에 의해서 data를 주고 받음
그림의 X는 조합회로의 딜레이
Launch edge : 첫 번째 posi-edge
모든 FF은 setup 시간이 있음
Capture Edge : 다음에 받는 edge
period : 런치, 캡처 엣지 사이
period - ffsetup : data required time(DRT)
data arrive time(DAT)
DAT와 DRT을 비교하는 게 중요
T_max : 합성 가능한 최대 시간
이제는 Path에 대한 기준점을 설명할 거임
모든 path는 start point, end point가 있음.
주의할 것. 셀 입장에서는 입력핀이지만 end point가 된다.
//i-10
input_delay(데이터 도착하는 시간)+ create_clock >> design spec(constraint,DC)
ex) SDC
STA도 DC에 대해 구성된다.
그걸 안 주면 아무 리포트가 나오지 않음
완벽하고 정확한 DC를 줘야 함
//i-11
S : static 즉 synchronous
asynchronous로는 분석 못함
//i-12
무조건 철저하고 규칙적인 방법으로 분석해야 한다.
Static, synchronous로 정확하게 규칙성 파악해야 함.
그럼 asynchronous 디자인은 어떻게 검증??? >>> 그게 시뮬레이션
//i-13
입력 i/p
출력 o/p
slew 0>1로 갈 때
GBA로 worst case만 빠르게 분석
왜냐면 경로가 무지 많기 때문에
그럼 왜 worst case만 분석하는가?
회로 디자인은 회로의 최악의 조건에서 해결을 해서 어떻게든 동작하게 해야되기 때문에
//i-14
On Chip Variation (OCV)
데이터는 launch edge 때 보내고 capture edge일 때 받는다.
완벽한 워스트 케이스 slowest launch and fasture capture
//i-15
skew balency
common point(C.M)
CRP : 늦게 도착한 거(C.M) - 빨리 도착한 거(C.M) ==0이 되야 함
constraint 잘못 적어서
//i-16 (중요)
prime time 사용이유 : 합성 후 합성이 잘 되어있는지 확인하기 위해
합성 데이트를 받아야 함
1. gate-level netlist를 회로도라고 함. 스키메틱, 디자인도 같은 말
ㄴ타이밍도는 공정회사에서 옴
2. libraries : 공정회사에서 옴
3. design constraints
선이 길어지면 딜레이가 길어짐
이 값은 라우팅을 해야지만 나타남
모든 net는 R,C가 기생함
4.Parasitics : R,C
5.SDF 파일
총 1~5번 >>>>> report
//i-17
흐름도
//i-18
//1-3
prime time은 해결방법을 찾는 교육임.
//1-4
구름모양 : 클럭단에서 생긴 네트 딜레이
//1-5,6
skew
//1-7
//1-8
//1-9
//1-10
//1-11
negative slack을 보고 찾아서 해결함
cp /synopsys/Lab/ces* ./
tar - zxvf ces_pt_2016.06.tar.gz
타이밍을 확인하기 위해서 맞는지 확인하기 위해
clk timing이 맞는지 확인하기 위해서
restore session이 디자인을 불러오기 위해서 사용한 코드
report_anlaysis_conver 확인이 가능한지 확인하는 코드
pt에서 사용하는 기본적인 코드가 잘 작동하는지 확인해보는게 이번 실습
===> 디자인이 규격에 맞게 잘 동작하는지 확인하겠다.
ip정보가 바뀌어있었던거 같다..
마지막 reports
2.736그리고 pessimism의 0.470
이 레포트의 slack은 Violated인 상태인데 그 이유를 찾는 것이 pt의 목적
pt_shell> !rep -delay min의 코드를 통해 holdtime에 대한 레포트를 생성
skew가 slack에 방해가 되는 이유 디시(디자인 컴파일러)
skew의 계산은 관점의 차이