Simulation (VCS)
ASIC Design Flow (by SYNOPSYS)
PI(Front-End) - physical implementation
-
RTL : verilog를 가지고 code를 작성함
관련 Tool : Verilog-HDL -
Verification : code가 목적에 맞게 잘 작동하는지 확인. 즉, 시뮬레이션
관련 Tool : VCS, Verdi
+버디는 GUI에서 베릴로그 코드나 테스터벤치 코드를 수정할 수 있음. -
Synthesis(합성) : 디지털 설계에서 RTL 설계를 논리 게이트 레벨의 회로 설계로 변환하는 과정
관련 Tool : Design Compiler(DC)
Synthesis = Translation + Optimization + Mapping
verilog code를 Translation으로 번역
GTECH : 정보를 갖고 있지 않음
DC(최적화 Optimization+mapping)를 거치면서 회로를 만듦(GLN)
정보가 갖춰진 GLN(gate-level-netlist)로 나타남
즉 DC는 logic level 최적화(optimizations), technology library로 부터 gate들로 연결하고(mapping), gate-level 최적화(optimizations)으로 확인
회로도가 베릴로그에 맞게 만들어졌는지 확인필요 : Function
또한 타이밍이 맞는지 확인 필요 : Timing
but, 2가지를 동시에 검사하면 시간이 오래걸림
-
DFT & ATPG (Test Max) - 얘는 팀이 따로 있다고 함. (정보)
-
Logic verification, STA(Static timing analysis) : Timing 검사 (Prime_Time)
-
formal verification : Function 검사 (formality)
PD(Back-End) - physical design
- Floor plan : cells(마크로 셀(벤더쪽에서 하나의 기능을 위해 스탠다드 셀을 모아 만든 셀) 마크로 셀을 수동 배치함 (IC Compiler 2-ICC2)
- Place : 스탠다드 셀 뿌림
- Route : CTS(배선하기), net 같은 것들을 다 라우팅
-
다시 타이밍 검사
다시 PI로 가서 타이밍 검증을 함
라우팅까지 하고 SPEF를 뽑을 수 있는데 이때 사용되는 툴 (star RC)
Backannotation : net에 대한 RC값
SPEF 파일 : Backannotation 고려된 파일
파일을 뽑고 PT에 넣어줌 (NET까지 고려) >> SDF 파일 -
Sign-off verification : 설계가 완료되었고 제조 과정에 들어가기 전에 필요한 여러 검증 단계 포함
검사 분야 : DRC, LVS, IRdrop(전압강하), EM, Cross-talk
ㄴ회사마다 다름
+IR drop(Voltage Drop Analysis)은 p전원 네트워크에서 발생하는 전압 강하를 분석합니다. 제조된 칩에서 각각의 소자가 동작할 때 전원 공급이 안정적으로 유지되는지 확인
+DRC (Design Rule Checking) 는 PCB 설계 / 레이아웃에서 간격 및 트레이스 폭과 같은 오류 및 불일치를 식별하는 데 사용되는 프로세스
+LVS (Layout vs. Schematic)는 회로 도면과 실제 레이아웃 간의 일치 여부를 확인합니다. 즉, 회로 도면에서 정의한 회로가 레이아웃에 정확하게 반영되어 있는지를 검증
+EM (Electromigration)은 전자의 이동에 따라 금속 선로에서 발생하는 현상으로, 금속이 이동하면서 소자의 신뢰성을 감소시킬 수 있습니다. EM 검증은 이러한 현상을 감지하고 방지하기 위한 설계 검증 단계
+Cross-Talk은 인접한 신호선 사이에서 발생하는 상호 간섭입니다. 인접한 회로나 신호선이 서로 영향을 미치는 것을 방지하기 위해 크로스토크 분석이 수행됩니다. 이는 신호의 왜곡이나 잘못된 동작을 방지하고 안정적인 성능을 유지하는 데 중요
Design Compiler - tool 사용
1.read_verilog ./lab_0_even_parity.v
2.compile
: DC 사용
//DC_shell gui로 키기
//코드(초록 글씨)
// GLN 회로도 생성
VCS - tool 사용
vcs -full64 -gui -R ./lab_0_even_parity.v ./testbench/lab_0_even_parity_tb.v
: VCS 사용 방법
//tb 코드 가져오기
//wave 보는 방법
//wave 확인하기
VCS Vivado testbench 차이
Vivado_TB에서 자동으로 변수명 연계를 해줬는데
VCS_TB에서는 직접 다 짜줘야 한다는 차이점이 있음.
verilog 작성 시 주의
-
Don't care
//if문에서는 dont care 사용 불가 -
If 문 우선순위
// 덮어쓰기 마지막은 C 출력으로 나타남
// Mux로 회로도를 나타내서 우선순위를 나타낼 수 있음
<> else if는 우선 순위가 위에가 가장 높음
-
case Expression 에서의 우선순위 >> if, if else문 변환에 따라 코드 순서 달라짐
왜냐면 우선순위가 case문에서는 위에서 부터 아래의 우선순위를 가지고 시뮬하기 때문
-
non-blocking
-
blocking & non-blocking in sequential logic
verilog에서 latch를 만드는 것을 권장하지 않음
(이유)
즉, latcㅗ를 피하는 것이 설계의 안정성과 예측 가능성을 향상시키며, 회로가 의도한 대로 동작할 수 있도록 보장함.
+그럼 latch의 기능을 사용할 때는 언제일까?
Latch vs FF
1. latch는 지속적으로 입력 변화에 따라 출력을 변경 / FF은 입력변경과 함께 클럭 펄스가 트리거될 때만 출력 변경
2. latch는 외부 클록 필요X / FF은 외부의 클럭 신호를 필요로 함.
3. latch는 비동기적 / FF 동기적 작동
4. latch는 FF에 비해 회로 분석이 매우 어려움
Full Case
: 모든 case가 다 있으면 그것은 Full case
Non-full case에 대해서 맞는 조건의 case없어 실행하지 못할 때 DC가 Latch가 생성됨
해결방법
full_case Directive로 DC에게 아래 코드로만 case로 되어있고 나머지는 없다는 것을 알려줌
(방법) //synopsys full_case : DC에서는 full_case Directive로 인식함.
하지만 VCS에서는 인식을 안함. 시뮬레이션에서는 synopsys에서는 주석처리가 됨
Parallel Case vs Non-Parallel Case
Non-Parallel Case : sel A,B,C에 1을 다 넣어줌. 즉, case item에 1이 2개이상에 들어간 상황 상황
해결방법
주석 사용 시 값이 무조건 1개만 들어가는 걸로 DC에 인식
but VCS에서는 인식을 못함
