SystemVerilog 검증 IDEC 강의 1일차 내용 요약

IDEC에서 SystemVerilog 강의를 올려놓았다.

그래서 해당 강의를 보려는데 10시간 가까이 되어서 천천히 보기에는 조금 오래 걸린다.

그래서 Open AI 사의 whisper AI로 동영상 강의의 자막을 따서 글로 읽으려 요약한 내용이다.

완전히 배경지식 없이 강의 내용을 받아쓴 내용이라 오탈자는 많지만 대충 알아들을 정도는 된다.

해당강의 내용이다.

https://www.idec.or.kr/vod/apply/view/?pay=&search_val=veril&no=328

반도체설계교육센터

 

그 골드 레벨을 이용해서 DUT라고 보통 하는데 내가 만든 설계된 부분을 이제 자동으로 확인할 수 있는 그런 방법이 필요합니다. 그래갖고 이 트랜잭션 레벨 모델링이 그래서 필요한 거고요.
그 다음에 이거랑 또 같이 쓸 수 있는 게 Assertion입니다. 그러니까 Assertion 같은 경우에는 소프트웨어를 쓰는 거니까 이거를 통해서 지금 현재 수행 중인 실행하고 있는 테스트 벤치의 결과가 정말 내가 원하는 대로 나오는 게 맞는지를 확인하는 자동으로 확인하는 그런 방법을 사용합니다.
그 다음에 마지막에 다룰 거는 커버리지 드리븐 베리피케이션인데 이거는 내가 이게 랜덤하게 입력을 생성을 해가지고 검증을 하다 보면 이게 테스트 케이스가 굉장히 많아져요.
많아지기는 하는데 내가 이 정도면 충분히 검증을 했나? 이거를 확인할 방법이 필요하죠. 다시 말하면 언제 이 검증을 멈춰야 되나? 이거를 확인할 수 있는 방법이 필요합니다.
그래서 허버리지라고 하는 거를 정의를 해서 허버리지가 예를 들어갖고 95% 이상이 되면 그러면 내가 충분히 검증했다고 생각하고 이제 이거는 검증은 이 정도면 끈대도 되겠다.
뭐 이런 것들을 이제 정량적인 근거를 통해서 판단을 할 수가 있는 거죠. 그래서 이런 것들이 방금 말씀드린 이런 개념들이 UVM에서 가장 핵심적인 개념이라고 말씀드릴 수가 있고요.
그래서 그런 것들을 다 다루게 될 거고. 그 다음에 근데 이제 UVM이라고 하는 거에 대해서 제가 많은 말을 들어갖고 자꾸 이렇게 말씀을 드리는 건데
UVM은 정확하게 그게 약자가 Universal Verification Methodology예요. 그러니까 Methodology예요. 이거는 방법론.
그렇기 때문에 이거는 개념이기 때문에 이거를 어떤 방식으로 구현을 할지는 사실은 그거는 구현의 이슈거든요.
그 UVM을 시스템 베릴로그로 구현해도 되지만 시스템 C를 써가지고 구현하기도 하고 제가 사실은 한 몇 년 전에는 시스템 C를 이용한 검증 방법론에 대해서도 강의를 했었거든요.
그랬는데 그걸 하다 보니까 사람들이 요즘 시스템 C는 별로 안 쓰고 시스템 베릴로그를 많이 쓰니까 시스템 베릴로그를 해달라고 해서 이걸로 바꾼 건데
근데 어쨌든 개념은 똑같아요. 똑같은 개념인데 그거를 구현하는 랭기지가 시스템 C냐 시스템 베릴로그냐 그 차이밖에 없는 거죠.
근데 또 UVM 같은 경우에는 UVM 클래스 라이브러리라고 하는 일종의 템플린 라이브러리를 제공을 합니다.
그래서 사람들이 UVM을 써서 검증을 했다라고 말을 하면 이런 베리피케이션 메소돌로지를 써서 검증을 했다는 의미로 쓰기도 하지만
시스템 베릴로그를 써서 검증을 했다는 의미로 쓰기도 하고 방금 말씀드린 UVM 클래스 라이브러리를 써가지고 검증했다는 뜻으로 쓰기도 해요.
그래서 이게 좀 사용하는 사람에 따라 컨텍스트에 따라 다른 의미를 가지고 있기 때문에 제가 그거를 좀 명확하게 하려고 지금 설명을 드리는 겁니다.
그래서 여러분들이 어쨌든 간에 여기서 배우는 거는 시스템 베릴로그의 문법을 배우기는 하지만
UVM의 핵심적인 개념들은 다 다룬다. 그거를 이제 말씀을 드리고 싶었던 거고요.
그래서 이번 강의에서는 그런 것들을 가르게 되겠고
그리고 그 다음에 조금 더 구체적인 계획은 간단하게만 말씀드리겠지만
오늘 오전에는 이제 그 검증 방법론에 대해서 여러 가지 방법론들을 그냥 일반적인 이론적인 것들에 대해서 한번 쭉 살펴보도록 하겠습니다.
그러니까 여기서는 제가 UVM에 대한 핵심적인 개념들을 말씀을 드린다고 했는데
UVM에 포함되어 있지 않은 다른 검증 방법론들이 수도 없이 많습니다.
이게 제가 옛날에 회사를 다닐 때까지만 해도 이게 벌써 한 15년 전이니까 옛날 얘기이긴 하지만
그때는 이런 검증 방법론이 일종의 춘추 전국 시대였어요.
그래서 굉장히 많은 방법론들이 나와서 이거라면 뭐가 좋다 뭐가 좋다 그러면서 서로 막 경쟁하던 때였는데
이게 한 10년쯤 지나니까 이 중에서 옥석이 가려져서 사람들이 정말 이거는 정말 효과가 있다.
이거 정말 괜찮은 방법론이다. 라고 인정을 받는 그런 방법론들만 어떻게 보면 살아남은 거예요.
그래서 그런 살아남은 방법론들을 하나로 모은 게 UVM이라고 생각을 하시면 됩니다.
특히나 제가 컨스트레인 랜덤 베리피케이션 같은 경우에는 제가 회사 다닐 때 많이 썼던 방법론인데
이거는 정말로 제가 개인적인 경험으로 정말 효과가 있는 그거라고 제가 말씀드릴 수가 있어요.
왜냐하면 제가 이제 담당했던 것 중에 제가 하드웨어 블럭을 설계를 한 다음에
이거를 검증을 해야 되니까 이거를 FPGA에 올려서 소프트웨어 개발팀에다가 전달을 해요.
그러면 소프트웨어 개발팀이 이걸 가지고 소프트웨어를 개발해서 돌려보고
혹시 문제가 생기면 저한테 다시 연락을 해가지고 이거 이렇게 좀 고쳐주세요. 이렇게 연락이 오거든요.
그러면 제가 처음에 넘길 때는 컨스트레인 랜덤으로 다 검증을 해가지고 넘겨요.
그때는 별로 문제가 생기지를 않아. 그랬는데 소프트웨어 쪽에서 해보다가 보니까
이런 게 좀 불편하니까 좀 고쳐주세요라고 요청이 와요.
그러면 제가 많이 고친 것도 아니고 조금 고친 거니까 살짝 고쳐서
또 컨스트레인 랜덤 다 돌리려면 귀찮으니까 그냥 보내.
그러면 이게 또 뭔가 버그가 생겨요.
그래갖고 이제는 고쳐달라고가 아니라 문제가 있다고 연락이 와.
그러면 이게 왜 안 되지? 라고 그때 가서 컨스트레인 랜덤을 돌려요.
그러면 여기서 얘가 버그를 칙사주더라고 걔가.
그러니까 제가 진작 돌렸으면 이거를 찾을 수 있었던 버그인데
안 돌려가지고 못 찾은 거예요.
그래갖고 제가 이번에는 그거를 수정을 해가지고
이제는 컨스트레인 랜덤을 다 돌려가지고 보내면
그때는 이제 그 버그로 인한 문제로 그런 것들을 피드백을 받은 적이 거의 없어요.
그러니까 저의 개인적인 경험으로 봐도
이게 컨스트레인 랜덤 베리피케이션이 굉장히 좋은 방법론이라고 말씀을 드릴 수가 있겠어요.
그런데 여기에 포함되지 않은 다른 종류의 검증 방법론들이 굉장히 많이 있습니다.
이게 아예 안 쓰이는 건 아니고 그냥 필요한 경우에만 쓰이는 것들도 있고
아니면 지금도 쓰이고 있기는 한데 좀 검증의 목적이 달라가지고
제한적인 영역에서만 쓰이는 그런 검증 방법론들도 있어요.
그래서 어쨌든 간에 이런 것들을 큰 그림에서 어떤 것들이 있는지를 좀 알아두시면 좋을 것 같아서
일단은 검증 방법론들에 대한 전체적인 개괄적인 설명을 오늘 오전에 하도록 하겠습니다.
그 다음에 오늘 오후부터는 이제 시스템 베릴로그의 문법들을
챕터별로 데이터 타입, 스테인먼트, 기본적인 OOP, 객체지향 언어
시스템 베릴로그도 객체지향 언어를 지원을 하거든요.
그런 것들에 대해서 한 챕터씩 하나씩 하나씩 해보도록 하겠습니다.
자 그래서 이게 전체적인 강의 계획이고요.
혹시 강의 계획이나 진행 상황 아니면 뭐가 됐든 수업에 관련해서 질문 있으신 분은 혹시 있으신가요?
온라인 혹시 온라인으로 참석하시는 분들도 질문 있으시면
채팅창에 남겨주시면 특별히 없으신 것 같으니까 일단은 지나가도록 하겠습니다.
그러면 아까 말씀드린 것처럼 오늘 오전 시간에는
전체적인 방법론에 대해서 강의를 하도록 하겠습니다.
그래서 이게 여기 같은 경우에는 이제 다양한 종류의 방법론들이 있어요.
그러니까 그런 것들이 뭐가 있는지에 대해서 설명을 드리도록 하겠고요.
제가 듣기에 배포가 됐다고 들었는데 혹시 안 받으셨나요? 아무도 안 받으셨나요?
네. 검증. 그런데 여기서 한 가지 용어를 명확하게 해야 될 게
이쪽 우리 하드웨어 설계 또는 반도체 설계 관점에서는
이 검증하고 테스트는 다른 의미로 쓰입니다.
검증, 베리피케이션하고 테스트.
그러니까 검증은 설계 관점에서
그러니까 베릴로그 또는 HDL 이런 거를 써가지고
기능을 설계를 한 게 정상적으로 동작하는지
그 기능 부분에 초점이 맞춰서 확인을 하는 거를 검증이라고 얘기를 하고요.
테스트는 제조가 끝난 다음에 이 제조된 칩이 실리콘이
내가 설계한 대로 구현이 제조가 됐는지
이거를 확인을 하는 거를 테스팅이라고 합니다.
이거 두 개가 어쨌든
그래서 이제 용어를 이렇게 분리를 해서 써요.
이 두 개는 아예 방법이 다르기 때문에
그런데 이 칩이 정상적으로 동작하는지를
확인하기 위한 목적인 거는 동일하지만
어느 부분을 확인을 하느냐
설계, 로직 이런 부분을 확인할 때는
검증, 물리적인 구현, 제조
이 부분을 확인할 때는 테스트라고 하는 용어를 씁니다.
그래서 우리가 지금 3일 동안 할 거는 검증입니다.
베리피케이션. 그래서 검증이고요.
그래서 이미 거의 한 20년 전, 한 15년 전부터
이 검증이 굉장히 큰 문제가 될 거다.
앞으로 이게 굉장히 이쪽 반도체 설계하는 분야에서는
굉장히 어려운 문제가 될 거다.
이거를 이렇게 예측을 했다는 그런 얘기고요.
이게 왜 검증이 어렵냐 하면
일단은 검증을 해야 될 게 너무 많아.
검증이라는 게 옛날에 그냥 반도체가 별로 복잡하지 않고
간단했을 때는 이게 확인을 해봐야 될 부분이 그렇게 많지는 않았어요.
그랬는데 이제는 이 반도체가
이 딥섬 미크론 같은 게 나오면서
요즘은 2나노, 4나노 이런 얘기도 하고 있는데
그러다 보니까 이게 공정의 집중도가 올라가면서
이게 칩 하나에 들어가는 기능이 굉장히 많아졌죠.
그래서 디자인 컴플렉스라고 말씀드린 게
하나의 칩 안에 옛날에는 간단한 로직 정도만 구현되어 있었다면
이제는 프로세서를 포함해가지고
아날로그 IP도 들어가고
뭐 클락 뭐 이런 여러 가지 복잡한 것들이 많이 들어갑니다.
그러다 보니까 이제 검증하기 어려워진 면이 좀 있고요.
근데 그거 외에도 여기서 말하는 건
펑셔널러티 얘기를 한 거였고
그 다음에는 여기서 검증을 해야 되는 게
기능, 내가 설계를 한 로직만 정상적으로
설계를 했다고 해서 칩이 돌아가는 게 아니에요.
왜냐하면 이 칩이 특히나 우리가 쓰는 현대에서 쓰는 칩들은
다 기본적으로 동기화된 싱크로노스 로직을 쓰잖아요.
클락에 의해가지고 동기가 된 회로를 쓰기 때문에
여기서 타이밍이 맞지 않으면
그러면 정상적으로 동작하질 않아요.
그러니까 검증을 우리가 설계할 때 검증을 해야 되는 부분이
기능적인 부분도 검증을 해야 되지만
타이밍이 정확하게 클락 시그널에 맞춰가지고
정상적으로 신호가 생성이 되는지
이 타이밍도 검증을 해줄 필요가 있습니다.
그래서 여기서 말하는 타이밍은 퍼포먼스랑은 조금 다른 게
타이밍은 이 클락에 맞춰가지고
그 클락의 한 클락 피어리어드 내에
필요한 모든 시그널들이 다 생성이 되느냐
이거를 확인을 해야 된다는 얘기고요.
퍼포먼스는 이 칩이 내가 원하는 만큼 빠르게 동작하느냐
뭐 이런 거를 얘기를 하는 거고요.
그 다음에 최근 들어갔고는 이제 모바일 디바이스가 나오면서
전력 소모가 굉장히 중요한 문제가 되기도 했고
그 다음에 인텔 프로세서나 이런 것도 여러분들이 아시겠지만
다 방열판이 붙잖아요.
그러니까 방열판이 붙는다는 얘기는
이 칩이 전력 소모가 굉장히 커가지고
이게 발열 문제가 생기기 시작했죠.
그러니까 발열 문제는 결국은 전력 소모랑 연관이 있는 거기 때문에
발열 문제를 줄이려면은 이제 그 전력 소모가 또 그래서 이제 중요해지기도 했습니다.
그래서 그 다음에 이제 물리적인 여러 가지
그 이제 딥선미크론으로 가면서
이제 뒤에 가서도 나오겠지만
뭐 크로스토기니 뭐 하여튼 여러 가지 이제
시그널 인테그레이티에 관련된 문제들이 생기기 시작했어요.
그러니까 이런 것들을 이제 다 검증을 해줘야 되는 거예요.
그러니까 얼마나 어렵겠어요.
시간도 많이 걸리고.
그래서 이게 검증이 굉장히 어려운 문제가 되었고
그 다음에 점점 더 어려워지고 있습니다.
특히나 요즘 나오는 최신 공정들 같은 경우에는
이게 우리가 지금 하고 있는 검증들은
이 물리적인 트랜지스터나 이런 소자들을
상위 수준에서 시뮬레이션 모델로 만들어가지고
그거를 이용을 해서 검증을 해요.
근데 최신 공정들 요즘 나오는 뭐 2나노 3나노 이런 공정들은
이 물리적인 현상을 시뮬레이션 모델로 만드는 것부터
어렵다고 하더라고요.
그래갖고 이제는 하여튼 검증이라는 게 굉장히 어려워지고 있어요.
그래서 뭐 말씀드린 대로 이런 여러 가지
그 다양한 성격을 갖는 이런
그 컴포넌트들이 하나의 칩 안에 다 들어오고 있어갖고
그래서 어렵다.
그래서 뭐 이게 이제 뭐 여러
그 하나의 회사에서 다 만드는 것도 아니고
뭐 CPU는 ARM에서 만들고
뭐 USB는 뭐 시납시스에서 만든 거 갖다 쓰고
이렇게 여러 회사 것들을 갖다 쓰다 보니까
뭐 회사마다 뭐 디자인 컨벤션도 다르고
뭐 여러 가지 것들이 다른 그런 것도 있고요.
그 다음에 IP의 종류도 뭐 RTL 같이
그냥 소스 코드 형태로 제공되는 것도 있고
아예 하드닝을 다 해가지고 뭐 GDS로 제공되는 것도 있고
뭐 이런 것도 다양하고
그 다음에 뭐 디지털만 있으면 또 괜찮은데
아날로그 IP 같은 경우가 있으면
이게 이제 아날로그는 이게 0V
그러니까 뭐 1V냐 1.1V냐 1.2V냐에 따라서
동작이 달라지는 애들이고
디지털 같은 경우에는 뭐 0안이 면 1이니까
뭐 이거는 뭐 코와 볼티지에 따라 다르지만
예를 들면은 0V냐 1.2V냐만 중요하지
그 사이에 뭐가 어떻게 되는지는 중요하지 않잖아요.
그러다 보니까 이 아날로그 IP랑
디지털 IP가 같이 있게 되면은
아날로그 IP가 디지털 IP에 의해서 영향을 많이 받습니다.
그래서 그런 영향들을 이렇게 차단할 수 있는 게 필요하고요.
그래서 어쨌든 이런 여러 가지 것들이
이제 하나의 칩 안에 들어오고
그거를 다 검증을 해줘야 되기 때문에
검증이 어려워지고 있습니다.
그 다음에 코스트의 입장에서 보면은
이게 그 블럭 레벨에서
작은 레벨에서 버그를 찾고
이거를 고치는 거는
상대적으로 비용도 적고
시간도 적게 들지만
이거를 이제 인테그레이션에서
모듈로 가고 시스템으로 가게 되면
여기서 말하는 시스템은
이제 소프트웨어까지 포함한 거예요.
뒷부분에 가가지고 버그를 발견을 하게 되면은
버그를 찾기도 어렵지만
수정하기도 어렵습니다.
뒤쪽으로 갈수록.
근데 제가 이 컨스트레인 랜덤
또는 UVM을 사용한 경험형으로 비춰보면
이쪽 블럭 레벨에서 사용하는 게 제일 효과적이에요.
사실은 컨스트레인 랜덤을 모듈 레벨이나
시스템 레벨에서도 쓸 수 있어요.
쓸 수는 있는데
그거를 하려면은
이게 예를 들어 시스템 레벨에서 내가
컨스트레인 랜덤 또는 UVM을 적용을 해야겠다라고 생각하면은
이 테스트 벤치를 만드는 시간과 노력이 너무 많이 들어가요.
너무 많이 들어가는데
제가 볼 때는 굳이 2단계 가서 할 필요는 없고
블럭 레벨에서 하면은
이게 그래도 간단하기 때문에
이 컨스트레인 랜덤을 적용한
그런 테스트 벤치를 만들기가 쉽고요.
그 다음에 2단계에서 컨스트레인 랜덤으로
철저하게 검증을 하고 나면은
뒷부분에 가서 검증을 해야 되는
그런 버그가 생길 가능성을 굉장히 많이 줄여줄 수가 있습니다.
그러니까 이 컨스트레인 랜덤을 쓰는
이 블럭 레벨에서 쓰는 게
제일 효과적이다.
이렇게 보시면 되겠습니다.
그 다음에 이제 이게 공정이 미세화가 되면서
이런 게 이제 점점 더 어려워졌다는 거고요.
공정이 미세화가 되니까 이제 타이밍 클로저
아까 말한 플락에 맞춰갖고
이 신호들이 정상적으로 생성되는지를 확인을 하는
이게 점점 더 어려워지고 있어요.
어려워지고 있고
왜냐하면 뒤에 가서 또 말씀을 드릴 거고요.
그 다음에 이제 집적도가 올라가니까
당연히 성능도 늘어나고
뭐 하여튼 그런 것들이 이슈가
성능이 아니라 그 뭐야
칩 안에 들어가는 기능들이 많아지니까
이제 검증하기가 어려워지는 그런 면도 좀 있습니다.
그래서 이렇게 딥섬 미크론으로 가면은
이런 것들이 이제 이슈가 됩니다.
그래서 이런 것들을 하나씩 살펴보겠습니다.
먼저 인터커넥트 이슈가 있는데요.
그거는 뭐냐면은
이제 딥섬 미크론이라는 말은
이제 공정이 점점 미세화가 된다는 얘기잖아요.
미세화가 된다는 얘기는
여기 있는 이제 피처 사이즈가
점점점점 준다는 얘기인데
여기서 말하는 피처 사이즈는 대부분
트랜지스터의 크기를 얘기를 해요.
그래서 트랜지스터의 크기는
뭐 옛날에 나오는 걸로 치면은
뭐 90나노에서
뭐 65나노, 45나노
이렇게 쭉 줄어들었어요.
근데 이 트랜지스터의 크기가
줄은 거에 비하면은
이 인터커넥트는 어찌됐든 간에
그 트랜지스터를 연결을 해줘야 되니까
트랜지스터의 크기가 줄어도
트랜지스터의 개수는 늘어나니까
이게 걔네들을 연결해주는
인터커넥트들의
뭐 전반적인 총 길이
예를 들면
그런 걸로 보면은
인터커넥트는 그렇게까지 줄지는 않더라는 거죠.
그러니까 여기서 말하는 인터커넥트는
트랜지스터들끼리 이렇게 연결해주는
와이어들을 얘기를 하는 건데
걔네들이 결국은 상대적으로 봤을 때
이런 인터커넥트들의 비중이
늘어나고 있다는 겁니다.
그래갖고 이게 옛날에는
검증을 한다고 그러면은
검증의 초점은
이 로직 쪽에 있었는데
그러니까 뭐 트랜지스터라던가
그 다음에 뭐 스탠다드 셀
이런 것들을 기능적인 부분을
굉장히 신경을 쓰고
여기서 소모되는 전력
뭐 이런 것들을 확인을 하는 거가
보통은 초점이었지만
이제는 인터커넥트의 비중이 점점 늘어나면서
인터커넥트 특히나 전력 소모가
최근에 나오는 칩들은
거의 뭐 한 반 정도는
칩마다 다르긴 하지만요.
그 한 반 정도는 인터커넥트에서 소모한다.
뭐 이렇게 레포트가 되기도 합니다.
그러니까 이런 그 인터커넥트가
이제 그 뭐 요즘은 더 비중이 늘어나고 있다.
이렇게 말씀드릴 수가 있어요.
그 다음에 이게 아까 말씀드렸던 것 중에 하나인데
아날로그 IP랑 디지털 IP가
같은 다이에 있게 되면은
디지털 IP 쪽에서 이렇게 스위칭을 하게 되면
그 스위칭한 영향이
아날로그 IP에 전달이 됩니다.
그래서 이게 일종의 노이즈라고 말할 수가 있는 거죠.
디지털 IP 때문에 노이즈가 생기는데
노이즈는 디지털 IP 자체는
그 노이즈에 그래도 좀 강건한 편인데
아날로그 IP는 영향을 많이 받기 때문에
이거 두 개를 하나의 칩 안에다 넣으면
이런 아날로그 IP들은
디지털 IP에 영향을 받지 않도록
이게 쉴딩 같은 것들을 잘 해줘야 됩니다.
그 다음에 크로스톡은
이제 이게 와이어가 이렇게 있으면은
신호를 전달하는 회선이 있으면은
이 와이어가 옛날에는
이게 공정이 미세화되지 않았을 때는
얘네들이 충분히 멀리 떨어져 있었어요.
그러니까 이 회선이
이 시그널이
이 시그널에 영향을 줄 일이 별로 없었는데
이제는 공정이 미세화가 되면서
얘네들이 이제 점점점점 크기가 줄어드니까
얘네들이 점점점점 가까워지는 거예요.
가까워지다 보니까 이제
뭐 예를 들면은 전자기 유도 현상
뭐 이런 것 때문에
이쪽에서 그 신호가 0101 바뀌는 게
얘한테도 영향을 주기 시작했어요.
그래서 이런 거를 이제 크로스톡이라고 얘기를 합니다.
그래서 이게
이게 이제 딥선미크론으로 가면서
점점 더
그 이런 것들이 문제가 되고 있고
그래서 이게 시그널 인테그레티에 영향을 주고 있습니다.
그 다음에 이제는
아까 이것도 이제 제가 2나노 3나노 얘기를 하면서
말씀드렸던 것 중에 하나인데
이거를 이제 물리적인
그 트랜지스터라든가 와이어를
그거를 이제 우리가 물리적으로 다 실험을 해볼 수는 없잖아요.
그러니까 이거를
상위 수준에서 모델링을 해가지고
시뮬레이션을 해야 되는데
이걸 어떻게 모델링을 하느냐
이것도 이제 중요한 그것 중에 하나입니다.
그러니까 모델링을 할 때
굉장히 자세하게 모델링을 하면
그러면은 이제
우리가 여러 가지 것들을
시뮬레이션을 통해서 확인해 볼 수가 있겠지만
이렇게 되면 속도가 너무 느려져요.
그러니까 여기서 우리가
꼭 필요한 부분만
이게 이렇게 간략화 해가지고
이런 식으로 좀
앱스트랙트를 할 필요가 있습니다.
그러니까 이렇게 자동차를 몽땅 다 모델링을 하는 게 아니라
우리가 필요한 거는
이런 언덕에서 이렇게 내려올 때
얘가 뭐 예를 들면은
위치와 속도가 어떻게 되는지
뭐 이 정도 수준으로만 알고 싶으면은
뭐 이런 식으로 간단하게 모델링을 할 수 있고
더 간단하게 하려고 그러면은
이렇게 모델링을 할 수가 있다는 겁니다.
그래서 이런 식으로 모델링을 하게 되면은
이제 우리가 원하는 거는
시뮬레이션을 해볼 수 있지만
시뮬레이션 속도를 빠르게 할 수 있다는 거죠.
그런데 문제는 이게
우리가 이런 시뮬레이션을
모델을 갖고 만들었는데
우리가 뭐 테스트를 하다 보니까요.
검증을 하다 보니까
약간 더 뭐 필요한 것들이 또 있어.
그러면은 이거를 다시 이렇게
모델링을 해야 되고
뭐 이런 것들이 왔다 갔다 하게 되는
그런 경우가 생길 수는 있습니다.
그다음에 이게 양산 가능성
이것도 이제는 중요해진 문제가
중요한 문제가 되기도 했습니다.
물론 이거는 이제 설계하는 사람이
뭐 이렇게 크게 걱정할 문제는
아닐 수도 있기는 한데
이게 소위 말하는
그거를 얘기를 하는 거예요.
일드
그 양산 수율
그래서 그게
이게 공정이 뭐
성숙 공정이다
공정이 안정화되어 있다라고 하면은
보통은 양산 수율이
충분히 높다라는 뜻이고
이제 새로 생긴
신생 공정들
뭐 그 뭐
이쪽 용어로 쓰면은
선단 공정들
선단 공정들 같은 경우에는
양산 수율이 높지가 않습니다.
그래서 이게 이제
뭐 사람이 이렇게 설계를 하다 보면
아무래도
특히나 이렇게
딥선미코로로 가면은
설계를 하는 당시에는
경험이 없으니까
잘 몰랐던
생각지도 못했던
여러 가지 물리적인 현상들이 생겨요.
그러니까 그런 것들을 고려를 못하고
일단은
공정을 만들었는데
여기서 이제 생각지도 못했던 문제가 생겨갖고
양산 수율이 뭐 10% 20%밖에 안 나오는 거예요.
그러니까 이렇게 되면은 이제
이거 가지고 칩을 만들어도
이게 이제 수익을 내기가 어려운 거죠.
그러면은 여기서 이제 그런 문제들을 찾아갖고
해결하는 과정을 반복하다 보면은
이 양산 수율이 이렇게 올라가게 됩니다.
근데 이것들은 뭐 사실은 이거는
공정 쪽에서 해결해줘야 되는 문제이기는 해요.
문제이기는 하지만
이게 가끔은 설계를 할 때
이런 것들을 고려해가지고 설계를 하면
좀 도움이 되는 면들이 있습니다.
예를 들면은
뭐 이렇게
그
이게
그
일종의 폴트 톨러런스
그런 기술을 적용을 해가지고
아니면은
비스트 같은 것들이 있어요. 비스트
비스트는
메모리 같은 경우에는 많이 쓰는데
예를 들면은 어떤 칩이 있는데
칩에
온칩 메모리가 있어요.
프로세서 같은 경우에는
뭐 캐시 같은 게 이제 온칩 메모리를 쓰겠죠.
그러면은 이 온칩 메모리가
원래는 내가 필요한 거는
예를 들면은 32킬로바이트인데
여기에 혹시 공정이 안정화가 안 돼가지고
또는 여러 가지 다른 이유로
이 메모리에 이제 물리적인 결함이 생길 수가 있을 거라는 거를
가정을 하고
여기다가 예를 들면은 한 4킬로바이트 정도의
일종의 스페어 리전을
메모리에다가 미리 설계를 해놓는 거예요.
그러면은 만약에 혹시나 이 칩이
메모리 쪽에 뭔가 물리적인 결함이 있다 그러면
만약에 이런 4킬로바이트짜리 스페어 리전이 없었으면은
그 칩은 그냥 버려야 되는 칩인데
이게 있으면은 그걸로 교체를 해가지고 쓰면 되니까
양산 수율이 올라가는데 도움이 되겠죠.
이 칩 버리는 것보다는
4킬로바이트 정도 조금 더
그 코스트를 들이면
이게 정상적으로 동작하는 칩을 얻을 확률이 더 올라가는
뭐 그런 것들이 있습니다.
그래서 이런 것들을 설계 단계에서
고려를 할 수 있으면 도움이 될 때가 있기 때문에
그래갖고 이제
요거에 이제
여기서 이제 우리가
우리는 지금 설계 입장에서
검증을 지금 얘기를 하고 있는데
요런 것들을 지금
뭐 말씀을 드리는 거고요.
그 다음에 똑같은 칩인데
뭐 멀쩡히 동작하는 칩인데
얘가 그 주변 환경에 따라가지고
또 이게 동작을 하기도 하고
하지도 않고
뭐 이런 경우가 생길 수가 있습니다.
그런 것들을 이제
Reliability라고 얘기를 하죠.
그래서 제일 대표적인 게
여기 나와 있는 것처럼
이걸 내가 알래스카에도 쓸 수 있고
텍사스에도 쓸 수 있을까라는 질문이에요.
다시 말하면은
칩은 온도의 영향을 많이 받아요.
그래갖고 보통의 경우에 있으면
이렇게 우리가 지금 있는
이런 룸 템퍼레이처라고 하죠.
이런 룸 템퍼레이처에서
보통은 이제
그 사용을 하게 되지만
예를 들면은
자동차에 들어가는 반도체다.
그러면은 자동차를 몰고
알래스카에도 갈 수도 있고
텍사스에도 갈 수도 있잖아요.
그런데 이게 거기서도
정상적으로 동작하느냐
뭐 요런 것들이 이제 문제가 될 수 있는 거죠.
그래서 이 칩을 만들 때
우리가 테스트를 할 때
이거는 이제 뭐 베리피케이션이라기보다는
테스트 이슈기는 합니다만
그런데 테스트 쪽에서 만약에 페일이 나면은
이게 또 설계에도 영향을 줄 수가 있으니까
그러니까 이제 요런 것들까지도 고려를 해서
설계를 해야 될 필요가 있을 때가 있습니다.
그 다음에 전력 소모도
뭐 큰 문제라고 말씀을 드렸죠.
이게 이제 뭐 모바일 같은 경우에는
배터리로 동작을 하니까
전력 소모가 중요하기도 하지만
또 여기서 이게 그림에도 나와 있는 것처럼
이제 그 전력 소모가
곧 발열 문제로 연결이 되기 때문에
전력 소모를 줄이는 게
이런 그 발열 문제
발열 문제가 생기면은
인텔 프로세서 같은 경우에는
칩이 너무 뜨거워지면은
그걸 자동으로 이렇게 성능을 낮춰주잖아요.
그러니까 이게 이제
발열 문제가 결국은 성능에도 영향을 주는
그런 상황이 되었습니다.
그래서 이렇게 검증해야 될 게 많고
뭐 생각해야 될 게 많다 보니까
검증이 점점 어려워지고 있어요.
그래서 이게 말하자면은
디자인 크라이시스라고 하는 그런 그래프인데
이거는 뭐냐면은
여기 빨간 그래프로 보시는 게
이게 이제 공정의 집적도가 올라가는
속도예요.
그래서 그 트랜지스터
그러니까 공정이
트랜지스터가 크기가 줄어들면서
트랜지스터의 개수가 늘어나는
그런 속도가 이렇게 빨리 올라가고 있지만
디자인 프로덕티비티는
그렇게까지 빠르게
늘어나고 있지 않다는 겁니다.
그러니까 그 트랜지스터가
늘어나는 속도에 비해 갖고
사람이 그거를 그럼 설계를 해줘야 되는데
사람이 코딩을 해가지고
설계를 하는 설계 생산성은
그만큼 따라가지고 있지 못하다.
그러니까 우리가 이렇게 빨리 증가하는
트랜지스터를 충분히 활용을 못하고 있다는 얘기죠.
그런데 이거보다 더 심각한 거는
검증 생산성은 이렇게 떨어진다는 거예요.
이게 설계는 그나마 이렇게 좀 따라가는데
이거 설계를 해놓으면 뭐해.
이거를 검증을 해야 되는데
검증하기가 너무 어렵다 보니까
검증의 생산성은 설계 생산성조차도 따라가지 못하는
그런 어려운 문제가 있다는 겁니다.
그래서 이제 뭐 UVM이니 뭐 이런 것들이 나오면서
이런 것들을 좀 해결해 보려는
그런 노력들을 하고 있습니다.
그래서 이런 검증할 수 있는 방법론들을
조금 구분을 해보면
이렇게 구분을 해볼 수가 있습니다.
그래서 이것들도 이제 하나씩 좀 살펴보도록 할게요.
처음에 나오는 거는 시뮬레이션 기반의
그 검증 방법론입니다.
그게 이제 뭐 베리로그 같이 우리가 코딩을 하고 나면
시뮬레이션 돌리잖아요.
제가 여태까지 쭉 얘기를 했던 것들이 결국은
그 물리적인 그런 실리콘의 물리적인 현상을
시뮬레이션 모델로 만든다 뭐 이런 말씀을 드렸는데
그건 결국은 시뮬레이션을 이용을 해서
검증을 하겠다는 뜻이죠.
그러니까 이게 사실은 제일 많이 쓰이는 방법이고요.
그래서 시뮬레이션 방법을 이용한 방법이 있고
스태틱 테크놀로지는 뭐냐면
이거는 실제로 이걸 수행을 해보는 게 아니라
그냥 소스 코드만 보고 소스 코드를 분석해서
얘가 정상적으로 어떤 문제가 없는지
뭐 이런 것들을 확인을 하는 겁니다.
그러니까 이게 스태틱한 방법만 가지고
검증을 할 수도 없고 모든 것들을
시뮬레이션만 가지고 모든 것을 검증할 수도 없고
그래갖고 이런 것들을 다 조합해가지고
내가 검증 또는 설계하는 목적에 따라 갖고
잘 활용을 해 줄 필요가 있습니다.
그래갖고 제가 이렇게 큰 그림에서
어떤 검증 방법분들이 있는지를 설명을 드리겠다고 한 게
여러분들이 만약에 혹시나 이쪽 분야에서
일을 하신다면 이제 목적에 따라 필요에 따라
필요한 검증 방법들을 선택을 해서
또는 걔네들을 조합을 해가지고 사용하실 필요가 있어갖고
어떤 것들이 있는지 그것들은 좀 알아 놓으시면
도움이 될 것 같습니다.
그 다음에 물리적인 현상들을 검증하는
그런 방법은 또 따로 있고요.
그러니까 우리가 설계 로직, 기능적인 관점에서
검증을 하는 거와는 또 이렇게 물리적인 현상을
검증하는 거는 좀 완전히 다른 얘기이기 때문에
이쪽은 또 별도의 방법론과 툴이 있습니다.
그 다음에 포멀 테크놀로지는 뭐냐면
이게 수학적인 모델을 이용을 해가지고 말하자면
일종의 증명을 하는 거예요.
그러니까 이 칩이 정상적으로 내가 설계를 한
이 기능이 정상적으로 동작하는지를 확인을 하는데
시뮬레이션을 통해서 확인을 하게 되면
내가 만든 시뮬레이션 벡터들
그러니까 검증 시나리오들에 대해서는 검증을 하지만
컨스트레인 랜덤을 쓰게 되면
그 시나리오가 조금 더 많아지기는 하지만
이게 정말로 완벽하게
그 설계가 정확하다는 거를
완벽하다고는 말할 수가 없잖아요.
그러니까 99%는 될 수 있을지언정
100%라고는 말할 수가 없기 때문에
근데 물론 대부분의 경우에는
그 정도면 충분한데
문제는 미션 크리티컬한 시스템들이 있어요.
0.001의 확률로라도
혹시나 이 칩이 정상적으로 동작하지 않으면
굉장히 큰 문제가 생길 수 있는
그런데 사용되는 칩들이 있다는 거죠.
그래서 예를 들면 요즘
자율주행 자동차 이런 게 나오기 시작했으니까
그런데 쓰이는 칩들 같은 경우에는
혹시나 문제가 생길 때 사고가 나면서
인명피해가 생길 수도 있는 거잖아요.
그러니까 이런 것들은
이 칩이 정상적으로 동작하지 않았을 때
생길 수 있는 피해가 굉장히 심각한
그런 종류의 칩에는
얘를 굉장히 철저하게 검증할 필요가 있습니다.
그럴 때는 이런 수학적인 모델을 써가지고
증명을 하는 방식으로 해서
이거를 확실하게 검증할 수 있는
그런 방법론을 사용을 합니다.
그런데 대신에 이런 것들은 아직까지는
복잡한 칩에는 적용하기가 좀 어려워요.
그래서 그렇기 때문에
제가 아까 말씀드린 대로
이게 칩의 종류에 따라
목적에 따라
그다음에 요구사항에 따라서
이런 것들을 적절한 검증 방법론을
사용을 할 필요가 있습니다.
그래서 우리가 지금
요 3일 동안에 배울 거는
이 시뮬레이션 기반의
시스템 베를로그 또는 컨스트레인 랜덤을
쓴다는 얘기는 결국은 시뮬레이터로 쓴다는 얘기이기 때문에
요 방법론을 집중적으로 배우기는 할 거지만
왜냐하면 이게 제일 많이 쓰이는 거고
근데 요런 것들도 어쨌든
알아놓으실 필요는 있다는 겁니다.
시뮬레이션 방법만 해도
이렇게 다양한 방법들이 있습니다.
이벤트 드리븐 시뮬레이터가
실질적으로 제일 많이 쓰이는 시뮬레이터입니다.
베를로그 시뮬레이터도
이벤트 드리븐 시뮬레이터이고요.
이벤트 드리븐 시뮬레이터랑
사이클 베이스 시뮬레이터가 있는데
요거 두 개의 가장 큰 차이점은 뭐냐면
우리가 사용하고 있는 하드웨어는 대부분이 다
싱크로노스 로직이라고 말씀을 드렸어요.
클락에 의해 갖고 동기가 되는
그런 회로들이기 때문에
이 회로는 기본적으로
매 클락마다 동작을 해요.
클락과 클락 사이에서도 물론
이런 컴비네이션 로직들이 동작을 하지만
실질적으로 기능의 입장에서 봤을 때는
측면에서 봤을 때는
클락의 엣지에서 뭔가 중요한
그런 기능의 변화가 생기는 거죠.
그렇기 때문에 사이클 베이스 시뮬레이션은
매 클락마다 이 현재 회로의 상태를
시뮬레이션을 합니다.
그런데 이벤트 드리븐 시뮬레이션 같은 경우에는
기본적으로 어떤 컴비네이션 로직을
보통은 시뮬레이션을 할 때는 보면
회로가 이렇게 여러 개의 게이트로 이루어진 회로가 있다 그러면
실질적으로 여기서 입력이 변하는 거는
모든 입력이 한꺼번에 동시에 변하는 경우는
별로 없더라 라고 하는 게
일종의 관찰이라고 말씀드릴 수가 있어요.
그러면 이 중에서 일부의 입력만 변하면
변하는 입력에 의해 갖고 영향을 받는 회로들만
시뮬레이션을 다시 해주면 되지
이거에 의해 갖고 영향을 받지 않는 회로들 같은 경우에는
어차피 얘네들은 똑같은 출력을 내보낼 건데
굳이 이거를 다시 시뮬레이션을 해줄 필요가 있느냐라고 해가지고
시뮬레이션한 방법이 이벤트 드리븐 시뮬레이션이에요.
그러니까 여기서 말하는 이벤트라고 하는 게
어떤 입력의 변화를 이벤트라고 보시면 되겠습니다.
그래서 이벤트가 발생을 했을 때 그 이벤트에 의해 갖고
영향을 받는 회로들만 다시 시뮬레이션을 해주는
그런 방식이 이벤트 드리븐 시뮬레이터입니다.
그렇기 때문에 우리가 베릴로그를 쓰다 보면
베릴로그에 센서티비티 리스트를 등록을 하잖아요.
그 센서티비티 리스트라고 하는 게
결국은 그 이벤트 드리븐 시뮬레이션을 위해서 있는 겁니다.
그러니까 이 센서티비티 리스트에 들어가 있는 이벤트가 발생을 하면
그 always라고 하면 always 그 블럭 안에 들어있는 것들을
다시 시뮬레이션을 해라 라고 시뮬레이션 시뮬레이터한테 알려주는
그런 역할을 하는 거죠.
그래서 이런 것들이 대표적인 이벤트 드리븐 시뮬레이터가 되겠고요.
그러면 이벤트 드리븐 시뮬레이터가 빠를까요?
사이클 베이스드 시뮬레이터가 빠를까요?
이거는 사실 그때그때 다르기는 한데
이게 회로에 따라서 다르긴 합니다.
그런데 우리가 싱크로노스 로직을
우리가 시뮬레이션을 할 때는
일반적으로 사이클 베이스 시뮬레이터가 조금 더 빠르기는 합니다.
그런데 이거는 싱글 클락 도메인에서는
사이클 베이스 시뮬레이터를 쓸 수가 있는데
이게 또 멀티 도메인 칩 같은 경우에는
하나의 칩 안에 다른 클락을 사용하는 모듈들이 섞여 있게 되면
또 사이클 베이스 시뮬레이션을 쓰기가 어려워요.
그때는 어쩔 수 없이 이벤트 드리븐 시뮬레이터를 써야 되는
그런 또 상황이 있을 수가 있습니다.
그래서 이게 이제 대표적인 시뮬레이션 기술들이고요.
그 다음에는 래피드 프로토타입 또는 에뮬레이션 같은 게 있어요.
그 다음에 시뮬레이션의 속도를 높이기 위한 방법들이 있고
이 세 가지 방법들은 여전히 시뮬레이션 방법들이기는 하지만
이제 칩이 너무 커지고 기능이 복잡해지다 보니까
시뮬레이션 속도가 이제 너무 느린 거예요.
사이클 베이스 시뮬레이션을 써도 느리고
이벤트 드리븐 시뮬레이션을 써도 느리고
뭐 옛날 얘기긴 하지만 제가 회사에 있을 때
그때 당시에 저희 부서에서 만들었던 칩이
이 핸드폰에 들어가는 베이스밴드 모뎀 칩이었어요.
그 베이스밴드 모뎀 칩을 하나를 설계를 한 다음에
얘를 풀 시스템 시뮬레이션
그러니까 이 칩에 있는 모든 기능들을 다 시뮬레이션을 했을 때
실시간으로 실제 이 칩에서는 실제로 돌리면
25 밀리세컨드 걸리는 일을 시뮬레이션을 하면
한 일주일 정도 걸렸어요.
그러니까 너무 느린 거죠.
25 밀리세컨드 시뮬레이션을 하기 위해서 일주일이 걸려.
그러면 사실상 그거는 시뮬레이션을 통해서 검증을 해보는 게
거의 불가능한 정도 수준입니다.
그렇기 때문에 이제 이거를 속도를 높이기 위해서 사용하는 방법들이
이제 요한 세 가지 방법이 있다고 보시면 돼요.
먼저 래피드 프로토타이핑 같은 경우에는
쉽게 말해서 FPGA 같은 거를 말씀을 드리는 겁니다.
그러니까 프로그래머블 한 하드웨어를 이용을 해가지고
뭐 ASIC으로 구현을 하지는 못했지만
FPGA에다가 구현을 해서 FPGA 정도 되면은
ASIC만큼 빠르게는 못 돌려도
그래도 시뮬레이션보다는 빠르고
그 다음에 여기다가 이 정도 수준의 속도면은
소프트웨어 정도는 올려볼 수 있어요.
그래갖고 이게 어쨌든 ASIC만큼 빠르지는 못하지만
어쨌든 그 시뮬레이터보다는 훨씬 빠르니까
이 래피드 프로토타이핑을 써가지고 검증을 해볼 수가 있습니다.
에뮬레이션은 뭐냐면은 우리가 시뮬레이터를 돌리면
시뮬레이터는 보통 인텔 프로세서 같은
일반적인 CPU 위에서 수행되는 소프트웨어예요.
그런데 그러다 보니까 느린 거예요.
그런데 에뮬레이션 시스템 같은 경우에는
이 하드웨어 시뮬레이션을 하기 위한
전용 하드웨어를 만든 거예요.
그래서 여기 같은 경우에는
이 시뮬레이터는 범용 CPU
제너럴 퍼포즈 CPU에서 돌아가는 소프트웨어잖아요.
그런데 에뮬레이터는
이 에뮬레이션 장비에서는
얘는 전용 기기예요.
그래서 이 에뮬레이터는
베를로그 시뮬레이션밖에 못하는 거예요.
대신에 베를로그 시뮬레이션은
엄청나게 빠르게 할 수 있는
뭐 그런 거죠.
GPU 같은 거라고 생각하시면 돼요.
GPU.
GPU에서 물론 요즘은 GPU가
여러 가지 기능들을 할 수 있도록
프로그래머블하게 나오지만
뭐 이거는 어쨌든 간에
원래 취지는
그래픽 프로세싱하는 알고리즘을
여기서 수행하기 위한 거잖아요.
그래서 원래 GPU가 그런 거였잖아요.
원래는.
요즘은 뭐 다른 용도로 많이 쓰지만
그거랑 마찬가지로
이 에뮬레이터 같은 경우에는
베를로그 시뮬레이션만을 위한 전용 기기예요.
그래서 여기는
베를로그 시뮬레이션은
엄청나게 빨리 돼요.
그 다음에 이 래피트 프로토타입
FPGA랑 다른 점은 뭐냐면
FPGA는 빨리 수행을 해볼 수 있지만
우리가 베를로그 시뮬레이터에서
나오는 웨이브 폼 같은 거는
볼 수가 없어요.
그러니까 이 하드웨어 내부에 있는
내부 시그널들을 찍어볼 방법은 없어요.
래피드 프로토타이핑을 하게 되면
그러니까 FPGA를 쓰게 되면
그렇지만 에뮬레이터에서는 그게 돼요.
그러니까 기본적으로 우리가
베를로그 시뮬레이션을 하는 데 사용할 수
하는 데서 얻을 수 있는 정보는
여기서 다 얻을 수 있어요.
그래서 에뮬레이션이
시뮬레이터에 비해서 훨씬 빠르고
시뮬레이터에서 제공되는
그런 여러 가지 웨이브 폼 같은
그런 정보들도 다 제공하고 하기 때문에
굉장히 사용하기 편합니다.
대신에 엄청나게 비쌉니다.
왜냐하면 이거는 전용 기기이기 때문에
하드웨어 시뮬레이션만 할 수 있어갖고
사실 이게 범용적으로 쓰이지는 않다 보니까
시장 규모가 그렇게 크지 않아서 그런지
아니면 이거를 만드는 게 어려워서 그런지
이 장비는 상당히 고가의 장비입니다.
그다음에는 이거를 시뮬레이션 모델을
조금 개선을 해가지고
시뮬레이션 속도를 높이는 방법들이 있습니다.
아까 제가 퍼스트 오더
이거를 보여드렸잖아요.
그러니까 우리가 일반적으로
베릴로그 시뮬레이션을 할 때
사용하는 모델은 예를 들면
한 이 정도 수준인 거예요.
그런데 이 시뮬레이터
내가 시뮬레이션하는 칩의 어떤 부분에 대해서는
내가 지금 현재 하고 있는 시뮬레이션의 목적에서는
그게 굳이 자세하게 모델링이 될 필요가 없는 거예요.
그러면 이거를 별로 내가 관심이 없는 부분은
이걸로 바꾸는 거죠.
그러면 그 부분은 시뮬레이션 속도를
이렇게 해서 빠르게 할 수가 있습니다.
그래서 그게 제일 대표적인 것들이 이런 게 있어요.
버스 펑셔널 모델
인스트럭션셋 시뮬레이터
이런 것들이 있는 겁니다.
예를 들면 인스트럭션셋 시뮬레이터 같은 경우에는
프로세서인 거예요.
그러니까 예를 들어갖고 내가
어떤 시스템이 있는데
그 시스템에 보통은 프로세서가 들어가잖아요.
프로세서가 들어가고
나는 내가 개발한 거는
그 프로세서가 사용하는 일종의
하나의 페리페러를 하나 만든 거예요.
예를 들면 내가 USB를 만들었어요.
그러면 나의 입장에서는
USB를 검증하는 게 목적이에요.
프로세서를 검증하는 게 아니고
그다음에 이 시뮬레이션을 통해서
나한테 필요한 입력은
저 프로세서가 어떤 명령어를 수행해서 나온 결과
그런데 그 결과 중에서도
USB 쪽으로 오는 어떤 명령
또는 데이터
이런 것들이 중요한 거지
프로세서가 내부에서 어떻게 돌아가는지는
나한테는 전혀 중요한 게 아닌 거죠.
그러니까 이런 경우에는
이 프로세서를 내부에 있는 시그널까지
다 디테일하게 시뮬레이션을 할 필요가 없고
이거를 인스트럭션셋 시뮬레이터로 바꾸는 겁니다.
그러면 이 인스트럭션셋 시뮬레이터는
이 프로세서 내부에 있는 시그널들을
하드웨어 시그널 단위로 다 시뮬레이션을 해주는 게 아니고
얘는 그냥 소프트웨어의 인스트럭션을 하나하나 실행을 시켜서
거기서 나오는 결과물들만
그러니까 말하자면 하드웨어 쪽으로 나오는 시그널들만
정확하게 모델링을 해놓은 거예요.
그러니까 이거 같은 경우에는
이거를 쓰게 되면
그러니까 이런 내가 USB를 검증한다는 목적에만 사용할 때는
내가 프로세서의 내부를 알고 싶지 않을 때는
그럴 때는 이걸로 시뮬레이션을 하면
시뮬레이션 속도를 높일 수가 있겠죠.
그거랑 비슷하게 이 버스 펑셔널 모델은
버스에 대해서도 이거랑 유사한 걸 할 수가 있어요.
그러니까 보통은 프로세서를 사용하게 되면
그 프로세서의 프로세서가 사용하는
시스템 버스 규격이 있잖아요.
내가 암을 쓰면 암에서 나오는 APB, AXI 이런
암밥 프로토콜이 있고
아니면 내가 다른 프로세서를 쓰게 되면
그 프로세서에 맞는 위시본이라든가
소닉스라든가 여러 가지 시스템 버스 표준들이 있잖아요.
그런 표준들이 있어요.
그런데 여기서도 마찬가지로
나는 USB를 검증하고 싶은데
거기서 이 시스템 버스의 시그널들이 뭐가 있고
시스템 버스도 얘네들을 구성하고 있는 컴포넌트들이 있으니까
걔네들이 어떻게 동작하는지는 별로 관심이 없는 거예요.
나는 그냥 그 버스에서 오는 명령, 데이터 이런 것들만 알면 되는 거죠.
나의 입장에서는.
그럴 때는 이 버스도 버스 펑셔널 모델로 바꾸면 된다는 겁니다.
그다음에 C 같은 경우에는 이거는 나는 USB를 만들었는데
이 USB가 예를 들면 옆에 있는 다른 메모리 컨트롤러랑
아니면 DMA 이런 거랑 같이 동작을 하는 거예요.
그러니까 이런 것도 시뮬레이션을 통해서
잘 동작하는지 검증을 해볼 필요가 있어요.
그런데 나는 USB를 검증하면 되는 거기 때문에
저기 있는 저 DMA가 어떻게 동작하는지는 별로 관심이 없어요.
그러면 저 DMA를 DMA 내부 시그널까지
다 베리로그로 디테일하게 모델링을 한 거를 쓰지 않고
이거를 상위 수준에서 C 같은 걸로 모델링한 거를 쓰겠다는 거예요.
그래서 이게 트랜잭션 레벨 모델링이라고 얘기를 합니다.
그래서 제가 아까 그 강의 계획을 설명을 하면서
트랜잭션 레벨 모델 이런 것들이 있다고 말씀드렸는데
이게 결국은 어떤 IP나 어떤 하드웨어를
이게 사실은 인스트럭션 세트 시뮬레이터나 버스 펑셔널 모델이
다 트랜잭션 레벨 모델의 일조기과로 보시면 돼요.
그러니까 하드웨어가 있을 때 그 하드웨어를
베리로그 수준에서 디테일하게 모델링을 한 게 아니라
얘를 상위 수준으로 끌어올려갖고
디테일한 거를 필요 없는 것들을 숨기는
내가 원하는 중요한 기능만 모델링을 하는 거를
트랜잭션 레벨 모델링이라고 합니다.
그런데 트랜잭션 레벨 모델링을 할 때
C 같은 이런 소프트웨어 랭기지를 쓰기도 하고요.
아니면 C++나 시스템 C
아니면 심지어 시스템 베리로그를 이용을 해서도
어쨌든 이 상위 수준 모델링이 가능합니다.
그래서 그런 것들이 이제 시뮬레이션 속도를 높이기 위한 방법들이 있습니다.
그리고 이 밑에 있는 것들은 이 두 가지
이거는 이제 검증에 쓰이는 시뮬레이션 방법인데
이 커버리지 드리븐 베리피케이션은 아까 제가
강의 계획 설명할 때 간단하게 말씀을 드렸어요.
어섹션 베이스도 그렇고 그리고 이거 두 개는 어차피
이제 우리가 강의 시간에 할 거니까
이거는 넘어가도록 하겠고요.
그 다음에 코 시뮬레이션이 있어요.
코 시뮬레이션도 크게 두 가지가 있는데
하드웨어랑 소프트웨어를 같이 시뮬레이션을 한다는 의미에서의
코 시뮬레이션이 있고
아날로그랑 디지털을 같이 시뮬레이션을 한다는 의미에서의
또 코 시뮬레이션이 있어요.
그래서 이거 두 개는 서로 다른 종류의 시뮬레이터를
같이 붙여갖고 쓰는 그런 상황을 얘기를 하는 겁니다.
그러니까 하드웨어 시뮬레이션은 보통은 베리로그 같은 거를 쓰고
소프트웨어 시뮬레이션은 아까 말씀드렸던
인스트럭션셋 시뮬레이터 이런 거를 쓰니까
이거를 서로 다른 시뮬레이터를 쓰게 되는 경우들이 생기는데
그러면 얘네들을 같이 연결해서 쓰는
그런 시뮬레이션 기술을 얘기를 하는 거고요.
아날로그 디지털 시뮬레이션도 마찬가지입니다.
그러니까 아날로그 시뮬레이션을 하는 거는
보통은 P-spice라는 것과 H-spice 같은
그런 아날로그 시뮬레이션 하는 툴이 별도로 있고
베리로그 같은 그런 디지털 로직을 시뮬레이션 하는 툴은
또 따로 있잖아요.
얘네들을 이렇게 연결해서 쓰는
그런 것들을 얘기를 하는 거죠.
그래서 이런 시뮬레이션 검증을 위해서 사용되는
시뮬레이션 방법론들이 이렇게 다양한 것들이 있습니다.
그래서 이벤트 드리브 사이클 베이스 시뮬레이션 이거는 다
설명을 드렸고요.
그래서 이것도 앱 스테이션 레벨에 따라갖고
여기서 말하는 스파이스가
보통은 아날로그 IP 시뮬레이션 하는 데 쓰는데
디지털 IP도 어떻게 보면 아날로그의 일정이니까
그것에 사용하는 시뮬레이션 하는 데 쓸 수 있습니다.
그래서 이게 이제 어쨌든 점점 사이즈가 커지면서
시뮬레이션 해야 될 게 굉장히 많아져가지고
시뮬레이션 속도가 굉장히 문제가 되고 있다라는 말씀이고요.
그래서 쓸 수 있는 게 이제 이런 래피드 프로토타입
아까 말씀드렸던 FPGA 같은 게 대표적인 거고
그런 것들을 사용을 합니다.
그 다음에 시뮬레이션 속도를 높이기 위한
버스 펑셔널 모델, 인스트럭션 세트 시뮬레이션
뭐 이런 것들을 다 말씀을 드렸고요.
그 다음에 테스트 벤치 같은 경우에는
우리가 결국 이번 강의에서 제가
시스템 베를로그 중에서 검증에 관련된
그런 문법들 위주로 제가 설명을 드린다고 말씀을 드렸는데
그러니까 검증에 필요한 문법이라는 거는
결국은 테스트 벤치를 만드는 데 필요한 문법이라는
그런 얘기라고 이해를 하시면 됩니다.
이거는 거꾸로 말하면은
설계하는 데는 쓰기가 좀 어려운 문법들이 있어요.
모든 게 다 그런 거는 아닌데
설계를 한다는 얘기는
나중에 결국은 합성을 해가지고
개인 레벨로 만든다는 얘기인데
보통은 베를로그에도 그런 용어가 있잖아요.
Synthesizable Subset
그러니까 베를로그에서도 여러 가지 문법들을
시멘틱을 지원을 하는데
그중에서 하드웨어로 나중에 결국은
합성이 가능한 그런 시멘틱이 있어요.
근데 그 하드웨어로 합성 가능한 시멘틱을 제외한 부분
그런 것들이 다 이제 보통은
테스트 벤치를 만들기 위해서 사용되는
그런 시멘틱인 거죠.
그래서 이번 강의에서는
SystemBerylog에서
그런 테스트 벤치를 만들기 위해 사용되는
시멘틱 또는 신텍스를
이렇게 설명을 드린다고 보시면 될 것 같아요.
그래서 결국은 검증을 위해서 우리가 하는 일은
테스트 벤치를 만드는 거를
이제 하게 되는
그런 거라고 보시면 되겠습니다.
그래서 여기서 나오는 게 이제
어떤 Stimulus Generator
이게 결국은 Constraint Random
Verification이라고 말씀을 드릴 수가 있고
그 다음에 이거를 자동으로 확인할 필요가 있다고 말씀을 드렸죠.
그래서 자동으로 확인하는 방법은
Transition Level 같은 일종의 골든 모델을 만들어서
개랑 결과를 비교를 하거나
Assertion을 쓰거나
뭐 이런 것들을 할 수가 있습니다.
물론 이거는 이제 자동으로 할 때 얘기고
사람이 할 때는 보통은 이제 웨이브 폼 같은 거를 쓰죠.
그래갖고 이게 웨이브 폼을 보고
사람이 눈으로 보고 판단을 하는 거를
보통은 사용을 합니다.
Covered Reality Driven Verification은 이제
아까 말씀드린 것처럼
내가 이 정도면 충분히 검증을 했나?
라고 하는 거를 확인을 하는 데 사용되는
그런 방법론입니다.
그래갖고 요거를 이제
요것도 이제 우리가 수업 시간에 다룰 거예요.
그러니까 요거는 그냥 요 정도로만 하고 넘어가겠습니다.
자, 여태까지가 이제 시뮬레이션에 관련된 내용이었어요.
그 다음에는 그 Static
이거는 시뮬레이션을 돌려보지 않고
코드만 보고 검증을 하는 겁니다.
그러니까 여기 같은 경우에는
모든 것을 다 검증할 수는 없고
이제 필요한 부분만 검증을 하는 거예요.
그러니까 기능적인 부분을 검증하는 데 쓰이기도 하는데
그거는 이제 뒤에서 얘기할
포멀 verification에 더 가깝고
여기서는 주로 이런 것들을 합니다.
먼저 나오는 거는
Lint 또는 뭐 Inspection이라고도 하는 건데
이거는 뭐냐면은
이게 이제 주로 쓰이는 거는
이 디자인 룰 체크
DRC라고 하죠.
거기에 많이 사용이 됩니다.
그러니까 이거는
기능적인 부분이라기보다는
어떤 코딩 스타일
같은 거를 확인을 해준다던가
아니면은 이게 결국은 나중에
합성을 해가지고
어떤 그 레이아웃까지 했다고 했을 때
거기서 뭔가 나중에 물리적으로 생길 수 있는
문제를 막기 위해서
이 설계를 하는 단계에서
뭔가 해줘야 되는 것들이 있는 경우들이 있어요.
예를 들면은
그 어떤 공정에서는
어떤 공정에서는
클락 게이팅이 지원이 안 되는 공정이 있을 수가 있어요.
그런데 그거 같은 경우에는
클락 게이팅 말고 그러면
뭐
예를 들면은 뭐 래치 같은 거를 쓰면 안 된다던가
뭐 이런 식으로 공정에 따라서
그런 것들을 이제 코딩 스타일이 안 맞는
그런 이제 뭐 공정 같은 게 있을 수가 있다는 거죠.
그래서 그런 경우에는
이거를 RTL에서
그런 것들을 확인해주는
그런 툴이 있습니다.
그래서 이거 같은 경우에는
시뮬레이션을 굳이 돌려보지 않아도
RTL 코드만 보고
이게 나중에 합성이 돼서
레이아웃이 끝나고 난 다음에
혹시나 공정에 가가지고
문제가 생기는 거를
이 코드 단계에서
이제 걸러주는
그런 것들을 자동으로 해주는 툴들이 있어요.
그래서 보통은 이제
그런 데에 많이 쓰입니다.
그래서 뭐 이런 것들이
아까 말씀드린
DRC, RTL, DRC 같은 것들이 그런 거고요.
그 다음에는
뭐 합성을 하기 전 단계에서
프리 프로세싱을 하는 것도 있고
그 다음에
여기서는 그러니까 기능적인 부분을 검증한다기보다는
이게 다 결국은 DRC라고
DRC의 일종이다 이렇게 말할 수가 있는데
어떤 회사 같은 데서
어떤 조직에서
코딩 스타일을 통일을 해놓는
그런 경우들이 있어요.
제가 옛날에 있었던 삼성 같은 경우에는
예를 들면 뭐 이런 것들이 있었어요.
어떤 모듈을
여기서는 이제
그러니까 말하자면
그거는 그 회사만의 규칙인 거예요.
그러니까 예를 들면
저희 부서 같은 경우는
이런 규칙들이 있었어요.
하나의 베릴로그 파일에는
하나의 모듈만 정의를 해요.
하나의 파일 안에
여러 개의 모듈이 들어가 있지 않아.
하나의 파일에는 하나의 모듈
그리고 그 파일 이름은
그 모듈의 이름하고 동일해.
그 다음에
어떤 모듈의 포트가 있으면
그 포트는 항상
소문자 I, 소문자 O로 시작을 해요.
입력 포트는 I로 시작하고
출력 포트는 O로 시작을 해.
그러니까 이게 그 소프트웨어 쪽에서 얘기하는
뭐 헝가리안 노테이션 뭐 이런 거 있잖아요.
C++ 같은 경우에도
이게 뭐 C++라는 랭기지에서
뭔가 문제가 있기 때문에
이렇게 이름을 붙여야 되는 거는 아니지만
이런 규칙을 써가지고 이름을 붙이면
나중에 디버깅을 하거나
유지 보수할 때 편하다라고 해가지고
사람들이 이제 뭐 써보니까
괜찮네 해가지고 많이 쓰는
그 네이밍 컨벤션이 있는데
그거를 이제 뭐 헝가리안 노테이션 이렇게 부르잖아요.
그런 거가 있는 거예요. 말하자면은.
그러니까 이런 것들은 뭐
이걸 안 지킨다고 해가지고
동작하지 않거나 뭐 이런 것들은 아니지만
어떤 부서에서의 모든 사람이 다
이 동일한 코딩 스타일로 코딩을 해라라고 하는
그 부서만의 규칙이 있다면
이거를 규칙만 만들어 놓고
확인을 안 하면 아무도 안 지킬 거 아니에요.
그러니까 이런 것들을 자동으로 확인해주는
툴이 있는 거죠.
그래서 그런 것들을
뭐 사용을 하기도 합니다.
그래서 그런 데 쓰이는 게 이제
이런 린터라고 하는 툴이 있고요.
그러니까 이런 것들은 뭐
소스 코드만 보고 확인을 할 수 있는 거다 보니까
뭐 시뮬레이션을 하지는 않습니다.
그 다음에 시뮬레이션을 하지 않고
코드만 보고 또는 뭐 레이아웃만 보고
돌리는 툴 중에서 굉장히 대표적인
뭐 린트 같은 경우에는
뭐 쓰기도 하고 안 쓰기도 하고 할 수 있지만
이 STA는 많이 사용하는 툴입니다.
그러니까 이거는 이제
스태틱 타이밍 언어네시스라고 해가지고
제가 그 검증하는 그
검증할 때 확인해야 되는 필요가 있는
항목 중에 하나가 이제 타이밍이라고 말씀을 드렸는데
그 타이밍이라고 하는 게 결국은
어떤 클락의 엣지 사이에서
어떤 컨비넨셜 로직이
필요한 시그널들을 다 타이밍에 맞춰가지고
생성을 해주는지 여부를 확인을
그거를 다 검증을 해야 된다고 말씀을 드렸어요.
근데 이거를 검증을 하는데 보통은
시뮬레이션을 통해서 할 수가 있어요.
그래서 어떤 그 게이트의 딜레이
그 다음에 와이어의 딜레이
같은 것들을 다 모델링을 해가지고
시뮬레이션 모델을 이용을 해서
시뮬레이션을 해보면
여기서부터 여기까지 딜레이가
얼마나 되는구나
라고 하는 것들을 다 시뮬레이션 통해서
확인을 할 수가 있죠.
그런데 이게
워낙 그 칩이 이제 복잡해지고
커지다 보니까
이거를 시뮬레이션만을 통해 갖고
검증을 하려면
시간이 이제 너무 많이 걸리는 거예요.
그러다 보니까 이제 이거를
스태틱 타이밍 언어넬스스를 합니다.
그러니까 이거는 시뮬레이션을 해보지 않고
이 구조가 딱 있으면
이 구조를 보면
이 게이트 딜레이 얼마
이 와이어 딜레이 얼마라고 하는 게
그냥 시뮬레이션을 해보지 않아도
계산을 할 수가 있잖아요.
그러니까 이거를 시뮬레이션을 해보지 않고
여기서 이제 계산을 해보는 거죠.
물론 시뮬레이션을 했을 때
조금 더 정확하게 모델링을 할 수 있는 경우가
있을 수는 있어요.
그런데
이거는 이제
시뮬레이션을 통해 갖고 할 때는
예를 들면
이런
그
데이트의 딜레이도
얘가
라이징을 할 때랑
폴링을 할 때가
약간 다를 수 있어요.
속도가
그러니까
그 말은 뭐냐면
이 게이트에서 나오는
출력이 0이냐 1이냐에 따라 갖고
딜레이가 조금 달라질 수 있다는 거죠.
그러니까 이런 것들을 디테일하게 알고 싶을 때는
시뮬레이션을 해야 되겠지만
우리가 여기서
STA를 하는 목적은 뭐냐면
월스트 케이스 딜레이를 알고 싶은 거예요.
그러니까 크리티컬 패스 딜레이를 알고 싶은 거예요.
왜냐하면 그게 중요하니까
그러니까 우리가 타이밍을 검증한다는 말의 의미는
이 클락의 엣지에서
그 다음 클락 엣지가
엣지 전까지
모든 시그널들이 다
그
안정적으로
출력을
만들어내느냐
여부를
이제 검증을 하겠다는 건데
그러면은
이 말은
이 출력 시그널 중에서
제일 늦게 나오는 시그널
이
다음 클락 라이징 엣지 전에
그 제일 늦게 나오는 시그널이
다음 라이징 엣지 전에
생성이 되느냐
요거를 확인을 하겠다는 거죠.
그러니까
월스트 케이스 딜레이가
그
한 클락의 주기보다 짧으냐
이거를 알고 싶은 거거든요.
그러니까 이 STA를 하게 되면은
그 월스트 케이스 딜레이 위주로
이제 확인을 하게 되는 겁니다.
그러니까 시뮬레이션을 하게 되면은
월스트 케이스가 아니라
여러 가지 시나리오에 대해서 다 딜레이를 계산을 해볼 수가 있다면
이 STA는
어차피 내가
내가 이거를 하는 목적은
월스트 케이스 딜레이를 알고 싶은 거기 때문에
그거를 이제
이 스태틱 타이밍 어네리시스를 통해서 하겠다는 거죠.
그래서
스태틱 타이밍 어네리시스도
원칙
원래는 이거를
레이아웃이 다 끝나고
GDS까지 나왔을 때
그때 해야 제일 정확하겠죠.
왜냐하면 그때는 이제 이런 게이트들도 다 배치가 끝났고
걔네들도 다 연결이 됐고
걔네들이 어떻게 연결될지
그 패턴들도 다 나와 있기 때문에
각각의 와이어의 딜레이
뭐 그런 것들이 다 정확하게 모델링이 돼요.
그렇기 때문에 그때 돌리는 게 제일 정확하기는 하지만
근데 그때 가서 문제가 생기면은
이거를 또 그 앞단계로 돌아와가지고
수정을 해가지고
이거를 계속 이 룹을 돌아야 된단 말이죠.
근데 레이아웃까지 다 끝나고 난 답을 확인해가지고
다시 설계 단계로 문제가 생기면
다시 설계 단계로 돌아가가지고
또 이 룹을 돌라고 그러면은
시간이 너무 많이 걸리는 거예요.
그러니까 이 스태틱 타이밍 어네리시스도
GDS 단계에서 하지 않고
앞단계에서 하기도 해요.
물론 앞단계에서 하게 되면은
속도가 빠르기는 하지만
이제 정확도가 조금 떨어지기는 하죠.
그러니까 어쨌든 GDS2 제일 마지막 단계에서
뭐 최종적으로 해주기는 해줘야 되지만
앞단계에서 할 수 있으면
앞단계에서 나오는 것들을 조금 부정확하지만
일단 다 어느 정도 해결을 해놓고
그 다음에 뒤에 가서 또 문제가 생기는 거는
그때 가서 해결을 하는
그런 방식으로 하는 게 조금 더 효율적이라서
그런 방식으로 많이들 합니다.
특히나 복잡하고 큰 칩 같은 거
뭐 간단한 칩들이야.
뭐 언제도 상관이 없는데
근데 복잡한 칩 같은 경우에는
그런 식으로 해서
앞부분에서 빠르게 확인을 좀 해봐서
웬만한 문제는 거기서 한 번 다 해결을 하고
거기서 해결이 안 되는 것들을
이제 뒤에 가서 확인하는
그런 방식을 사용을 합니다.
그래서 어쨌든 이거는 이제
타이밍을 검증한다는 목적에서
활용되는 툴이고
그래서 이거는 시뮬레이션을 굳이 하지 않고
이제 이런 것들을 확인을 해볼 수가 있습니다.
그 다음에 아까 제가 뭐
베리피케이션 챌린지라고 해가지고
여러 가지 것들을 말씀을 드렸잖아요.
그래서 방금 말씀드린 게 이제 타이밍이고
그 다음에 시그널 인테그리티 같은 게
이제 크로스톡하고 관련되어 있는
그러니까 뭐 그런 것들이고
그래서 이런 것들은 사실 설계 단계에서
고려를 하기보다는
이거는 보통은 설계가 끝나고 난
뭐 소위 말하는 백엔드
그 쪽에서 주로 아니면 공정 쪽에서 이제
주로 하는 것들인데
근데 이것들을 이제
경우에 따라서는
설계 단계에
그 반영을 하게 되는 경우들이 있기 때문에
여러분들이 이제 대충 이런 것들은
있다라는 것 정도를 알아주시는 건
나쁘지 않습니다.
예를 들면은 타이밍 같은 경우만 해도
이제 이런 경우들이 생겨요.
그러니까 내가 어떤 IP를 설계를 했는데
이거를 뭐 기능적으로는 아무 문제가 없어요.
그래갖고 뭐 기능은 검증이 다 끝나갖고
이제 합성을 하고 레이아웃을 해가지고
그 뭐 최종적으로 STA까지 돌렸는데
타이밍을 맞출 수가 없어.
그러니까 타이밍을 맞출 수가 없다는 거는
보통은 이제 설계를 할 때
내가 만든 IP에
하겟 클락 프리컨시를 정해요.
그래서 내가 예를 뭐 예를 들면은
200메가로 돌려야겠다.
라고 하는 것들이 이제 목표가 정해집니다.
그러면은 설계가 끝나고 난 다음에
그 목표에 따라서
합성을 하고 레이아웃을 해요.
근데 레이아웃을 해봤는데
200메가 헤르츠가 도저히 안 나와.
그러면은 이제 앞단계로 돌아가서
합성을 다시 하거나
뭐 레이아웃을 다시 하거나 해가지고
어떻게 해서든지 이게 200메가로 돌아가게
그 백엔드 뭐 툴 돌려가지고
이제 백엔드 하는 사람들이
열심히 툴에 뭐 이렇게 컨스트레인트 조정하고
뭐 레이아웃 바꿔보고
막 이래가지고 해결을 시도를 해요.
그랬는데 하다 하다 하다 안 되면
결국은 RTL 프로그래머한테 요청을 해요.
이거 도저히 타이밍이 못 맞추겠으니까
RTL 좀 고쳐주세요.
그러면은 RTL 하는 사람이 결국은 고쳐야 돼요.
제일 뭐 쉽게 제일 쉬운 거는 예를 들면은
이게 문제가 되는 어떤 크리티컬 패스에 있는
어떤 그 로직이 있어요.
그러면은 뭐 그 거기다가 중간에다가
레지스터를 하나를 추가를 해요.
그러면은 얘가 사이클의 관점에서는
한 사이클 늘어나지만
크리티컬 패스 관점에서는 반으로 줄잖아요.
그러니까 만약에 이렇게 해서 해결되면
제일 간단한 거고
만약에 이게 안 되면은 이제 RTL을 완전히 다 뜯어 고쳐야 되고
뭐 그런 문제가 생길 수가 있는 거죠.
어쨌든 이런 식으로 이게 백엔드 쪽에서
예를 들면은 이거는 제가 말씀드린 거는
타이밍에 관련된 문제였는데
타이밍에 관련된 문제가 아니라
다른 종류의 문제들에 있어서도
이거를 뒤에 가서 백엔드나 공정 쪽에서 생기는 문제들을
그쪽에서 막 이렇게 해결을 하려고 하다가
하다 하다 안 되면은 결국은 RTL까지 와요.
그래갖고 이거를 RTL을 수정을 해야 되는 경우가
생길 수 있다는 거죠.
근데 이제 문제는 RTL을 수정을 하게 되면은 이거를 이 프로세서를 다시 다 해야 되죠.
합성도 다시 해야 되고 레이아웃도 다시 해야 되고
이걸 다시 다 해야 되니까
여기까지 돌아오면은 이제 시간이 많이 걸려요.
이 룹을 엄청나게 큰 룹을 돌아야 되는 거예요.
그래서 어쨌든 설계를 아예 시작할 때부터
이런 것들을 어느 정도 고려를 해가지고
설계를 할 수 있으면 좋다는 거고
뭐 어쨌든 간에 뒤에 가서 백엔드 쪽에서 문제가 생기는 거를
RTL 쪽에서 반영을 해야 되는 경우가 생길 수도 있다는 거.
그래서 이런 물리적인 현상들을 이제 검증을 하는 게
어떤 것들이 있는지 이게 왜 문제가 되는지
뭐 이런 것들은 어느 정도는 알아주시면
뭐 좋을 거라고 생각을 합니다.
다음에는 뭐 디바이스 테스트 같은 거는
이거는 이제 테스트예요. 테스트.
이거는 베리피케이션이 아니고
이거는 이제 다 뭐 실리콘으로 물리적으로 구현이 끝난 다음에
얘가 정말 제대로 되고 있는 건지를 확인하는 뭐 그런 겁니다.
그래서 이거는 뭐 테스트 쪽이니까
뭐 그냥 이 정도로만 하고 간략하게 넘어가도록 하겠고요.
근데 이 테스트가 여기서 또 왜 나오느냐.
이 테스트를 하는데도 이거를
그러니까 이 물리적인 결함이 있는지를
다 제조가 끝난 다음에 확인을 하는 거예요.
이걸 어떻게 확인해?
검증을 다시 해볼 수도 없잖아요.
이미 칩이 다 제조가 돼서 나왔는데
얘를 다시 시뮬레이션을 해볼 수도 없고
물론 여기에 칩이 있으면 그 칩에 핀들이 있어갖고
그 핀들의 입력과 출력을 우리가 입력을 넣어보고
출력이 제대로 나오는지 정도는 확인을 해볼 수가 있겠죠.
그런데 그 입력만 가지고 내부가 모든 케이스를 다 확인을 해보기에는
시간도 너무 많이 걸리고
그런 하여튼 현실적인 문제가 있어요.
그래서 보통은 그 DFT라고 해서
디자인 포 테스터빌리티라고 하는 그런 기술을 씁니다.
그러니까 이거는 설계를 하는 정확하게 말하면 설계라기보다는
합성하는 단계에서 이 DFT에 관련된 로직을 집어넣어요.
그래갖고 나중에 테스트하기 편하도록
이제 만들어주는 그런 기능들을 합니다.
그러니까 베리로그를 하시다 보면
여러분들이 스캔체인이나 이런 걸 들어보신 분도 있을 텐데
제일 대표적인 게 그런 스캔체인이에요.
그래서 이거 스캔체인은 뭐냐면
우리가 이제 싱크로노스 로직을 주로 쓴다고 말씀을 드렸는데
싱크로노스 로직들은 결국은 회로 안에 레지스터들이 쭉 들어가게 됩니다.
그러면 그 레지스터를 체인으로 이렇게 쭉 엮어놓은 거예요.
그래서 이게 스캔체인이에요.
그런데 이 스캔체인은 테스트할 때만 쓰는 거지
일반적으로 정상적인 동작하는 상황에서는 쓰는 것들이 아니에요.
그래서 이거를 테스트를 할 때 이 스캔체인을 이용을 하면
이 회로 안에 있는 모든 레지스터의 값들을
이 체인을 통해서 다 변경을 할 수 있고
그 레지스터의 값을 이 체인을 통해서
딱 이게 확인을 해볼 수가 있습니다.
그래서 그것들을 지원을 하는 게
디자인 포 테스트빌러티라고 해서
DFT라고 보통을 얘기를 하고
그거는 설계 단계에서 들어가는 건 아니지만
합성을 할 때 합성해주는 툴이
이제 자동으로 그런 것들을 생성을 해줍니다.
그래서 이런 DFT를 써가지고
이제 그런 테스팅을 하게 되겠고요.
그리고 이 DFT가
스캔체인이 또 하드웨어 쪽에서만 쓰이는 게 아니라
이거를 이제 프로소스 쪽에다가 집어넣으면
우리가 왜 디버거 같은 거 쓰잖아요.
근데 뭐 데스크탑에서 쓰이는 디버거 같은 경우에는
그냥 뭐 디버거 붙여가지고 쓰게 되지만
이런 그 인베디드 보드 같은 경우에는
그 아이스 같은 에뮬레이터 장비를 써가지고
얘를 거기다가 이제 보드에다가 연결을 해가지고
디버거를 붙이게 되죠.
그러면 그 아이스 장비가 해주는 게 결국은
이 스캔체인을 이용해서 프로세서 내부에 있는
레지스터를 이제 확인해보던가
그 값을 바꿔보던가
이런 것들을 이제
이 스캔체인을 이용해서 할 수 있게 해줍니다.
그래서 그런 것들이 들어가고요.
그런데 여기서 이제
이 테스트를 쉽게 하기 위한 로직이 들어가기도 하지만
테스트를 아예 자동으로 해주는 로직이 들어가기도 해요.
그게 이제 그 빌트인 셀프 테스트라고 해가지고
리스트라고 얘기를 합니다.
이거는 우리가 테스트를 한다고 그러면 나중에
다 그 칩이 제조가 되고 난 다음에
여기에 테스트 패턴을 입력해가지고
그 출력이 제대로 나오는지를 확인을 해요.
그래서 여기에 테스트 패턴을
뭐 만들어주는 게 이제
오토매틱 테스트 패턴 제너레이터라고 해가지고
ATP지 이런 거를 사용을 하는데
그러면 이거는 이제 로직에 따라가지고
테스트 패턴을 만들어줘야 되는데
메모리 같은 경우만 해도
제일 대표적인 게 메모리에 많이 쓰는데 비스트가
메모리는 사실은 그냥 메모리에다가 데이터를 쓰고
쓴 값이 정상적으로 읽혀지는지만 확인하면 되니까
이거는 테스트 패턴이 굉장히 단순한 거죠.
그래서 이거를 굳이 뭐 이거를 나중에 가가지고
테스트 장비를 연결을 해가지고 테스트 해볼 필요가 없이
이렇게 간단한 테스트 시나리오 정도는
그냥 셀프 테스트 할 수 있는 로직으로 만들어요.
그래갖고 메모리 같은 경우에는
그냥 이 비스트 같은 거를 쓰게 되면
알아서 테스트를 해줍니다. 테스트 로직이
그리고 심지어는 아까 왜 스페어 리전 같은 거를
만들 수도 있다고 했잖아요.
그러니까 원래 내가 필요한 거는 32KB 메모리인데
이게 혹시나 여기에 뭔가 물리적인 결함이 있으면
얘를 4KB짜리 스페어 리전을 넣어가지고
얘로 이렇게 교체를 해가지고 쓰게 되는
그런 것도 할 수 있다고 말씀드렸잖아요.
심지어는 비스트가 그런 것도 자동으로 해줍니다.
그래서 메모리 비스트 같은 경우에 실제로 많이 쓰이고요.
그래서 그런 것들은 설계할 때 반영이 되는 것들이고
근데 메모리 비스트가 아니더라도
이제 DFD 같은 것들은 또 이제
스캔 체인 같은 거를 통해가지고
나중에 테스트하기 편하도록 하는 것들도
많이 사용을 하고 있습니다.
그런 거고요.
그래서 아까 말씀드린 메모리 비스트
뭐 이런 것들이 있고 스캔 체인
그래서 이거를 제가 지금까지 설명을 드린 거고요.
자 그 다음에 이제 그 검증 방법론의 마지막으로
포멀 테크놀로지가 있습니다.
포멀이라고 하는 거는 이제 아까 말씀드린 것처럼
어떤 수학적인 모델을 이용을 해가지고
그 증명을 하는 거예요.
그래갖고 이거는 이제
이것도 이제 방법이 몇 가지가 있는데
그중에 이것도 이제 시뮬레이션을 통해 갖고 하는 것도 있고
완전히 수학적인 모델로 하는 것도 있어요.
그래서 이런 것들에 대해서 한 가지씩 조금 알아보도록 하겠습니다.
먼저 나오는 게 이제 Theorem Proving인데
이거는 말 그대로 Proving을 하는 거예요.
그래갖고 내가 어떤 시스템이 있을 때
그 시스템이 내가 원하는 대로 동작하는지를 확인을 하기 위해서
어떤 그 어떤 그 수학적으로 얘를 모델링을 해서
그거를 가지고 이제 그 증명을 하는 거죠.
그러다 보니까 이거는 어떻게 자동화를 하기가 조금 어려워요.
그냥 문자 그대로 기능을 보고
걔를 어떤 그 공리나 그러니까 뭐 엑시움
엑시움이나 무슨 Theorem 같은 거를 만들면서
얘가 정말로 내가 원하는 대로 동작하는지를
증명을 하는 과정이기 때문에
이거는 그러니까 이렇게 여기서 말씀드린 것처럼
이게 굉장히 어렵고 시간도 많이 걸리고
그래서 이거는 정말 중요한 어플리케이션
또는 정말 중요한 어떤 모듈
이런 데서만 제한적으로 쓰이지
일반적으로 쓰이는 거는 아닙니다.
그리고 이거는 뭐 자동으로 하기가 조금 어려워가지고
사람이 보고 해야 되는 거니까
그런 조금 어려운 점이 있고요.
근데 어쨌든 이게 만약에 가능하다고 그러면
이것만큼 확실한 게 없는 거죠.
그 다음에 모델 체킹이라고 하는 게 있어요.
모델 체킹은 이거는 이제 어떻게 보면
아까 Theorem Proving이 100% 완벽하게 증명을 하는 거라면
모델 체킹 같은 경우에는
내가 정의한 어떤 특정한 프로퍼티들
얘네들이 항상 만족되는지 정도 수준으로만 확인을 하는 겁니다.
그러니까 여기 같은 경우에는
프로퍼티를 어떻게 정의하느냐가 굉장히 중요해요.
그런데 어찌 됐든 내가 프로퍼티를 정의를 해놓은 거에 대해서는
얘가 전부 만족한다라고 하는 거를 확인을 해볼 수가 있게 되는 거죠.
그래서 이거 같은 경우에도 이제 크게 나누면
얘도 스태틱한 방법이 있고
시뮬레이션을 이용한 방법이 있어요.
내가 정의해놓은 이 프로퍼티가 항상 만족되는지를
시뮬레이션을 통해서 확인하는 방법이 있어요.
그러니까 이거는 이 시뮬레이션을 쓰게 되면 문제가
시뮬레이션 시나리오에 대해서만 검증이 되는 거죠.
그런데 스태틱한 방법은 이거를 소스 코드를 보고 분석을 하는 거니까
얘는 시나리오에 상관없이 항상 만족된다라는 거를 확인을 할 수가 있습니다.
대신에 이렇게 되면 이게 좀 속도가 느린 면이 좀 있어요.
왜냐하면 시뮬레이션을 하지 않고 스태틱하게 하는 방법은
대부분의 경우에는 가능한 모든 케이스들을 다 검증을 해요.
그러다 보니까 얘가 케이스들이 회로가 조금만 복잡해져도
케이스가 익스프네셜하게 증가를 하잖아요.
그러니까 이게 이제 스테잇 익스플로전 프로블럼이라고 해서
이 스테잇이 폭발적으로 증가를 하는 거예요.
그러니까 이게 복잡한 회로에는 사용을 하기가 좀 어렵습니다.
그래서 뭐 하여튼 그런 게 있고요.
그래갖고 어쨌든 어떤 시스템이 내가 정의한 프로포티들을 항상 만족되는지를
확인을 하는 거를 이제 모델 체킹이라고 보통 이야기를 합니다.
그 다음에는 이제 이키밸런스 체킹이라는 게 있어요.
이거는 이 모델 체킹의 한 가지 일종인데
두 개의 모델이 동일한지를 확인을 하는 그런 모델 체킹입니다.
그러니까 이게 제일 보통 많이 쓰는 것들은 이런 데 많이 써요.
그러니까 우리가 이제 RTL 설계가 끝나고 나면은 백엔드 툴들을 돌리면서
합성하고 레이아웃하고 뭐 이런 과정을 거치잖아요.
그러니까 이런 쭉 과정을 거칠 때마다 이게 RTL 설계랑 동일한지
이런 것들을 계속 확인을 합니다.
이거는 거꾸로 말하면은 이 툴들을 못 믿겠다는 얘기이기도 해요.
그러니까 이 툴들에 혹시나 버그가 있거나 이렇게 문제가 있어 갖고
얘가 내가 설계한 대로 혹시나 구현이 안 되고 뭔가 이렇게 조금 달라진 게 있는지를
확인하기 위해서 뭐 이런 이키밸런스 체킹을 쓰기도 합니다.
그런데 이런 데 쓰기도 하지만 이거를 또 언제 쓰냐면은
그 RTL을 설계를 해놓고 만약에 이 RTL을 설계를 하기 위한
일종의 골든 수학적 모델이 있다면 이 골든 모델과 똑같은지를 확인하는 데도 쓸 수가 있습니다.
그러니까 이런 경우에는 어떤 경우가 있냐면은
이것도 제가 옛날에 삼성에 있을 때 아까 베이스밴드 모델 칩을 만들었다고 말씀드렸잖아요.
그러면은 이 베이스밴드 모델 칩을 그 RTL 설계를 하기 전에
알고리즘 설계를 먼저 해요.
그래서 이 알고리즘은 그러니까 예를 들면은 뭐 CDMA이다.
그러면은 그 CDMA 그 전파를 처리하기 위한 알고리즘이 있잖아요.
그래서 그 알고리즘을 먼저 설계를 하고
그 알고리즘을 C 같은 걸로 검증을 합니다.
그러면은 이게 말하자면은 골든 모델이 되는 거예요.
그래서 이거를 그대로 RTL로 구현을 한 게 하드웨어가 되는 거고요.
그렇게 되면은 이 RTL과 이 C 코드랑 동일한지를 확인을 해볼 필요가 있죠.
그래서 이거를 보통은 저희는 이제 RTL에서 시뮬레이션 벡터를 뽑아갖고
시뮬레이션을 통해갖고 RTL에서 나오는 결과랑
이 C 모델에서 나오는 결과가 동일한지를 확인하는 방식을 썼었어요.
이거 같은 경우에는 그러니까 기본적으로 시뮬레이션을 이용한 검증 방법인데
이렇게 할 수도 있지만 이런 포멀 메토드로지
이키밸런스 체크 같은 거를 사용을 한다면
그 C에서 나오는 그 C 코드와 RTL 코드가 완전히 동일한지를
어떤 수학적 모델을 통해갖고 검증할 수가 있다는 거예요.
그래서 이런 것들을 이제 이키밸런스 체킹에 활용을 할 수도 있습니다.
근데 어쨌든 포멀 베리피케이션이 철저하게 검증한다는 면에서는
굉장히 좋지만 아까 말씀드린 스테이 스페이스 익스플로전 프로블럼이 있어요.
그래서 이거를 실질적으로 하기에는 큰 시스템, 복잡한 칩에는
이거를 적용하기가 어렵고 정말 정말 크리티컬한 그런 기능을 검증하는데
주로 사용을 하게 됩니다.
그래서 저희가 뭐 이런 것들을 쭉 여러 가지 테크놀로지를 했는데
뭐 간단하게 그냥 비교를 한 테이블이고요.
자 지금부터는 이 포멀 베리피케이션 중에서도
그 Theorem Proving에 대해서 핵심적인 개념만 간단하게 소개를 시켜드리고
오전 세션을 마무리를 하도록 하겠습니다.
제가 이거를 하는 이유는 뭐냐면요.
여러분들이 뭐 여러분들 중에 나중에 RTL 설계 같은 데 관심이 있으시니까
아마 이 수업을 들으실 거라고 생각을 하는데
대부분의 경우에는 뭐 U부인 같은 걸 써서 시뮬레이션을 통해서 검증하고
아마 대부분 다 그런 걸로 검증을 하실 거예요.
검증을 하시긴 하겠지만 아까 말씀드린 대로 이게 정말 미션 크리티컬한 시스템이 있을 때는
이거를 수학적으로 조금 더 철저하게 검증해야 되는 필요가 있을 수가 있어요.
그래서 이게 근데 이거를 자동화된 툴이 아니라
사람이 이제 머리로 검증을 해야 되는 필요가 있을 때가 있는데
있을 수가 있는데 그럴 때는 여러분들이 이거를 어떻게 하면 되는지에 대해서
개념적으로라도 아이디어라도 알아 놓으시면
혹시나 여러분들이 나중에 검증을 할 때
Theorem Proving을 통해서 검증을 할 일이 있으면
이 방법이 기억이 나면 이거를 적용해 보면
그거를 미션 크리티컬한 시스템들을 검증하는 데 도움이 될 수도 있을 것 같아서
이 미션 크리티컬한 시스템을 검증하는 Theorem Proving
이거는 사람이 하는 거예요.
이거는 기계가 자동으로 해주는 게 아니라
그래서 그거에 대해서 아주 간략하게 개념적인 부분만
뭐 좀 설명을 드리도록 하겠습니다.
그래서 몇 가지 이제 중요한 컨셉들을 정의를 해야 되는데
일단 Requirement라고 하는 게 나와요.
그래서 이 Requirement는 이게 결국은 이 시스템이
내가 설계한 이 예를 들면 회로가
어떻게 동작해야 되는지를 정의한 거라고 보시면 돼요.
그러니까 이게 말로 정의가 된 걸 수도 있고
아니면은 뭔가 여기서 보시면 이렇게
인포멀하게 그냥 말로 설명한 거야 말로
아니면은 뭔가 포멀한 방법으로
이게 정의가 되어 있을 수도 있고요.
그래서 어쨌든 이 Requirement가 제일 처음에 식별이 돼야 됩니다.
왜냐하면 내가 이 회로를 검증을 한다는 말의 의미는
이 회로가 저 Requirement대로 동작하는지를 확인을 하겠다는 게
결국은 이 Theorem Proving의 목적이기 때문에
이 Requirement가 명확하지 않으면 내가 뭘 검증해야 되는지 조차 알 수가 없는 상황이 생기잖아요.
그러니까 먼저 해야 되는 일을 이 Requirement가 뭔지를 이제 확인을 해야 되는 거죠.
그 다음에 이거를 실제로 구현한 게 시스템이에요.
말하자면은 시스템이라는 용어를 씁시다. 회로라기보다는.
그래서 우리가 여기서 할 거는 뭐냐면은
어떤 Requirement 파이라고 하는 게 주어지고
어떤 시스템에 대한 수학적인 모델 C가 주어졌을 때
이 시스템 C가 Requirement 파이를 만족하는지를 증명을 하거나
만족하지 않는지를 증명을 하거나
둘 중에 한 가지에 대해서 결론을 내리는 게 우리가 해야 되는 일입니다.
그래서 우리한테는 두 가지가 필요해요. 입력으로
Requirement 파이랑 시스템 모델 C가 필요해요.
이거는 어떻게 보면 주어지는 거고
이거 두 개가 주어지면 우리가 하려고 하는 거는
그래서 C가 파이를 만족하느냐를 증명을 하던가
만족하지 않는다는 거를 증명을 하던가
물론 만족하지 않는다는 거를 증명하는 거는 그냥
뭐 발레만 들어주면 되니까 간단한 거고
이게 항상 만족한다는 거를 증명하는 게 어려운 일이 되겠죠.
그래서 그거를 어떻게 할 거냐.
이거를 이제 알아보겠다는 겁니다.
그러면은 여기서 우리가 시스템 C
C라고 하는 시스템을 모델이 필요하다고 했는데
그 모델을 어떻게 모델링을 할 거냐인데
여기서는 이제 트랜지션 시스템이라는 컨셉으로 모델링을 합니다.
이게 사실 우리가 알고 있는 웬만한 하드웨어
또는 소프트웨어는 다 기본적으로 트랜지션 시스템이라고 보면 돼요.
이 트랜지션 시스템은 어떤 스테잇을 가지고 있어요.
그래서 이 스테잇이 아끼는 거를 트랜지션이라고 하고요.
그래서 어떤 시스템이 동작하는 거는 결국은
이 스테잇이 계속해서 트랜지션이 일어나가지고
아끼는 거를 이 시스템이라고 볼 수가 있어요.
이게 기본적으로 여러분들이 들어보셨으면 아실
그 트위링 머신이 결국은 이거예요.
트위링 머신이 이렇게 테이프가 있고
이 테이프가 결국은 스테잇이고
얘네들을 계속 이렇게 변경해가면서 이렇게 동작을 하잖아요.
그러니까 우리가 알고 있는 디지털 시스템은 결국은 다 트위링 머신이고
트위링 머신은 이 트랜지션 시스템이라고 얘기를 할 수가 있어요.
그러면 이 트랜지션 시스템은 이렇게 세 가지의 일종의 집합이 있으면
모델링을 할 수가 있습니다.
먼저 그 스테잇의 집합이 있어요.
이 시스템이 가질 수 있는 스테잇이 뭐가 있느냐
그래서 그것들을 하나의 집합으로 모아놓은 게 있을 수가 있고
그 다음에 이 중에서 이니셜 스테잇이 뭐냐
이니셜 스테잇도 스테잇이 하나만 있는 게 아니라
뭐 시스템에 따라 갖고는 여러 개의 스테잇이 이니셜 스테잇일 수가 있어요.
그래서 이것도 집합으로 표현을 할 수 있고요.
그 다음에 트랜지션 셋이 있어요.
이거는 어떤 스테잇에서 어떤 입력이 들어오면은
어떤 스테잇으로 변경이 되느냐를 집합으로 다 모아놓은 거
그게 트랜지션 셋이에요.
그래서 이 세 가지가 있으면은 어떤 시스템이든지 간에
트랜지션 시스템으로 우리가 모델링을 할 수가 있습니다.
뭐 예를 들면 뭐 이런 게 있을 수가 있어요.
스위치 트랜지션 시스템이라는 게 있다고 생각을 해봅시다.
그래서 어떤 스위치가 있어요.
그러면은 우리가 이 스위치를 이제 오프 상태가 되면 잠겨 있는 거예요.
잠겨 있는데 여기에 버튼이 하나 있어갖고
그 버튼을 누르면 온 상태가 돼가지고 얘가 열려요.
열리는데 여기서 얘가 10초를 기다렸는데도
그 버튼이 더 눌리지 않으면은 자동으로 잠겨요.
아니면은 버튼을 한 번 더 누르면은 잠기든가.
그래서 그런 시스템을 우리가 이렇게
스위치 트랜지션 시스템으로 모델링을 한 겁니다.
그래서 여기서는 스테잇이 오프냐 온이냐
이거 두 개가 스테잇이기도 하지만
여기에 한 가지 더 변수가 있어갖고
얘는 이 온 상태에서 몇 초 동안 얘가
버튼이 눌리지 않았는지를
카운트를 하고 있는 카운터가 있어요.
그래서 이 카운터도 스테잇의 일부인 거죠.
그래서 여기는 스테잇이라고 하는 게
오프냐 온이냐를 저장하는 모드
그러니까 얘가 오프냐 온이냐
얘는 뭐 일종의 불리한 변수가 되겠죠.
그런 모드라고 하는 스테잇 변수가 하나 있고
그 다음에 어떤 인티저 엑스 얘는 카운터예요.
그래갖고 얘는 온 상태에 있을 때
얘가 몇 초 동안이나 눌리지 않았는지를
카운트를 하는 카운터 변수.
그래서 이거 두 개의 조합이
이 시스템의 스테잇을 표현을 하는 거라고 볼 수가 있겠고요.
그러면 여기서 이니셜 스테잇은 뭐냐
이니셜 스테잇은 이 모드는 오프고
엑스는 0인 게 이니셜 스테잇이에요.
그 다음에 트랜지션은 여기 그래프에 보이는 것처럼
오프인데 오프 상태에 있을 때
프레스 어떤 버튼이 눌리게 되면
온으로 가는 그런 스테잇이 트랜지션이 있고요.
아니면 오프 상태에 있을 때
아무 버튼이 안 눌리면
그냥 오프 상태에 계속 있겠죠.
그래서 그것도 트랜지션이에요.
그 다음에 이거 같은 경우에는
이제 어떤 온이라고 하는 스테잇에 있는데
버튼이 안 눌리게 되면
그 카운터가 하나 증가를 하겠죠.
그래서 증가를 하게 되는 고 트랜지션이 있고
그 다음에 여기서 온이라고 하는 스테잇에 있다가
버튼이 눌리거나
버튼이 눌리거나
아니면 이 카운터의 값이
10 이상이 되면
이쪽으로 오프로 가거나
뭐 이런 트랜지션이 있습니다.
그래서 이 트랜지션의 집합은
이렇게 될 수 있다.
이렇게 볼 수가 있어요.
그래서 여기서 보시면은
이게 스위치 트랜지션 시스템은
이렇게 세 개의 집합으로
모델링을 한 겁니다.
그래서 이렇게 간단한 시스템이긴 하지만
좀 복잡한 시스템도
좀 복잡하기는 하겠지만
어쨌든 간에 이렇게 세 개의 집합으로
다 모델링을 할 수가 있습니다.
그리고 여기 밑에 보이는 거는 뭐냐면은
이 트랜지션 시스템이 있을 때
이 트랜지션 시스템이 실제로 동작하는
몇 가지 사례들이 있는 거라고 볼 수가 있어요.
그런데 여기서 보시면은
이렇게 동그라밀 쳐놓은 게
이니셜 스테잇이고
여기서 들어오는 입력에 따라서
이렇게 스테잇이 변경되는 걸
이렇게 화살표로 표현을 해놓은 겁니다.
그런데 여기서 보시면은
여기서 제가 하고 싶은 얘기는 뭐냐면은
여기서 예를 들어갖고
온 상태인데 카운터가 2예요.
그러면은 얘가 버튼이 눌리면은
오프 상태로 갈 수가 있겠고
버튼이 안 눌리면은
이쪽으로 갈 수가 있겠죠.
그런데 온인데 카운터가 17이에요.
이 경우는 정상적인 상황에서는
이런 스테잇으로 도달할 일은 없겠죠.
왜냐하면은 온인 상태인데
이 카운터가 10 이상이 되면은
오프로 가야 돼.
그런데 온이면서
X가 17인 경우에는
이 스테잇은 절대로 도달할 수 없는 스테잇이에요.
도달하면 안 되는 스테잇이고
그런데 어쨌든 간에
이런 스테잇 베리어블을
인티저로 만약에 내가 선언을 해놓게 되면은
이런 스테잇이 가능은 하겠죠.
가능은.
가능은 하지만 정상적인 상황에서는
도달할 일이 없는 그런 스테잇입니다.
그래서 이거를 이제 구분을 하는 게
리처블 스테잇이라고 하는 개념을
얘기해서 정의를 하는 거예요.
그래서 내가 이니셜 스테잇으로부터
정상적인 트랜지션을 통해서
도달할 수 있는 모든 스테잇의 집합을
리처블 스테잇이라고 얘기를 합니다.
아까 말씀드린 온인데
X가 17인
이 스테잇은 리처블 스테잇은 아니에요.
물론 이 트랜지션 시스템의
가능한 스테잇 중에 하나이기는 한데
가능은 하지만 리처블한 것은 아닌 거죠.
그래서 리처블 스테잇이라고 하는 걸로
이런 식으로 정의를 합니다.
이 리처블 스테잇을 왜 정의를 했는지를
여러분들이 이제
눈치가 빠르신 분들은
확인하실 수가 있을 거예요.
왜냐하면 우리가 이 시스템이
항상 리퀘이먼트를 만족하는지
여부를 확인을 하겠다고 했어요.
그런데 여기서 말하는
항상이라고 하는 것은
엄밀하게 말하면
모든 리처블 스테잇에서
이 리퀘이먼트가
만족하는지 여부를
확인하면 된다는 거예요.
그러니까 여기서 말하는
항상이라고 하는 것을
엄밀하게 정의를 하기 위해서
이 리처블 스테잇이라고 하는 개념을
지금 정의를 한 겁니다.
그러니까 항상 만족되느냐라는 말의 의미는
모든 리처블 스테잇에서
만족하느냐라는 말의 의미다라고
이해를 하시면 될 것 같습니다.
그래서 이거는 그냥
그거를 지금 설명을 드린 거고요.
그다음에 여기서 말하는
인베리언츠라고 하는 개념이 있어요.
그래서 방금 제가 말씀드린 것처럼
어떤 리처블 스테잇에서
어떤 프로퍼티가 있는데
이런 프로퍼티를 우리가 정의를 했잖아요.
이게 리퀘이먼트라고 말씀을 드렸는데
어떤 리퀘이먼트가 있을 때
그거를 이제 수학적으로 표현을 한 거를
프로퍼티라고 얘기를 하는 겁니다.
그러니까 리퀘이먼트는 어떤
뭐 그냥 말로 설명한 걸 수도 있다고 했잖아요.
그러니까 그 말로 설명한 걸로는
우리가 수학적으로 증명을 할 수가 없기 때문에
말로 설명해 놓은 거를
수학적으로 표현을 한 거를
프로퍼티라고 얘기를 하는 거고요.
그래서 그 프로퍼티가
모든 리처블 스테잇에서
변하지 않는 거예요.
다시 말하면 얘가
항상 만족된다고 볼 수가 있는 거죠.
그래서 이거를
그 어떤 프로퍼티가 있을 때
걔가
이 모든 리처블 스테잇에서
항상 변하지 않는다면
우리가 그거를
인베리언트다
라고 정의를 합니다.
그래서 이제
이런 개념들을 가지고
정의를 해놓고 보면
우리가 아까 처음에 얘기했던
어떤 시스템 C가
리퀘이먼트 파일을
항상 만족하느냐를
우리가 증명을 하는 게
이 지금
Theore Improving의 목적이라고
말씀드렸는데
방금 저희가 쭉
정의를 한 단어들로
그거를 다시 표현을 하면
어떤 트랜지션 시스템 C가 있을 때
그 C의 모든 리처블 스테잇에서
주어진 프로퍼티가
인베리언트냐를
증명을 하는 거가
우리가 지금부터 할 거의
목적이라고
그렇게 다시 정의를 할 수가 있습니다.
그래서 그거를 지금부터 할 건데
시간이 딱 40분인 관계로
여기서 잠깐 멈추고
이 뒷부분은 점심 식사 후에
1시에 다시 진행을 하도록 하겠습니다.
혹시 그래도
지금까지 한 거에 대해서
질문이 있으신 분 있으세요?
어쨌든 질문 있으시면
시간이 됐으니까
이따가 점심 식사 이후에
질문하셔도 되니까
그때 질문을 해주시고
줌으로 들어오신 분들도
혹시 질문 있으시면
남겨주세요.
그러면 제가 나중에
식사 마치고 1시에
다시 시작할 때
그때 답변을 드리도록 하겠습니다.
그러면 잠깐 쉬고
1시부터 다시 시작하도록 하겠습니다.
혹시 질문 있으신 분 있으세요?
없으시면 일단 진행하도록 하겠고요.
마찬가지로
마찬가지로
오후 세션도
쭉 진행해서
1시니까
2시 40분에
마치도록 하겠습니다.
그래서 지금까지 했던 얘기를
간단하게 요약을 다시 하자면
간단하게 요약을 하면
우리가 지금
Theorem Proving을 지금 하고 있는 거예요.
그래서
Theorem Proving을 하는 거는
목표가
목표가
이제
어떤 프로퍼티가 주어졌을 때
어떤 시스템 C가
그 프로퍼티 파일을
항상 만족하는지
여부를
증명하는 거라고
말씀을 드렸는데
요거를 조금 더
포멀하게 정의를 하면
어떤 트랜지시션 C가
주어졌을 때
그 트랜지시션 시스템 C의
모든 리처블 스테이트에서
Requirement 파이가
인베리언트인지를
그 증명하는 거
그게 이제
저희가 지금부터
하려고 하는 것의
목표입니다.
그래서
인베리언트까지
설명을 드렸고요.
그러니까
아까 말씀드린 것처럼
어떤 모델이 주어졌어요.
C
트랜지시션 시스템이에요.
그 다음에 어떤
Requirement가 주어졌어요.
Requirement 파이인데
여기서 말하는
Requirement는
말로 설명하는
Requirement가 아니라
그 말로 설명한
Requirement를
어떤 수학적인
수식으로 표현한 거를
얘기를 하는 거죠.
그래서 그거 두 개를
입력으로 받아서
지금 우리가
뭔가를 하는
베리파이어가
뭔가를 하고 나면
결과적으로
이게 맞다.
그러니까 항상
만족한다라고 하는
거에 대한
프루프가 나오던가
아니면 어떤
발레가 나와갖고
이거는 만족하지 않는
경우가 있으니
인베리언트가 아니다.
이거를 이제
저희가
판단을 하려고 하는 겁니다.
그래서 이거를
하려고 하는 방법 중에는
생각해보면
다이나믹 어나리시스
같은 경우에는
일종의
시뮬레이션 기반의
방법이에요.
그러니까
이거를 우리가
사람이 굳이
이렇게
Theorem 프로빙 같은 걸
하지 않고
그냥 시뮬레이션
돌려보는 거예요.
그래갖고
이거 같은 경우에는
Assertion Based
Verification이
이 방법입니다.
그러니까
Property라고 하는 거를
Assertion 형태로
표현을 한 다음에
그러면
Rechable State는
어떻게 정의를 하냐면
결국은 그냥
시뮬레이션
테스트
시나리오가
Rechable State이
되는 거죠.
그런데
이게
모든
Rechable State이냐
그건
보장이 안 되는 겁니다.
그건
보장이 안 되지만
어쨌든
시뮬레이션 시나리오에
포함되어 있는
Rechable State에
한해서는
Assertion이 들어가 있으니까
모든 Assertion을
만족한다
라고 하는 거는
확인을 할 수가 있다는 겁니다.
그래서 이거를
시뮬레이션을 통해서
확인을 할 수가 있어요.
그러니까 어떻게 보면 우리가
이 Assertion에 관련해가지고는
저희가 지금
오늘 내일 모레
이 강의에서는
간단하게만
알아보겠지만
어쨌든 그런
Assertion이라고 하는 것에 대한
일종의
이론적인 배경이라고
말씀드릴 수가 있겠고요.
그런데 지금부터
저희가 하려고 하는 거는
Static Analysis예요.
그러니까 이거는
자동화가 좀 어렵고
사람이
Proving을 해주는 거예요.
그럴 때
이거를
어떻게 할 수 있느냐
그거를 지금부터
해보려고 하는 거고요.
그러니까 Proof Based
이거라고 보시면 되겠고
모델 체킹도 있기는 해요.
이거는
State Space Analysis인데
이거 같은 경우에는
뭐
이게
시뮬레이션 방식은 아니지만
이게
가능한
모든 경우의 수를
다
말하자면
확인해 보는 거예요.
그러니까
이거 같은 경우에는
시뮬레이션보다는
더 많은
시나리오를
확인해 볼 수 있겠죠.
얘는 그냥 말 그대로
전수조사를 하는 거니까
대신에
이거 같은 경우에는
복잡한 시스템을
쓸 수가 없어요.
너무
뭐
State이 많으면
그거를 쓸 수가 없겠죠.
그러니까
그거는 안 된다는 거고
그래서 저희가 하려고 하는 건
어쨌든 지금부터
이 Proof Based로
하려고 하는 겁니다.
자 그러면
그걸 어떻게 할 거냐
어떻게 할 거냐 하면
수학적 귀납법을
통해 갖고
이거를 할 거예요.
수학적 귀납법
뭐 고등학교 때
요즘 고등학교 교과 과정에
이게 포함되어 있나?
포함되어 있겠지?
어쨌든
배우셨을 테지만
수학적 귀납법은
간단하게 말하면
이니셜 스테이트에서
어떠한 특정한
프로포티가
만족된다는 거를
먼저 확인을 해요.
그 다음에는
K번째 스테이트에서
그 프로포티가
만족한다고
가정을 하고
K플러스 1번째
다음 스테이트에서도
만족한다는 거를
증명을 하면
그러면은
모든 스테이트에서
이 프로포티가
만족이 된다라고 하는 게
증명이 되는 거죠.
그래서 이게
수학적 귀납법입니다.
그래서 그거 두 가지를 하는 거예요.
그러니까
일단은
이니셜 스테이트에서
프로포티가
만족이 된다는 거를
먼저 확인을 합니다.
그 다음에
K번째 스테이트에서
그게 만족이 된다는 거를
가정을 하고
다음 스테이트
다음 스테이트은
이 스테이트에서
트랜지션이
하나만 있는 게 아니라
여러 개가 있을 수 있잖아요.
그러니까
트랜지션마다
다 트랜지션이
일어났을 때
그 다음 스테이트
될 수 있는 것들을
모두
확인을 해서
걔네들이
다 이 스테이트를
만족을 하면
이 리퀘어먼트를
만족하면
이제 이게
인베리언트다.
이렇게 얘기를 할 수가 있는 거죠.
그래서
이게 이제
우리가 지금부터
하려고 하는 겁니다.
그래서 예를 들어볼게요.
여기서 보시면
이 어떤
간단한
트랜지션 시스템이 있어요.
그래서 여기 같은 경우에는
스테이트
베리어물이
x예요.
x만 있어요.
그리고 이거는
0으로
이니셜라이즈가 돼요.
그렇다는 얘기는
얘가
이니셜 스테이트은
0인 거죠.
그 다음에
트랜지션은
요게
요거
요거 한 가지
조건밖에 없어요.
그래서
x가
n보다 작으면
x가 더하기 1이 돼요.
그러면은
x가 0보다 작지 않으면
어떻게 되느냐.
그러면은
x값이 그냥 변하지 않고
그대로 유지가 되겠죠.
그래서 이렇게
굉장히 간단한
이 스테이트
트랜지션 시스템입니다.
그러면은
우리가 여기서
프로포티로
확인하고 싶은 거는
뭐냐면은
x가 항상
0보다 크거나 같고
m보다 작거나 같으냐.
이 프로포티가
인베리언트냐.
라고 하는 거를
확인을 해보고 싶은 겁니다.
그래서 이걸 하려면은
수학적 귀납법에 의해서
처음에 해야 될 거는
이니셜 스테이트에서
이거를 만족하는지를
먼저 확인을 해야 되겠죠.
그러면은
이니셜 스테이트라는 얘기는
x가 0일 때니까
x가 0일 때
이 프로포티를
만족하느냐.
만족하죠.
x가 0이면
0보다 크거나 같고
m보다 작거나 같으니까
m은 뭐
양수라고 생각을 하면
그래서
일단은
이니셜 스테이트는
만족한다는 게
확인이 됐습니다.
자, 그러면은
자, 그러면은
k번째 스테이트에서
이게 만족한다고
이게 만족한다고
가정을 해보겠습니다.
그러면은
어떤 k번째 스테이트에 있을 때의
x의 값을
예를 들어갖고
a라고 얘기를 해볼게요.
그러면은
이 a라는 값은
항상
0보다 크거나 같고
m보다는
작거나 같습니다.
그랬을 때
다음 스테이트
k 플러스 1번 스테이트은
뭐가 될 수 있을까?
두 가지 케이스가 가능해요.
a가
m보다 작거나
같기 때문에
a가
m일 때랑
m보다 작을 때랑
이 두 가지에
대해서는
다른 스테이트로
트랜지션이 일어날 겁니다.
a가 만약에
m보다
작으면
이 조건을
만족하니까
x는
x 플러스 1이 되고
다시 말하면
현재의 x값이
a니까
a 플러스 1이 되겠죠.
그러면
다음 스테이트에서는
x값이
a 플러스 1이 될 텐데
그게
이거를 만족하느냐?
만족하죠.
왜냐하면은
방금 말씀드린 대로
a는
m보다 작다고
그랬어요.
m보다 작고
0보다
크거나 같으니까
거기에
더하기 1을 해도
m보다
작거나
작거나
같기는 하겠죠.
그러니까
이 조건을
여전히 만족합니다.
a가
m보다 작을 때는
그러면
a가
m이면
m이면
그러면은
다음 스테이트에서도
그냥
여전히
x가
그냥
a겠죠.
왜냐하면은
이 조건을
만족하지 않으니까
x값은 그대로
유지가 된다고
그랬어요.
그러니까
다음 스테이트에서는
그냥
x가
a예요.
그러면
그거를
이 프로포티를
만족하느냐?
만족하죠.
그렇기 때문에
이 경우에는
k번째
스테이트에서
이 프로포티를
만족한다고
가정을 했을 때
다음 스테이트도
이 프로포티를
여전히 만족한다.
라고 하는 거를
우리가 확인을 했습니다.
그러니까
이제는
수학적
귀납법에 의해서
이 프로포티는
모든
리처블 스테이트에 대해서
인베리언트다.
라고 우리가
결론을 내릴 수가 있습니다.
그래서 이런 방식을
이거는 워낙
지금 간단한
얘기 때문에
이렇게 간단하게
지금
증명을 할 수가 있었는데
사실은
이게
조금만
복잡해져도
그리 간단하지는
않습니다.
그렇지만
제가 이거를
설명을 드린 이유는
어쨌든
이런 아이디어가
이런 아이디어가
있다는 것
정도는
아시면
나중에 혹시
이게 이제
필요해지면
이런 것들을
적용해 볼 수 있는
그런 사례가
있을 수 있으니까
여러분들이 좀
기억을 하시면
이런 것들을
활용을 해보실 수 있을 것 같아서
말씀을 드린 거고요.
이거는
그냥 이거를
다이어그램
형태로
표현을 한 거고
이거는
이런 거를
이용을
한
하나의
사례인데
뭐
네
하여튼
이것도
설명을 드릴게요.
일단
이게
마지막
슬라이드
일 것
같은데
이게 뭐냐면
이게
그냥
수학적
귀납법을
적용한
또 하나의
사례인 거예요.
사례인 건데
이거는 뭐냐면
어떤
예를 들면
유치원에서
애들이
진흙
뭐야
진흙탕에서
지금 놀고 있어요.
예를 들면
갯벌
이런 데라고 합시다.
이런 데서 놀고 있는데
애들이 놀다 보면
진흙이 여기저기
못할 거 아니에요.
그런데
자기 이마에
진흙이 묻을 수가
있잖아.
그러면
자기 이마에
진흙이 묻으면
나는 내 이마에
진흙이 묻은지를
모르지만
남의
이마에는
진흙이 묻었는지는
볼 수가 있잖아.
그래서
여기서의
가정은
이거를
내가
만져가지고는
확인을 할 수가
없다고
가정을 하고
눈으로만
확인할 수 있는데
만약에
여기서
애들한테
선생님이
물어보는 거예요.
네 이마에
본인 이마에
진흙이 묻어있다고
생각하는 사람이
있으면 손 들어봐.
남이 있는 거는
보여.
그렇지만
내 이마는
안 보여.
그렇지만
내 이마에
진흙이 묻어있다고
네 스스로 생각할 때
그게 확실하다고
생각하면 손 들어.
라고 질문을 하는데
선생님이
N번
물어봤을 때
만약에
그 애들 중에서
N명의
애들한테
이마에 진흙이
묻어있으면
정확하게
선생님이
N번째
질문을 하면
그
이마에
진흙이 묻은
N명의 애들이
다
그 순간에
손을 든다.
라는 거를
증명을 하는 거예요.
무슨 말인지
되게 어렵죠.
자
그럼 이거를
그냥 쉽게 생각하면
이렇게 증명을 할 수 있어요.
쉽게는 아니지만
어쨌든 이걸 차근차근
생각해보면
이런 의미예요.
먼저
가정을 할 때
애들이
아무도
이마에
그
그 뭐야
진흙이 묻은 애가 없어.
그러면은
선생님이
이마에
진흙이 묻었다고
생각하는 사람
손 들어가면은
뭐 일단은
확실하지 않으니까
아무도 손을 안 들어요.
그런데
만약에
그거는 뭐
두 번부터
세 번부터는
다 똑같아.
근데 만약에
딱 한 명
딱 한 명이
이마에
진흙이 묻었어.
진흙이 묻었는데
선생님이 물어보는 거예요.
그러니까
그
그렇죠?
그러니까
선생님이 물어보는 거예요.
그
잠깐만
잠깐만
조금 헷갈리는데
아
이
이
이
가정이 중요한 거네.
그러니까 이게 있어야 돼.
뭐냐면은
선생님이 이 얘기를 해준 거야.
자
니들 중에
이마에
진흙이 묻은 애가 있어.
그러니까
근데 그게
너라고 생각하면 손 들어.
이거예요.
그러니까 아까
0명일 때는
이거는
가정이 성립하지 않은 거고
한 명이 있다고 생각해보시다.
한 명.
딱 한 명이
이마에 진흙이 묻었어.
그러면은
걔의
본인의 입장에서는
나 말고
나머지 애들은
지금
이마에 진흙이 묻은 애가
한 명도 없어.
근데 선생님이 뭐라고 했냐면은
니들 중에
이마에 진흙이 묻은 애가 있어.
그게 너라고 생각하면 손 들어.
라고 얘기를 했으니까
이마에 진흙이 묻은 애의 입장에서는
나 빼고 아무도 없는데
그러면은
나밖에 없잖아요.
그러니까 손을 들겠죠.
근데
나머지 애들의 입장에서는
나는
내 이마에 진흙이 있는지 없는지 모르겠는데
저기 한 명이 있는 애가 보이네.
그러면은
쟤가
이마에 진흙이 묻었으니까
선생님이 얘기하는
걔가 쟤겠네.
난지 아닌지는 나는 모르겠고
그러니까 손은 안 들겠지.
그러니까
처음에 딱 한 번 질문을 했을 때는
딱 한 명
이마에 진흙이 있는 애가 있으면
내만 손을 들다는 거예요.
자 그래서 이게
이니셜 스테이트예요.
이니셜 스테이트고
그러면은
두 번째
두 명이 있다고 생각을 해보셨다.
두 명이
두 명이 있으면은
처음에 선생님이 일단 질문을 해.
자
네 이마에
진흙이 묻었다고 생각하는 사람이 있으면
손 들어.
그러면은
만약에 내가
내 이마에 지금 진흙이 묻어있는 사람이에요.
그러면은
나는 내 이마에 진흙이 있는지 모르겠어.
근데
다른 애들을 쭉 보니까
한 명이 보여.
그러면은
똑같은 이유에 의해갖고
어 그러면은
선생님이 얘기하는
이마에 진흙이 묻은 애가
쟤인가 보다.
나는 모르겠고
그러니까 손을 안 들겠죠.
걔 입장에서도 마찬가지고
나머지 애들도 다 마찬가지고
그러니까
선생님이 처음에
야 니네 중에
이마에 진흙이 묻은 애가 있어.
그게 너라고 생각하는 사람은
손 들어.
하고 처음 딱 물으면은
아무도 손을 안 들 거예요.
근데
선생님이 한 번 더 물어.
니들 중에
이마에 진흙 묻은 애가 있다니까
손 들어 봐.
그러면 이제
두 번째 물어보면은
어떤 과정이 생기냐면은
내 이마에 진흙이 묻은 애
그러니까
이마에 진흙이 묻은 애
입장에서 봤을 때는
일단은
한 명이
이마에 진흙이 묻은 게
아니라는 거는
확실해.
왜냐하면
아까의 리듬에 따르면은
한 명이 있으면은
걔가 손을 들었어야 돼.
아까 내 눈에 보이는
제가 손을 들었어야 돼.
근데 제가 손을 안 들었어.
그러니까
한 명은 아니라는 얘기예요.
그러면은
최소 두 명이 있다는 얘기죠.
최소 두 명이 있는데
내 눈에 보이는 애는
한 명밖에 없어.
그러면 나머지 애는
나밖에 없네.
그러니까 손을 든다는 거예요.
제 입장에서도 마찬가지고.
나머지 애들의 입장에서는
다 지금 두 명씩 보여.
그러니까
아 선생님이 물어봤을 때
한 명은 아니고
최소 두 명인데
저기 두 명이 있으니까
나라는 보장은 없네.
하니까
손을 안 들겠고
그러니까 여기서는
내 이마에 진흙이 묻은
딱 두 명만
두 번째 질문할 때
손을 든다는 거죠.
이거를 조금 일반화시키면
K번째 선생님이 질문을 하면
여기서의 가정은
최소한 K명 이상의
그 이마에 진흙이 묻은 애들이
있다라는 게
여기서의 이제
기존에 있었던
그 가정이 되는 거고
그러니까 이 프로퍼티가
만족한다는 가정이 되는 거고
이때 이제
다음 질문을 했을 때
그러면은
K플러스 1명이 있으면은
그때
대답을 한다
라고 하는 거를
이렇게 일반화시켜가지고
증명을 할 수가 있다는 겁니다.
그래서 이게
하여튼 이것도 이제
뭐 그냥 사례 중에 하나로
제가 설명을 드린 거고요.
이런 식으로
이 수학적 귀납법을
사용을 해가지고
뭔가 이런 프로퍼티가
인베리언트인지
여부를
증명을 하는 데
활용을 할 수가 있어요.
그리고 이런 것들을 이제
우리가
설계를 하려고 하는
시스템에다가 적용을 하면
이 시스템에서
내가 원하는 프로퍼티가
항상 만족되는지
여부를
증명을 할 수가 있다는 거죠.
그래서
이게 이제
첫 번째
일반적인
검증 방법론에 대한
설명을 쭉 드린 거고요.
자 그럼 이제부터는
어
잠깐만요.
네 뭐 질문이
마우스 포인트가 원래 없나요?
여기 레이저 포인트가 있긴 한데
온라인상에서는
레이저 포인트는 안 보이시나?
네?
안 보여요.
아
그러면
어쨌든 그러면은
제가 여기
뭐 이 이후부터는
여기 앉아서 진행을 할게요.
앉아서
이게 마우스로
레이저 포인트가 나오니까
그렇게 진행을 하도록 하겠습니다.
그래서
이거는
이렇게
정리를
하겠고요.
그 다음에는
이제
이거는 지금부터 하려고 하는 거에 대한
뭐 간단한
그
뭐
인트로덕션이라고 볼 수가 있습니다.
이제부터는 이제 본격적으로
시스템 베릴로그를 이용을 해서
검증을 하는
문법에 대해 갖고
설명을 드리도록 하겠습니다.
근데 여기서는 이제
그
뭐 이거는 아까
뭐 보여드렸던
똑같은 내용이고요.
똑같은 내용이긴 한데
뭐냐면은
여기서 말하고 싶은 거는
이거예요.
그러니까
어
검증이라고 하는 거는
시뮬레이션만을
의미하는 거는 아니다.
보통은 이제
사람들이 흔히 생각할 때
제가 이미
이 앞에서
뭐 포멀
베리피케이션이라든가
뭐 이런 거를
이미 다 설명을 드렸기 때문에
사실은 이거는
어느 정도 설명이 된 거기는 하지만
어쨌든
시뮬레이션이나
테스팅을 통해 갖고는
알 수 있는 게
버그가 있다는 거는
알 수 있지만
없다는 게
증명되지는 않는다.
뭐 이런 얘기고요.
그러니까 이건 어떻게 보면은
그 포멀 베리피케이션이
필요하다는 거에 대한
얘기였고요.
하여튼 검증이 어렵다는
얘기를 하고 싶었던 거였고
그 다음에
이거는 이제
우리가 시뮬레이션을
해가지고
검증을 할 때 보면은
대부분의 경우에는
이제
테스트 벤치를 써가지고
다이렉티드 베리피케이션을
합니다.
그러니까 이거 같은 경우에는
어떤
그
설계자가
생각할 수 있는
그런
시나리오들로만
검증을
보통을 해요.
그래서
어떤
DUT가 있을 때
Search Space가
이렇게 3D로
이렇게 표현을 한다고
그러면
여기 빨간색으로
표현된 게
버그라고 하면
이런 식으로밖에는
그거를 찾을 수가
없게 되는 거죠.
그러다 보니까
시간이 지나가면서
찾을 수 있는
버그가
이렇게 천천히
증가를 하게 되는데
이거를 만약에
Constraint 랜덤을
쓰게 되면은
이거는
자동으로
랜덤한
테스트 입력을
생성을 해주는 거기 때문에
사람이 생각하지 못했던
굉장히 다양한
테스트
스나리오를
확인을 해볼 수가
있다는 겁니다.
그래서
이런 랜덤 테스트를
사용을 하게 되면은
초기에는 조금 더
시간이 걸릴 수는 있어요.
왜냐하면은
이 랜덤 테스트를
하기 위해서는
테스트 벤치도
말하자면은
일종의 프로그래밍이
필요해서
처음에 개발하는 데
시간이 더 들어가기는 하지만
일단 그게 끝나고 나면은
굉장히 빠른 속도로
여러 가지 케이스들을
테스트를 해볼 수가 있게 됩니다.
그래서 커버리지를
이렇게 다이어그램 형식으로
표현을 하면은
어떤 피처가 있고
버그가 있을 때
이
다이렉티드 테스트를 하게 되면은
이렇게
이렇게 이렇게
테스트를 해보는 거예요.
이렇게 네모로 친 게
말하자면 테스트
시나리오인 거예요.
이렇게 테스트를 해볼 수가 있는데
근데
이제
뭐
랜덤하게 되면은
이렇게
뭐
그
내가 잘 몰랐던
이런 에어리어까지
다 할 수도 있고
그 다음에
뭐 이런 식으로 이제
뭔가
테스트 케이스가
이렇게 랜덤하게 하다 보니까
이렇게 겹치는 영역도 생기고
뭐 그럴 수는 있습니다.
그 다음에는 이제
커버리지 같은 경우에는
이렇게 여러 개의 커버리지를 돌리다 보면
이게 시나리오가 좀 복잡해지면은
이게 랜덤한 거다 보니까
커버리지가 이제
처음에는 빠르게 올라가는데
이게 어느 정도 또
세츄레이션이 되면은
그 다음부터는 좀
천천히 올라가게 돼요.
왜냐하면은
뭐 예를 들어갖고
커버리지가 뭐
80, 90%
할까 90%가 된다고 그러면은
그
얘가 커버리지가 더 올라가려고 그러면은
아직까지 커버가 되지 않은
10% 남아있는 영역에
뭔가 랜덤한 입력이 생성이 돼야 되다 보니까
확률이 10분의 1로 줄어드는 거고
뭐 커버리지가 더 올라가가지고
95%가 됐다.
그러면은 여기에
그 커버리지가 올라가려면은
20분의 1의 확률로만
얘가 커버리지가 올라갈 거잖아요.
그러니까 뒤로 갈수록
커버리지가 올라가는 속도가
점점점점 느려지다 보니까
이제 여기서 조금 더
그 나아가면은
이게
다이렉티드 테스트랑
컨스트레인 랜덤이랑을
같이 쓰는 게
뒤쪽으로 가가지고는
효율적일 수 있습니다.
그러니까 처음에는
랜덤하게 쭉 테스트를 하다가
어느 정도 커버리지가 올라가면은
그 다음부터는 올라가는데
속도가 너무 오래 걸리니까
그때부터는 이제
다이렉티드 테스트로 전환을 해가지고
아직까지 테스트 못한
소수의 영역들에 대해서는
그냥 사람이 매뉴얼하게
그 테스트를 해주는 거죠.
뭐 그런 식으로 이렇게 섞어갖고
쓸 수도 있다는 얘기입니다.
그러면은 랜덤하이즈를 할 때
뭘 랜덤하게 할 수 있느냐
뭐 입력을 일단은
입력 데이터를 랜덤하시게 할 수 있는 게
제일 기본적으로 생각할 수 있는 거기는 하지만
이거 말고도
디바이스의 컨피규레이션을
랜덤하게 한다던가
이거는 어떨 때 쓰냐면은
어떤 블럭이 있는데
그 블럭을 내가 지금
뭐 예를 들면은
이 어떤 하나의 프로덕트에만 쓸 게 아니라
다양한 프로덕트에
뭐 재활용을 할 수도 있잖아요.
그러니까 그럴 때는
어떤 프로덕트에 얘가 쓰일지 모르니까
그런 것들을 이렇게
바꿔가면서 테스트를 해볼 수 있는 거죠.
그래서 뭐 그런 것도 할 수 있고
익셉션이나 딜레이, 에러
이런 것도 확인을 해볼 수가 있습니다.
랜덤하이즈를 할 수가 있어요.
그러니까 우리가 테스트를 할 때 꼭
정상적인 시나리오만 테스트를 하는 게 아니라
이게 비정상적인 상황에서도
얘가 정상적으로 그거를
익셉션 핸들링을 잘 하는지
이것도 확인을 해볼 필요가 있을 수 있잖아요.
그러니까 그런데도
이런 랜덤하이즈를 할 수가 있다는 거죠.
그 다음에 이거는 뭐 커버리지를 측정하는
그냥 결과를 보여주는 건데
이거는 툴마다 달라요.
저희가 지금 사용을 하려고 하는 거는
그냥 EDA 플레이그라운드에서 나오는 걸 쓰다 보니까
이런 식으로 뭐 GUI를 통해 갖고
커버리지가 나오지는 않고
그냥 텍스트 파일로
커버리지를 확인을 해볼 수가 있습니다.
어쨌든 이 화면은 GUI마다 다른데
어쨌든 이런 커버리지를 우리가
이게 측정을 해가지고
확인을 할 수가 있다는 겁니다.
그래서 일반적으로
다이렉티드 테스트를 쓸 때는
테스트벤치의 구조가 이렇게 생겼어요.
그래서 여기서 우리가 테스트를
그러니까 검증을 하고자 하는
어떤 설계가 있고
그 설계에다가
테스트벤치 쪽에서 입력을 넣어주고
그 설계로부터 나온 출력을
테스트벤치로 다시 입력을 받아갖고
테스트벤치에서
이게 정상적으로 수행된 결과인지를 판단하는
그런 구조를 갖고 있죠.
근데 이렇게 컨스트레인 랜덤을 쓰게 되면
테스트벤치 자체를
자동화를 해야 되기 때문에
그렇게 되면
이 테스트벤치를 만드는 게
사실 굉장히 시간과 노력이 많이 들어갑니다.
그래서 이거를
검증의 효율성
또는 검증의 생산성을 높이기 위한
일반적인 방법 중에 하나가
재활용을 최대한 많이 하는 거예요.
그래서 재활용성을 높이기 위한 방법들을
사람들이 이제 많이 이거를 사용을 하다 보니까
테스트벤치의 구조를
이런 식으로 쪼개놓으면
그러면은
이게 재활용성이 좋아지더라
해가지고
이런 그 구조로 테스트벤치를
이제 작성을 하는 거를
말하자면 일종의
베스트 노운 프랙틱스로
권장을 합니다.
그래서 이게 일종의
UVM에서 사용하는
그런 방법론이에요.
그러니까
이거를 이런 식으로 쪼개놓으면
이거를 쉽게 재활용할 수 있다는 거죠.
예를 들어갖고
이 DUT가
그
DMA라고 생각을 해볼게요.
그러면은
이 DMA는
이쪽에서
그 입력은
얘가
컨피규레이션을 해주는 거죠.
DMA한테 커맨드를 주는 거예요.
그래갖고
뭐 소스 어드레스는 어디서부터
데스티네이션 어디까지
뭐 몇 개의 데이터를 옮겨라
뭐 이런 식으로 커맨드를 주죠.
그러면은 이제 DMA가
이제 버스에 마스터 인터페이스를 써가지고
버스에 접근을 해가지고
메모리에 있는 데이터를 읽어서
다른 데다가 쓰겠죠.
그러면은
이 DMA가
실질적으로는
커맨드를 받기 위한
인터페이스가 있어요.
예를 들면 이게 APB라고 합시다.
그러면은
이 APB 프로토콜을
통해갖고
얘한테 입력을 줘야 될 거 아니에요.
그러니까 그 APB 프로토콜을
처리하는 부분이 말하자면
드라이버인 거예요.
그 다음에
이 에이전트는
이 제너레이터는
시나리오를 만들어주는 거예요.
그러니까 얘는
말하자면은
어떤 그 DMA가
뭐 0번
그러니까
0번 어드레스부터
그 100번 어드레스까지
있는 데이터를
1000번지에 딱 옮겨라
라고 하는 시나리오를
만들어주고
그러면은
이 에이전트는
뭘 해주냐면은
이 DUT도
이거를 세팅하기 위한
레지스터 맵이 있을 거 아니에요.
0번 레지스터에는
소울스 어드레스가 들어가고
4번 레지스터에는
데스티네이션 어드레스가 들어가고
이런 레지스터 맵이 있겠죠.
그러면은 그 레지스터 맵에
맞춰갖고
이 시나리오에서 만든
그 시나리오대로
레지스터에다가
라이트를 해주는 것까지를
이 에이전트가 담당을 하고
그러면은
이렇게 레지스터 맵에
맞춰갖고
어떤 데이터를
입력해주는 게 나오면
그거를 APB 프로토콜에
맞춰갖고
DUT에다가
이제 실제로
시그널 레벨로
전달을 해주는 거를
드라이버가 하는 겁니다.
그러니까 이런 식으로
이 시나리오를
제공하는 거를
이렇게
쪼개놓은 거예요.
이렇게 되면은
재활용성이 높아지는 이유는
만약에 내가
DMA가 지금은
APB를 통해갖고
입력을 받는데
이거를 내가
AXI 슬레이브 인터페이스로
바꿨어요.
그러면은
이거를
드라이버만
바꾸면 돼.
다른 거는
시나리오나
레지스터 맵
이런 거는
바뀐 게 없으니까
얘네들은
다 재활용할 수가 있고
드라이버만
APB에서
AXI 시그널로
바꾸는 걸로
그러니까
만들어주는 걸로
바꾸면 돼요.
그러니까
에이전트랑
제너레이터는
그대로 쓸 수 있는 거죠.
아니면은
DMA가 있는데
APB 인터페이스는
그대로 쓰는데
여기에 기능이
추가가 되면서
레지스터 맵이
바뀌었어.
그러면은
제너레이터랑
드라이버는
그냥 쓰면 되고
에이전트만
바꾸면 돼요.
그러니까
이런 식으로
이거를
쪼개놓으면
이게
그 부분적으로
필요한 부분만
교체를 해서
쓰면 되니까
재활용성이
높아지는 겁니다.
그래갖고
이게
어떻게 보면은
이게 재활용성을
높이는 거는
사실은 일반적인
방법이고요.
근데 이거를
테스트 벤치 쪽에서
보니까
테스트 벤치는
일반적으로
이런 구조를
가지면
여기서 말하는 건
일반적이라는 게
컨스트레인 랜덤
베리피케이션을
썼을 때
얘기기는 하지만
어쨌든
컨스트레인 랜덤
베리피케이션을
사용을 할 때는
이런 구조를
가지면
이게
가장
재활용성이
높다.
그렇게 볼 수가
있습니다.
그래서 이게
UVM에서
우리가 아까
제가
오전에 말씀드린
UVM 클래스
라이브러리가
딱
이런 식의
구조를 갖는
테스트 벤치를
말하자면은
템플릿으로
제공을 해요.
그러니까
UVM 클래스
라이브러리를
사용을 하면은
이 구조에
맞는
클래스들의
템플릿이
있어갖고
여기에
맞게 내가
예를 들어서
어떤 기능을
추가한다고
그러면은
에이전트 드라이버
이런 것들은
이미 다 있어요.
거기에
그러니까
그 맞는
템플릿에
들어가서
템플릿에
해당하는
클래스를
내가 원하는
대로 수정만
해주면은
테스트 벤치를
만들 수 있게
해줘요.
그래갖고
이 UVM 클래스
라이브러리를
쓰면은
이런 테스트
벤치를
만드는 거를
이렇게
딱
이 구조에
맞게
만들 수가
있습니다.
근데
그 UVM
클래스
라이브러리를
굳이
사용하지
않더라도
내가
그냥
스스로
드라이버
에이전트를
만들면
되는 거기 때문에
그 클래스
라이브러리를
굳이
사용하지
않아도
어쨌든
UVM은
할 수
있어요.
그리고
UVM에서는
제너레이터
에이전트
드라이버
다
나눠갖고
하면은
이게
재활용성도
좋아지고
다 좋다고
하는데
뭐 생각하기에
따라서는
이거를
굳이
이렇게
나눠놓지
않아도
어찌 됐든 간에
컨스트레인 랜덤을
써가지고
검증을 할 수
있거든요.
그러니까
그것도
이제
나는
그냥
이거
굳이
재활용할
생각 없고
그냥
내가 만든
IP
내가
그냥
검증하는
데만
쓸 거다
이러면
그냥
내가
원하는
내가
편한
대로만
테스트벤치를
만들어주면
되는 거니까
그거에
대해서는
필요에
따라서
이렇게
테스트벤치를
만들어주면
되는 겁니다.
그래서
어쨌든
이게
UVM에서
사용되는
클래스
라이브러리의
구조라고
이렇게 일단은
말씀드릴 수가
있겠고요.
여기까지가
시스템
베를로그에 대한
전반적인
소개였고
그 다음에는
이제
본격적으로
시스템
베를로그
문법에 대해서
설명을 드리도록
하겠습니다.
자
먼저 나오는 거는
이제
데이터 타입입니다.
여기
다시 말씀드리지만
여기서는
일단은
베를로그는
어느 정도
안다고
가정을 하고
베를로그에는
없는
추가적인
시스템
베를로그만의
그런 문법들에
대해서
주로 다루고
있어요.
물론
베를로그에
대해서도
간략하게
설명을 하긴
하겠지만
어쨌든
뭐
그런 거라고
보시면 돼요.
그래서
시스템
베를로그에서는
이제
full state
variable
이라고 하는 게
추가가 되었습니다.
그래서
하여튼 요거는
요약을 해놓은 거고
하여튼
그거는 제가
한 가지씩
자세하게 설명을
드릴게요.
먼저
two state
variable이라는 게
생겼는데
원래
베를로그는
four state
네 가지
state을 갖는
variable을 써요.
그러니까
0하고 1은
당연히
있는 건데
Z랑
X가
있습니다.
Z는
high impedance
고
X는
unknown
이에요.
그래서
항상
어떤
시그널이
있으면
그 시그널은
이
네 개
중에
하나의
값을
가질 수가
있어요.
그런데
이제
시스템
베를로그에서는
딱
두 개
0 아니면
1만
그
state으로
갖는
variable도
생겼습니다.
그러니까
예를 들면
이게
비트라고 하는
새로운
데이터
타입이 생긴 거예요.
이게
그
한
비트짜리
그
two state
variable인데
말하자면
이게
와이어
같은 거라고
보시면 돼요.
와이어는
한
비트짜리
그
four state
variable인 거죠.
그런데
시스템
베를로그에는
비트라고 하는
variable이 있는 거고
마찬가지로
이제
뭐
인티저
바이트
숏
인트
롱
인트
이런 애들이
전부
two state
variable
들인 겁니다.
그러니까
이게
뭐
사실은
그
이거는
주로
이런 거를
사용하는
목적은
시뮬레이션
속도를
높이고
시뮬레이터가
차지하는
메모리를
이렇게
공간을
줄이는
그런
주로
최적화의
목적으로
이거를
사용을 할 수가
있어요.
사용을 할 수가
있고
근데
여기서
한 가지
좀
조심해야 되는 게
이거예요.
만약에
four state
variable을
two state
variable에
assign을 한다고
할 때는
무슨 일이로
일어날까
예를 들면
어떤
와이어가
있는데
그 와이어는
0, 1, z, x 중에
하나의 값을
갖고 있을 수
있는데
이거를
비트에다가
assign을 해요.
그러면
이 와이어의 값이
0이나 1일 때는
상관이 없어요.
근데
z나 x였으면
그때는
이 비트로는
표현이 안 되는데
이렇게
assign을 하면
무슨 일이 일어날까
일단은
assign이 되기는 해요.
되는데
그냥 assign이 돼.
이게 무슨 말이냐면
z나 x가
0이나 1로
변환이 돼가지고
assign이 돼버려요.
근데 이게
별로 문제가
없을 수도 있지만
경우에 따라서는
이게 원하는
동작은
아닐 수가 있어요.
특히나
x 같은 경우에는
우리가
시뮬레이션을 할 때
얘는 반드시
확인을 해줘야 되는
것 중에 하나거든요.
그러니까
웨이브 폼을 딱
띄우면
제가 이제
베리로그 강의할 때
여기서는 베리로그
강의는 안 하지만
베리로그 강의할 때는
제가 항상 하는 말이
웨이브 폼을
띄웠는데
x가 보이면
그거는 무조건
해결을 해야 되는 거다.
x는 절대로
보이면 안 된다.
물론
리셋이 들어가기
전에는
x가 있을 수 있는데
리셋이 들어간
이후에도
계속 x가 보이면
그거는
무조건
해결을 해야 된다.
라고 얘기를 합니다.
그러니까
하는 게 보이는 게
얘가 지금
뭔가 문제가 있다는 걸
알려주는 거기 때문에
x가 없어져 버리면
문제가 있는데도
확인할 수가 없게 되는 거니까
이거는 그렇게
바람직한 상황은 아니거든요.
그러니까
이런 경우가 있을 수가 있어요.
그래서
이런 경우에 있어서는
이제
얘가
폴 스테이트인데
얘가
언노운 스테이트인지를
확인을 하고
퓨 스테이트 베리로그에다가
어사인을 해줘야 돼요.
그래서 그런 것들이
약간의
주의사항입니다.
제 개인적으로는
굳이
투 스테이트 베리어블을
쓸 정도로
큰 디자인에다가
시스템 베리로그를 적용해서
검증을 할 필요는 없다고 생각합니다.
개인적인 의견이에요.
개인적인 의견.
이건 거꾸로
다시 말씀드리면
투 스테이트 베리어블은
뭐
이런 이슈도 있고
또 베리로그랑 조금
헷갈리기도 하고
하기 때문에
뭐
굳이
안 써도 되는
그런 기능이라고
저는 개인적으로 생각을 해요.
근데 이런 거는
조금 이제 편리해진 게 있어요.
왜냐하면은
이
어레이를 선언을 할 때
베리로그 같은 경우에는
항상 이런 스타일로
선언을 해줬어요.
0에서부터
16
그러니까 16개의
엘리먼트를 갖는
어레이를 선언할 때는
베리로그 스타일로
항상 이렇게 선언을 했는데
이제는
C나 C플러스 같은
그 소프트웨어처럼
개수만
이렇게
지정을 해주면
동일한 의미로
어레이를 선언을 할 수가 있어요.
그래서 이거는 조금
편리해졌고
이게 뭐
1차원 어레이는
큰 차이가 없는데
4차원 어레이는
이게 이제 훨씬 편합니다.
그래서
뭐 이런 것들은
이제 시스템 베리로그에
추가된 기능이고요.
그 다음에
어레이를
선언을 하면서
동시에
이니셜라이즈 하는 것도
가능합니다.
여기서 이런
어퍼스트로피를 써가지고
이렇게
선언과 동시에
이니셜라이즈 하는 게
가능하고요.
그 다음에
이
4룹을 돌 때
4이치라고 하는 게
이제 또
추가가 됐어요.
근데 사실은 이거는
그
센서사이저블
섭셋은 아니에요.
그러니까
어차피 우리가
베리로그에서도
하드웨어를
합성하는
그런
합성하려고
하는 목적으로
하드웨어를
모델링을 할 때
4룹을 쓰진 않잖아요.
물론
뭐 쓰는 경우가
아예 없지는 않지만
그런데
이거는 주로
이제 테스트 벤치에
쓰이는 거예요.
마찬가지로
4이치도
이거는 테스트 벤치에
쓰는 그런
신텍스입니다.
의도는.
그래서
여기는 어쨌든 간에
이거는 테스트 벤치에
쓰려고 하는 거고
여기에서 보면은
4를 이렇게 하는 거에
비해갖고
조금 편해진 거는
4이치를 쓰게 되면
어떤 어레이가
있을 때
이 어레이에
처음부터
끝까지
모든 엘리먼트를
순차적으로
억세스를 해요.
그래서
4이치를
여기 보면은
4 같은 경우에는
인덱스 베리어블을
선언을 해주고
인덱스 베리어블을
초기화를 하고
그래서 그게
어디까지
터미네이션 조건을
명세를 해주고
각각의
아이테레이션 별로
뭘 해야 되는지를
다 프로그래머가
적어줘야 됐잖아요.
근데 이거를
요거 한 줄이면
끝납니다.
그래서
4이치 뒤에다가
어레이를 넣어주고
그 다음에
여기에
인덱스 베리어블을
그냥
이름만 이렇게
적어주면
요게 자동으로
생긴다고
보시면 돼요.
그러니까
0번부터
끝까지
1씩
증가하면서
이 엘리먼터를
하나씩
다 억세스를 해요.
그래서
요런
그 용도로
4이치를
쓸 수가 있습니다.
그래서
이거 같은 경우에는
그래도
좀 편리한
기능 중에 하나예요.
자 그래서
이거를 한번
이제 실습을
해볼 거예요.
그래서 이거는
아까 말씀드린
EDA 플라이그라운드에서
이거를
한번 직접
타이핑을 해가지고
해보시고요.
물론
이거를
카피앤페이스트를
하시면
금방 하실 수 있어요.
근데
제가
타이핑을
한번 해보시라고
권장을 드리는데
권장을 드리는 이유는
이거를
이제
타이핑을 하다 보면은
여러분들이
요런
구문에
대해 갖고
조금 더
잘
이해를
그러니까 익숙해지는
그런 측면도
있고
그 다음에
이게 그냥
말로만
설명 들었을 때는
그냥
뭐
그냥
그냥
그냥
그냥
별로 이렇게
신경 쓰지 않고
휙 지나가 버렸던
것들도
타이핑을
하다 보면은
그 말로
설명 들었을 때는
보이지 않던
디테일한 것들이
또 보여요.
그러니까
그런 것들을
여러분들이 한번
확인을 해보려면
타이핑을 한번
해보시는 게
어쨌든
제가 볼 때
도움이 됩니다.
그리고 이거 솔직히
몇 줄 안되는데
이거 타이핑하는데
뭐 한 2, 3분이면 해요.
그러니까
요걸 해보시고
그러면은
이거를
실습을
어떻게 하느냐
잠시만요.
EDA 플레이그라운드에
요렇게 들어가 보시면은
이거는 이제
그
요거를
로�인을 한 거예요.
그래서
아까 뭐
그
그 뭐야
회원 가입하라고
말씀을 드렸잖아요.
그러니까 회원 가입을 하시고
로�인을 하면은
이제 이 화면이 뜰 거고
그래서
요기 왼쪽에
요
그러니까 저희는 지금
시스템 베리 로그
요번 강의에서는
테스트 벤치만
만들 거예요.
그러니까
제가 지금
뭐
엑서사이즈라고 해가지고
말씀드린
이런 코드들은
전부
여기
테스트 벤치 쪽에다가만
작성을 해주시면 됩니다.
그러니까 요기
디자인 쪽은 그냥
아무것도 안 하셔도 돼요.
그래서 테스트 벤치 쪽에다가
이렇게 타이핑을 하시고
그 다음에
실제로 실행을 할 때는
왼쪽에 보시면은
딴 거는 뭐
특별히 바꾸실 거는 없고
요것만 바꾸시면 돼요.
요 툴을
지금 제가
뭐
제공해드리는
요 실습들은 전부
시납시스
VCS
요거를 기준으로
되어 있거든요.
이게 화면이 너무
작아가지고
네
그래서
그래서 말씀드린 대로
디자인 쪽은 안 해도 되고
테스트 벤치 쪽에다가만
앞으로
제가 드릴
엑서사이즈들은
전부
여기다가
타이핑을 하시면 되고요.
그 다음에
여기 왼쪽에 있는
여기서
요
그
툴만
시납시스
VCS로
선택을 하시고
그 다음에는
이 런 버튼을
눌르면
결과가 나올 거예요.
네
그래서
요게 나온 거를
확인을 해보시고
그래서 요 실습을 보시면은
실습이 지금
1번 실습하고
2번 실습이 있어요.
그래서 요거 두 가지를
한번
실행을 해보시고
그 다음에
제가 한 시간을
한 5분에서
10분 정도
드릴 테니까
각자 실행을 해보시고
실행 결과를 한번
확인해 보시죠.
그 다음에
요게 실행을 하시고
난 다음에는
제가
요 코드에 대해 갖고는
실험을 하고 난 다음에
설명을 드리도록
하겠습니다.
앞으로도 계속
수업은 이제
이런 식으로 진행될 거예요.
제가 수업 시간에
뭔가 설명을 하고
그 다음에
그 실습을
여러분들한테
제가 한 5분 내지
10분 정도
잠깐
실습 시간을 드리고
그래서 여러분들이
타이핑을 하고
실행도 시켜보고
뭐 여러분들이 원하면은
뭐 이것저것 한번
고쳐가면서
뭐 이것저것 한번
시도를 해보시고
그 다음에
그 실습이 끝나면은
제가 그 실습한
코드에 대해서
설명을 드리고
다음 진도 나가고
그 다음에 또
실습하고 이렇게
실습과
설명이 계속
왔다 갔다 왔다 갔다
하면서 반복을 할 거거든요.
그래서 이런 식으로
앞으로 진행이 될 거고요.
그러니까
뭐 쉬는 시간 없이
쭉 진행을 하기는 하지만
지금 뭐 실습할 때
필요하면
뭐 잠깐 화장실 갔다
오신다던가
아니면은 뭐
혹시나 저한테
뭐 질문 있으시면
와서 질문을 하신다던가
그런 시간으로
활용을 하시면 되겠습니다.
자 그러면
어쨌든
이번에는
첫 실습이니까
조금 더 시간을 드릴게요.
한 10분 정도
시간을 드릴 테니까
이거 한번
직접 타이핑을 해가지고
한번 실행을
시켜보시기 바랍니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
네.
뭐 잘 되고
있으신 거죠?
네.
무반응이
희반응이라고
아무 질문이 없으신 거 보니까
뭐 잘 되고 있다고 생각을 하겠습니다.
그래서 지금 실행을 해보신 두 개의
그 실습은
첫 번째 거는
첫 번째 거는
for each인데
이거는 아까 말씀드렸던 거고요.
근데 이 for each는 이렇게
그
뭐야
다중
다처원 배열에서도
동일하게 쓸 수가 있다.
이거를 이제
보여드린 거고요.
그래서 아까 실행 화면을
잠깐 보시면은
이 for each 해가지고
md라고 하는
그 멀티디멘전 array를
이렇게 두 개의
인덱스 variable로
이렇게만 해주면
얘가 알아서
이제
이 엘리먼트가
이제 여섯 개가 있는데
이 여섯 개를 전부
하나씩 돌아가면서
다 억세스를 해주는 거를
for loop을 돌면서
자동으로 해준다.
이게 그래서 좀
편리한 기능 중에 하나고요.
그 다음에는
이 operation을
이렇게
aggregate 형태의
operation이
가능해졌습니다.
그러니까
두 개의 이렇게
어레이가 있을 때
이거를
두 개의 어레이가
똑같냐
라고 하는
비교 연산자를 쓰게 되면은
이거는
요 각각의
어레이에 있는
각각의
엘리먼트들을
하나하나 다
비교해서 얘가
똑같은지
여부를
판단해주는
그런 operator입니다.
만약에
이거랑 똑같은 거를
소프트웨어
예를 들어갖고
c 같은 데서 했으면
사실은
c는 어레이의 이름이
포인터잖아요.
그러니까
요렇게 되면은
얘는 무조건
다르다고 나오기는 할 건데
어쨌든
그
베릴로그
시스템 베릴로그에서는
어레이의 이름을 가지고
비교하는
연산을 하게 되면
그
안에 들어 있는
각각의
엘리먼트들을
하나하나 다 비교해서
얘가
전부 똑같은지를
판단해주는
그런
그 오퍼레이터로
활용이 됩니다.
어사인하는 것도
가능해요.
그래서
어레이를 이런 식으로
통째로
어사인을 하는 게
가능하다는 거고요.
그래서 이게
편리한 기능이기는 한데
이게
어떻게 생각하면은
또 c나
이런 소프트웨어
랭기지에
익숙한 사람한테는
약간 좀 헷갈릴 수
있는
뭐 그런 기능이기도
합니다.
자 다음에는
이게
다이나믹 어레이도
지원을 합니다.
물론
다시 말씀드리지만
여기서 지금 저희가
설명드리고 있는 거는
테스트 벤치에 쓰는 거를
얘기를 하는 거예요.
다이나믹 어레이 같은 거를
하드웨어로
합성은 못하겠죠.
못하는데
테스트 벤치 쪽에서는
저희가
어차피 이거는
시뮬레이션만
할 거니까
여기서는 우리가
테스트 벤치 만들 때는
이런 것들을
충분히 활용을 할 수가 있습니다.
그래서
다이나믹 어레이 같은 경우에는
C나 C++처럼
런타임에
이 어레이의
엘리먼트의
개수를
바꿔볼 수 있는 거죠.
그래서 선언을 할 때는
이런 식으로 선언을 합니다.
그래서 이렇게
어레이니까
이 대괄호가
들어가기는 하지만
이 대괄호 안에
이 어레이의
엘리먼트의 개수가
몇 개다
라고 하는 거는
이제
없는 상태로
이거를 선언을
할 수가 있습니다.
그래서 이렇게 선언을
일단은 해놓고
여기서 이제 우리가
엘리먼트 5개짜리
어레이를 만들어야 되겠다.
그러면은
이런 new라고 하는
명령어
또는 뭐
오퍼레이터라고 할 수도 있고요.
이 오퍼레이터를
이용을 해가지고
이 어레이가
다섯 개짜리
엘리먼트를 갖는
어레이다.
라고 하는 거를
여기서 이렇게
런타임에
결정을 해 줄 수가 있습니다.
물론 이 new라고 하는
오퍼레이터의
뒤에 들어가는
이 숫자는
이거는 이제
상수가 아니라
변수도 가능합니다.
그 다음에
얘는 뭐 이렇게
for each 같은 거를
통해 갖고
하나씩 이렇게
억세스를 할 수도 있고요.
그 다음에 이렇게
통째로
어사인하는 것도
가능하고
그 다음에
각각의
엘리먼트 억세스 하는 것도
되고요.
그렇습니다.
그 다음에 또 한 가지는
이런 것도
가능해요.
여기서
카피를 할 수가 있어요.
카피.
그래서 새로운
어레이를
얼로케이션을 할 때
뒤에
이런 식으로
파라미터를
기존에 있는
어레이를
주게 되면
20개짜리
어레이를
새로 만들면서
기존에 있었던
5개짜리
어레이를
카피를 해 줍니다.
그러니까
결국은 이거를
카피를 하면서
20개짜리에다
카피를 하니까
결국은
5개짜리를
20개짜리로
늘리는 효과가 있죠.
이렇게 되는 것도 되고
그 다음에는 얘를
오버라이스를 해 주기도 해요.
이렇게
오버라이스를 하게 되면
얘를
기존에 그러면
5개짜리
여기 같은 경우는
이 순서대로 실행하면
20개짜리
어레이가 최종적으로
이 다이나믹 어레이라고 하는
이 변수에
지금 할당이 되어 있는데
이거를
100개짜리로
교체를 하게 되면
기존에 있었던
이 20개짜리는
그냥
없어지게 됩니다.
없어지게 되고요.
아니면
이게
시스템 베릴 로그는
가비지 컬렉션을 해요.
나중에 가서 설명을 드리긴 하겠는데
가비지 컬렉션을 하기 때문에
여기
20개짜리
이 어레이가
이제 더 이상
레퍼런스가 되는
그러니까 핸들이라고 하는데
시스템 베릴 로그에서는
이거를 레퍼런스 하는 핸들이
더 이상 없어지게 되면
가비지 컬렉터가 알아서
얘를 지워줍니다.
그래서 시스템 베릴 로그는
가비지 컬렉션이 돼요.
그렇기 때문에
굳이 이런 식으로
딜리트를 하지 않고
그냥 이런 식으로
오버라잇을 해버려도
시뮬레이터에서 알아서
사용하지 않는 어레이는
알아서
삭제를 해줍니다.
자 그러면은
그 다음에 또
두 개의
그 엑서사이즈가 있어요.
요것도
한번 실행을 해보시고
제가 또 실행을 하고 나면
그거에 대해서
설명을 드리도록 하겠습니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
여러분
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
이 실습에서 구현을 해보신 거는 Q랑 그 뒤에 보면은 어소시에이티브 어레이 이거 두 가지를 해보신 거죠.
그래서 채팅창에 보니까 질문하신 게 이 Q하고 달러 사인이 뭐냐라고 질문을 주셨는데 이거 안 그래도 설명을 드리려고 한 건데
이 달러라는 뜻의 뜻은 이게 이 Q라는 데이터 구조다.
이게 그냥 어레이가 아니라 얘가 만약에 달러가 없으면 얘는 그냥 어레이인데 달러가 없고 숫자가 없으면 얘는 그냥 다이나믹 어레이인 거죠.
방금 전에 설명드렸던.
근데 여기다 달러를 넣게 되면은 이거는 Q라는 뜻이고 그래서 이게 Q이기 때문에 여기서 있는 이제 인서트 딜리트 이런 함수들을 쓸 수 있는 거죠.
이거를 뒤에 거랑 비교해 보시면은 여기서는 지금 이 별표를 쓰고 있잖아요. 이 에스터리스크가 들어가니까 얘는 어소시에이티브 어레이다라는 뜻으로 이걸 쓴 겁니다.
그러니까 결국 이 앞에 있는 그러니까 이 지금 그 뭐야 이 어레이의 타입이 뭔지를 알려주는 그런 역할을 하는 게 이 달러랑 에스터리스크 별표가 그 역할을 한다고 보시면 되겠습니다.
그래서 여기 자이번째 엑서사이즈에서는 이 Q에 관련된 여러가지 함수들을 지원을 하는 거를 사용을 해보신 거예요.
이것도 전부 시스템 베를로그에서 빌트인으로 제공을 하는 겁니다.
그러니까 뭐 C++ 같은 데서 스탠다드 라이브러리들이 있잖아요.
그러니까 그런 거랑 뭐 유사하다고 보시면 돼요.
그래서 여기서 보시면은 뭐 인서트 딜리트 뭐 푸시 프론트 푸시 백 뭐 이런 것들을 지금 지원을 하는 거를 지금 보고 계시죠.
그래서 여기서는 뭐 이런 것들에 대한 의미는 뭔지는 뭐 제가 굳이 설명을 안 드려도 옆에 있는 커멘트를 보시고 실행을 시켜보셨으니까
대충 무슨 뜻인지는 아마 쉽게 파악을 하실 수 있을 것 같아요.
여기 이름도 보고.
그래서 이게 Q라고 하는 이름으로 되어 있기는 한데 실질적으로는 보시면은 얘가 사실 Q는 한쪽에서 푸시하고 반대쪽에서 판만 하는 게 Q잖아요.
근데 여기는 아무데서나 푸시를 할 수도 있고 중간에다가 끼워놓을 수도 있고 뭐 빼내는 것도 중간에서 뺄 수 있고 아무데서나 빼낼 수가 있습니다.
그렇기 때문에 이건 어떻게 보면은 C++로 치면은 벡터에 가까운 그런 자료구조라고 볼 수가 있어요.
그래서 시스템 베를로그에서는 Q라고 부르지만 뭐 실질적으로는 벡터에 가까운 그런 자료구조입니다.
그래서 요거를 쓰게 되면은 이제 요런 벡터 같은 그런 역할을 하는 데이터 구조를 이제 그거를 이제 프로그래머가 직접 만들어줄 필요가 없이
여기 시스템 베를로그에서 기본적으로 제공하는 이 자료구조를 쓸 수가 있어서 상당히 편리하게 쓸 수가 있고요.
어소시에이티브 어레이도 있습니다.
어소시에이티브 어레이라고 하는 개념은 일단은 기본적으로는 원래 소프트웨어 쪽에서 있는 개념이고
물론 C나 C++ 같은 그런 뭐 전통적인 스트럭셔럴 랭기지에는 이런 어레이가 없고
뭐 조금 뭐 최근에 나오는 파이썬이나 뭐 이런 그 스크립트 기반의 랭기지 쪽에서
이런 것들을 지원을 하기 시작을 했죠.
그러니까 어소시에이티브 어레이 같은 경우에는 말하자면은 메모리에 이게 얼로케이션이 될 때
일반적인 어레이는 모든 그 어레이의 크기만큼 연속된 메모리 공간에
걔네들이 다 할 땅이 되잖아요.
그래서 예를 들어갖고 내가 100개짜리 엘리먼트 100개의 엘리먼트를 갖는 어레이를 내가 하나 선언을 했다.
그러면은 그 100개의 엘리먼트를 다 쓰던 안 쓰던 어쨌든 그 100개의 엘리먼트에 해당하는 메모리가
연속적인 메모리 공간에 다 할 땅이 됩니다.
근데 어소시에이티브 어레이는 그렇지 않아요.
어소시에이티브 어레이는 말하자면은 일종의 스팔스 어레이라고 볼 수가 있고
얘는 사용하는 엘리먼트만 메모리에 저장이 그때그때 되고
그렇기 때문에 얘가 항상 연속적인 공간에 다 저장이 되는 건 또 아닙니다.
그래서 이거 같은 경우에는 인덱스는 굉장히 커가지고
큰데 실질적으로 사용되는 엘리먼트는 몇 개 없는
그런 스팔스한 어레이 같은 경우에는 이런 어소시에이티브 어레이를 쓸 수가 있죠.
그래서 그런 거를 쓰는데 이제 이런 어레이를 활용을 할 수가 있습니다.
그 다음에 이 어소시에이티브 어레이에도 이런 여러 가지 지원해주는 펑션들이 있어요.
얘는 이 연속적인 공간에 이 메모리가 할 땅이 되는 게 아니고
그러다 보니까 여기에 있는 인덱스들이 순차적으로 배열되어 있지 않아요.
그러니까 모든 인덱스가 다 엘리먼트를 갖고 있는 건 아니기 때문에
모든 인덱스에 대해서 다 메모리 공간이 할 땅이 되는 건 아닌 거죠.
그러니까 일반적인 4룹을 돌면서 물론 여기서 보시면은
얘는 이런 for each를 쓰면은 뒤에 보이는 이게 그냥 자동으로 돼요.
그러니까 이 for each가 생각보다 굉장히 쓸모가 많아요.
그런데 어쨌든 여기서 이제 이 for each가 실질적으로 해주는 거는
이거를 한다고 보시면 돼요.
그러니까 어떤 어소시에이티브 어레이에서
첫 번째 인덱스에서부터 시작을 해가지고
그 다음 다음 다음 인덱스들을 하나씩 하나씩
아이터레이션을 돌면서 억세스를 해주는 거를
이 for each가 해주는 거라고 보시면 되겠습니다.
그런데 그거를 for each를 안 쓰고
이제 프로그래머가 직접 이거를 룹을 돌려고 그러면
그때는 이런 first라든가 next라든가
이런 것들을 이용을 해가지고
이제 이 어소시에이티브 어레이를 억세스를 해야 됩니다.
그 다음에 이 어소시에이티브 어레이가 또 좋은 점 중에 하나는
이런 인덱스를 꼭 숫자로 하지 않아도 된다는 거예요.
그래서 이거 같은 경우에는 c++로 치면은
딕셔너리 같은 그런 기능이라고 보시면 되겠습니다.
여기서 보시면은 스위치라고 하는 어소시에이티브 어레이가 있는데
이 어레이에는 인덱스가 민 어드레스라고 하는 스트링을
얘는 지금 인덱스로 받고 있어요.
그러니까 이 민 어드레스라고 하는 하나의 스트링이
인덱스의 역할을 하는 거죠.
그리고 이것만 있는 게 아니라
뭐 맥스 어드레스라든가 그런 여러 가지 것들을
다 이 어레이에다가 이제 저장을 해놓을 수가 있습니다.
그래서 이거를 사용을 하게 되면은 이제
여기 같은 경우에는 지금 일종의 컨피규레이션 파일을
읽어갖고 그거를 이런 스트링으로 인덱스를
인덱싱을 하는 어레이에다가 넣어놓은 거예요.
그래서 그 어떤 베리어블이 있는데
그 베리어블 설정 변수가 있으면
그 설정 변수의 값을 어소시에이티브 어레이에다가 집어넣고
이거는 설정 변수의 이름을 인덱스로 쓰고
그 설정 변수의 값을 그 엘리먼트의 값으로
이렇게 활용을 한 예인 거죠.
그래서 이거를 이제 이런 식으로 쓸 수 있다는 얘기고
이거 말고도 어찌됐든 간에 어떤 어레이가 있을 때
인덱스를 스트링으로 쓸 수 있으면
여러 가지 용도로 쓸 수가 있습니다.
그리고 어레이의 리덕션 펑션을 지원을 합니다.
사실 이 리덕션 자체는 베리로그에도 있는 문법이죠.
그런데 베리로그에 있기는 하지만
그 어레이에도 이거를 적용을 할 수가 있다는 거예요.
대신에 어레이에다 적용을 할 때는 이런 식으로
함수를 호출을 하는 형식으로 여기에 적용을 합니다.
그래서 예를 들면 여기 보시면
이제 뭐 이런 썸이라고 하는 그런 그게 있어요.
리덕션이 있어요.
그러면 이 어레이가 있을 때
그 어레이가 가지고 있는 각각의 엘리먼트들을 다 더한 값이
여기에 이제 출력으로 나오게 되겠고
뭐 프로덕트 같은 경우에는 다 곱한 값
엔드는 모든 엘리먼트를 빛, 와이즈, 엔드를 한 값
O와 XO와 다 마찬가지고요.
그래서 이거는 기본적으로는
이제 베리로그에서 지원하는 리덕션을
어레이에도 사용할 수 있다.
뭐 이렇게 이해를 하시면 되겠습니다.
그 다음에 어레이에도 또 이렇게 몇 가지
좀 유용한 기능들이 있어요.
그래갖고 이거는 뭐 시스템 베리로그에서만
쓸 수 있는 기능들이기는 합니다.
예를 들어갖고 어떤 어레이가 있는데
그 중에서 최소값을 찾거나 최대값을 찾거나
뭐 이런 것들은 이 함수 하나 호출을 하는 걸로
다 구현이 되어 있습니다.
그 다음에 이 유닉 같은 경우에는 뭐냐면
어레이 같은 경우에는 얘는
그 뭐야 집합은 아니기 때문에
중복되는 엘리먼트가 있을 수 있잖아요.
여기 보시면은 f라고 하는 어레이에 보면
1, 6, 2, 6, 8, 6 해가지고
6이 세 번이나 나와요.
그런데 얘를 유닉이라고 하는
이 함수를 호출을 하게 되면
얘를 집합처럼 만들어줍니다.
다시 말해서 중복되는 엘리먼트들을 다 제거를 해줘요.
그래서 이 f라는 것을 유닉을 호출을 하게 되면
여기 보이시는 것처럼 1, 6, 2, 8이라고 하는
그런 중복된 엘리먼트가 제거된 집합으로
이게 그 값이 리턴되게 됩니다.
그래서 이런 것들을 또 이제 시스템 베리로그에서
기본적으로 제공을 해주고요.
그 다음에 그 밑에 보시면은
인라인으로 어떤 리덕션을 할 때
조건을 줄 수가 있어요.
그래서 예를 들어갖고 내가
sum이라고 하는 그런
리덕션 함수가 있다고 말씀을 드렸는데
sum을 호출을 하게 되면은
이 어레이에 있는 모든 엘리먼트들을
다 더해주는 기능인데
이거를 그냥 더하지 말고
어떤 특정한 조건을 만족하는 엘리먼트만
더하도록 그렇게 할 수가 있습니다.
그래서 그때 쓰는 키워드가
with라고 하는 키워드를 쓰고요.
이 with 뒤에 조건을 이런 식으로 주게 되면
7보다 큰 엘리먼트들에 대해서만
sum을 수행을 해라.
라고 하는 명령이 되겠고
그 다음 거는 8보다 작은 것들에 대해서만
sum을 해라.
라고 하는 그런 의미가 되겠습니다.
그래서 이런 편리한 기능들이 있다는 얘기고요.
근데 제가 이제 한 가지 조금
제가 잘 이해가 안 가는 부분은
제가 이걸 설명하기가 좀 어렵기는 한데
여기서는 sum이라고 하는
리덕션을 썼는데
실제로는 카운트를 해줘요.
이게 잘 이해가 안 가더라고요.
왜 그런지 솔직히 잘 모르겠어요.
설명하기가 좀 어려운데
아이템이 7보다 큰 거에 대해 갖고
sum이라고 하는 리덕션 함수를 호출하면
결과가 2가 나와요.
그러니까 여기 있는 이름만 놓고 보면
7보다 큰 거 9랑 8을 더해 갖고
17이 나와야 될 것 같은데
그냥 개수만 나와요. 개수만.
이게 참 저도
이게 뭐라 설명을 해야 될지 모르겠는
이게 뭐
뭐 타입이라도 비트면은 모르겠는데
비트도 아니고
이게 sum이
이 d가 지금 인티저인데
인티저를 sum을 했는데
이게 왜 카운트가 리턴이 되는지
하여튼 그건 잘 모르겠습니다.
그래서 이거는 조금 제가 아직까지도
풀리지 않는 의문이고
근데 어쨌든 간에 이런 것들을 호출을 할 때
이렇게
인라인 조건을
줄 수가 있다는 게
뭐 이게 그냥
여기 시스템 베리로그에서
지원을 한다는 것 정도로만
이해를 하시면 될 것 같고요.
자 그 다음에 또
엑서사이즈를 하나 더 해보도록 하겠습니다.
이거는 간단한 거니까
시간은 그냥 잠깐만 드릴게요.
그래서 파인드라고 하는 게 있어요.
그래서 그걸 한번 사용해 보는 예를
간단하게 한번 실행을 한번
해보시기 바랍니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
네 이거는 뭐 금방 하셨을 거라고 생각을 하고요.
이거는 여기 나와 있는 이 의미대로
뭐 찾아줍니다.
그러니까 그 아이템이 3보다 큰 거에 대해 갖고
찾아주는 뭐 그런 기능을 하고 있고요.
그러니까 이게 뭐 어쨌든
뭐 필요할 때
이런 기능들이 있다는 걸 기억을 하시면은
이제 그 어떤 어레이에 대해 갖고
뭔가 내가 원하는 걸 찾거나 할 때
뭐 사용을 하실 수가 있습니다.
그 다음에 여기서도 보시면은
뭐 꼭 그 해당 조건에 만족하는
엘리먼트를 찾아주는 거 외에도
이런 식으로 뭐 인덱스를 찾거나
아니면은 여러 개의 엘리먼트가 있을 때
첫 번째 거를 찾거나
아니면 첫 번째로 찾아진 거에 인덱스만을 리턴을 하거나
뭐 마지막 거를 찾거나 이런 식으로
다양한 파인드에
뭐 일종의
뭐 일종의
뭐 이런 그 유사한 그런 시리즈의
그런 그 도구들이 있습니다.
그 다음에 이제 타입 데피니션이라고 하는
또 새로운 키워드를 제공을 하는데요.
뭐 베릴로그에서는 일반적으로 이런 식으로 쓰죠.
디파인을 씁니다. 디파인.
그래서 디파인을 쓸 수도 있기는 하지만
이제 파라미터라든가
타입 데피니션 같은 거를 써서
이것도 이제 뭐 C랑 유사한 그런 소프트웨어 쪽에서 나오는 스타일인 거죠.
그래서 뭐 이런 식으로 쓰는 것도 이제 뭐 가능하다는 얘기고요.
그 다음에 스트럭쳐도 이제 쓸 수가 있습니다.
그래서 이런 식으로 스트럭쳐를 쓸 수가 있고
그 다음에 팩트라고 하는 거를 쓰게 되면
이것도 이제 뭐 그 C랑 이런 소프트웨어 쪽에서 나오는 거랑 개념이 기본적으로 똑같은데
이 팩을 안 쓰면
이 스트럭쳐 안에 들어가 있는 각각의 엘리먼트들은
그냥 32b씩 메모리를 차지를 하게 됩니다.
왜냐하면 이제 기본적으로 우리가 돌리는
그 머신이 이제 32b 머신이라고 가정을 하면
그 32b을 이제 사용을 하게 되고요.
근데 여기 보시면은 RGB 각각의 엘리먼트들은
8비트씩밖에 필요가 없거든요.
근데 메모리는 32b씩 차지를 하고 있게 되는 거죠.
이렇게 32b씩 차지를 하게 되면 어쨌든
이게 억세스 속도가 좋으니까
이제 퍼포먼스 측면에서는 이득이 있는데
근데 이제 메모리 공간의 효율성 측면에서는 낭비가 있으니까
이 팩트라고 하는 이 키워드를 사용을 하게 되면은
여기에 딱 필요한 만큼만 메모리 공간이 할당이 되게 됩니다.
대신에 근데 이게 R이나 G나 B 같은
하나의 엘리먼트를 억세스를 하게 되면
실질적으로는 얘를 하나만 딱 읽어오는 게 아니라
그 32b을 통째로 읽어온 다음에
거기서 필요한 부분만 이렇게 추출을 하는 형식으로
그런 식으로 실제로 구현이 될 수밖에 없어서
이거를 억세스하는 데는 조금 더 시간이 걸립니다.
그 다음에 유니언은 이것도 C 같은 데서 쓰이는 유니언이랑
동일한 의미입니다.
그래서 예를 들면 여기서 보면
인티저 I랑 리얼 F라고 하는 게
유니언의 멤버로 선언이 되어 있으면
I랑 F가 결국 동일한 메모리 공간을 공유를 하는
그런 상황을 그런 거라고 보시면 되겠습니다.
그 다음에 이누머레이션 타입도 지원을 하는데요.
이런 식으로 이것도 이제 기본적으로는
C에서 쓰이는 이누머레이션 타입하고
동일한 문법을 가집니다.
그리고 이것도 마찬가지고요.
어떤 이누머레이션 타입에다가는 숫자를 지정을 안 해주면
그냥 디폴트로 0, 1, 2 이렇게 순서대로 어사인이 되는데
내가 특정한 엘리먼트를 특정한 숫자로 어사인을 하고 싶으면
이렇게 어사인을 하는 이 오퍼레이터를 써가지고
숫자를 내가 지정을 해줄 수가 있습니다.
그래서 이렇게 되게 되면
이닛은 0, 디코드는 2,
그 다음에 아이들은 디코드가 2니까 그냥 더하기 1을 해서 3
이런 식으로 이제 숫자가 부여가 되죠.
근데 여기서 한 가지 또 이제 주의사항은 뭐가 있냐면
이누머레이션 타입을 1번부터 시작하도록 예를 들어서 만들었어요.
그러면은 퍼스트는 1, 세컨드는 2, 서드는 3
이런 식으로 어사인을 하게 되는데
이 이누머레이션 타입을 갖는 변수를 이렇게 딱 선언을 하게 되면
이 변수는 시스템 베릴로그에서는 일단 무조건 0으로 이니셜라이즈가 됩니다.
이게 이제 C나 이런 데서는 보통은 다 얘가 그냥 쓰레기 값으로 이니셜라이즈가
이니셜라이즈가 안 되는 거죠. 기본적으로.
안 되는데 시스템 베릴로그에서는 변수를 선언을 하면은
뭐 0으로 기본적으로 이니셜라이즈가 됩니다.
근데 문제는 얘가 이누머레이션 타입인데
0이라는 값은 이누머레이션 타입에 정의가 되어 있지 않잖아요.
이렇게 되면은.
왜냐하면 얘는 1, 2, 3만 갔는데
이니셜밸류는 여기에 정의되어 있지 않은 0이라는 값을 갖게 되니까
이게 뭐 문제가 있을 수도 있고 없을 수도 있지만
어찌됐든 간에 이게 바람직한 상황은 아니기 때문에
이렇게 하고 싶으면 어쨌든 0이라고 하는 값을
이런 식으로 이누머레이션 타입에다가 정의를 해 줄 필요는 있다는 겁니다.
그래서 이런 게 약간의 사소한 거기는 하지만
주의사항이라고 말씀드릴 수가 있겠고요.
그 다음에 이누머레이션 타입도 이런 식으로 여러 가지
그런 멤버 함수들을 가지고 있습니다.
그래서 첫 번째 엘리먼트라든가 다음 거라든가
이런 식으로 몇 가지 이런 유용한 펑션들을 제공을 하고 있고요.
그래서 그거 관련해가지고 한번 또 엑서사이즈를 해보도록 하겠습니다.
바로 이어갖고 다음 엑서사이즈도 나오니까
그거 두 개 한꺼번에 진행을 한번 해보시죠.
이 여섯 번째 엑서사이즈 실습은
이제 이누머레이션 타입에 관련된 거고
다음 거는 이제 그 뭐야
문자열에 관련된 겁니다.
그러면 실습하시고 제가 또 그거에 대해서
코드에 대해서는 또 설명을 드리도록 하겠습니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
이 여섯 번째 실습에서는 이누머레이션 타입을 타입 캐스팅하는 거에 대해서 몇 가지 얘기가 나오는 게 있는 겁니다.
그러니까 이누머레이션 타입은 기본적으로 문자와 숫자가 약간 이렇게 서로 왔다 갔다 하면서 쓸 수 있게 해주는 그런 편리한 기능이기는 한데
이렇게 타입 캐스팅을 할 수가 있다는 거죠.
그래서 사실은 이거를 숫자를 그러니까 이누머레이션 타입을 인티저 타입으로 캐스팅하는 거는 별 문제가 없습니다.
왜냐하면 뭐 이 인티저 타입이 훨씬 더 표현할 수 있는 숫자의 범위가 크니까요.
근데 이걸 거꾸로 인티저 타입을 이누머레이션 타입으로 타입 캐스팅을 하게 되면
잘못하면 이 이누머레이션 타입이 없는 숫자가 타입 캐스팅이 되는 수가 있어서 이 경우는 좀 조심이 필요하다는 거죠.
그래서 이런 식으로 그냥 캐스팅을 그냥 체크를 하지 않고 하게 되면은 할 때는 문제가 없는 경우도 있지만 문제가 생길 수도 있으니까
이 밑에 있는 것처럼 이런 캐스트라고 하는 그런 오퍼레이터를 써가지고 하게 되면 얘는 이제 캐스팅이 정상적으로 되는지까지도 확인할 수 있게 해주기 때문에
이게 더 안전한 방법이다. 그렇게 이해를 하시면 되겠습니다.
그 다음에는 이제 스트링에 관련된 겁니다. 스트링도 이제 여기서는 시스템 베릴로그에서는 기본적으로 제공을 해주는 그런 기능 중에 하나입니다.
그래서 굉장히 뭐 이것도 실제로 그 뭐 테스트 디버깅 같은 거를 위해 갖고 아무래도 디버깅 메시지 같은 것들을 출력을 하게 되는데
테스트 벤치를 짜다 보면은요. 그러니까 그런 디버깅 메시지를 잘 이렇게 뭐 이렇게 조작을 해가지고 디버깅 메시지를 만들 때
이런 기능들을 사용을 할 수가 있습니다. 그래서 이거는 뭐 모든 스트링에 관련된 그런 함수들을 다 지금 보여주고 있는 것은 아니고
이거는 이제 뭐 시스템스 레퍼런스 매뉴얼 같은 거를 검색을 해보시면 거기에 그 뭐 특정한 시뮬레이터가 지원하는 모든 함수들이 다 나와있기는 할 거거든요.
여기는 이제 뭐 대표적인 것들만 좀 해놓은 거고요. 많이 쓰는 거라고 제가 보여지는 거는 이런 거 뭐 서브 스트링 같은 거.
그러니까 어떤 문자율이 있는데 그 중에서 일부를 이렇게 추출해내는 뭐 그런 것들 좀 많이 쓸 수 있고
그 다음에 이거는 그 프린트 F인데 그 포맷에 맞춰 갖고 프린트 F를 할 수가 있잖아요.
근데 그거를 프린트 F를 하는 게 아니라 프린트 F를 한 포맷티드 스트링을 반환해주는 뭐 그런 함수가 있습니다.
그래서 이거를 사용을 하게 되면은 뭐 C 같은 경우에는 S프린트 F 같은 뭐 유사한 역할을 한다고 볼 수 있겠죠.
대신에 S프린트 F는 이제 그 첫 번째 인자에다가 이 포맷티드 스트링이 그 뭐야 저장이 되는데
근데 여기 같은 경우에는 아예 리턴 값으로 그 포맷티드 스트링이 리턴이 되게 됩니다.
그래서 그런 식으로 하는데 이제 활용할 수 있는 함수들이 있고요.
그래서 어쨌든 스트링에 관련된 것도 시스템 베리로그에서 많이 보강이 돼가지고
굉장히 뭐 필요한 거는 하여튼 필요한 것들을 편리하게 사용을 할 수가 있습니다.
자 그래서 여기까지가 이제 그 데이터 타입에 관련된 것들을 쭉 한번 설명을 드렸고요.
오늘 이제 계획된 강의 계획에 따르면 하여튼 해야 될 거는 다 했고
그래서 오늘 그 계획을 보시면 1일차 때 디자인 베리피케이션 메소드에 대해서 전반적으로 말씀을 드렸고
베리피케이션 가이드라인 설명 아까 뭐 인트로덕션에서 간단하게 설명을 드리고
데이터 타입을 한번 쭉 설명을 드렸습니다.
그리고 이제 내일부터는 이제 문법들 중에서 뭐 스테인먼트라든가 뭐 OOP
그 다음에 뭐 인터페이스 랜더마이제이션 뭐 이런 것들에 대해서는 내일 배우도록 하겠습니다.
자 그래서 오늘 수업은 이 정도로 이제 시간이 다 돼서 마치려고 하는데요.
시간이 조금 남았는데 혹시 질문 있으신 분 있으세요?
네 온라인으로 참여하시는 분들 중에서도 혹시 질문 있으신 분 있으신가요?
네 온라인으로 참여해주세요. 그 골드 레벨을 이용해서 DUT라고 보통 하는데 내가 만든 설계된 부분을 이제 자동으로 확인할 수 있는 그런 방법이 필요합니다. 그래갖고 이 트랜잭션 레벨 모델링이 그래서 필요한 거고요.
그 다음에 이거랑 또 같이 쓸 수 있는 게 Assertion입니다. 그러니까 Assertion 같은 경우에는 소프트웨어를 쓰는 거니까 이거를 통해서 지금 현재 수행 중인 실행하고 있는 테스트 벤치의 결과가 정말 내가 원하는 대로 나오는 게 맞는지를 확인하는 자동으로 확인하는 그런 방법을 사용합니다.
그 다음에 마지막에 다룰 거는 커버리지 드리븐 베리피케이션인데 이거는 내가 이게 랜덤하게 입력을 생성을 해가지고 검증을 하다 보면 이게 테스트 케이스가 굉장히 많아져요.
많아지기는 하는데 내가 이 정도면 충분히 검증을 했나? 이거를 확인할 방법이 필요하죠. 다시 말하면 언제 이 검증을 멈춰야 되나? 이거를 확인할 수 있는 방법이 필요합니다.
그래서 허버리지라고 하는 거를 정의를 해서 허버리지가 예를 들어갖고 95% 이상이 되면 그러면 내가 충분히 검증했다고 생각하고 이제 이거는 검증은 이 정도면 끈대도 되겠다.
뭐 이런 것들을 이제 정량적인 근거를 통해서 판단을 할 수가 있는 거죠. 그래서 이런 것들이 방금 말씀드린 이런 개념들이 UVM에서 가장 핵심적인 개념이라고 말씀드릴 수가 있고요.
그래서 그런 것들을 다 다루게 될 거고. 그 다음에 근데 이제 UVM이라고 하는 거에 대해서 제가 많은 말을 들어갖고 자꾸 이렇게 말씀을 드리는 건데
UVM은 정확하게 그게 약자가 Universal Verification Methodology예요. 그러니까 Methodology예요. 이거는 방법론.
그렇기 때문에 이거는 개념이기 때문에 이거를 어떤 방식으로 구현을 할지는 사실은 그거는 구현의 이슈거든요.
그 UVM을 시스템 베릴로그로 구현해도 되지만 시스템 C를 써가지고 구현하기도 하고 제가 사실은 한 몇 년 전에는 시스템 C를 이용한 검증 방법론에 대해서도 강의를 했었거든요.
그랬는데 그걸 하다 보니까 사람들이 요즘 시스템 C는 별로 안 쓰고 시스템 베릴로그를 많이 쓰니까 시스템 베릴로그를 해달라고 해서 이걸로 바꾼 건데
근데 어쨌든 개념은 똑같아요. 똑같은 개념인데 그거를 구현하는 랭기지가 시스템 C냐 시스템 베릴로그냐 그 차이밖에 없는 거죠.
근데 또 UVM 같은 경우에는 UVM 클래스 라이브러리라고 하는 일종의 템플린 라이브러리를 제공을 합니다.
그래서 사람들이 UVM을 써서 검증을 했다라고 말을 하면 이런 베리피케이션 메소돌로지를 써서 검증을 했다는 의미로 쓰기도 하지만
시스템 베릴로그를 써서 검증을 했다는 의미로 쓰기도 하고 방금 말씀드린 UVM 클래스 라이브러리를 써가지고 검증했다는 뜻으로 쓰기도 해요.
그래서 이게 좀 사용하는 사람에 따라 컨텍스트에 따라 다른 의미를 가지고 있기 때문에 제가 그거를 좀 명확하게 하려고 지금 설명을 드리는 겁니다.
그래서 여러분들이 어쨌든 간에 여기서 배우는 거는 시스템 베릴로그의 문법을 배우기는 하지만
UVM의 핵심적인 개념들은 다 다룬다. 그거를 이제 말씀을 드리고 싶었던 거고요.
그래서 이번 강의에서는 그런 것들을 가르게 되겠고
그리고 그 다음에 조금 더 구체적인 계획은 간단하게만 말씀드리겠지만
오늘 오전에는 이제 그 검증 방법론에 대해서 여러 가지 방법론들을 그냥 일반적인 이론적인 것들에 대해서 한번 쭉 살펴보도록 하겠습니다.
그러니까 여기서는 제가 UVM에 대한 핵심적인 개념들을 말씀을 드린다고 했는데
UVM에 포함되어 있지 않은 다른 검증 방법론들이 수도 없이 많습니다.
이게 제가 옛날에 회사를 다닐 때까지만 해도 이게 벌써 한 15년 전이니까 옛날 얘기이긴 하지만
그때는 이런 검증 방법론이 일종의 춘추 전국 시대였어요.
그래서 굉장히 많은 방법론들이 나와서 이거라면 뭐가 좋다 뭐가 좋다 그러면서 서로 막 경쟁하던 때였는데
이게 한 10년쯤 지나니까 이 중에서 옥석이 가려져서 사람들이 정말 이거는 정말 효과가 있다.
이거 정말 괜찮은 방법론이다. 라고 인정을 받는 그런 방법론들만 어떻게 보면 살아남은 거예요.
그래서 그런 살아남은 방법론들을 하나로 모은 게 UVM이라고 생각을 하시면 됩니다.
특히나 제가 컨스트레인 랜덤 베리피케이션 같은 경우에는 제가 회사 다닐 때 많이 썼던 방법론인데
이거는 정말로 제가 개인적인 경험으로 정말 효과가 있는 그거라고 제가 말씀드릴 수가 있어요.
왜냐하면 제가 이제 담당했던 것 중에 제가 하드웨어 블럭을 설계를 한 다음에
이거를 검증을 해야 되니까 이거를 FPGA에 올려서 소프트웨어 개발팀에다가 전달을 해요.
그러면 소프트웨어 개발팀이 이걸 가지고 소프트웨어를 개발해서 돌려보고
혹시 문제가 생기면 저한테 다시 연락을 해가지고 이거 이렇게 좀 고쳐주세요. 이렇게 연락이 오거든요.
그러면 제가 처음에 넘길 때는 컨스트레인 랜덤으로 다 검증을 해가지고 넘겨요.
그때는 별로 문제가 생기지를 않아. 그랬는데 소프트웨어 쪽에서 해보다가 보니까
이런 게 좀 불편하니까 좀 고쳐주세요라고 요청이 와요.
그러면 제가 많이 고친 것도 아니고 조금 고친 거니까 살짝 고쳐서
또 컨스트레인 랜덤 다 돌리려면 귀찮으니까 그냥 보내.
그러면 이게 또 뭔가 버그가 생겨요.
그래갖고 이제는 고쳐달라고가 아니라 문제가 있다고 연락이 와.
그러면 이게 왜 안 되지? 라고 그때 가서 컨스트레인 랜덤을 돌려요.
그러면 여기서 얘가 버그를 칙사주더라고 걔가.
그러니까 제가 진작 돌렸으면 이거를 찾을 수 있었던 버그인데
안 돌려가지고 못 찾은 거예요.
그래갖고 제가 이번에는 그거를 수정을 해가지고
이제는 컨스트레인 랜덤을 다 돌려가지고 보내면
그때는 이제 그 버그로 인한 문제로 그런 것들을 피드백을 받은 적이 거의 없어요.
그러니까 저의 개인적인 경험으로 봐도
이게 컨스트레인 랜덤 베리피케이션이 굉장히 좋은 방법론이라고 말씀을 드릴 수가 있겠어요.
그런데 여기에 포함되지 않은 다른 종류의 검증 방법론들이 굉장히 많이 있습니다.
이게 아예 안 쓰이는 건 아니고 그냥 필요한 경우에만 쓰이는 것들도 있고
아니면 지금도 쓰이고 있기는 한데 좀 검증의 목적이 달라가지고
제한적인 영역에서만 쓰이는 그런 검증 방법론들도 있어요.
그래서 어쨌든 간에 이런 것들을 큰 그림에서 어떤 것들이 있는지를 좀 알아두시면 좋을 것 같아서
일단은 검증 방법론들에 대한 전체적인 개괄적인 설명을 오늘 오전에 하도록 하겠습니다.
그 다음에 오늘 오후부터는 이제 시스템 베릴로그의 문법들을
챕터별로 데이터 타입, 스테인먼트, 기본적인 OOP, 객체지향 언어
시스템 베릴로그도 객체지향 언어를 지원을 하거든요.
그런 것들에 대해서 한 챕터씩 하나씩 하나씩 해보도록 하겠습니다.
자 그래서 이게 전체적인 강의 계획이고요.
혹시 강의 계획이나 진행 상황 아니면 뭐가 됐든 수업에 관련해서 질문 있으신 분은 혹시 있으신가요?
온라인 혹시 온라인으로 참석하시는 분들도 질문 있으시면
채팅창에 남겨주시면 특별히 없으신 것 같으니까 일단은 지나가도록 하겠습니다.
그러면 아까 말씀드린 것처럼 오늘 오전 시간에는
전체적인 방법론에 대해서 강의를 하도록 하겠습니다.
그래서 이게 여기 같은 경우에는 이제 다양한 종류의 방법론들이 있어요.
그러니까 그런 것들이 뭐가 있는지에 대해서 설명을 드리도록 하겠고요.
제가 듣기에 배포가 됐다고 들었는데 혹시 안 받으셨나요? 아무도 안 받으셨나요?
네. 검증. 그런데 여기서 한 가지 용어를 명확하게 해야 될 게
이쪽 우리 하드웨어 설계 또는 반도체 설계 관점에서는
이 검증하고 테스트는 다른 의미로 쓰입니다.
검증, 베리피케이션하고 테스트.
그러니까 검증은 설계 관점에서
그러니까 베릴로그 또는 HDL 이런 거를 써가지고
기능을 설계를 한 게 정상적으로 동작하는지
그 기능 부분에 초점이 맞춰서 확인을 하는 거를 검증이라고 얘기를 하고요.
테스트는 제조가 끝난 다음에 이 제조된 칩이 실리콘이
내가 설계한 대로 구현이 제조가 됐는지
이거를 확인을 하는 거를 테스팅이라고 합니다.
이거 두 개가 어쨌든
그래서 이제 용어를 이렇게 분리를 해서 써요.
이 두 개는 아예 방법이 다르기 때문에
그런데 이 칩이 정상적으로 동작하는지를
확인하기 위한 목적인 거는 동일하지만
어느 부분을 확인을 하느냐
설계, 로직 이런 부분을 확인할 때는
검증, 물리적인 구현, 제조
이 부분을 확인할 때는 테스트라고 하는 용어를 씁니다.
그래서 우리가 지금 3일 동안 할 거는 검증입니다.
베리피케이션. 그래서 검증이고요.
그래서 이미 거의 한 20년 전, 한 15년 전부터
이 검증이 굉장히 큰 문제가 될 거다.
앞으로 이게 굉장히 이쪽 반도체 설계하는 분야에서는
굉장히 어려운 문제가 될 거다.
이거를 이렇게 예측을 했다는 그런 얘기고요.
이게 왜 검증이 어렵냐 하면
일단은 검증을 해야 될 게 너무 많아.
검증이라는 게 옛날에 그냥 반도체가 별로 복잡하지 않고
간단했을 때는 이게 확인을 해봐야 될 부분이 그렇게 많지는 않았어요.
그랬는데 이제는 이 반도체가
이 딥섬 미크론 같은 게 나오면서
요즘은 2나노, 4나노 이런 얘기도 하고 있는데
그러다 보니까 이게 공정의 집중도가 올라가면서
이게 칩 하나에 들어가는 기능이 굉장히 많아졌죠.
그래서 디자인 컴플렉스라고 말씀드린 게
하나의 칩 안에 옛날에는 간단한 로직 정도만 구현되어 있었다면
이제는 프로세서를 포함해가지고
아날로그 IP도 들어가고
뭐 클락 뭐 이런 여러 가지 복잡한 것들이 많이 들어갑니다.
그러다 보니까 이제 검증하기 어려워진 면이 좀 있고요.
근데 그거 외에도 여기서 말하는 건
펑셔널러티 얘기를 한 거였고
그 다음에는 여기서 검증을 해야 되는 게
기능, 내가 설계를 한 로직만 정상적으로
설계를 했다고 해서 칩이 돌아가는 게 아니에요.
왜냐하면 이 칩이 특히나 우리가 쓰는 현대에서 쓰는 칩들은
다 기본적으로 동기화된 싱크로노스 로직을 쓰잖아요.
클락에 의해가지고 동기가 된 회로를 쓰기 때문에
여기서 타이밍이 맞지 않으면
그러면 정상적으로 동작하질 않아요.
그러니까 검증을 우리가 설계할 때 검증을 해야 되는 부분이
기능적인 부분도 검증을 해야 되지만
타이밍이 정확하게 클락 시그널에 맞춰가지고
정상적으로 신호가 생성이 되는지
이 타이밍도 검증을 해줄 필요가 있습니다.
그래서 여기서 말하는 타이밍은 퍼포먼스랑은 조금 다른 게
타이밍은 이 클락에 맞춰가지고
그 클락의 한 클락 피어리어드 내에
필요한 모든 시그널들이 다 생성이 되느냐
이거를 확인을 해야 된다는 얘기고요.
퍼포먼스는 이 칩이 내가 원하는 만큼 빠르게 동작하느냐
뭐 이런 거를 얘기를 하는 거고요.
그 다음에 최근 들어갔고는 이제 모바일 디바이스가 나오면서
전력 소모가 굉장히 중요한 문제가 되기도 했고
그 다음에 인텔 프로세서나 이런 것도 여러분들이 아시겠지만
다 방열판이 붙잖아요.
그러니까 방열판이 붙는다는 얘기는
이 칩이 전력 소모가 굉장히 커가지고
이게 발열 문제가 생기기 시작했죠.
그러니까 발열 문제는 결국은 전력 소모랑 연관이 있는 거기 때문에
발열 문제를 줄이려면은 이제 그 전력 소모가 또 그래서 이제 중요해지기도 했습니다.
그래서 그 다음에 이제 물리적인 여러 가지
그 이제 딥선미크론으로 가면서
이제 뒤에 가서도 나오겠지만
뭐 크로스토기니 뭐 하여튼 여러 가지 이제
시그널 인테그레이티에 관련된 문제들이 생기기 시작했어요.
그러니까 이런 것들을 이제 다 검증을 해줘야 되는 거예요.
그러니까 얼마나 어렵겠어요.
시간도 많이 걸리고.
그래서 이게 검증이 굉장히 어려운 문제가 되었고
그 다음에 점점 더 어려워지고 있습니다.
특히나 요즘 나오는 최신 공정들 같은 경우에는
이게 우리가 지금 하고 있는 검증들은
이 물리적인 트랜지스터나 이런 소자들을
상위 수준에서 시뮬레이션 모델로 만들어가지고
그거를 이용을 해서 검증을 해요.
근데 최신 공정들 요즘 나오는 뭐 2나노 3나노 이런 공정들은
이 물리적인 현상을 시뮬레이션 모델로 만드는 것부터
어렵다고 하더라고요.
그래갖고 이제는 하여튼 검증이라는 게 굉장히 어려워지고 있어요.
그래서 뭐 말씀드린 대로 이런 여러 가지
그 다양한 성격을 갖는 이런
그 컴포넌트들이 하나의 칩 안에 다 들어오고 있어갖고
그래서 어렵다.
그래서 뭐 이게 이제 뭐 여러
그 하나의 회사에서 다 만드는 것도 아니고
뭐 CPU는 ARM에서 만들고
뭐 USB는 뭐 시납시스에서 만든 거 갖다 쓰고
이렇게 여러 회사 것들을 갖다 쓰다 보니까
뭐 회사마다 뭐 디자인 컨벤션도 다르고
뭐 여러 가지 것들이 다른 그런 것도 있고요.
그 다음에 IP의 종류도 뭐 RTL 같이
그냥 소스 코드 형태로 제공되는 것도 있고
아예 하드닝을 다 해가지고 뭐 GDS로 제공되는 것도 있고
뭐 이런 것도 다양하고
그 다음에 뭐 디지털만 있으면 또 괜찮은데
아날로그 IP 같은 경우가 있으면
이게 이제 아날로그는 이게 0V
그러니까 뭐 1V냐 1.1V냐 1.2V냐에 따라서
동작이 달라지는 애들이고
디지털 같은 경우에는 뭐 0안이 면 1이니까
뭐 이거는 뭐 코와 볼티지에 따라 다르지만
예를 들면은 0V냐 1.2V냐만 중요하지
그 사이에 뭐가 어떻게 되는지는 중요하지 않잖아요.
그러다 보니까 이 아날로그 IP랑
디지털 IP가 같이 있게 되면은
아날로그 IP가 디지털 IP에 의해서 영향을 많이 받습니다.
그래서 그런 영향들을 이렇게 차단할 수 있는 게 필요하고요.
그래서 어쨌든 이런 여러 가지 것들이
이제 하나의 칩 안에 들어오고
그거를 다 검증을 해줘야 되기 때문에
검증이 어려워지고 있습니다.
그 다음에 코스트의 입장에서 보면은
이게 그 블럭 레벨에서
작은 레벨에서 버그를 찾고
이거를 고치는 거는
상대적으로 비용도 적고
시간도 적게 들지만
이거를 이제 인테그레이션에서
모듈로 가고 시스템으로 가게 되면
여기서 말하는 시스템은
이제 소프트웨어까지 포함한 거예요.
뒷부분에 가가지고 버그를 발견을 하게 되면은
버그를 찾기도 어렵지만
수정하기도 어렵습니다.
뒤쪽으로 갈수록.
근데 제가 이 컨스트레인 랜덤
또는 UVM을 사용한 경험형으로 비춰보면
이쪽 블럭 레벨에서 사용하는 게 제일 효과적이에요.
사실은 컨스트레인 랜덤을 모듈 레벨이나
시스템 레벨에서도 쓸 수 있어요.
쓸 수는 있는데
그거를 하려면은
이게 예를 들어 시스템 레벨에서 내가
컨스트레인 랜덤 또는 UVM을 적용을 해야겠다라고 생각하면은
이 테스트 벤치를 만드는 시간과 노력이 너무 많이 들어가요.
너무 많이 들어가는데
제가 볼 때는 굳이 2단계 가서 할 필요는 없고
블럭 레벨에서 하면은
이게 그래도 간단하기 때문에
이 컨스트레인 랜덤을 적용한
그런 테스트 벤치를 만들기가 쉽고요.
그 다음에 2단계에서 컨스트레인 랜덤으로
철저하게 검증을 하고 나면은
뒷부분에 가서 검증을 해야 되는
그런 버그가 생길 가능성을 굉장히 많이 줄여줄 수가 있습니다.
그러니까 이 컨스트레인 랜덤을 쓰는
이 블럭 레벨에서 쓰는 게
제일 효과적이다.
이렇게 보시면 되겠습니다.
그 다음에 이제 이게 공정이 미세화가 되면서
이런 게 이제 점점 더 어려워졌다는 거고요.
공정이 미세화가 되니까 이제 타이밍 클로저
아까 말한 플락에 맞춰갖고
이 신호들이 정상적으로 생성되는지를 확인을 하는
이게 점점 더 어려워지고 있어요.
어려워지고 있고
왜냐하면 뒤에 가서 또 말씀을 드릴 거고요.
그 다음에 이제 집적도가 올라가니까
당연히 성능도 늘어나고
뭐 하여튼 그런 것들이 이슈가
성능이 아니라 그 뭐야
칩 안에 들어가는 기능들이 많아지니까
이제 검증하기가 어려워지는 그런 면도 좀 있습니다.
그래서 이렇게 딥섬 미크론으로 가면은
이런 것들이 이제 이슈가 됩니다.
그래서 이런 것들을 하나씩 살펴보겠습니다.
먼저 인터커넥트 이슈가 있는데요.
그거는 뭐냐면은
이제 딥섬 미크론이라는 말은
이제 공정이 점점 미세화가 된다는 얘기잖아요.
미세화가 된다는 얘기는
여기 있는 이제 피처 사이즈가
점점점점 준다는 얘기인데
여기서 말하는 피처 사이즈는 대부분
트랜지스터의 크기를 얘기를 해요.
그래서 트랜지스터의 크기는
뭐 옛날에 나오는 걸로 치면은
뭐 90나노에서
뭐 65나노, 45나노
이렇게 쭉 줄어들었어요.
근데 이 트랜지스터의 크기가
줄은 거에 비하면은
이 인터커넥트는 어찌됐든 간에
그 트랜지스터를 연결을 해줘야 되니까
트랜지스터의 크기가 줄어도
트랜지스터의 개수는 늘어나니까
이게 걔네들을 연결해주는
인터커넥트들의
뭐 전반적인 총 길이
예를 들면
그런 걸로 보면은
인터커넥트는 그렇게까지 줄지는 않더라는 거죠.
그러니까 여기서 말하는 인터커넥트는
트랜지스터들끼리 이렇게 연결해주는
와이어들을 얘기를 하는 건데
걔네들이 결국은 상대적으로 봤을 때
이런 인터커넥트들의 비중이
늘어나고 있다는 겁니다.
그래갖고 이게 옛날에는
검증을 한다고 그러면은
검증의 초점은
이 로직 쪽에 있었는데
그러니까 뭐 트랜지스터라던가
그 다음에 뭐 스탠다드 셀
이런 것들을 기능적인 부분을
굉장히 신경을 쓰고
여기서 소모되는 전력
뭐 이런 것들을 확인을 하는 거가
보통은 초점이었지만
이제는 인터커넥트의 비중이 점점 늘어나면서
인터커넥트 특히나 전력 소모가
최근에 나오는 칩들은
거의 뭐 한 반 정도는
칩마다 다르긴 하지만요.
그 한 반 정도는 인터커넥트에서 소모한다.
뭐 이렇게 레포트가 되기도 합니다.
그러니까 이런 그 인터커넥트가
이제 그 뭐 요즘은 더 비중이 늘어나고 있다.
이렇게 말씀드릴 수가 있어요.
그 다음에 이게 아까 말씀드렸던 것 중에 하나인데
아날로그 IP랑 디지털 IP가
같은 다이에 있게 되면은
디지털 IP 쪽에서 이렇게 스위칭을 하게 되면
그 스위칭한 영향이
아날로그 IP에 전달이 됩니다.
그래서 이게 일종의 노이즈라고 말할 수가 있는 거죠.
디지털 IP 때문에 노이즈가 생기는데
노이즈는 디지털 IP 자체는
그 노이즈에 그래도 좀 강건한 편인데
아날로그 IP는 영향을 많이 받기 때문에
이거 두 개를 하나의 칩 안에다 넣으면
이런 아날로그 IP들은
디지털 IP에 영향을 받지 않도록
이게 쉴딩 같은 것들을 잘 해줘야 됩니다.
그 다음에 크로스톡은
이제 이게 와이어가 이렇게 있으면은
신호를 전달하는 회선이 있으면은
이 와이어가 옛날에는
이게 공정이 미세화되지 않았을 때는
얘네들이 충분히 멀리 떨어져 있었어요.
그러니까 이 회선이
이 시그널이
이 시그널에 영향을 줄 일이 별로 없었는데
이제는 공정이 미세화가 되면서
얘네들이 이제 점점점점 크기가 줄어드니까
얘네들이 점점점점 가까워지는 거예요.
가까워지다 보니까 이제
뭐 예를 들면은 전자기 유도 현상
뭐 이런 것 때문에
이쪽에서 그 신호가 0101 바뀌는 게
얘한테도 영향을 주기 시작했어요.
그래서 이런 거를 이제 크로스톡이라고 얘기를 합니다.
그래서 이게
이게 이제 딥선미크론으로 가면서
점점 더
그 이런 것들이 문제가 되고 있고
그래서 이게 시그널 인테그레티에 영향을 주고 있습니다.
그 다음에 이제는
아까 이것도 이제 제가 2나노 3나노 얘기를 하면서
말씀드렸던 것 중에 하나인데
이거를 이제 물리적인
그 트랜지스터라든가 와이어를
그거를 이제 우리가 물리적으로 다 실험을 해볼 수는 없잖아요.
그러니까 이거를
상위 수준에서 모델링을 해가지고
시뮬레이션을 해야 되는데
이걸 어떻게 모델링을 하느냐
이것도 이제 중요한 그것 중에 하나입니다.
그러니까 모델링을 할 때
굉장히 자세하게 모델링을 하면
그러면은 이제
우리가 여러 가지 것들을
시뮬레이션을 통해서 확인해 볼 수가 있겠지만
이렇게 되면 속도가 너무 느려져요.
그러니까 여기서 우리가
꼭 필요한 부분만
이게 이렇게 간략화 해가지고
이런 식으로 좀
앱스트랙트를 할 필요가 있습니다.
그러니까 이렇게 자동차를 몽땅 다 모델링을 하는 게 아니라
우리가 필요한 거는
이런 언덕에서 이렇게 내려올 때
얘가 뭐 예를 들면은
위치와 속도가 어떻게 되는지
뭐 이 정도 수준으로만 알고 싶으면은
뭐 이런 식으로 간단하게 모델링을 할 수 있고
더 간단하게 하려고 그러면은
이렇게 모델링을 할 수가 있다는 겁니다.
그래서 이런 식으로 모델링을 하게 되면은
이제 우리가 원하는 거는
시뮬레이션을 해볼 수 있지만
시뮬레이션 속도를 빠르게 할 수 있다는 거죠.
그런데 문제는 이게
우리가 이런 시뮬레이션을
모델을 갖고 만들었는데
우리가 뭐 테스트를 하다 보니까요.
검증을 하다 보니까
약간 더 뭐 필요한 것들이 또 있어.
그러면은 이거를 다시 이렇게
모델링을 해야 되고
뭐 이런 것들이 왔다 갔다 하게 되는
그런 경우가 생길 수는 있습니다.
그다음에 이게 양산 가능성
이것도 이제는 중요해진 문제가
중요한 문제가 되기도 했습니다.
물론 이거는 이제 설계하는 사람이
뭐 이렇게 크게 걱정할 문제는
아닐 수도 있기는 한데
이게 소위 말하는
그거를 얘기를 하는 거예요.
일드
그 양산 수율
그래서 그게
이게 공정이 뭐
성숙 공정이다
공정이 안정화되어 있다라고 하면은
보통은 양산 수율이
충분히 높다라는 뜻이고
이제 새로 생긴
신생 공정들
뭐 그 뭐
이쪽 용어로 쓰면은
선단 공정들
선단 공정들 같은 경우에는
양산 수율이 높지가 않습니다.
그래서 이게 이제
뭐 사람이 이렇게 설계를 하다 보면
아무래도
특히나 이렇게
딥선미코로로 가면은
설계를 하는 당시에는
경험이 없으니까
잘 몰랐던
생각지도 못했던
여러 가지 물리적인 현상들이 생겨요.
그러니까 그런 것들을 고려를 못하고
일단은
공정을 만들었는데
여기서 이제 생각지도 못했던 문제가 생겨갖고
양산 수율이 뭐 10% 20%밖에 안 나오는 거예요.
그러니까 이렇게 되면은 이제
이거 가지고 칩을 만들어도
이게 이제 수익을 내기가 어려운 거죠.
그러면은 여기서 이제 그런 문제들을 찾아갖고
해결하는 과정을 반복하다 보면은
이 양산 수율이 이렇게 올라가게 됩니다.
근데 이것들은 뭐 사실은 이거는
공정 쪽에서 해결해줘야 되는 문제이기는 해요.
문제이기는 하지만
이게 가끔은 설계를 할 때
이런 것들을 고려해가지고 설계를 하면
좀 도움이 되는 면들이 있습니다.
예를 들면은
뭐 이렇게
그
이게
그
일종의 폴트 톨러런스
그런 기술을 적용을 해가지고
아니면은
비스트 같은 것들이 있어요. 비스트
비스트는
메모리 같은 경우에는 많이 쓰는데
예를 들면은 어떤 칩이 있는데
칩에
온칩 메모리가 있어요.
프로세서 같은 경우에는
뭐 캐시 같은 게 이제 온칩 메모리를 쓰겠죠.
그러면은 이 온칩 메모리가
원래는 내가 필요한 거는
예를 들면은 32킬로바이트인데
여기에 혹시 공정이 안정화가 안 돼가지고
또는 여러 가지 다른 이유로
이 메모리에 이제 물리적인 결함이 생길 수가 있을 거라는 거를
가정을 하고
여기다가 예를 들면은 한 4킬로바이트 정도의
일종의 스페어 리전을
메모리에다가 미리 설계를 해놓는 거예요.
그러면은 만약에 혹시나 이 칩이
메모리 쪽에 뭔가 물리적인 결함이 있다 그러면
만약에 이런 4킬로바이트짜리 스페어 리전이 없었으면은
그 칩은 그냥 버려야 되는 칩인데
이게 있으면은 그걸로 교체를 해가지고 쓰면 되니까
양산 수율이 올라가는데 도움이 되겠죠.
이 칩 버리는 것보다는
4킬로바이트 정도 조금 더
그 코스트를 들이면
이게 정상적으로 동작하는 칩을 얻을 확률이 더 올라가는
뭐 그런 것들이 있습니다.
그래서 이런 것들을 설계 단계에서
고려를 할 수 있으면 도움이 될 때가 있기 때문에
그래갖고 이제
요거에 이제
여기서 이제 우리가
우리는 지금 설계 입장에서
검증을 지금 얘기를 하고 있는데
요런 것들을 지금
뭐 말씀을 드리는 거고요.
그 다음에 똑같은 칩인데
뭐 멀쩡히 동작하는 칩인데
얘가 그 주변 환경에 따라가지고
또 이게 동작을 하기도 하고
하지도 않고
뭐 이런 경우가 생길 수가 있습니다.
그런 것들을 이제
Reliability라고 얘기를 하죠.
그래서 제일 대표적인 게
여기 나와 있는 것처럼
이걸 내가 알래스카에도 쓸 수 있고
텍사스에도 쓸 수 있을까라는 질문이에요.
다시 말하면은
칩은 온도의 영향을 많이 받아요.
그래갖고 보통의 경우에 있으면
이렇게 우리가 지금 있는
이런 룸 템퍼레이처라고 하죠.
이런 룸 템퍼레이처에서
보통은 이제
그 사용을 하게 되지만
예를 들면은
자동차에 들어가는 반도체다.
그러면은 자동차를 몰고
알래스카에도 갈 수도 있고
텍사스에도 갈 수도 있잖아요.
그런데 이게 거기서도
정상적으로 동작하느냐
뭐 요런 것들이 이제 문제가 될 수 있는 거죠.
그래서 이 칩을 만들 때
우리가 테스트를 할 때
이거는 이제 뭐 베리피케이션이라기보다는
테스트 이슈기는 합니다만
그런데 테스트 쪽에서 만약에 페일이 나면은
이게 또 설계에도 영향을 줄 수가 있으니까
그러니까 이제 요런 것들까지도 고려를 해서
설계를 해야 될 필요가 있을 때가 있습니다.
그 다음에 전력 소모도
뭐 큰 문제라고 말씀을 드렸죠.
이게 이제 뭐 모바일 같은 경우에는
배터리로 동작을 하니까
전력 소모가 중요하기도 하지만
또 여기서 이게 그림에도 나와 있는 것처럼
이제 그 전력 소모가
곧 발열 문제로 연결이 되기 때문에
전력 소모를 줄이는 게
이런 그 발열 문제
발열 문제가 생기면은
인텔 프로세서 같은 경우에는
칩이 너무 뜨거워지면은
그걸 자동으로 이렇게 성능을 낮춰주잖아요.
그러니까 이게 이제
발열 문제가 결국은 성능에도 영향을 주는
그런 상황이 되었습니다.
그래서 이렇게 검증해야 될 게 많고
뭐 생각해야 될 게 많다 보니까
검증이 점점 어려워지고 있어요.
그래서 이게 말하자면은
디자인 크라이시스라고 하는 그런 그래프인데
이거는 뭐냐면은
여기 빨간 그래프로 보시는 게
이게 이제 공정의 집적도가 올라가는
속도예요.
그래서 그 트랜지스터
그러니까 공정이
트랜지스터가 크기가 줄어들면서
트랜지스터의 개수가 늘어나는
그런 속도가 이렇게 빨리 올라가고 있지만
디자인 프로덕티비티는
그렇게까지 빠르게
늘어나고 있지 않다는 겁니다.
그러니까 그 트랜지스터가
늘어나는 속도에 비해 갖고
사람이 그거를 그럼 설계를 해줘야 되는데
사람이 코딩을 해가지고
설계를 하는 설계 생산성은
그만큼 따라가지고 있지 못하다.
그러니까 우리가 이렇게 빨리 증가하는
트랜지스터를 충분히 활용을 못하고 있다는 얘기죠.
그런데 이거보다 더 심각한 거는
검증 생산성은 이렇게 떨어진다는 거예요.
이게 설계는 그나마 이렇게 좀 따라가는데
이거 설계를 해놓으면 뭐해.
이거를 검증을 해야 되는데
검증하기가 너무 어렵다 보니까
검증의 생산성은 설계 생산성조차도 따라가지 못하는
그런 어려운 문제가 있다는 겁니다.
그래서 이제 뭐 UVM이니 뭐 이런 것들이 나오면서
이런 것들을 좀 해결해 보려는
그런 노력들을 하고 있습니다.
그래서 이런 검증할 수 있는 방법론들을
조금 구분을 해보면
이렇게 구분을 해볼 수가 있습니다.
그래서 이것들도 이제 하나씩 좀 살펴보도록 할게요.
처음에 나오는 거는 시뮬레이션 기반의
그 검증 방법론입니다.
그게 이제 뭐 베리로그 같이 우리가 코딩을 하고 나면
시뮬레이션 돌리잖아요.
제가 여태까지 쭉 얘기를 했던 것들이 결국은
그 물리적인 그런 실리콘의 물리적인 현상을
시뮬레이션 모델로 만든다 뭐 이런 말씀을 드렸는데
그건 결국은 시뮬레이션을 이용을 해서
검증을 하겠다는 뜻이죠.
그러니까 이게 사실은 제일 많이 쓰이는 방법이고요.
그래서 시뮬레이션 방법을 이용한 방법이 있고
스태틱 테크놀로지는 뭐냐면
이거는 실제로 이걸 수행을 해보는 게 아니라
그냥 소스 코드만 보고 소스 코드를 분석해서
얘가 정상적으로 어떤 문제가 없는지
뭐 이런 것들을 확인을 하는 겁니다.
그러니까 이게 스태틱한 방법만 가지고
검증을 할 수도 없고 모든 것들을
시뮬레이션만 가지고 모든 것을 검증할 수도 없고
그래갖고 이런 것들을 다 조합해가지고
내가 검증 또는 설계하는 목적에 따라 갖고
잘 활용을 해 줄 필요가 있습니다.
그래갖고 제가 이렇게 큰 그림에서
어떤 검증 방법분들이 있는지를 설명을 드리겠다고 한 게
여러분들이 만약에 혹시나 이쪽 분야에서
일을 하신다면 이제 목적에 따라 필요에 따라
필요한 검증 방법들을 선택을 해서
또는 걔네들을 조합을 해가지고 사용하실 필요가 있어갖고
어떤 것들이 있는지 그것들은 좀 알아 놓으시면
도움이 될 것 같습니다.
그 다음에 물리적인 현상들을 검증하는
그런 방법은 또 따로 있고요.
그러니까 우리가 설계 로직, 기능적인 관점에서
검증을 하는 거와는 또 이렇게 물리적인 현상을
검증하는 거는 좀 완전히 다른 얘기이기 때문에
이쪽은 또 별도의 방법론과 툴이 있습니다.
그 다음에 포멀 테크놀로지는 뭐냐면
이게 수학적인 모델을 이용을 해가지고 말하자면
일종의 증명을 하는 거예요.
그러니까 이 칩이 정상적으로 내가 설계를 한
이 기능이 정상적으로 동작하는지를 확인을 하는데
시뮬레이션을 통해서 확인을 하게 되면
내가 만든 시뮬레이션 벡터들
그러니까 검증 시나리오들에 대해서는 검증을 하지만
컨스트레인 랜덤을 쓰게 되면
그 시나리오가 조금 더 많아지기는 하지만
이게 정말로 완벽하게
그 설계가 정확하다는 거를
완벽하다고는 말할 수가 없잖아요.
그러니까 99%는 될 수 있을지언정
100%라고는 말할 수가 없기 때문에
근데 물론 대부분의 경우에는
그 정도면 충분한데
문제는 미션 크리티컬한 시스템들이 있어요.
0.001의 확률로라도
혹시나 이 칩이 정상적으로 동작하지 않으면
굉장히 큰 문제가 생길 수 있는
그런데 사용되는 칩들이 있다는 거죠.
그래서 예를 들면 요즘
자율주행 자동차 이런 게 나오기 시작했으니까
그런데 쓰이는 칩들 같은 경우에는
혹시나 문제가 생길 때 사고가 나면서
인명피해가 생길 수도 있는 거잖아요.
그러니까 이런 것들은
이 칩이 정상적으로 동작하지 않았을 때
생길 수 있는 피해가 굉장히 심각한
그런 종류의 칩에는
얘를 굉장히 철저하게 검증할 필요가 있습니다.
그럴 때는 이런 수학적인 모델을 써가지고
증명을 하는 방식으로 해서
이거를 확실하게 검증할 수 있는
그런 방법론을 사용을 합니다.
그런데 대신에 이런 것들은 아직까지는
복잡한 칩에는 적용하기가 좀 어려워요.
그래서 그렇기 때문에
제가 아까 말씀드린 대로
이게 칩의 종류에 따라
목적에 따라
그다음에 요구사항에 따라서
이런 것들을 적절한 검증 방법론을
사용을 할 필요가 있습니다.
그래서 우리가 지금
요 3일 동안에 배울 거는
이 시뮬레이션 기반의
시스템 베를로그 또는 컨스트레인 랜덤을
쓴다는 얘기는 결국은 시뮬레이터로 쓴다는 얘기이기 때문에
요 방법론을 집중적으로 배우기는 할 거지만
왜냐하면 이게 제일 많이 쓰이는 거고
근데 요런 것들도 어쨌든
알아놓으실 필요는 있다는 겁니다.
시뮬레이션 방법만 해도
이렇게 다양한 방법들이 있습니다.
이벤트 드리븐 시뮬레이터가
실질적으로 제일 많이 쓰이는 시뮬레이터입니다.
베를로그 시뮬레이터도
이벤트 드리븐 시뮬레이터이고요.
이벤트 드리븐 시뮬레이터랑
사이클 베이스 시뮬레이터가 있는데
요거 두 개의 가장 큰 차이점은 뭐냐면
우리가 사용하고 있는 하드웨어는 대부분이 다
싱크로노스 로직이라고 말씀을 드렸어요.
클락에 의해 갖고 동기가 되는
그런 회로들이기 때문에
이 회로는 기본적으로
매 클락마다 동작을 해요.
클락과 클락 사이에서도 물론
이런 컴비네이션 로직들이 동작을 하지만
실질적으로 기능의 입장에서 봤을 때는
측면에서 봤을 때는
클락의 엣지에서 뭔가 중요한
그런 기능의 변화가 생기는 거죠.
그렇기 때문에 사이클 베이스 시뮬레이션은
매 클락마다 이 현재 회로의 상태를
시뮬레이션을 합니다.
그런데 이벤트 드리븐 시뮬레이션 같은 경우에는
기본적으로 어떤 컴비네이션 로직을
보통은 시뮬레이션을 할 때는 보면
회로가 이렇게 여러 개의 게이트로 이루어진 회로가 있다 그러면
실질적으로 여기서 입력이 변하는 거는
모든 입력이 한꺼번에 동시에 변하는 경우는
별로 없더라 라고 하는 게
일종의 관찰이라고 말씀드릴 수가 있어요.
그러면 이 중에서 일부의 입력만 변하면
변하는 입력에 의해 갖고 영향을 받는 회로들만
시뮬레이션을 다시 해주면 되지
이거에 의해 갖고 영향을 받지 않는 회로들 같은 경우에는
어차피 얘네들은 똑같은 출력을 내보낼 건데
굳이 이거를 다시 시뮬레이션을 해줄 필요가 있느냐라고 해가지고
시뮬레이션한 방법이 이벤트 드리븐 시뮬레이션이에요.
그러니까 여기서 말하는 이벤트라고 하는 게
어떤 입력의 변화를 이벤트라고 보시면 되겠습니다.
그래서 이벤트가 발생을 했을 때 그 이벤트에 의해 갖고
영향을 받는 회로들만 다시 시뮬레이션을 해주는
그런 방식이 이벤트 드리븐 시뮬레이터입니다.
그렇기 때문에 우리가 베릴로그를 쓰다 보면
베릴로그에 센서티비티 리스트를 등록을 하잖아요.
그 센서티비티 리스트라고 하는 게
결국은 그 이벤트 드리븐 시뮬레이션을 위해서 있는 겁니다.
그러니까 이 센서티비티 리스트에 들어가 있는 이벤트가 발생을 하면
그 always라고 하면 always 그 블럭 안에 들어있는 것들을
다시 시뮬레이션을 해라 라고 시뮬레이션 시뮬레이터한테 알려주는
그런 역할을 하는 거죠.
그래서 이런 것들이 대표적인 이벤트 드리븐 시뮬레이터가 되겠고요.
그러면 이벤트 드리븐 시뮬레이터가 빠를까요?
사이클 베이스드 시뮬레이터가 빠를까요?
이거는 사실 그때그때 다르기는 한데
이게 회로에 따라서 다르긴 합니다.
그런데 우리가 싱크로노스 로직을
우리가 시뮬레이션을 할 때는
일반적으로 사이클 베이스 시뮬레이터가 조금 더 빠르기는 합니다.
그런데 이거는 싱글 클락 도메인에서는
사이클 베이스 시뮬레이터를 쓸 수가 있는데
이게 또 멀티 도메인 칩 같은 경우에는
하나의 칩 안에 다른 클락을 사용하는 모듈들이 섞여 있게 되면
또 사이클 베이스 시뮬레이션을 쓰기가 어려워요.
그때는 어쩔 수 없이 이벤트 드리븐 시뮬레이터를 써야 되는
그런 또 상황이 있을 수가 있습니다.
그래서 이게 이제 대표적인 시뮬레이션 기술들이고요.
그 다음에는 래피드 프로토타입 또는 에뮬레이션 같은 게 있어요.
그 다음에 시뮬레이션의 속도를 높이기 위한 방법들이 있고
이 세 가지 방법들은 여전히 시뮬레이션 방법들이기는 하지만
이제 칩이 너무 커지고 기능이 복잡해지다 보니까
시뮬레이션 속도가 이제 너무 느린 거예요.
사이클 베이스 시뮬레이션을 써도 느리고
이벤트 드리븐 시뮬레이션을 써도 느리고
뭐 옛날 얘기긴 하지만 제가 회사에 있을 때
그때 당시에 저희 부서에서 만들었던 칩이
이 핸드폰에 들어가는 베이스밴드 모뎀 칩이었어요.
그 베이스밴드 모뎀 칩을 하나를 설계를 한 다음에
얘를 풀 시스템 시뮬레이션
그러니까 이 칩에 있는 모든 기능들을 다 시뮬레이션을 했을 때
실시간으로 실제 이 칩에서는 실제로 돌리면
25 밀리세컨드 걸리는 일을 시뮬레이션을 하면
한 일주일 정도 걸렸어요.
그러니까 너무 느린 거죠.
25 밀리세컨드 시뮬레이션을 하기 위해서 일주일이 걸려.
그러면 사실상 그거는 시뮬레이션을 통해서 검증을 해보는 게
거의 불가능한 정도 수준입니다.
그렇기 때문에 이제 이거를 속도를 높이기 위해서 사용하는 방법들이
이제 요한 세 가지 방법이 있다고 보시면 돼요.
먼저 래피드 프로토타이핑 같은 경우에는
쉽게 말해서 FPGA 같은 거를 말씀을 드리는 겁니다.
그러니까 프로그래머블 한 하드웨어를 이용을 해가지고
뭐 ASIC으로 구현을 하지는 못했지만
FPGA에다가 구현을 해서 FPGA 정도 되면은
ASIC만큼 빠르게는 못 돌려도
그래도 시뮬레이션보다는 빠르고
그 다음에 여기다가 이 정도 수준의 속도면은
소프트웨어 정도는 올려볼 수 있어요.
그래갖고 이게 어쨌든 ASIC만큼 빠르지는 못하지만
어쨌든 그 시뮬레이터보다는 훨씬 빠르니까
이 래피드 프로토타이핑을 써가지고 검증을 해볼 수가 있습니다.
에뮬레이션은 뭐냐면은 우리가 시뮬레이터를 돌리면
시뮬레이터는 보통 인텔 프로세서 같은
일반적인 CPU 위에서 수행되는 소프트웨어예요.
그런데 그러다 보니까 느린 거예요.
그런데 에뮬레이션 시스템 같은 경우에는
이 하드웨어 시뮬레이션을 하기 위한
전용 하드웨어를 만든 거예요.
그래서 여기 같은 경우에는
이 시뮬레이터는 범용 CPU
제너럴 퍼포즈 CPU에서 돌아가는 소프트웨어잖아요.
그런데 에뮬레이터는
이 에뮬레이션 장비에서는
얘는 전용 기기예요.
그래서 이 에뮬레이터는
베를로그 시뮬레이션밖에 못하는 거예요.
대신에 베를로그 시뮬레이션은
엄청나게 빠르게 할 수 있는
뭐 그런 거죠.
GPU 같은 거라고 생각하시면 돼요.
GPU.
GPU에서 물론 요즘은 GPU가
여러 가지 기능들을 할 수 있도록
프로그래머블하게 나오지만
뭐 이거는 어쨌든 간에
원래 취지는
그래픽 프로세싱하는 알고리즘을
여기서 수행하기 위한 거잖아요.
그래서 원래 GPU가 그런 거였잖아요.
원래는.
요즘은 뭐 다른 용도로 많이 쓰지만
그거랑 마찬가지로
이 에뮬레이터 같은 경우에는
베를로그 시뮬레이션만을 위한 전용 기기예요.
그래서 여기는
베를로그 시뮬레이션은
엄청나게 빨리 돼요.
그 다음에 이 래피트 프로토타입
FPGA랑 다른 점은 뭐냐면
FPGA는 빨리 수행을 해볼 수 있지만
우리가 베를로그 시뮬레이터에서
나오는 웨이브 폼 같은 거는
볼 수가 없어요.
그러니까 이 하드웨어 내부에 있는
내부 시그널들을 찍어볼 방법은 없어요.
래피드 프로토타이핑을 하게 되면
그러니까 FPGA를 쓰게 되면
그렇지만 에뮬레이터에서는 그게 돼요.
그러니까 기본적으로 우리가
베를로그 시뮬레이션을 하는 데 사용할 수
하는 데서 얻을 수 있는 정보는
여기서 다 얻을 수 있어요.
그래서 에뮬레이션이
시뮬레이터에 비해서 훨씬 빠르고
시뮬레이터에서 제공되는
그런 여러 가지 웨이브 폼 같은
그런 정보들도 다 제공하고 하기 때문에
굉장히 사용하기 편합니다.
대신에 엄청나게 비쌉니다.
왜냐하면 이거는 전용 기기이기 때문에
하드웨어 시뮬레이션만 할 수 있어갖고
사실 이게 범용적으로 쓰이지는 않다 보니까
시장 규모가 그렇게 크지 않아서 그런지
아니면 이거를 만드는 게 어려워서 그런지
이 장비는 상당히 고가의 장비입니다.
그다음에는 이거를 시뮬레이션 모델을
조금 개선을 해가지고
시뮬레이션 속도를 높이는 방법들이 있습니다.
아까 제가 퍼스트 오더
이거를 보여드렸잖아요.
그러니까 우리가 일반적으로
베릴로그 시뮬레이션을 할 때
사용하는 모델은 예를 들면
한 이 정도 수준인 거예요.
그런데 이 시뮬레이터
내가 시뮬레이션하는 칩의 어떤 부분에 대해서는
내가 지금 현재 하고 있는 시뮬레이션의 목적에서는
그게 굳이 자세하게 모델링이 될 필요가 없는 거예요.
그러면 이거를 별로 내가 관심이 없는 부분은
이걸로 바꾸는 거죠.
그러면 그 부분은 시뮬레이션 속도를
이렇게 해서 빠르게 할 수가 있습니다.
그래서 그게 제일 대표적인 것들이 이런 게 있어요.
버스 펑셔널 모델
인스트럭션셋 시뮬레이터
이런 것들이 있는 겁니다.
예를 들면 인스트럭션셋 시뮬레이터 같은 경우에는
프로세서인 거예요.
그러니까 예를 들어갖고 내가
어떤 시스템이 있는데
그 시스템에 보통은 프로세서가 들어가잖아요.
프로세서가 들어가고
나는 내가 개발한 거는
그 프로세서가 사용하는 일종의
하나의 페리페러를 하나 만든 거예요.
예를 들면 내가 USB를 만들었어요.
그러면 나의 입장에서는
USB를 검증하는 게 목적이에요.
프로세서를 검증하는 게 아니고
그다음에 이 시뮬레이션을 통해서
나한테 필요한 입력은
저 프로세서가 어떤 명령어를 수행해서 나온 결과
그런데 그 결과 중에서도
USB 쪽으로 오는 어떤 명령
또는 데이터
이런 것들이 중요한 거지
프로세서가 내부에서 어떻게 돌아가는지는
나한테는 전혀 중요한 게 아닌 거죠.
그러니까 이런 경우에는
이 프로세서를 내부에 있는 시그널까지
다 디테일하게 시뮬레이션을 할 필요가 없고
이거를 인스트럭션셋 시뮬레이터로 바꾸는 겁니다.
그러면 이 인스트럭션셋 시뮬레이터는
이 프로세서 내부에 있는 시그널들을
하드웨어 시그널 단위로 다 시뮬레이션을 해주는 게 아니고
얘는 그냥 소프트웨어의 인스트럭션을 하나하나 실행을 시켜서
거기서 나오는 결과물들만
그러니까 말하자면 하드웨어 쪽으로 나오는 시그널들만
정확하게 모델링을 해놓은 거예요.
그러니까 이거 같은 경우에는
이거를 쓰게 되면
그러니까 이런 내가 USB를 검증한다는 목적에만 사용할 때는
내가 프로세서의 내부를 알고 싶지 않을 때는
그럴 때는 이걸로 시뮬레이션을 하면
시뮬레이션 속도를 높일 수가 있겠죠.
그거랑 비슷하게 이 버스 펑셔널 모델은
버스에 대해서도 이거랑 유사한 걸 할 수가 있어요.
그러니까 보통은 프로세서를 사용하게 되면
그 프로세서의 프로세서가 사용하는
시스템 버스 규격이 있잖아요.
내가 암을 쓰면 암에서 나오는 APB, AXI 이런
암밥 프로토콜이 있고
아니면 내가 다른 프로세서를 쓰게 되면
그 프로세서에 맞는 위시본이라든가
소닉스라든가 여러 가지 시스템 버스 표준들이 있잖아요.
그런 표준들이 있어요.
그런데 여기서도 마찬가지로
나는 USB를 검증하고 싶은데
거기서 이 시스템 버스의 시그널들이 뭐가 있고
시스템 버스도 얘네들을 구성하고 있는 컴포넌트들이 있으니까
걔네들이 어떻게 동작하는지는 별로 관심이 없는 거예요.
나는 그냥 그 버스에서 오는 명령, 데이터 이런 것들만 알면 되는 거죠.
나의 입장에서는.
그럴 때는 이 버스도 버스 펑셔널 모델로 바꾸면 된다는 겁니다.
그다음에 C 같은 경우에는 이거는 나는 USB를 만들었는데
이 USB가 예를 들면 옆에 있는 다른 메모리 컨트롤러랑
아니면 DMA 이런 거랑 같이 동작을 하는 거예요.
그러니까 이런 것도 시뮬레이션을 통해서
잘 동작하는지 검증을 해볼 필요가 있어요.
그런데 나는 USB를 검증하면 되는 거기 때문에
저기 있는 저 DMA가 어떻게 동작하는지는 별로 관심이 없어요.
그러면 저 DMA를 DMA 내부 시그널까지
다 베리로그로 디테일하게 모델링을 한 거를 쓰지 않고
이거를 상위 수준에서 C 같은 걸로 모델링한 거를 쓰겠다는 거예요.
그래서 이게 트랜잭션 레벨 모델링이라고 얘기를 합니다.
그래서 제가 아까 그 강의 계획을 설명을 하면서
트랜잭션 레벨 모델 이런 것들이 있다고 말씀드렸는데
이게 결국은 어떤 IP나 어떤 하드웨어를
이게 사실은 인스트럭션 세트 시뮬레이터나 버스 펑셔널 모델이
다 트랜잭션 레벨 모델의 일조기과로 보시면 돼요.
그러니까 하드웨어가 있을 때 그 하드웨어를
베리로그 수준에서 디테일하게 모델링을 한 게 아니라
얘를 상위 수준으로 끌어올려갖고
디테일한 거를 필요 없는 것들을 숨기는
내가 원하는 중요한 기능만 모델링을 하는 거를
트랜잭션 레벨 모델링이라고 합니다.
그런데 트랜잭션 레벨 모델링을 할 때
C 같은 이런 소프트웨어 랭기지를 쓰기도 하고요.
아니면 C++나 시스템 C
아니면 심지어 시스템 베리로그를 이용을 해서도
어쨌든 이 상위 수준 모델링이 가능합니다.
그래서 그런 것들이 이제 시뮬레이션 속도를 높이기 위한 방법들이 있습니다.
그리고 이 밑에 있는 것들은 이 두 가지
이거는 이제 검증에 쓰이는 시뮬레이션 방법인데
이 커버리지 드리븐 베리피케이션은 아까 제가
강의 계획 설명할 때 간단하게 말씀을 드렸어요.
어섹션 베이스도 그렇고 그리고 이거 두 개는 어차피
이제 우리가 강의 시간에 할 거니까
이거는 넘어가도록 하겠고요.
그 다음에 코 시뮬레이션이 있어요.
코 시뮬레이션도 크게 두 가지가 있는데
하드웨어랑 소프트웨어를 같이 시뮬레이션을 한다는 의미에서의
코 시뮬레이션이 있고
아날로그랑 디지털을 같이 시뮬레이션을 한다는 의미에서의
또 코 시뮬레이션이 있어요.
그래서 이거 두 개는 서로 다른 종류의 시뮬레이터를
같이 붙여갖고 쓰는 그런 상황을 얘기를 하는 겁니다.
그러니까 하드웨어 시뮬레이션은 보통은 베리로그 같은 거를 쓰고
소프트웨어 시뮬레이션은 아까 말씀드렸던
인스트럭션셋 시뮬레이터 이런 거를 쓰니까
이거를 서로 다른 시뮬레이터를 쓰게 되는 경우들이 생기는데
그러면 얘네들을 같이 연결해서 쓰는
그런 시뮬레이션 기술을 얘기를 하는 거고요.
아날로그 디지털 시뮬레이션도 마찬가지입니다.
그러니까 아날로그 시뮬레이션을 하는 거는
보통은 P-spice라는 것과 H-spice 같은
그런 아날로그 시뮬레이션 하는 툴이 별도로 있고
베리로그 같은 그런 디지털 로직을 시뮬레이션 하는 툴은
또 따로 있잖아요.
얘네들을 이렇게 연결해서 쓰는
그런 것들을 얘기를 하는 거죠.
그래서 이런 시뮬레이션 검증을 위해서 사용되는
시뮬레이션 방법론들이 이렇게 다양한 것들이 있습니다.
그래서 이벤트 드리브 사이클 베이스 시뮬레이션 이거는 다
설명을 드렸고요.
그래서 이것도 앱 스테이션 레벨에 따라갖고
여기서 말하는 스파이스가
보통은 아날로그 IP 시뮬레이션 하는 데 쓰는데
디지털 IP도 어떻게 보면 아날로그의 일정이니까
그것에 사용하는 시뮬레이션 하는 데 쓸 수 있습니다.
그래서 이게 이제 어쨌든 점점 사이즈가 커지면서
시뮬레이션 해야 될 게 굉장히 많아져가지고
시뮬레이션 속도가 굉장히 문제가 되고 있다라는 말씀이고요.
그래서 쓸 수 있는 게 이제 이런 래피드 프로토타입
아까 말씀드렸던 FPGA 같은 게 대표적인 거고
그런 것들을 사용을 합니다.
그 다음에 시뮬레이션 속도를 높이기 위한
버스 펑셔널 모델, 인스트럭션 세트 시뮬레이션
뭐 이런 것들을 다 말씀을 드렸고요.
그 다음에 테스트 벤치 같은 경우에는
우리가 결국 이번 강의에서 제가
시스템 베를로그 중에서 검증에 관련된
그런 문법들 위주로 제가 설명을 드린다고 말씀을 드렸는데
그러니까 검증에 필요한 문법이라는 거는
결국은 테스트 벤치를 만드는 데 필요한 문법이라는
그런 얘기라고 이해를 하시면 됩니다.
이거는 거꾸로 말하면은
설계하는 데는 쓰기가 좀 어려운 문법들이 있어요.
모든 게 다 그런 거는 아닌데
설계를 한다는 얘기는
나중에 결국은 합성을 해가지고
개인 레벨로 만든다는 얘기인데
보통은 베를로그에도 그런 용어가 있잖아요.
Synthesizable Subset
그러니까 베를로그에서도 여러 가지 문법들을
시멘틱을 지원을 하는데
그중에서 하드웨어로 나중에 결국은
합성이 가능한 그런 시멘틱이 있어요.
근데 그 하드웨어로 합성 가능한 시멘틱을 제외한 부분
그런 것들이 다 이제 보통은
테스트 벤치를 만들기 위해서 사용되는
그런 시멘틱인 거죠.
그래서 이번 강의에서는
SystemBerylog에서
그런 테스트 벤치를 만들기 위해 사용되는
시멘틱 또는 신텍스를
이렇게 설명을 드린다고 보시면 될 것 같아요.
그래서 결국은 검증을 위해서 우리가 하는 일은
테스트 벤치를 만드는 거를
이제 하게 되는
그런 거라고 보시면 되겠습니다.
그래서 여기서 나오는 게 이제
어떤 Stimulus Generator
이게 결국은 Constraint Random
Verification이라고 말씀을 드릴 수가 있고
그 다음에 이거를 자동으로 확인할 필요가 있다고 말씀을 드렸죠.
그래서 자동으로 확인하는 방법은
Transition Level 같은 일종의 골든 모델을 만들어서
개랑 결과를 비교를 하거나
Assertion을 쓰거나
뭐 이런 것들을 할 수가 있습니다.
물론 이거는 이제 자동으로 할 때 얘기고
사람이 할 때는 보통은 이제 웨이브 폼 같은 거를 쓰죠.
그래갖고 이게 웨이브 폼을 보고
사람이 눈으로 보고 판단을 하는 거를
보통은 사용을 합니다.
Covered Reality Driven Verification은 이제
아까 말씀드린 것처럼
내가 이 정도면 충분히 검증을 했나?
라고 하는 거를 확인을 하는 데 사용되는
그런 방법론입니다.
그래갖고 요거를 이제
요것도 이제 우리가 수업 시간에 다룰 거예요.
그러니까 요거는 그냥 요 정도로만 하고 넘어가겠습니다.
자, 여태까지가 이제 시뮬레이션에 관련된 내용이었어요.
그 다음에는 그 Static
이거는 시뮬레이션을 돌려보지 않고
코드만 보고 검증을 하는 겁니다.
그러니까 여기 같은 경우에는
모든 것을 다 검증할 수는 없고
이제 필요한 부분만 검증을 하는 거예요.
그러니까 기능적인 부분을 검증하는 데 쓰이기도 하는데
그거는 이제 뒤에서 얘기할
포멀 verification에 더 가깝고
여기서는 주로 이런 것들을 합니다.
먼저 나오는 거는
Lint 또는 뭐 Inspection이라고도 하는 건데
이거는 뭐냐면은
이게 이제 주로 쓰이는 거는
이 디자인 룰 체크
DRC라고 하죠.
거기에 많이 사용이 됩니다.
그러니까 이거는
기능적인 부분이라기보다는
어떤 코딩 스타일
같은 거를 확인을 해준다던가
아니면은 이게 결국은 나중에
합성을 해가지고
어떤 그 레이아웃까지 했다고 했을 때
거기서 뭔가 나중에 물리적으로 생길 수 있는
문제를 막기 위해서
이 설계를 하는 단계에서
뭔가 해줘야 되는 것들이 있는 경우들이 있어요.
예를 들면은
그 어떤 공정에서는
어떤 공정에서는
클락 게이팅이 지원이 안 되는 공정이 있을 수가 있어요.
그런데 그거 같은 경우에는
클락 게이팅 말고 그러면
뭐
예를 들면은 뭐 래치 같은 거를 쓰면 안 된다던가
뭐 이런 식으로 공정에 따라서
그런 것들을 이제 코딩 스타일이 안 맞는
그런 이제 뭐 공정 같은 게 있을 수가 있다는 거죠.
그래서 그런 경우에는
이거를 RTL에서
그런 것들을 확인해주는
그런 툴이 있습니다.
그래서 이거 같은 경우에는
시뮬레이션을 굳이 돌려보지 않아도
RTL 코드만 보고
이게 나중에 합성이 돼서
레이아웃이 끝나고 난 다음에
혹시나 공정에 가가지고
문제가 생기는 거를
이 코드 단계에서
이제 걸러주는
그런 것들을 자동으로 해주는 툴들이 있어요.
그래서 보통은 이제
그런 데에 많이 쓰입니다.
그래서 뭐 이런 것들이
아까 말씀드린
DRC, RTL, DRC 같은 것들이 그런 거고요.
그 다음에는
뭐 합성을 하기 전 단계에서
프리 프로세싱을 하는 것도 있고
그 다음에
여기서는 그러니까 기능적인 부분을 검증한다기보다는
이게 다 결국은 DRC라고
DRC의 일종이다 이렇게 말할 수가 있는데
어떤 회사 같은 데서
어떤 조직에서
코딩 스타일을 통일을 해놓는
그런 경우들이 있어요.
제가 옛날에 있었던 삼성 같은 경우에는
예를 들면 뭐 이런 것들이 있었어요.
어떤 모듈을
여기서는 이제
그러니까 말하자면
그거는 그 회사만의 규칙인 거예요.
그러니까 예를 들면
저희 부서 같은 경우는
이런 규칙들이 있었어요.
하나의 베릴로그 파일에는
하나의 모듈만 정의를 해요.
하나의 파일 안에
여러 개의 모듈이 들어가 있지 않아.
하나의 파일에는 하나의 모듈
그리고 그 파일 이름은
그 모듈의 이름하고 동일해.
그 다음에
어떤 모듈의 포트가 있으면
그 포트는 항상
소문자 I, 소문자 O로 시작을 해요.
입력 포트는 I로 시작하고
출력 포트는 O로 시작을 해.
그러니까 이게 그 소프트웨어 쪽에서 얘기하는
뭐 헝가리안 노테이션 뭐 이런 거 있잖아요.
C++ 같은 경우에도
이게 뭐 C++라는 랭기지에서
뭔가 문제가 있기 때문에
이렇게 이름을 붙여야 되는 거는 아니지만
이런 규칙을 써가지고 이름을 붙이면
나중에 디버깅을 하거나
유지 보수할 때 편하다라고 해가지고
사람들이 이제 뭐 써보니까
괜찮네 해가지고 많이 쓰는
그 네이밍 컨벤션이 있는데
그거를 이제 뭐 헝가리안 노테이션 이렇게 부르잖아요.
그런 거가 있는 거예요. 말하자면은.
그러니까 이런 것들은 뭐
이걸 안 지킨다고 해가지고
동작하지 않거나 뭐 이런 것들은 아니지만
어떤 부서에서의 모든 사람이 다
이 동일한 코딩 스타일로 코딩을 해라라고 하는
그 부서만의 규칙이 있다면
이거를 규칙만 만들어 놓고
확인을 안 하면 아무도 안 지킬 거 아니에요.
그러니까 이런 것들을 자동으로 확인해주는
툴이 있는 거죠.
그래서 그런 것들을
뭐 사용을 하기도 합니다.
그래서 그런 데 쓰이는 게 이제
이런 린터라고 하는 툴이 있고요.
그러니까 이런 것들은 뭐
소스 코드만 보고 확인을 할 수 있는 거다 보니까
뭐 시뮬레이션을 하지는 않습니다.
그 다음에 시뮬레이션을 하지 않고
코드만 보고 또는 뭐 레이아웃만 보고
돌리는 툴 중에서 굉장히 대표적인
뭐 린트 같은 경우에는
뭐 쓰기도 하고 안 쓰기도 하고 할 수 있지만
이 STA는 많이 사용하는 툴입니다.
그러니까 이거는 이제
스태틱 타이밍 언어네시스라고 해가지고
제가 그 검증하는 그
검증할 때 확인해야 되는 필요가 있는
항목 중에 하나가 이제 타이밍이라고 말씀을 드렸는데
그 타이밍이라고 하는 게 결국은
어떤 클락의 엣지 사이에서
어떤 컨비넨셜 로직이
필요한 시그널들을 다 타이밍에 맞춰가지고
생성을 해주는지 여부를 확인을
그거를 다 검증을 해야 된다고 말씀을 드렸어요.
근데 이거를 검증을 하는데 보통은
시뮬레이션을 통해서 할 수가 있어요.
그래서 어떤 그 게이트의 딜레이
그 다음에 와이어의 딜레이
같은 것들을 다 모델링을 해가지고
시뮬레이션 모델을 이용을 해서
시뮬레이션을 해보면
여기서부터 여기까지 딜레이가
얼마나 되는구나
라고 하는 것들을 다 시뮬레이션 통해서
확인을 할 수가 있죠.
그런데 이게
워낙 그 칩이 이제 복잡해지고
커지다 보니까
이거를 시뮬레이션만을 통해 갖고
검증을 하려면
시간이 이제 너무 많이 걸리는 거예요.
그러다 보니까 이제 이거를
스태틱 타이밍 언어넬스스를 합니다.
그러니까 이거는 시뮬레이션을 해보지 않고
이 구조가 딱 있으면
이 구조를 보면
이 게이트 딜레이 얼마
이 와이어 딜레이 얼마라고 하는 게
그냥 시뮬레이션을 해보지 않아도
계산을 할 수가 있잖아요.
그러니까 이거를 시뮬레이션을 해보지 않고
여기서 이제 계산을 해보는 거죠.
물론 시뮬레이션을 했을 때
조금 더 정확하게 모델링을 할 수 있는 경우가
있을 수는 있어요.
그런데
이거는 이제
시뮬레이션을 통해 갖고 할 때는
예를 들면
이런
그
데이트의 딜레이도
얘가
라이징을 할 때랑
폴링을 할 때가
약간 다를 수 있어요.
속도가
그러니까
그 말은 뭐냐면
이 게이트에서 나오는
출력이 0이냐 1이냐에 따라 갖고
딜레이가 조금 달라질 수 있다는 거죠.
그러니까 이런 것들을 디테일하게 알고 싶을 때는
시뮬레이션을 해야 되겠지만
우리가 여기서
STA를 하는 목적은 뭐냐면
월스트 케이스 딜레이를 알고 싶은 거예요.
그러니까 크리티컬 패스 딜레이를 알고 싶은 거예요.
왜냐하면 그게 중요하니까
그러니까 우리가 타이밍을 검증한다는 말의 의미는
이 클락의 엣지에서
그 다음 클락 엣지가
엣지 전까지
모든 시그널들이 다
그
안정적으로
출력을
만들어내느냐
여부를
이제 검증을 하겠다는 건데
그러면은
이 말은
이 출력 시그널 중에서
제일 늦게 나오는 시그널
이
다음 클락 라이징 엣지 전에
그 제일 늦게 나오는 시그널이
다음 라이징 엣지 전에
생성이 되느냐
요거를 확인을 하겠다는 거죠.
그러니까
월스트 케이스 딜레이가
그
한 클락의 주기보다 짧으냐
이거를 알고 싶은 거거든요.
그러니까 이 STA를 하게 되면은
그 월스트 케이스 딜레이 위주로
이제 확인을 하게 되는 겁니다.
그러니까 시뮬레이션을 하게 되면은
월스트 케이스가 아니라
여러 가지 시나리오에 대해서 다 딜레이를 계산을 해볼 수가 있다면
이 STA는
어차피 내가
내가 이거를 하는 목적은
월스트 케이스 딜레이를 알고 싶은 거기 때문에
그거를 이제
이 스태틱 타이밍 어네리시스를 통해서 하겠다는 거죠.
그래서
스태틱 타이밍 어네리시스도
원칙
원래는 이거를
레이아웃이 다 끝나고
GDS까지 나왔을 때
그때 해야 제일 정확하겠죠.
왜냐하면 그때는 이제 이런 게이트들도 다 배치가 끝났고
걔네들도 다 연결이 됐고
걔네들이 어떻게 연결될지
그 패턴들도 다 나와 있기 때문에
각각의 와이어의 딜레이
뭐 그런 것들이 다 정확하게 모델링이 돼요.
그렇기 때문에 그때 돌리는 게 제일 정확하기는 하지만
근데 그때 가서 문제가 생기면은
이거를 또 그 앞단계로 돌아와가지고
수정을 해가지고
이거를 계속 이 룹을 돌아야 된단 말이죠.
근데 레이아웃까지 다 끝나고 난 답을 확인해가지고
다시 설계 단계로 문제가 생기면
다시 설계 단계로 돌아가가지고
또 이 룹을 돌라고 그러면은
시간이 너무 많이 걸리는 거예요.
그러니까 이 스태틱 타이밍 어네리시스도
GDS 단계에서 하지 않고
앞단계에서 하기도 해요.
물론 앞단계에서 하게 되면은
속도가 빠르기는 하지만
이제 정확도가 조금 떨어지기는 하죠.
그러니까 어쨌든 GDS2 제일 마지막 단계에서
뭐 최종적으로 해주기는 해줘야 되지만
앞단계에서 할 수 있으면
앞단계에서 나오는 것들을 조금 부정확하지만
일단 다 어느 정도 해결을 해놓고
그 다음에 뒤에 가서 또 문제가 생기는 거는
그때 가서 해결을 하는
그런 방식으로 하는 게 조금 더 효율적이라서
그런 방식으로 많이들 합니다.
특히나 복잡하고 큰 칩 같은 거
뭐 간단한 칩들이야.
뭐 언제도 상관이 없는데
근데 복잡한 칩 같은 경우에는
그런 식으로 해서
앞부분에서 빠르게 확인을 좀 해봐서
웬만한 문제는 거기서 한 번 다 해결을 하고
거기서 해결이 안 되는 것들을
이제 뒤에 가서 확인하는
그런 방식을 사용을 합니다.
그래서 어쨌든 이거는 이제
타이밍을 검증한다는 목적에서
활용되는 툴이고
그래서 이거는 시뮬레이션을 굳이 하지 않고
이제 이런 것들을 확인을 해볼 수가 있습니다.
그 다음에 아까 제가 뭐
베리피케이션 챌린지라고 해가지고
여러 가지 것들을 말씀을 드렸잖아요.
그래서 방금 말씀드린 게 이제 타이밍이고
그 다음에 시그널 인테그리티 같은 게
이제 크로스톡하고 관련되어 있는
그러니까 뭐 그런 것들이고
그래서 이런 것들은 사실 설계 단계에서
고려를 하기보다는
이거는 보통은 설계가 끝나고 난
뭐 소위 말하는 백엔드
그 쪽에서 주로 아니면 공정 쪽에서 이제
주로 하는 것들인데
근데 이것들을 이제
경우에 따라서는
설계 단계에
그 반영을 하게 되는 경우들이 있기 때문에
여러분들이 이제 대충 이런 것들은
있다라는 것 정도를 알아주시는 건
나쁘지 않습니다.
예를 들면은 타이밍 같은 경우만 해도
이제 이런 경우들이 생겨요.
그러니까 내가 어떤 IP를 설계를 했는데
이거를 뭐 기능적으로는 아무 문제가 없어요.
그래갖고 뭐 기능은 검증이 다 끝나갖고
이제 합성을 하고 레이아웃을 해가지고
그 뭐 최종적으로 STA까지 돌렸는데
타이밍을 맞출 수가 없어.
그러니까 타이밍을 맞출 수가 없다는 거는
보통은 이제 설계를 할 때
내가 만든 IP에
하겟 클락 프리컨시를 정해요.
그래서 내가 예를 뭐 예를 들면은
200메가로 돌려야겠다.
라고 하는 것들이 이제 목표가 정해집니다.
그러면은 설계가 끝나고 난 다음에
그 목표에 따라서
합성을 하고 레이아웃을 해요.
근데 레이아웃을 해봤는데
200메가 헤르츠가 도저히 안 나와.
그러면은 이제 앞단계로 돌아가서
합성을 다시 하거나
뭐 레이아웃을 다시 하거나 해가지고
어떻게 해서든지 이게 200메가로 돌아가게
그 백엔드 뭐 툴 돌려가지고
이제 백엔드 하는 사람들이
열심히 툴에 뭐 이렇게 컨스트레인트 조정하고
뭐 레이아웃 바꿔보고
막 이래가지고 해결을 시도를 해요.
그랬는데 하다 하다 하다 안 되면
결국은 RTL 프로그래머한테 요청을 해요.
이거 도저히 타이밍이 못 맞추겠으니까
RTL 좀 고쳐주세요.
그러면은 RTL 하는 사람이 결국은 고쳐야 돼요.
제일 뭐 쉽게 제일 쉬운 거는 예를 들면은
이게 문제가 되는 어떤 크리티컬 패스에 있는
어떤 그 로직이 있어요.
그러면은 뭐 그 거기다가 중간에다가
레지스터를 하나를 추가를 해요.
그러면은 얘가 사이클의 관점에서는
한 사이클 늘어나지만
크리티컬 패스 관점에서는 반으로 줄잖아요.
그러니까 만약에 이렇게 해서 해결되면
제일 간단한 거고
만약에 이게 안 되면은 이제 RTL을 완전히 다 뜯어 고쳐야 되고
뭐 그런 문제가 생길 수가 있는 거죠.
어쨌든 이런 식으로 이게 백엔드 쪽에서
예를 들면은 이거는 제가 말씀드린 거는
타이밍에 관련된 문제였는데
타이밍에 관련된 문제가 아니라
다른 종류의 문제들에 있어서도
이거를 뒤에 가서 백엔드나 공정 쪽에서 생기는 문제들을
그쪽에서 막 이렇게 해결을 하려고 하다가
하다 하다 안 되면은 결국은 RTL까지 와요.
그래갖고 이거를 RTL을 수정을 해야 되는 경우가
생길 수 있다는 거죠.
근데 이제 문제는 RTL을 수정을 하게 되면은 이거를 이 프로세서를 다시 다 해야 되죠.
합성도 다시 해야 되고 레이아웃도 다시 해야 되고
이걸 다시 다 해야 되니까
여기까지 돌아오면은 이제 시간이 많이 걸려요.
이 룹을 엄청나게 큰 룹을 돌아야 되는 거예요.
그래서 어쨌든 설계를 아예 시작할 때부터
이런 것들을 어느 정도 고려를 해가지고
설계를 할 수 있으면 좋다는 거고
뭐 어쨌든 간에 뒤에 가서 백엔드 쪽에서 문제가 생기는 거를
RTL 쪽에서 반영을 해야 되는 경우가 생길 수도 있다는 거.
그래서 이런 물리적인 현상들을 이제 검증을 하는 게
어떤 것들이 있는지 이게 왜 문제가 되는지
뭐 이런 것들은 어느 정도는 알아주시면
뭐 좋을 거라고 생각을 합니다.
다음에는 뭐 디바이스 테스트 같은 거는
이거는 이제 테스트예요. 테스트.
이거는 베리피케이션이 아니고
이거는 이제 다 뭐 실리콘으로 물리적으로 구현이 끝난 다음에
얘가 정말 제대로 되고 있는 건지를 확인하는 뭐 그런 겁니다.
그래서 이거는 뭐 테스트 쪽이니까
뭐 그냥 이 정도로만 하고 간략하게 넘어가도록 하겠고요.
근데 이 테스트가 여기서 또 왜 나오느냐.
이 테스트를 하는데도 이거를
그러니까 이 물리적인 결함이 있는지를
다 제조가 끝난 다음에 확인을 하는 거예요.
이걸 어떻게 확인해?
검증을 다시 해볼 수도 없잖아요.
이미 칩이 다 제조가 돼서 나왔는데
얘를 다시 시뮬레이션을 해볼 수도 없고
물론 여기에 칩이 있으면 그 칩에 핀들이 있어갖고
그 핀들의 입력과 출력을 우리가 입력을 넣어보고
출력이 제대로 나오는지 정도는 확인을 해볼 수가 있겠죠.
그런데 그 입력만 가지고 내부가 모든 케이스를 다 확인을 해보기에는
시간도 너무 많이 걸리고
그런 하여튼 현실적인 문제가 있어요.
그래서 보통은 그 DFT라고 해서
디자인 포 테스터빌리티라고 하는 그런 기술을 씁니다.
그러니까 이거는 설계를 하는 정확하게 말하면 설계라기보다는
합성하는 단계에서 이 DFT에 관련된 로직을 집어넣어요.
그래갖고 나중에 테스트하기 편하도록
이제 만들어주는 그런 기능들을 합니다.
그러니까 베리로그를 하시다 보면
여러분들이 스캔체인이나 이런 걸 들어보신 분도 있을 텐데
제일 대표적인 게 그런 스캔체인이에요.
그래서 이거 스캔체인은 뭐냐면
우리가 이제 싱크로노스 로직을 주로 쓴다고 말씀을 드렸는데
싱크로노스 로직들은 결국은 회로 안에 레지스터들이 쭉 들어가게 됩니다.
그러면 그 레지스터를 체인으로 이렇게 쭉 엮어놓은 거예요.
그래서 이게 스캔체인이에요.
그런데 이 스캔체인은 테스트할 때만 쓰는 거지
일반적으로 정상적인 동작하는 상황에서는 쓰는 것들이 아니에요.
그래서 이거를 테스트를 할 때 이 스캔체인을 이용을 하면
이 회로 안에 있는 모든 레지스터의 값들을
이 체인을 통해서 다 변경을 할 수 있고
그 레지스터의 값을 이 체인을 통해서
딱 이게 확인을 해볼 수가 있습니다.
그래서 그것들을 지원을 하는 게
디자인 포 테스트빌러티라고 해서
DFT라고 보통을 얘기를 하고
그거는 설계 단계에서 들어가는 건 아니지만
합성을 할 때 합성해주는 툴이
이제 자동으로 그런 것들을 생성을 해줍니다.
그래서 이런 DFT를 써가지고
이제 그런 테스팅을 하게 되겠고요.
그리고 이 DFT가
스캔체인이 또 하드웨어 쪽에서만 쓰이는 게 아니라
이거를 이제 프로소스 쪽에다가 집어넣으면
우리가 왜 디버거 같은 거 쓰잖아요.
근데 뭐 데스크탑에서 쓰이는 디버거 같은 경우에는
그냥 뭐 디버거 붙여가지고 쓰게 되지만
이런 그 인베디드 보드 같은 경우에는
그 아이스 같은 에뮬레이터 장비를 써가지고
얘를 거기다가 이제 보드에다가 연결을 해가지고
디버거를 붙이게 되죠.
그러면 그 아이스 장비가 해주는 게 결국은
이 스캔체인을 이용해서 프로세서 내부에 있는
레지스터를 이제 확인해보던가
그 값을 바꿔보던가
이런 것들을 이제
이 스캔체인을 이용해서 할 수 있게 해줍니다.
그래서 그런 것들이 들어가고요.
그런데 여기서 이제
이 테스트를 쉽게 하기 위한 로직이 들어가기도 하지만
테스트를 아예 자동으로 해주는 로직이 들어가기도 해요.
그게 이제 그 빌트인 셀프 테스트라고 해가지고
리스트라고 얘기를 합니다.
이거는 우리가 테스트를 한다고 그러면 나중에
다 그 칩이 제조가 되고 난 다음에
여기에 테스트 패턴을 입력해가지고
그 출력이 제대로 나오는지를 확인을 해요.
그래서 여기에 테스트 패턴을
뭐 만들어주는 게 이제
오토매틱 테스트 패턴 제너레이터라고 해가지고
ATP지 이런 거를 사용을 하는데
그러면 이거는 이제 로직에 따라가지고
테스트 패턴을 만들어줘야 되는데
메모리 같은 경우만 해도
제일 대표적인 게 메모리에 많이 쓰는데 비스트가
메모리는 사실은 그냥 메모리에다가 데이터를 쓰고
쓴 값이 정상적으로 읽혀지는지만 확인하면 되니까
이거는 테스트 패턴이 굉장히 단순한 거죠.
그래서 이거를 굳이 뭐 이거를 나중에 가가지고
테스트 장비를 연결을 해가지고 테스트 해볼 필요가 없이
이렇게 간단한 테스트 시나리오 정도는
그냥 셀프 테스트 할 수 있는 로직으로 만들어요.
그래갖고 메모리 같은 경우에는
그냥 이 비스트 같은 거를 쓰게 되면
알아서 테스트를 해줍니다. 테스트 로직이
그리고 심지어는 아까 왜 스페어 리전 같은 거를
만들 수도 있다고 했잖아요.
그러니까 원래 내가 필요한 거는 32KB 메모리인데
이게 혹시나 여기에 뭔가 물리적인 결함이 있으면
얘를 4KB짜리 스페어 리전을 넣어가지고
얘로 이렇게 교체를 해가지고 쓰게 되는
그런 것도 할 수 있다고 말씀드렸잖아요.
심지어는 비스트가 그런 것도 자동으로 해줍니다.
그래서 메모리 비스트 같은 경우에 실제로 많이 쓰이고요.
그래서 그런 것들은 설계할 때 반영이 되는 것들이고
근데 메모리 비스트가 아니더라도
이제 DFD 같은 것들은 또 이제
스캔 체인 같은 거를 통해가지고
나중에 테스트하기 편하도록 하는 것들도
많이 사용을 하고 있습니다.
그런 거고요.
그래서 아까 말씀드린 메모리 비스트
뭐 이런 것들이 있고 스캔 체인
그래서 이거를 제가 지금까지 설명을 드린 거고요.
자 그 다음에 이제 그 검증 방법론의 마지막으로
포멀 테크놀로지가 있습니다.
포멀이라고 하는 거는 이제 아까 말씀드린 것처럼
어떤 수학적인 모델을 이용을 해가지고
그 증명을 하는 거예요.
그래갖고 이거는 이제
이것도 이제 방법이 몇 가지가 있는데
그중에 이것도 이제 시뮬레이션을 통해 갖고 하는 것도 있고
완전히 수학적인 모델로 하는 것도 있어요.
그래서 이런 것들에 대해서 한 가지씩 조금 알아보도록 하겠습니다.
먼저 나오는 게 이제 Theorem Proving인데
이거는 말 그대로 Proving을 하는 거예요.
그래갖고 내가 어떤 시스템이 있을 때
그 시스템이 내가 원하는 대로 동작하는지를 확인을 하기 위해서
어떤 그 어떤 그 수학적으로 얘를 모델링을 해서
그거를 가지고 이제 그 증명을 하는 거죠.
그러다 보니까 이거는 어떻게 자동화를 하기가 조금 어려워요.
그냥 문자 그대로 기능을 보고
걔를 어떤 그 공리나 그러니까 뭐 엑시움
엑시움이나 무슨 Theorem 같은 거를 만들면서
얘가 정말로 내가 원하는 대로 동작하는지를
증명을 하는 과정이기 때문에
이거는 그러니까 이렇게 여기서 말씀드린 것처럼
이게 굉장히 어렵고 시간도 많이 걸리고
그래서 이거는 정말 중요한 어플리케이션
또는 정말 중요한 어떤 모듈
이런 데서만 제한적으로 쓰이지
일반적으로 쓰이는 거는 아닙니다.
그리고 이거는 뭐 자동으로 하기가 조금 어려워가지고
사람이 보고 해야 되는 거니까
그런 조금 어려운 점이 있고요.
근데 어쨌든 이게 만약에 가능하다고 그러면
이것만큼 확실한 게 없는 거죠.
그 다음에 모델 체킹이라고 하는 게 있어요.
모델 체킹은 이거는 이제 어떻게 보면
아까 Theorem Proving이 100% 완벽하게 증명을 하는 거라면
모델 체킹 같은 경우에는
내가 정의한 어떤 특정한 프로퍼티들
얘네들이 항상 만족되는지 정도 수준으로만 확인을 하는 겁니다.
그러니까 여기 같은 경우에는
프로퍼티를 어떻게 정의하느냐가 굉장히 중요해요.
그런데 어찌 됐든 내가 프로퍼티를 정의를 해놓은 거에 대해서는
얘가 전부 만족한다라고 하는 거를 확인을 해볼 수가 있게 되는 거죠.
그래서 이거 같은 경우에도 이제 크게 나누면
얘도 스태틱한 방법이 있고
시뮬레이션을 이용한 방법이 있어요.
내가 정의해놓은 이 프로퍼티가 항상 만족되는지를
시뮬레이션을 통해서 확인하는 방법이 있어요.
그러니까 이거는 이 시뮬레이션을 쓰게 되면 문제가
시뮬레이션 시나리오에 대해서만 검증이 되는 거죠.
그런데 스태틱한 방법은 이거를 소스 코드를 보고 분석을 하는 거니까
얘는 시나리오에 상관없이 항상 만족된다라는 거를 확인을 할 수가 있습니다.
대신에 이렇게 되면 이게 좀 속도가 느린 면이 좀 있어요.
왜냐하면 시뮬레이션을 하지 않고 스태틱하게 하는 방법은
대부분의 경우에는 가능한 모든 케이스들을 다 검증을 해요.
그러다 보니까 얘가 케이스들이 회로가 조금만 복잡해져도
케이스가 익스프네셜하게 증가를 하잖아요.
그러니까 이게 이제 스테잇 익스플로전 프로블럼이라고 해서
이 스테잇이 폭발적으로 증가를 하는 거예요.
그러니까 이게 복잡한 회로에는 사용을 하기가 좀 어렵습니다.
그래서 뭐 하여튼 그런 게 있고요.
그래갖고 어쨌든 어떤 시스템이 내가 정의한 프로포티들을 항상 만족되는지를
확인을 하는 거를 이제 모델 체킹이라고 보통 이야기를 합니다.
그 다음에는 이제 이키밸런스 체킹이라는 게 있어요.
이거는 이 모델 체킹의 한 가지 일종인데
두 개의 모델이 동일한지를 확인을 하는 그런 모델 체킹입니다.
그러니까 이게 제일 보통 많이 쓰는 것들은 이런 데 많이 써요.
그러니까 우리가 이제 RTL 설계가 끝나고 나면은 백엔드 툴들을 돌리면서
합성하고 레이아웃하고 뭐 이런 과정을 거치잖아요.
그러니까 이런 쭉 과정을 거칠 때마다 이게 RTL 설계랑 동일한지
이런 것들을 계속 확인을 합니다.
이거는 거꾸로 말하면은 이 툴들을 못 믿겠다는 얘기이기도 해요.
그러니까 이 툴들에 혹시나 버그가 있거나 이렇게 문제가 있어 갖고
얘가 내가 설계한 대로 혹시나 구현이 안 되고 뭔가 이렇게 조금 달라진 게 있는지를
확인하기 위해서 뭐 이런 이키밸런스 체킹을 쓰기도 합니다.
그런데 이런 데 쓰기도 하지만 이거를 또 언제 쓰냐면은
그 RTL을 설계를 해놓고 만약에 이 RTL을 설계를 하기 위한
일종의 골든 수학적 모델이 있다면 이 골든 모델과 똑같은지를 확인하는 데도 쓸 수가 있습니다.
그러니까 이런 경우에는 어떤 경우가 있냐면은
이것도 제가 옛날에 삼성에 있을 때 아까 베이스밴드 모델 칩을 만들었다고 말씀드렸잖아요.
그러면은 이 베이스밴드 모델 칩을 그 RTL 설계를 하기 전에
알고리즘 설계를 먼저 해요.
그래서 이 알고리즘은 그러니까 예를 들면은 뭐 CDMA이다.
그러면은 그 CDMA 그 전파를 처리하기 위한 알고리즘이 있잖아요.
그래서 그 알고리즘을 먼저 설계를 하고
그 알고리즘을 C 같은 걸로 검증을 합니다.
그러면은 이게 말하자면은 골든 모델이 되는 거예요.
그래서 이거를 그대로 RTL로 구현을 한 게 하드웨어가 되는 거고요.
그렇게 되면은 이 RTL과 이 C 코드랑 동일한지를 확인을 해볼 필요가 있죠.
그래서 이거를 보통은 저희는 이제 RTL에서 시뮬레이션 벡터를 뽑아갖고
시뮬레이션을 통해갖고 RTL에서 나오는 결과랑
이 C 모델에서 나오는 결과가 동일한지를 확인하는 방식을 썼었어요.
이거 같은 경우에는 그러니까 기본적으로 시뮬레이션을 이용한 검증 방법인데
이렇게 할 수도 있지만 이런 포멀 메토드로지
이키밸런스 체크 같은 거를 사용을 한다면
그 C에서 나오는 그 C 코드와 RTL 코드가 완전히 동일한지를
어떤 수학적 모델을 통해갖고 검증할 수가 있다는 거예요.
그래서 이런 것들을 이제 이키밸런스 체킹에 활용을 할 수도 있습니다.
근데 어쨌든 포멀 베리피케이션이 철저하게 검증한다는 면에서는
굉장히 좋지만 아까 말씀드린 스테이 스페이스 익스플로전 프로블럼이 있어요.
그래서 이거를 실질적으로 하기에는 큰 시스템, 복잡한 칩에는
이거를 적용하기가 어렵고 정말 정말 크리티컬한 그런 기능을 검증하는데
주로 사용을 하게 됩니다.
그래서 저희가 뭐 이런 것들을 쭉 여러 가지 테크놀로지를 했는데
뭐 간단하게 그냥 비교를 한 테이블이고요.
자 지금부터는 이 포멀 베리피케이션 중에서도
그 Theorem Proving에 대해서 핵심적인 개념만 간단하게 소개를 시켜드리고
오전 세션을 마무리를 하도록 하겠습니다.
제가 이거를 하는 이유는 뭐냐면요.
여러분들이 뭐 여러분들 중에 나중에 RTL 설계 같은 데 관심이 있으시니까
아마 이 수업을 들으실 거라고 생각을 하는데
대부분의 경우에는 뭐 U부인 같은 걸 써서 시뮬레이션을 통해서 검증하고
아마 대부분 다 그런 걸로 검증을 하실 거예요.
검증을 하시긴 하겠지만 아까 말씀드린 대로 이게 정말 미션 크리티컬한 시스템이 있을 때는
이거를 수학적으로 조금 더 철저하게 검증해야 되는 필요가 있을 수가 있어요.
그래서 이게 근데 이거를 자동화된 툴이 아니라
사람이 이제 머리로 검증을 해야 되는 필요가 있을 때가 있는데
있을 수가 있는데 그럴 때는 여러분들이 이거를 어떻게 하면 되는지에 대해서
개념적으로라도 아이디어라도 알아 놓으시면
혹시나 여러분들이 나중에 검증을 할 때
Theorem Proving을 통해서 검증을 할 일이 있으면
이 방법이 기억이 나면 이거를 적용해 보면
그거를 미션 크리티컬한 시스템들을 검증하는 데 도움이 될 수도 있을 것 같아서
이 미션 크리티컬한 시스템을 검증하는 Theorem Proving
이거는 사람이 하는 거예요.
이거는 기계가 자동으로 해주는 게 아니라
그래서 그거에 대해서 아주 간략하게 개념적인 부분만
뭐 좀 설명을 드리도록 하겠습니다.
그래서 몇 가지 이제 중요한 컨셉들을 정의를 해야 되는데
일단 Requirement라고 하는 게 나와요.
그래서 이 Requirement는 이게 결국은 이 시스템이
내가 설계한 이 예를 들면 회로가
어떻게 동작해야 되는지를 정의한 거라고 보시면 돼요.
그러니까 이게 말로 정의가 된 걸 수도 있고
아니면은 뭔가 여기서 보시면 이렇게
인포멀하게 그냥 말로 설명한 거야 말로
아니면은 뭔가 포멀한 방법으로
이게 정의가 되어 있을 수도 있고요.
그래서 어쨌든 이 Requirement가 제일 처음에 식별이 돼야 됩니다.
왜냐하면 내가 이 회로를 검증을 한다는 말의 의미는
이 회로가 저 Requirement대로 동작하는지를 확인을 하겠다는 게
결국은 이 Theorem Proving의 목적이기 때문에
이 Requirement가 명확하지 않으면 내가 뭘 검증해야 되는지 조차 알 수가 없는 상황이 생기잖아요.
그러니까 먼저 해야 되는 일을 이 Requirement가 뭔지를 이제 확인을 해야 되는 거죠.
그 다음에 이거를 실제로 구현한 게 시스템이에요.
말하자면은 시스템이라는 용어를 씁시다. 회로라기보다는.
그래서 우리가 여기서 할 거는 뭐냐면은
어떤 Requirement 파이라고 하는 게 주어지고
어떤 시스템에 대한 수학적인 모델 C가 주어졌을 때
이 시스템 C가 Requirement 파이를 만족하는지를 증명을 하거나
만족하지 않는지를 증명을 하거나
둘 중에 한 가지에 대해서 결론을 내리는 게 우리가 해야 되는 일입니다.
그래서 우리한테는 두 가지가 필요해요. 입력으로
Requirement 파이랑 시스템 모델 C가 필요해요.
이거는 어떻게 보면 주어지는 거고
이거 두 개가 주어지면 우리가 하려고 하는 거는
그래서 C가 파이를 만족하느냐를 증명을 하던가
만족하지 않는다는 거를 증명을 하던가
물론 만족하지 않는다는 거를 증명하는 거는 그냥
뭐 발레만 들어주면 되니까 간단한 거고
이게 항상 만족한다는 거를 증명하는 게 어려운 일이 되겠죠.
그래서 그거를 어떻게 할 거냐.
이거를 이제 알아보겠다는 겁니다.
그러면은 여기서 우리가 시스템 C
C라고 하는 시스템을 모델이 필요하다고 했는데
그 모델을 어떻게 모델링을 할 거냐인데
여기서는 이제 트랜지션 시스템이라는 컨셉으로 모델링을 합니다.
이게 사실 우리가 알고 있는 웬만한 하드웨어
또는 소프트웨어는 다 기본적으로 트랜지션 시스템이라고 보면 돼요.
이 트랜지션 시스템은 어떤 스테잇을 가지고 있어요.
그래서 이 스테잇이 아끼는 거를 트랜지션이라고 하고요.
그래서 어떤 시스템이 동작하는 거는 결국은
이 스테잇이 계속해서 트랜지션이 일어나가지고
아끼는 거를 이 시스템이라고 볼 수가 있어요.
이게 기본적으로 여러분들이 들어보셨으면 아실
그 트위링 머신이 결국은 이거예요.
트위링 머신이 이렇게 테이프가 있고
이 테이프가 결국은 스테잇이고
얘네들을 계속 이렇게 변경해가면서 이렇게 동작을 하잖아요.
그러니까 우리가 알고 있는 디지털 시스템은 결국은 다 트위링 머신이고
트위링 머신은 이 트랜지션 시스템이라고 얘기를 할 수가 있어요.
그러면 이 트랜지션 시스템은 이렇게 세 가지의 일종의 집합이 있으면
모델링을 할 수가 있습니다.
먼저 그 스테잇의 집합이 있어요.
이 시스템이 가질 수 있는 스테잇이 뭐가 있느냐
그래서 그것들을 하나의 집합으로 모아놓은 게 있을 수가 있고
그 다음에 이 중에서 이니셜 스테잇이 뭐냐
이니셜 스테잇도 스테잇이 하나만 있는 게 아니라
뭐 시스템에 따라 갖고는 여러 개의 스테잇이 이니셜 스테잇일 수가 있어요.
그래서 이것도 집합으로 표현을 할 수 있고요.
그 다음에 트랜지션 셋이 있어요.
이거는 어떤 스테잇에서 어떤 입력이 들어오면은
어떤 스테잇으로 변경이 되느냐를 집합으로 다 모아놓은 거
그게 트랜지션 셋이에요.
그래서 이 세 가지가 있으면은 어떤 시스템이든지 간에
트랜지션 시스템으로 우리가 모델링을 할 수가 있습니다.
뭐 예를 들면 뭐 이런 게 있을 수가 있어요.
스위치 트랜지션 시스템이라는 게 있다고 생각을 해봅시다.
그래서 어떤 스위치가 있어요.
그러면은 우리가 이 스위치를 이제 오프 상태가 되면 잠겨 있는 거예요.
잠겨 있는데 여기에 버튼이 하나 있어갖고
그 버튼을 누르면 온 상태가 돼가지고 얘가 열려요.
열리는데 여기서 얘가 10초를 기다렸는데도
그 버튼이 더 눌리지 않으면은 자동으로 잠겨요.
아니면은 버튼을 한 번 더 누르면은 잠기든가.
그래서 그런 시스템을 우리가 이렇게
스위치 트랜지션 시스템으로 모델링을 한 겁니다.
그래서 여기서는 스테잇이 오프냐 온이냐
이거 두 개가 스테잇이기도 하지만
여기에 한 가지 더 변수가 있어갖고
얘는 이 온 상태에서 몇 초 동안 얘가
버튼이 눌리지 않았는지를
카운트를 하고 있는 카운터가 있어요.
그래서 이 카운터도 스테잇의 일부인 거죠.
그래서 여기는 스테잇이라고 하는 게
오프냐 온이냐를 저장하는 모드
그러니까 얘가 오프냐 온이냐
얘는 뭐 일종의 불리한 변수가 되겠죠.
그런 모드라고 하는 스테잇 변수가 하나 있고
그 다음에 어떤 인티저 엑스 얘는 카운터예요.
그래갖고 얘는 온 상태에 있을 때
얘가 몇 초 동안이나 눌리지 않았는지를
카운트를 하는 카운터 변수.
그래서 이거 두 개의 조합이
이 시스템의 스테잇을 표현을 하는 거라고 볼 수가 있겠고요.
그러면 여기서 이니셜 스테잇은 뭐냐
이니셜 스테잇은 이 모드는 오프고
엑스는 0인 게 이니셜 스테잇이에요.
그 다음에 트랜지션은 여기 그래프에 보이는 것처럼
오프인데 오프 상태에 있을 때
프레스 어떤 버튼이 눌리게 되면
온으로 가는 그런 스테잇이 트랜지션이 있고요.
아니면 오프 상태에 있을 때
아무 버튼이 안 눌리면
그냥 오프 상태에 계속 있겠죠.
그래서 그것도 트랜지션이에요.
그 다음에 이거 같은 경우에는
이제 어떤 온이라고 하는 스테잇에 있는데
버튼이 안 눌리게 되면
그 카운터가 하나 증가를 하겠죠.
그래서 증가를 하게 되는 고 트랜지션이 있고
그 다음에 여기서 온이라고 하는 스테잇에 있다가
버튼이 눌리거나
버튼이 눌리거나
아니면 이 카운터의 값이
10 이상이 되면
이쪽으로 오프로 가거나
뭐 이런 트랜지션이 있습니다.
그래서 이 트랜지션의 집합은
이렇게 될 수 있다.
이렇게 볼 수가 있어요.
그래서 여기서 보시면은
이게 스위치 트랜지션 시스템은
이렇게 세 개의 집합으로
모델링을 한 겁니다.
그래서 이렇게 간단한 시스템이긴 하지만
좀 복잡한 시스템도
좀 복잡하기는 하겠지만
어쨌든 간에 이렇게 세 개의 집합으로
다 모델링을 할 수가 있습니다.
그리고 여기 밑에 보이는 거는 뭐냐면은
이 트랜지션 시스템이 있을 때
이 트랜지션 시스템이 실제로 동작하는
몇 가지 사례들이 있는 거라고 볼 수가 있어요.
그런데 여기서 보시면은
이렇게 동그라밀 쳐놓은 게
이니셜 스테잇이고
여기서 들어오는 입력에 따라서
이렇게 스테잇이 변경되는 걸
이렇게 화살표로 표현을 해놓은 겁니다.
그런데 여기서 보시면은
여기서 제가 하고 싶은 얘기는 뭐냐면은
여기서 예를 들어갖고
온 상태인데 카운터가 2예요.
그러면은 얘가 버튼이 눌리면은
오프 상태로 갈 수가 있겠고
버튼이 안 눌리면은
이쪽으로 갈 수가 있겠죠.
그런데 온인데 카운터가 17이에요.
이 경우는 정상적인 상황에서는
이런 스테잇으로 도달할 일은 없겠죠.
왜냐하면은 온인 상태인데
이 카운터가 10 이상이 되면은
오프로 가야 돼.
그런데 온이면서
X가 17인 경우에는
이 스테잇은 절대로 도달할 수 없는 스테잇이에요.
도달하면 안 되는 스테잇이고
그런데 어쨌든 간에
이런 스테잇 베리어블을
인티저로 만약에 내가 선언을 해놓게 되면은
이런 스테잇이 가능은 하겠죠.
가능은.
가능은 하지만 정상적인 상황에서는
도달할 일이 없는 그런 스테잇입니다.
그래서 이거를 이제 구분을 하는 게
리처블 스테잇이라고 하는 개념을
얘기해서 정의를 하는 거예요.
그래서 내가 이니셜 스테잇으로부터
정상적인 트랜지션을 통해서
도달할 수 있는 모든 스테잇의 집합을
리처블 스테잇이라고 얘기를 합니다.
아까 말씀드린 온인데
X가 17인
이 스테잇은 리처블 스테잇은 아니에요.
물론 이 트랜지션 시스템의
가능한 스테잇 중에 하나이기는 한데
가능은 하지만 리처블한 것은 아닌 거죠.
그래서 리처블 스테잇이라고 하는 걸로
이런 식으로 정의를 합니다.
이 리처블 스테잇을 왜 정의를 했는지를
여러분들이 이제
눈치가 빠르신 분들은
확인하실 수가 있을 거예요.
왜냐하면 우리가 이 시스템이
항상 리퀘이먼트를 만족하는지
여부를 확인을 하겠다고 했어요.
그런데 여기서 말하는
항상이라고 하는 것은
엄밀하게 말하면
모든 리처블 스테잇에서
이 리퀘이먼트가
만족하는지 여부를
확인하면 된다는 거예요.
그러니까 여기서 말하는
항상이라고 하는 것을
엄밀하게 정의를 하기 위해서
이 리처블 스테잇이라고 하는 개념을
지금 정의를 한 겁니다.
그러니까 항상 만족되느냐라는 말의 의미는
모든 리처블 스테잇에서
만족하느냐라는 말의 의미다라고
이해를 하시면 될 것 같습니다.
그래서 이거는 그냥
그거를 지금 설명을 드린 거고요.
그다음에 여기서 말하는
인베리언츠라고 하는 개념이 있어요.
그래서 방금 제가 말씀드린 것처럼
어떤 리처블 스테잇에서
어떤 프로퍼티가 있는데
이런 프로퍼티를 우리가 정의를 했잖아요.
이게 리퀘이먼트라고 말씀을 드렸는데
어떤 리퀘이먼트가 있을 때
그거를 이제 수학적으로 표현을 한 거를
프로퍼티라고 얘기를 하는 겁니다.
그러니까 리퀘이먼트는 어떤
뭐 그냥 말로 설명한 걸 수도 있다고 했잖아요.
그러니까 그 말로 설명한 걸로는
우리가 수학적으로 증명을 할 수가 없기 때문에
말로 설명해 놓은 거를
수학적으로 표현을 한 거를
프로퍼티라고 얘기를 하는 거고요.
그래서 그 프로퍼티가
모든 리처블 스테잇에서
변하지 않는 거예요.
다시 말하면 얘가
항상 만족된다고 볼 수가 있는 거죠.
그래서 이거를
그 어떤 프로퍼티가 있을 때
걔가
이 모든 리처블 스테잇에서
항상 변하지 않는다면
우리가 그거를
인베리언트다
라고 정의를 합니다.
그래서 이제
이런 개념들을 가지고
정의를 해놓고 보면
우리가 아까 처음에 얘기했던
어떤 시스템 C가
리퀘이먼트 파일을
항상 만족하느냐를
우리가 증명을 하는 게
이 지금
Theore Improving의 목적이라고
말씀드렸는데
방금 저희가 쭉
정의를 한 단어들로
그거를 다시 표현을 하면
어떤 트랜지션 시스템 C가 있을 때
그 C의 모든 리처블 스테잇에서
주어진 프로퍼티가
인베리언트냐를
증명을 하는 거가
우리가 지금부터 할 거의
목적이라고
그렇게 다시 정의를 할 수가 있습니다.
그래서 그거를 지금부터 할 건데
시간이 딱 40분인 관계로
여기서 잠깐 멈추고
이 뒷부분은 점심 식사 후에
1시에 다시 진행을 하도록 하겠습니다.
혹시 그래도
지금까지 한 거에 대해서
질문이 있으신 분 있으세요?
어쨌든 질문 있으시면
시간이 됐으니까
이따가 점심 식사 이후에
질문하셔도 되니까
그때 질문을 해주시고
줌으로 들어오신 분들도
혹시 질문 있으시면
남겨주세요.
그러면 제가 나중에
식사 마치고 1시에
다시 시작할 때
그때 답변을 드리도록 하겠습니다.
그러면 잠깐 쉬고
1시부터 다시 시작하도록 하겠습니다.
혹시 질문 있으신 분 있으세요?
없으시면 일단 진행하도록 하겠고요.
마찬가지로
마찬가지로
오후 세션도
쭉 진행해서
1시니까
2시 40분에
마치도록 하겠습니다.
그래서 지금까지 했던 얘기를
간단하게 요약을 다시 하자면
간단하게 요약을 하면
우리가 지금
Theorem Proving을 지금 하고 있는 거예요.
그래서
Theorem Proving을 하는 거는
목표가
목표가
이제
어떤 프로퍼티가 주어졌을 때
어떤 시스템 C가
그 프로퍼티 파일을
항상 만족하는지
여부를
증명하는 거라고
말씀을 드렸는데
요거를 조금 더
포멀하게 정의를 하면
어떤 트랜지시션 C가
주어졌을 때
그 트랜지시션 시스템 C의
모든 리처블 스테이트에서
Requirement 파이가
인베리언트인지를
그 증명하는 거
그게 이제
저희가 지금부터
하려고 하는 것의
목표입니다.
그래서
인베리언트까지
설명을 드렸고요.
그러니까
아까 말씀드린 것처럼
어떤 모델이 주어졌어요.
C
트랜지시션 시스템이에요.
그 다음에 어떤
Requirement가 주어졌어요.
Requirement 파이인데
여기서 말하는
Requirement는
말로 설명하는
Requirement가 아니라
그 말로 설명한
Requirement를
어떤 수학적인
수식으로 표현한 거를
얘기를 하는 거죠.
그래서 그거 두 개를
입력으로 받아서
지금 우리가
뭔가를 하는
베리파이어가
뭔가를 하고 나면
결과적으로
이게 맞다.
그러니까 항상
만족한다라고 하는
거에 대한
프루프가 나오던가
아니면 어떤
발레가 나와갖고
이거는 만족하지 않는
경우가 있으니
인베리언트가 아니다.
이거를 이제
저희가
판단을 하려고 하는 겁니다.
그래서 이거를
하려고 하는 방법 중에는
생각해보면
다이나믹 어나리시스
같은 경우에는
일종의
시뮬레이션 기반의
방법이에요.
그러니까
이거를 우리가
사람이 굳이
이렇게
Theorem 프로빙 같은 걸
하지 않고
그냥 시뮬레이션
돌려보는 거예요.
그래갖고
이거 같은 경우에는
Assertion Based
Verification이
이 방법입니다.
그러니까
Property라고 하는 거를
Assertion 형태로
표현을 한 다음에
그러면
Rechable State는
어떻게 정의를 하냐면
결국은 그냥
시뮬레이션
테스트
시나리오가
Rechable State이
되는 거죠.
그런데
이게
모든
Rechable State이냐
그건
보장이 안 되는 겁니다.
그건
보장이 안 되지만
어쨌든
시뮬레이션 시나리오에
포함되어 있는
Rechable State에
한해서는
Assertion이 들어가 있으니까
모든 Assertion을
만족한다
라고 하는 거는
확인을 할 수가 있다는 겁니다.
그래서 이거를
시뮬레이션을 통해서
확인을 할 수가 있어요.
그러니까 어떻게 보면 우리가
이 Assertion에 관련해가지고는
저희가 지금
오늘 내일 모레
이 강의에서는
간단하게만
알아보겠지만
어쨌든 그런
Assertion이라고 하는 것에 대한
일종의
이론적인 배경이라고
말씀드릴 수가 있겠고요.
그런데 지금부터
저희가 하려고 하는 거는
Static Analysis예요.
그러니까 이거는
자동화가 좀 어렵고
사람이
Proving을 해주는 거예요.
그럴 때
이거를
어떻게 할 수 있느냐
그거를 지금부터
해보려고 하는 거고요.
그러니까 Proof Based
이거라고 보시면 되겠고
모델 체킹도 있기는 해요.
이거는
State Space Analysis인데
이거 같은 경우에는
뭐
이게
시뮬레이션 방식은 아니지만
이게
가능한
모든 경우의 수를
다
말하자면
확인해 보는 거예요.
그러니까
이거 같은 경우에는
시뮬레이션보다는
더 많은
시나리오를
확인해 볼 수 있겠죠.
얘는 그냥 말 그대로
전수조사를 하는 거니까
대신에
이거 같은 경우에는
복잡한 시스템을
쓸 수가 없어요.
너무
뭐
State이 많으면
그거를 쓸 수가 없겠죠.
그러니까
그거는 안 된다는 거고
그래서 저희가 하려고 하는 건
어쨌든 지금부터
이 Proof Based로
하려고 하는 겁니다.
자 그러면
그걸 어떻게 할 거냐
어떻게 할 거냐 하면
수학적 귀납법을
통해 갖고
이거를 할 거예요.
수학적 귀납법
뭐 고등학교 때
요즘 고등학교 교과 과정에
이게 포함되어 있나?
포함되어 있겠지?
어쨌든
배우셨을 테지만
수학적 귀납법은
간단하게 말하면
이니셜 스테이트에서
어떠한 특정한
프로포티가
만족된다는 거를
먼저 확인을 해요.
그 다음에는
K번째 스테이트에서
그 프로포티가
만족한다고
가정을 하고
K플러스 1번째
다음 스테이트에서도
만족한다는 거를
증명을 하면
그러면은
모든 스테이트에서
이 프로포티가
만족이 된다라고 하는 게
증명이 되는 거죠.
그래서 이게
수학적 귀납법입니다.
그래서 그거 두 가지를 하는 거예요.
그러니까
일단은
이니셜 스테이트에서
프로포티가
만족이 된다는 거를
먼저 확인을 합니다.
그 다음에
K번째 스테이트에서
그게 만족이 된다는 거를
가정을 하고
다음 스테이트
다음 스테이트은
이 스테이트에서
트랜지션이
하나만 있는 게 아니라
여러 개가 있을 수 있잖아요.
그러니까
트랜지션마다
다 트랜지션이
일어났을 때
그 다음 스테이트
될 수 있는 것들을
모두
확인을 해서
걔네들이
다 이 스테이트를
만족을 하면
이 리퀘어먼트를
만족하면
이제 이게
인베리언트다.
이렇게 얘기를 할 수가 있는 거죠.
그래서
이게 이제
우리가 지금부터
하려고 하는 겁니다.
그래서 예를 들어볼게요.
여기서 보시면
이 어떤
간단한
트랜지션 시스템이 있어요.
그래서 여기 같은 경우에는
스테이트
베리어물이
x예요.
x만 있어요.
그리고 이거는
0으로
이니셜라이즈가 돼요.
그렇다는 얘기는
얘가
이니셜 스테이트은
0인 거죠.
그 다음에
트랜지션은
요게
요거
요거 한 가지
조건밖에 없어요.
그래서
x가
n보다 작으면
x가 더하기 1이 돼요.
그러면은
x가 0보다 작지 않으면
어떻게 되느냐.
그러면은
x값이 그냥 변하지 않고
그대로 유지가 되겠죠.
그래서 이렇게
굉장히 간단한
이 스테이트
트랜지션 시스템입니다.
그러면은
우리가 여기서
프로포티로
확인하고 싶은 거는
뭐냐면은
x가 항상
0보다 크거나 같고
m보다 작거나 같으냐.
이 프로포티가
인베리언트냐.
라고 하는 거를
확인을 해보고 싶은 겁니다.
그래서 이걸 하려면은
수학적 귀납법에 의해서
처음에 해야 될 거는
이니셜 스테이트에서
이거를 만족하는지를
먼저 확인을 해야 되겠죠.
그러면은
이니셜 스테이트라는 얘기는
x가 0일 때니까
x가 0일 때
이 프로포티를
만족하느냐.
만족하죠.
x가 0이면
0보다 크거나 같고
m보다 작거나 같으니까
m은 뭐
양수라고 생각을 하면
그래서
일단은
이니셜 스테이트는
만족한다는 게
확인이 됐습니다.
자, 그러면은
자, 그러면은
k번째 스테이트에서
이게 만족한다고
이게 만족한다고
가정을 해보겠습니다.
그러면은
어떤 k번째 스테이트에 있을 때의
x의 값을
예를 들어갖고
a라고 얘기를 해볼게요.
그러면은
이 a라는 값은
항상
0보다 크거나 같고
m보다는
작거나 같습니다.
그랬을 때
다음 스테이트
k 플러스 1번 스테이트은
뭐가 될 수 있을까?
두 가지 케이스가 가능해요.
a가
m보다 작거나
같기 때문에
a가
m일 때랑
m보다 작을 때랑
이 두 가지에
대해서는
다른 스테이트로
트랜지션이 일어날 겁니다.
a가 만약에
m보다
작으면
이 조건을
만족하니까
x는
x 플러스 1이 되고
다시 말하면
현재의 x값이
a니까
a 플러스 1이 되겠죠.
그러면
다음 스테이트에서는
x값이
a 플러스 1이 될 텐데
그게
이거를 만족하느냐?
만족하죠.
왜냐하면은
방금 말씀드린 대로
a는
m보다 작다고
그랬어요.
m보다 작고
0보다
크거나 같으니까
거기에
더하기 1을 해도
m보다
작거나
작거나
같기는 하겠죠.
그러니까
이 조건을
여전히 만족합니다.
a가
m보다 작을 때는
그러면
a가
m이면
m이면
그러면은
다음 스테이트에서도
그냥
여전히
x가
그냥
a겠죠.
왜냐하면은
이 조건을
만족하지 않으니까
x값은 그대로
유지가 된다고
그랬어요.
그러니까
다음 스테이트에서는
그냥
x가
a예요.
그러면
그거를
이 프로포티를
만족하느냐?
만족하죠.
그렇기 때문에
이 경우에는
k번째
스테이트에서
이 프로포티를
만족한다고
가정을 했을 때
다음 스테이트도
이 프로포티를
여전히 만족한다.
라고 하는 거를
우리가 확인을 했습니다.
그러니까
이제는
수학적
귀납법에 의해서
이 프로포티는
모든
리처블 스테이트에 대해서
인베리언트다.
라고 우리가
결론을 내릴 수가 있습니다.
그래서 이런 방식을
이거는 워낙
지금 간단한
얘기 때문에
이렇게 간단하게
지금
증명을 할 수가 있었는데
사실은
이게
조금만
복잡해져도
그리 간단하지는
않습니다.
그렇지만
제가 이거를
설명을 드린 이유는
어쨌든
이런 아이디어가
이런 아이디어가
있다는 것
정도는
아시면
나중에 혹시
이게 이제
필요해지면
이런 것들을
적용해 볼 수 있는
그런 사례가
있을 수 있으니까
여러분들이 좀
기억을 하시면
이런 것들을
활용을 해보실 수 있을 것 같아서
말씀을 드린 거고요.
이거는
그냥 이거를
다이어그램
형태로
표현을 한 거고
이거는
이런 거를
이용을
한
하나의
사례인데
뭐
네
하여튼
이것도
설명을 드릴게요.
일단
이게
마지막
슬라이드
일 것
같은데
이게 뭐냐면
이게
그냥
수학적
귀납법을
적용한
또 하나의
사례인 거예요.
사례인 건데
이거는 뭐냐면
어떤
예를 들면
유치원에서
애들이
진흙
뭐야
진흙탕에서
지금 놀고 있어요.
예를 들면
갯벌
이런 데라고 합시다.
이런 데서 놀고 있는데
애들이 놀다 보면
진흙이 여기저기
못할 거 아니에요.
그런데
자기 이마에
진흙이 묻을 수가
있잖아.
그러면
자기 이마에
진흙이 묻으면
나는 내 이마에
진흙이 묻은지를
모르지만
남의
이마에는
진흙이 묻었는지는
볼 수가 있잖아.
그래서
여기서의
가정은
이거를
내가
만져가지고는
확인을 할 수가
없다고
가정을 하고
눈으로만
확인할 수 있는데
만약에
여기서
애들한테
선생님이
물어보는 거예요.
네 이마에
본인 이마에
진흙이 묻어있다고
생각하는 사람이
있으면 손 들어봐.
남이 있는 거는
보여.
그렇지만
내 이마는
안 보여.
그렇지만
내 이마에
진흙이 묻어있다고
네 스스로 생각할 때
그게 확실하다고
생각하면 손 들어.
라고 질문을 하는데
선생님이
N번
물어봤을 때
만약에
그 애들 중에서
N명의
애들한테
이마에 진흙이
묻어있으면
정확하게
선생님이
N번째
질문을 하면
그
이마에
진흙이 묻은
N명의 애들이
다
그 순간에
손을 든다.
라는 거를
증명을 하는 거예요.
무슨 말인지
되게 어렵죠.
자
그럼 이거를
그냥 쉽게 생각하면
이렇게 증명을 할 수 있어요.
쉽게는 아니지만
어쨌든 이걸 차근차근
생각해보면
이런 의미예요.
먼저
가정을 할 때
애들이
아무도
이마에
그
그 뭐야
진흙이 묻은 애가 없어.
그러면은
선생님이
이마에
진흙이 묻었다고
생각하는 사람
손 들어가면은
뭐 일단은
확실하지 않으니까
아무도 손을 안 들어요.
그런데
만약에
그거는 뭐
두 번부터
세 번부터는
다 똑같아.
근데 만약에
딱 한 명
딱 한 명이
이마에
진흙이 묻었어.
진흙이 묻었는데
선생님이 물어보는 거예요.
그러니까
그
그렇죠?
그러니까
선생님이 물어보는 거예요.
그
잠깐만
잠깐만
조금 헷갈리는데
아
이
이
이
가정이 중요한 거네.
그러니까 이게 있어야 돼.
뭐냐면은
선생님이 이 얘기를 해준 거야.
자
니들 중에
이마에
진흙이 묻은 애가 있어.
그러니까
근데 그게
너라고 생각하면 손 들어.
이거예요.
그러니까 아까
0명일 때는
이거는
가정이 성립하지 않은 거고
한 명이 있다고 생각해보시다.
한 명.
딱 한 명이
이마에 진흙이 묻었어.
그러면은
걔의
본인의 입장에서는
나 말고
나머지 애들은
지금
이마에 진흙이 묻은 애가
한 명도 없어.
근데 선생님이 뭐라고 했냐면은
니들 중에
이마에 진흙이 묻은 애가 있어.
그게 너라고 생각하면 손 들어.
라고 얘기를 했으니까
이마에 진흙이 묻은 애의 입장에서는
나 빼고 아무도 없는데
그러면은
나밖에 없잖아요.
그러니까 손을 들겠죠.
근데
나머지 애들의 입장에서는
나는
내 이마에 진흙이 있는지 없는지 모르겠는데
저기 한 명이 있는 애가 보이네.
그러면은
쟤가
이마에 진흙이 묻었으니까
선생님이 얘기하는
걔가 쟤겠네.
난지 아닌지는 나는 모르겠고
그러니까 손은 안 들겠지.
그러니까
처음에 딱 한 번 질문을 했을 때는
딱 한 명
이마에 진흙이 있는 애가 있으면
내만 손을 들다는 거예요.
자 그래서 이게
이니셜 스테이트예요.
이니셜 스테이트고
그러면은
두 번째
두 명이 있다고 생각을 해보셨다.
두 명이
두 명이 있으면은
처음에 선생님이 일단 질문을 해.
자
네 이마에
진흙이 묻었다고 생각하는 사람이 있으면
손 들어.
그러면은
만약에 내가
내 이마에 지금 진흙이 묻어있는 사람이에요.
그러면은
나는 내 이마에 진흙이 있는지 모르겠어.
근데
다른 애들을 쭉 보니까
한 명이 보여.
그러면은
똑같은 이유에 의해갖고
어 그러면은
선생님이 얘기하는
이마에 진흙이 묻은 애가
쟤인가 보다.
나는 모르겠고
그러니까 손을 안 들겠죠.
걔 입장에서도 마찬가지고
나머지 애들도 다 마찬가지고
그러니까
선생님이 처음에
야 니네 중에
이마에 진흙이 묻은 애가 있어.
그게 너라고 생각하는 사람은
손 들어.
하고 처음 딱 물으면은
아무도 손을 안 들 거예요.
근데
선생님이 한 번 더 물어.
니들 중에
이마에 진흙 묻은 애가 있다니까
손 들어 봐.
그러면 이제
두 번째 물어보면은
어떤 과정이 생기냐면은
내 이마에 진흙이 묻은 애
그러니까
이마에 진흙이 묻은 애
입장에서 봤을 때는
일단은
한 명이
이마에 진흙이 묻은 게
아니라는 거는
확실해.
왜냐하면
아까의 리듬에 따르면은
한 명이 있으면은
걔가 손을 들었어야 돼.
아까 내 눈에 보이는
제가 손을 들었어야 돼.
근데 제가 손을 안 들었어.
그러니까
한 명은 아니라는 얘기예요.
그러면은
최소 두 명이 있다는 얘기죠.
최소 두 명이 있는데
내 눈에 보이는 애는
한 명밖에 없어.
그러면 나머지 애는
나밖에 없네.
그러니까 손을 든다는 거예요.
제 입장에서도 마찬가지고.
나머지 애들의 입장에서는
다 지금 두 명씩 보여.
그러니까
아 선생님이 물어봤을 때
한 명은 아니고
최소 두 명인데
저기 두 명이 있으니까
나라는 보장은 없네.
하니까
손을 안 들겠고
그러니까 여기서는
내 이마에 진흙이 묻은
딱 두 명만
두 번째 질문할 때
손을 든다는 거죠.
이거를 조금 일반화시키면
K번째 선생님이 질문을 하면
여기서의 가정은
최소한 K명 이상의
그 이마에 진흙이 묻은 애들이
있다라는 게
여기서의 이제
기존에 있었던
그 가정이 되는 거고
그러니까 이 프로퍼티가
만족한다는 가정이 되는 거고
이때 이제
다음 질문을 했을 때
그러면은
K플러스 1명이 있으면은
그때
대답을 한다
라고 하는 거를
이렇게 일반화시켜가지고
증명을 할 수가 있다는 겁니다.
그래서 이게
하여튼 이것도 이제
뭐 그냥 사례 중에 하나로
제가 설명을 드린 거고요.
이런 식으로
이 수학적 귀납법을
사용을 해가지고
뭔가 이런 프로퍼티가
인베리언트인지
여부를
증명을 하는 데
활용을 할 수가 있어요.
그리고 이런 것들을 이제
우리가
설계를 하려고 하는
시스템에다가 적용을 하면
이 시스템에서
내가 원하는 프로퍼티가
항상 만족되는지
여부를
증명을 할 수가 있다는 거죠.
그래서
이게 이제
첫 번째
일반적인
검증 방법론에 대한
설명을 쭉 드린 거고요.
자 그럼 이제부터는
어
잠깐만요.
네 뭐 질문이
마우스 포인트가 원래 없나요?
여기 레이저 포인트가 있긴 한데
온라인상에서는
레이저 포인트는 안 보이시나?
네?
안 보여요.
아
그러면
어쨌든 그러면은
제가 여기
뭐 이 이후부터는
여기 앉아서 진행을 할게요.
앉아서
이게 마우스로
레이저 포인트가 나오니까
그렇게 진행을 하도록 하겠습니다.
그래서
이거는
이렇게
정리를
하겠고요.
그 다음에는
이제
이거는 지금부터 하려고 하는 거에 대한
뭐 간단한
그
뭐
인트로덕션이라고 볼 수가 있습니다.
이제부터는 이제 본격적으로
시스템 베릴로그를 이용을 해서
검증을 하는
문법에 대해 갖고
설명을 드리도록 하겠습니다.
근데 여기서는 이제
그
뭐 이거는 아까
뭐 보여드렸던
똑같은 내용이고요.
똑같은 내용이긴 한데
뭐냐면은
여기서 말하고 싶은 거는
이거예요.
그러니까
어
검증이라고 하는 거는
시뮬레이션만을
의미하는 거는 아니다.
보통은 이제
사람들이 흔히 생각할 때
제가 이미
이 앞에서
뭐 포멀
베리피케이션이라든가
뭐 이런 거를
이미 다 설명을 드렸기 때문에
사실은 이거는
어느 정도 설명이 된 거기는 하지만
어쨌든
시뮬레이션이나
테스팅을 통해 갖고는
알 수 있는 게
버그가 있다는 거는
알 수 있지만
없다는 게
증명되지는 않는다.
뭐 이런 얘기고요.
그러니까 이건 어떻게 보면은
그 포멀 베리피케이션이
필요하다는 거에 대한
얘기였고요.
하여튼 검증이 어렵다는
얘기를 하고 싶었던 거였고
그 다음에
이거는 이제
우리가 시뮬레이션을
해가지고
검증을 할 때 보면은
대부분의 경우에는
이제
테스트 벤치를 써가지고
다이렉티드 베리피케이션을
합니다.
그러니까 이거 같은 경우에는
어떤
그
설계자가
생각할 수 있는
그런
시나리오들로만
검증을
보통을 해요.
그래서
어떤
DUT가 있을 때
Search Space가
이렇게 3D로
이렇게 표현을 한다고
그러면
여기 빨간색으로
표현된 게
버그라고 하면
이런 식으로밖에는
그거를 찾을 수가
없게 되는 거죠.
그러다 보니까
시간이 지나가면서
찾을 수 있는
버그가
이렇게 천천히
증가를 하게 되는데
이거를 만약에
Constraint 랜덤을
쓰게 되면은
이거는
자동으로
랜덤한
테스트 입력을
생성을 해주는 거기 때문에
사람이 생각하지 못했던
굉장히 다양한
테스트
스나리오를
확인을 해볼 수가
있다는 겁니다.
그래서
이런 랜덤 테스트를
사용을 하게 되면은
초기에는 조금 더
시간이 걸릴 수는 있어요.
왜냐하면은
이 랜덤 테스트를
하기 위해서는
테스트 벤치도
말하자면은
일종의 프로그래밍이
필요해서
처음에 개발하는 데
시간이 더 들어가기는 하지만
일단 그게 끝나고 나면은
굉장히 빠른 속도로
여러 가지 케이스들을
테스트를 해볼 수가 있게 됩니다.
그래서 커버리지를
이렇게 다이어그램 형식으로
표현을 하면은
어떤 피처가 있고
버그가 있을 때
이
다이렉티드 테스트를 하게 되면은
이렇게
이렇게 이렇게
테스트를 해보는 거예요.
이렇게 네모로 친 게
말하자면 테스트
시나리오인 거예요.
이렇게 테스트를 해볼 수가 있는데
근데
이제
뭐
랜덤하게 되면은
이렇게
뭐
그
내가 잘 몰랐던
이런 에어리어까지
다 할 수도 있고
그 다음에
뭐 이런 식으로 이제
뭔가
테스트 케이스가
이렇게 랜덤하게 하다 보니까
이렇게 겹치는 영역도 생기고
뭐 그럴 수는 있습니다.
그 다음에는 이제
커버리지 같은 경우에는
이렇게 여러 개의 커버리지를 돌리다 보면
이게 시나리오가 좀 복잡해지면은
이게 랜덤한 거다 보니까
커버리지가 이제
처음에는 빠르게 올라가는데
이게 어느 정도 또
세츄레이션이 되면은
그 다음부터는 좀
천천히 올라가게 돼요.
왜냐하면은
뭐 예를 들어갖고
커버리지가 뭐
80, 90%
할까 90%가 된다고 그러면은
그
얘가 커버리지가 더 올라가려고 그러면은
아직까지 커버가 되지 않은
10% 남아있는 영역에
뭔가 랜덤한 입력이 생성이 돼야 되다 보니까
확률이 10분의 1로 줄어드는 거고
뭐 커버리지가 더 올라가가지고
95%가 됐다.
그러면은 여기에
그 커버리지가 올라가려면은
20분의 1의 확률로만
얘가 커버리지가 올라갈 거잖아요.
그러니까 뒤로 갈수록
커버리지가 올라가는 속도가
점점점점 느려지다 보니까
이제 여기서 조금 더
그 나아가면은
이게
다이렉티드 테스트랑
컨스트레인 랜덤이랑을
같이 쓰는 게
뒤쪽으로 가가지고는
효율적일 수 있습니다.
그러니까 처음에는
랜덤하게 쭉 테스트를 하다가
어느 정도 커버리지가 올라가면은
그 다음부터는 올라가는데
속도가 너무 오래 걸리니까
그때부터는 이제
다이렉티드 테스트로 전환을 해가지고
아직까지 테스트 못한
소수의 영역들에 대해서는
그냥 사람이 매뉴얼하게
그 테스트를 해주는 거죠.
뭐 그런 식으로 이렇게 섞어갖고
쓸 수도 있다는 얘기입니다.
그러면은 랜덤하이즈를 할 때
뭘 랜덤하게 할 수 있느냐
뭐 입력을 일단은
입력 데이터를 랜덤하시게 할 수 있는 게
제일 기본적으로 생각할 수 있는 거기는 하지만
이거 말고도
디바이스의 컨피규레이션을
랜덤하게 한다던가
이거는 어떨 때 쓰냐면은
어떤 블럭이 있는데
그 블럭을 내가 지금
뭐 예를 들면은
이 어떤 하나의 프로덕트에만 쓸 게 아니라
다양한 프로덕트에
뭐 재활용을 할 수도 있잖아요.
그러니까 그럴 때는
어떤 프로덕트에 얘가 쓰일지 모르니까
그런 것들을 이렇게
바꿔가면서 테스트를 해볼 수 있는 거죠.
그래서 뭐 그런 것도 할 수 있고
익셉션이나 딜레이, 에러
이런 것도 확인을 해볼 수가 있습니다.
랜덤하이즈를 할 수가 있어요.
그러니까 우리가 테스트를 할 때 꼭
정상적인 시나리오만 테스트를 하는 게 아니라
이게 비정상적인 상황에서도
얘가 정상적으로 그거를
익셉션 핸들링을 잘 하는지
이것도 확인을 해볼 필요가 있을 수 있잖아요.
그러니까 그런데도
이런 랜덤하이즈를 할 수가 있다는 거죠.
그 다음에 이거는 뭐 커버리지를 측정하는
그냥 결과를 보여주는 건데
이거는 툴마다 달라요.
저희가 지금 사용을 하려고 하는 거는
그냥 EDA 플레이그라운드에서 나오는 걸 쓰다 보니까
이런 식으로 뭐 GUI를 통해 갖고
커버리지가 나오지는 않고
그냥 텍스트 파일로
커버리지를 확인을 해볼 수가 있습니다.
어쨌든 이 화면은 GUI마다 다른데
어쨌든 이런 커버리지를 우리가
이게 측정을 해가지고
확인을 할 수가 있다는 겁니다.
그래서 일반적으로
다이렉티드 테스트를 쓸 때는
테스트벤치의 구조가 이렇게 생겼어요.
그래서 여기서 우리가 테스트를
그러니까 검증을 하고자 하는
어떤 설계가 있고
그 설계에다가
테스트벤치 쪽에서 입력을 넣어주고
그 설계로부터 나온 출력을
테스트벤치로 다시 입력을 받아갖고
테스트벤치에서
이게 정상적으로 수행된 결과인지를 판단하는
그런 구조를 갖고 있죠.
근데 이렇게 컨스트레인 랜덤을 쓰게 되면
테스트벤치 자체를
자동화를 해야 되기 때문에
그렇게 되면
이 테스트벤치를 만드는 게
사실 굉장히 시간과 노력이 많이 들어갑니다.
그래서 이거를
검증의 효율성
또는 검증의 생산성을 높이기 위한
일반적인 방법 중에 하나가
재활용을 최대한 많이 하는 거예요.
그래서 재활용성을 높이기 위한 방법들을
사람들이 이제 많이 이거를 사용을 하다 보니까
테스트벤치의 구조를
이런 식으로 쪼개놓으면
그러면은
이게 재활용성이 좋아지더라
해가지고
이런 그 구조로 테스트벤치를
이제 작성을 하는 거를
말하자면 일종의
베스트 노운 프랙틱스로
권장을 합니다.
그래서 이게 일종의
UVM에서 사용하는
그런 방법론이에요.
그러니까
이거를 이런 식으로 쪼개놓으면
이거를 쉽게 재활용할 수 있다는 거죠.
예를 들어갖고
이 DUT가
그
DMA라고 생각을 해볼게요.
그러면은
이 DMA는
이쪽에서
그 입력은
얘가
컨피규레이션을 해주는 거죠.
DMA한테 커맨드를 주는 거예요.
그래갖고
뭐 소스 어드레스는 어디서부터
데스티네이션 어디까지
뭐 몇 개의 데이터를 옮겨라
뭐 이런 식으로 커맨드를 주죠.
그러면은 이제 DMA가
이제 버스에 마스터 인터페이스를 써가지고
버스에 접근을 해가지고
메모리에 있는 데이터를 읽어서
다른 데다가 쓰겠죠.
그러면은
이 DMA가
실질적으로는
커맨드를 받기 위한
인터페이스가 있어요.
예를 들면 이게 APB라고 합시다.
그러면은
이 APB 프로토콜을
통해갖고
얘한테 입력을 줘야 될 거 아니에요.
그러니까 그 APB 프로토콜을
처리하는 부분이 말하자면
드라이버인 거예요.
그 다음에
이 에이전트는
이 제너레이터는
시나리오를 만들어주는 거예요.
그러니까 얘는
말하자면은
어떤 그 DMA가
뭐 0번
그러니까
0번 어드레스부터
그 100번 어드레스까지
있는 데이터를
1000번지에 딱 옮겨라
라고 하는 시나리오를
만들어주고
그러면은
이 에이전트는
뭘 해주냐면은
이 DUT도
이거를 세팅하기 위한
레지스터 맵이 있을 거 아니에요.
0번 레지스터에는
소울스 어드레스가 들어가고
4번 레지스터에는
데스티네이션 어드레스가 들어가고
이런 레지스터 맵이 있겠죠.
그러면은 그 레지스터 맵에
맞춰갖고
이 시나리오에서 만든
그 시나리오대로
레지스터에다가
라이트를 해주는 것까지를
이 에이전트가 담당을 하고
그러면은
이렇게 레지스터 맵에
맞춰갖고
어떤 데이터를
입력해주는 게 나오면
그거를 APB 프로토콜에
맞춰갖고
DUT에다가
이제 실제로
시그널 레벨로
전달을 해주는 거를
드라이버가 하는 겁니다.
그러니까 이런 식으로
이 시나리오를
제공하는 거를
이렇게
쪼개놓은 거예요.
이렇게 되면은
재활용성이 높아지는 이유는
만약에 내가
DMA가 지금은
APB를 통해갖고
입력을 받는데
이거를 내가
AXI 슬레이브 인터페이스로
바꿨어요.
그러면은
이거를
드라이버만
바꾸면 돼.
다른 거는
시나리오나
레지스터 맵
이런 거는
바뀐 게 없으니까
얘네들은
다 재활용할 수가 있고
드라이버만
APB에서
AXI 시그널로
바꾸는 걸로
그러니까
만들어주는 걸로
바꾸면 돼요.
그러니까
에이전트랑
제너레이터는
그대로 쓸 수 있는 거죠.
아니면은
DMA가 있는데
APB 인터페이스는
그대로 쓰는데
여기에 기능이
추가가 되면서
레지스터 맵이
바뀌었어.
그러면은
제너레이터랑
드라이버는
그냥 쓰면 되고
에이전트만
바꾸면 돼요.
그러니까
이런 식으로
이거를
쪼개놓으면
이게
그 부분적으로
필요한 부분만
교체를 해서
쓰면 되니까
재활용성이
높아지는 겁니다.
그래갖고
이게
어떻게 보면은
이게 재활용성을
높이는 거는
사실은 일반적인
방법이고요.
근데 이거를
테스트 벤치 쪽에서
보니까
테스트 벤치는
일반적으로
이런 구조를
가지면
여기서 말하는 건
일반적이라는 게
컨스트레인 랜덤
베리피케이션을
썼을 때
얘기기는 하지만
어쨌든
컨스트레인 랜덤
베리피케이션을
사용을 할 때는
이런 구조를
가지면
이게
가장
재활용성이
높다.
그렇게 볼 수가
있습니다.
그래서 이게
UVM에서
우리가 아까
제가
오전에 말씀드린
UVM 클래스
라이브러리가
딱
이런 식의
구조를 갖는
테스트 벤치를
말하자면은
템플릿으로
제공을 해요.
그러니까
UVM 클래스
라이브러리를
사용을 하면은
이 구조에
맞는
클래스들의
템플릿이
있어갖고
여기에
맞게 내가
예를 들어서
어떤 기능을
추가한다고
그러면은
에이전트 드라이버
이런 것들은
이미 다 있어요.
거기에
그러니까
그 맞는
템플릿에
들어가서
템플릿에
해당하는
클래스를
내가 원하는
대로 수정만
해주면은
테스트 벤치를
만들 수 있게
해줘요.
그래갖고
이 UVM 클래스
라이브러리를
쓰면은
이런 테스트
벤치를
만드는 거를
이렇게
딱
이 구조에
맞게
만들 수가
있습니다.
근데
그 UVM
클래스
라이브러리를
굳이
사용하지
않더라도
내가
그냥
스스로
드라이버
에이전트를
만들면
되는 거기 때문에
그 클래스
라이브러리를
굳이
사용하지
않아도
어쨌든
UVM은
할 수
있어요.
그리고
UVM에서는
제너레이터
에이전트
드라이버
다
나눠갖고
하면은
이게
재활용성도
좋아지고
다 좋다고
하는데
뭐 생각하기에
따라서는
이거를
굳이
이렇게
나눠놓지
않아도
어찌 됐든 간에
컨스트레인 랜덤을
써가지고
검증을 할 수
있거든요.
그러니까
그것도
이제
나는
그냥
이거
굳이
재활용할
생각 없고
그냥
내가 만든
IP
내가
그냥
검증하는
데만
쓸 거다
이러면
그냥
내가
원하는
내가
편한
대로만
테스트벤치를
만들어주면
되는 거니까
그거에
대해서는
필요에
따라서
이렇게
테스트벤치를
만들어주면
되는 겁니다.
그래서
어쨌든
이게
UVM에서
사용되는
클래스
라이브러리의
구조라고
이렇게 일단은
말씀드릴 수가
있겠고요.
여기까지가
시스템
베를로그에 대한
전반적인
소개였고
그 다음에는
이제
본격적으로
시스템
베를로그
문법에 대해서
설명을 드리도록
하겠습니다.
자
먼저 나오는 거는
이제
데이터 타입입니다.
여기
다시 말씀드리지만
여기서는
일단은
베를로그는
어느 정도
안다고
가정을 하고
베를로그에는
없는
추가적인
시스템
베를로그만의
그런 문법들에
대해서
주로 다루고
있어요.
물론
베를로그에
대해서도
간략하게
설명을 하긴
하겠지만
어쨌든
뭐
그런 거라고
보시면 돼요.
그래서
시스템
베를로그에서는
이제
full state
variable
이라고 하는 게
추가가 되었습니다.
그래서
하여튼 요거는
요약을 해놓은 거고
하여튼
그거는 제가
한 가지씩
자세하게 설명을
드릴게요.
먼저
two state
variable이라는 게
생겼는데
원래
베를로그는
four state
네 가지
state을 갖는
variable을 써요.
그러니까
0하고 1은
당연히
있는 건데
Z랑
X가
있습니다.
Z는
high impedance
고
X는
unknown
이에요.
그래서
항상
어떤
시그널이
있으면
그 시그널은
이
네 개
중에
하나의
값을
가질 수가
있어요.
그런데
이제
시스템
베를로그에서는
딱
두 개
0 아니면
1만
그
state으로
갖는
variable도
생겼습니다.
그러니까
예를 들면
이게
비트라고 하는
새로운
데이터
타입이 생긴 거예요.
이게
그
한
비트짜리
그
two state
variable인데
말하자면
이게
와이어
같은 거라고
보시면 돼요.
와이어는
한
비트짜리
그
four state
variable인 거죠.
그런데
시스템
베를로그에는
비트라고 하는
variable이 있는 거고
마찬가지로
이제
뭐
인티저
바이트
숏
인트
롱
인트
이런 애들이
전부
two state
variable
들인 겁니다.
그러니까
이게
뭐
사실은
그
이거는
주로
이런 거를
사용하는
목적은
시뮬레이션
속도를
높이고
시뮬레이터가
차지하는
메모리를
이렇게
공간을
줄이는
그런
주로
최적화의
목적으로
이거를
사용을 할 수가
있어요.
사용을 할 수가
있고
근데
여기서
한 가지
좀
조심해야 되는 게
이거예요.
만약에
four state
variable을
two state
variable에
assign을 한다고
할 때는
무슨 일이로
일어날까
예를 들면
어떤
와이어가
있는데
그 와이어는
0, 1, z, x 중에
하나의 값을
갖고 있을 수
있는데
이거를
비트에다가
assign을 해요.
그러면
이 와이어의 값이
0이나 1일 때는
상관이 없어요.
근데
z나 x였으면
그때는
이 비트로는
표현이 안 되는데
이렇게
assign을 하면
무슨 일이 일어날까
일단은
assign이 되기는 해요.
되는데
그냥 assign이 돼.
이게 무슨 말이냐면
z나 x가
0이나 1로
변환이 돼가지고
assign이 돼버려요.
근데 이게
별로 문제가
없을 수도 있지만
경우에 따라서는
이게 원하는
동작은
아닐 수가 있어요.
특히나
x 같은 경우에는
우리가
시뮬레이션을 할 때
얘는 반드시
확인을 해줘야 되는
것 중에 하나거든요.
그러니까
웨이브 폼을 딱
띄우면
제가 이제
베리로그 강의할 때
여기서는 베리로그
강의는 안 하지만
베리로그 강의할 때는
제가 항상 하는 말이
웨이브 폼을
띄웠는데
x가 보이면
그거는 무조건
해결을 해야 되는 거다.
x는 절대로
보이면 안 된다.
물론
리셋이 들어가기
전에는
x가 있을 수 있는데
리셋이 들어간
이후에도
계속 x가 보이면
그거는
무조건
해결을 해야 된다.
라고 얘기를 합니다.
그러니까
하는 게 보이는 게
얘가 지금
뭔가 문제가 있다는 걸
알려주는 거기 때문에
x가 없어져 버리면
문제가 있는데도
확인할 수가 없게 되는 거니까
이거는 그렇게
바람직한 상황은 아니거든요.
그러니까
이런 경우가 있을 수가 있어요.
그래서
이런 경우에 있어서는
이제
얘가
폴 스테이트인데
얘가
언노운 스테이트인지를
확인을 하고
퓨 스테이트 베리로그에다가
어사인을 해줘야 돼요.
그래서 그런 것들이
약간의
주의사항입니다.
제 개인적으로는
굳이
투 스테이트 베리어블을
쓸 정도로
큰 디자인에다가
시스템 베리로그를 적용해서
검증을 할 필요는 없다고 생각합니다.
개인적인 의견이에요.
개인적인 의견.
이건 거꾸로
다시 말씀드리면
투 스테이트 베리어블은
뭐
이런 이슈도 있고
또 베리로그랑 조금
헷갈리기도 하고
하기 때문에
뭐
굳이
안 써도 되는
그런 기능이라고
저는 개인적으로 생각을 해요.
근데 이런 거는
조금 이제 편리해진 게 있어요.
왜냐하면은
이
어레이를 선언을 할 때
베리로그 같은 경우에는
항상 이런 스타일로
선언을 해줬어요.
0에서부터
16
그러니까 16개의
엘리먼트를 갖는
어레이를 선언할 때는
베리로그 스타일로
항상 이렇게 선언을 했는데
이제는
C나 C플러스 같은
그 소프트웨어처럼
개수만
이렇게
지정을 해주면
동일한 의미로
어레이를 선언을 할 수가 있어요.
그래서 이거는 조금
편리해졌고
이게 뭐
1차원 어레이는
큰 차이가 없는데
4차원 어레이는
이게 이제 훨씬 편합니다.
그래서
뭐 이런 것들은
이제 시스템 베리로그에
추가된 기능이고요.
그 다음에
어레이를
선언을 하면서
동시에
이니셜라이즈 하는 것도
가능합니다.
여기서 이런
어퍼스트로피를 써가지고
이렇게
선언과 동시에
이니셜라이즈 하는 게
가능하고요.
그 다음에
이
4룹을 돌 때
4이치라고 하는 게
이제 또
추가가 됐어요.
근데 사실은 이거는
그
센서사이저블
섭셋은 아니에요.
그러니까
어차피 우리가
베리로그에서도
하드웨어를
합성하는
그런
합성하려고
하는 목적으로
하드웨어를
모델링을 할 때
4룹을 쓰진 않잖아요.
물론
뭐 쓰는 경우가
아예 없지는 않지만
그런데
이거는 주로
이제 테스트 벤치에
쓰이는 거예요.
마찬가지로
4이치도
이거는 테스트 벤치에
쓰는 그런
신텍스입니다.
의도는.
그래서
여기는 어쨌든 간에
이거는 테스트 벤치에
쓰려고 하는 거고
여기에서 보면은
4를 이렇게 하는 거에
비해갖고
조금 편해진 거는
4이치를 쓰게 되면
어떤 어레이가
있을 때
이 어레이에
처음부터
끝까지
모든 엘리먼트를
순차적으로
억세스를 해요.
그래서
4이치를
여기 보면은
4 같은 경우에는
인덱스 베리어블을
선언을 해주고
인덱스 베리어블을
초기화를 하고
그래서 그게
어디까지
터미네이션 조건을
명세를 해주고
각각의
아이테레이션 별로
뭘 해야 되는지를
다 프로그래머가
적어줘야 됐잖아요.
근데 이거를
요거 한 줄이면
끝납니다.
그래서
4이치 뒤에다가
어레이를 넣어주고
그 다음에
여기에
인덱스 베리어블을
그냥
이름만 이렇게
적어주면
요게 자동으로
생긴다고
보시면 돼요.
그러니까
0번부터
끝까지
1씩
증가하면서
이 엘리먼터를
하나씩
다 억세스를 해요.
그래서
요런
그 용도로
4이치를
쓸 수가 있습니다.
그래서
이거 같은 경우에는
그래도
좀 편리한
기능 중에 하나예요.
자 그래서
이거를 한번
이제 실습을
해볼 거예요.
그래서 이거는
아까 말씀드린
EDA 플라이그라운드에서
이거를
한번 직접
타이핑을 해가지고
해보시고요.
물론
이거를
카피앤페이스트를
하시면
금방 하실 수 있어요.
근데
제가
타이핑을
한번 해보시라고
권장을 드리는데
권장을 드리는 이유는
이거를
이제
타이핑을 하다 보면은
여러분들이
요런
구문에
대해 갖고
조금 더
잘
이해를
그러니까 익숙해지는
그런 측면도
있고
그 다음에
이게 그냥
말로만
설명 들었을 때는
그냥
뭐
그냥
그냥
그냥
그냥
별로 이렇게
신경 쓰지 않고
휙 지나가 버렸던
것들도
타이핑을
하다 보면은
그 말로
설명 들었을 때는
보이지 않던
디테일한 것들이
또 보여요.
그러니까
그런 것들을
여러분들이 한번
확인을 해보려면
타이핑을 한번
해보시는 게
어쨌든
제가 볼 때
도움이 됩니다.
그리고 이거 솔직히
몇 줄 안되는데
이거 타이핑하는데
뭐 한 2, 3분이면 해요.
그러니까
요걸 해보시고
그러면은
이거를
실습을
어떻게 하느냐
잠시만요.
EDA 플레이그라운드에
요렇게 들어가 보시면은
이거는 이제
그
요거를
로�인을 한 거예요.
그래서
아까 뭐
그
그 뭐야
회원 가입하라고
말씀을 드렸잖아요.
그러니까 회원 가입을 하시고
로�인을 하면은
이제 이 화면이 뜰 거고
그래서
요기 왼쪽에
요
그러니까 저희는 지금
시스템 베리 로그
요번 강의에서는
테스트 벤치만
만들 거예요.
그러니까
제가 지금
뭐
엑서사이즈라고 해가지고
말씀드린
이런 코드들은
전부
여기
테스트 벤치 쪽에다가만
작성을 해주시면 됩니다.
그러니까 요기
디자인 쪽은 그냥
아무것도 안 하셔도 돼요.
그래서 테스트 벤치 쪽에다가
이렇게 타이핑을 하시고
그 다음에
실제로 실행을 할 때는
왼쪽에 보시면은
딴 거는 뭐
특별히 바꾸실 거는 없고
요것만 바꾸시면 돼요.
요 툴을
지금 제가
뭐
제공해드리는
요 실습들은 전부
시납시스
VCS
요거를 기준으로
되어 있거든요.
이게 화면이 너무
작아가지고
네
그래서
그래서 말씀드린 대로
디자인 쪽은 안 해도 되고
테스트 벤치 쪽에다가만
앞으로
제가 드릴
엑서사이즈들은
전부
여기다가
타이핑을 하시면 되고요.
그 다음에
여기 왼쪽에 있는
여기서
요
그
툴만
시납시스
VCS로
선택을 하시고
그 다음에는
이 런 버튼을
눌르면
결과가 나올 거예요.
네
그래서
요게 나온 거를
확인을 해보시고
그래서 요 실습을 보시면은
실습이 지금
1번 실습하고
2번 실습이 있어요.
그래서 요거 두 가지를
한번
실행을 해보시고
그 다음에
제가 한 시간을
한 5분에서
10분 정도
드릴 테니까
각자 실행을 해보시고
실행 결과를 한번
확인해 보시죠.
그 다음에
요게 실행을 하시고
난 다음에는
제가
요 코드에 대해 갖고는
실험을 하고 난 다음에
설명을 드리도록
하겠습니다.
앞으로도 계속
수업은 이제
이런 식으로 진행될 거예요.
제가 수업 시간에
뭔가 설명을 하고
그 다음에
그 실습을
여러분들한테
제가 한 5분 내지
10분 정도
잠깐
실습 시간을 드리고
그래서 여러분들이
타이핑을 하고
실행도 시켜보고
뭐 여러분들이 원하면은
뭐 이것저것 한번
고쳐가면서
뭐 이것저것 한번
시도를 해보시고
그 다음에
그 실습이 끝나면은
제가 그 실습한
코드에 대해서
설명을 드리고
다음 진도 나가고
그 다음에 또
실습하고 이렇게
실습과
설명이 계속
왔다 갔다 왔다 갔다
하면서 반복을 할 거거든요.
그래서 이런 식으로
앞으로 진행이 될 거고요.
그러니까
뭐 쉬는 시간 없이
쭉 진행을 하기는 하지만
지금 뭐 실습할 때
필요하면
뭐 잠깐 화장실 갔다
오신다던가
아니면은 뭐
혹시나 저한테
뭐 질문 있으시면
와서 질문을 하신다던가
그런 시간으로
활용을 하시면 되겠습니다.
자 그러면
어쨌든
이번에는
첫 실습이니까
조금 더 시간을 드릴게요.
한 10분 정도
시간을 드릴 테니까
이거 한번
직접 타이핑을 해가지고
한번 실행을
시켜보시기 바랍니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
네.
뭐 잘 되고
있으신 거죠?
네.
무반응이
희반응이라고
아무 질문이 없으신 거 보니까
뭐 잘 되고 있다고 생각을 하겠습니다.
그래서 지금 실행을 해보신 두 개의
그 실습은
첫 번째 거는
첫 번째 거는
for each인데
이거는 아까 말씀드렸던 거고요.
근데 이 for each는 이렇게
그
뭐야
다중
다처원 배열에서도
동일하게 쓸 수가 있다.
이거를 이제
보여드린 거고요.
그래서 아까 실행 화면을
잠깐 보시면은
이 for each 해가지고
md라고 하는
그 멀티디멘전 array를
이렇게 두 개의
인덱스 variable로
이렇게만 해주면
얘가 알아서
이제
이 엘리먼트가
이제 여섯 개가 있는데
이 여섯 개를 전부
하나씩 돌아가면서
다 억세스를 해주는 거를
for loop을 돌면서
자동으로 해준다.
이게 그래서 좀
편리한 기능 중에 하나고요.
그 다음에는
이 operation을
이렇게
aggregate 형태의
operation이
가능해졌습니다.
그러니까
두 개의 이렇게
어레이가 있을 때
이거를
두 개의 어레이가
똑같냐
라고 하는
비교 연산자를 쓰게 되면은
이거는
요 각각의
어레이에 있는
각각의
엘리먼트들을
하나하나 다
비교해서 얘가
똑같은지
여부를
판단해주는
그런 operator입니다.
만약에
이거랑 똑같은 거를
소프트웨어
예를 들어갖고
c 같은 데서 했으면
사실은
c는 어레이의 이름이
포인터잖아요.
그러니까
요렇게 되면은
얘는 무조건
다르다고 나오기는 할 건데
어쨌든
그
베릴로그
시스템 베릴로그에서는
어레이의 이름을 가지고
비교하는
연산을 하게 되면
그
안에 들어 있는
각각의
엘리먼트들을
하나하나 다 비교해서
얘가
전부 똑같은지를
판단해주는
그런
그 오퍼레이터로
활용이 됩니다.
어사인하는 것도
가능해요.
그래서
어레이를 이런 식으로
통째로
어사인을 하는 게
가능하다는 거고요.
그래서 이게
편리한 기능이기는 한데
이게
어떻게 생각하면은
또 c나
이런 소프트웨어
랭기지에
익숙한 사람한테는
약간 좀 헷갈릴 수
있는
뭐 그런 기능이기도
합니다.
자 다음에는
이게
다이나믹 어레이도
지원을 합니다.
물론
다시 말씀드리지만
여기서 지금 저희가
설명드리고 있는 거는
테스트 벤치에 쓰는 거를
얘기를 하는 거예요.
다이나믹 어레이 같은 거를
하드웨어로
합성은 못하겠죠.
못하는데
테스트 벤치 쪽에서는
저희가
어차피 이거는
시뮬레이션만
할 거니까
여기서는 우리가
테스트 벤치 만들 때는
이런 것들을
충분히 활용을 할 수가 있습니다.
그래서
다이나믹 어레이 같은 경우에는
C나 C++처럼
런타임에
이 어레이의
엘리먼트의
개수를
바꿔볼 수 있는 거죠.
그래서 선언을 할 때는
이런 식으로 선언을 합니다.
그래서 이렇게
어레이니까
이 대괄호가
들어가기는 하지만
이 대괄호 안에
이 어레이의
엘리먼트의 개수가
몇 개다
라고 하는 거는
이제
없는 상태로
이거를 선언을
할 수가 있습니다.
그래서 이렇게 선언을
일단은 해놓고
여기서 이제 우리가
엘리먼트 5개짜리
어레이를 만들어야 되겠다.
그러면은
이런 new라고 하는
명령어
또는 뭐
오퍼레이터라고 할 수도 있고요.
이 오퍼레이터를
이용을 해가지고
이 어레이가
다섯 개짜리
엘리먼트를 갖는
어레이다.
라고 하는 거를
여기서 이렇게
런타임에
결정을 해 줄 수가 있습니다.
물론 이 new라고 하는
오퍼레이터의
뒤에 들어가는
이 숫자는
이거는 이제
상수가 아니라
변수도 가능합니다.
그 다음에
얘는 뭐 이렇게
for each 같은 거를
통해 갖고
하나씩 이렇게
억세스를 할 수도 있고요.
그 다음에 이렇게
통째로
어사인하는 것도
가능하고
그 다음에
각각의
엘리먼트 억세스 하는 것도
되고요.
그렇습니다.
그 다음에 또 한 가지는
이런 것도
가능해요.
여기서
카피를 할 수가 있어요.
카피.
그래서 새로운
어레이를
얼로케이션을 할 때
뒤에
이런 식으로
파라미터를
기존에 있는
어레이를
주게 되면
20개짜리
어레이를
새로 만들면서
기존에 있었던
5개짜리
어레이를
카피를 해 줍니다.
그러니까
결국은 이거를
카피를 하면서
20개짜리에다
카피를 하니까
결국은
5개짜리를
20개짜리로
늘리는 효과가 있죠.
이렇게 되는 것도 되고
그 다음에는 얘를
오버라이스를 해 주기도 해요.
이렇게
오버라이스를 하게 되면
얘를
기존에 그러면
5개짜리
여기 같은 경우는
이 순서대로 실행하면
20개짜리
어레이가 최종적으로
이 다이나믹 어레이라고 하는
이 변수에
지금 할당이 되어 있는데
이거를
100개짜리로
교체를 하게 되면
기존에 있었던
이 20개짜리는
그냥
없어지게 됩니다.
없어지게 되고요.
아니면
이게
시스템 베릴 로그는
가비지 컬렉션을 해요.
나중에 가서 설명을 드리긴 하겠는데
가비지 컬렉션을 하기 때문에
여기
20개짜리
이 어레이가
이제 더 이상
레퍼런스가 되는
그러니까 핸들이라고 하는데
시스템 베릴 로그에서는
이거를 레퍼런스 하는 핸들이
더 이상 없어지게 되면
가비지 컬렉터가 알아서
얘를 지워줍니다.
그래서 시스템 베릴 로그는
가비지 컬렉션이 돼요.
그렇기 때문에
굳이 이런 식으로
딜리트를 하지 않고
그냥 이런 식으로
오버라잇을 해버려도
시뮬레이터에서 알아서
사용하지 않는 어레이는
알아서
삭제를 해줍니다.
자 그러면은
그 다음에 또
두 개의
그 엑서사이즈가 있어요.
요것도
한번 실행을 해보시고
제가 또 실행을 하고 나면
그거에 대해서
설명을 드리도록 하겠습니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
여러분
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
이 실습에서 구현을 해보신 거는 Q랑 그 뒤에 보면은 어소시에이티브 어레이 이거 두 가지를 해보신 거죠.
그래서 채팅창에 보니까 질문하신 게 이 Q하고 달러 사인이 뭐냐라고 질문을 주셨는데 이거 안 그래도 설명을 드리려고 한 건데
이 달러라는 뜻의 뜻은 이게 이 Q라는 데이터 구조다.
이게 그냥 어레이가 아니라 얘가 만약에 달러가 없으면 얘는 그냥 어레이인데 달러가 없고 숫자가 없으면 얘는 그냥 다이나믹 어레이인 거죠.
방금 전에 설명드렸던.
근데 여기다 달러를 넣게 되면은 이거는 Q라는 뜻이고 그래서 이게 Q이기 때문에 여기서 있는 이제 인서트 딜리트 이런 함수들을 쓸 수 있는 거죠.
이거를 뒤에 거랑 비교해 보시면은 여기서는 지금 이 별표를 쓰고 있잖아요. 이 에스터리스크가 들어가니까 얘는 어소시에이티브 어레이다라는 뜻으로 이걸 쓴 겁니다.
그러니까 결국 이 앞에 있는 그러니까 이 지금 그 뭐야 이 어레이의 타입이 뭔지를 알려주는 그런 역할을 하는 게 이 달러랑 에스터리스크 별표가 그 역할을 한다고 보시면 되겠습니다.
그래서 여기 자이번째 엑서사이즈에서는 이 Q에 관련된 여러가지 함수들을 지원을 하는 거를 사용을 해보신 거예요.
이것도 전부 시스템 베를로그에서 빌트인으로 제공을 하는 겁니다.
그러니까 뭐 C++ 같은 데서 스탠다드 라이브러리들이 있잖아요.
그러니까 그런 거랑 뭐 유사하다고 보시면 돼요.
그래서 여기서 보시면은 뭐 인서트 딜리트 뭐 푸시 프론트 푸시 백 뭐 이런 것들을 지금 지원을 하는 거를 지금 보고 계시죠.
그래서 여기서는 뭐 이런 것들에 대한 의미는 뭔지는 뭐 제가 굳이 설명을 안 드려도 옆에 있는 커멘트를 보시고 실행을 시켜보셨으니까
대충 무슨 뜻인지는 아마 쉽게 파악을 하실 수 있을 것 같아요.
여기 이름도 보고.
그래서 이게 Q라고 하는 이름으로 되어 있기는 한데 실질적으로는 보시면은 얘가 사실 Q는 한쪽에서 푸시하고 반대쪽에서 판만 하는 게 Q잖아요.
근데 여기는 아무데서나 푸시를 할 수도 있고 중간에다가 끼워놓을 수도 있고 뭐 빼내는 것도 중간에서 뺄 수 있고 아무데서나 빼낼 수가 있습니다.
그렇기 때문에 이건 어떻게 보면은 C++로 치면은 벡터에 가까운 그런 자료구조라고 볼 수가 있어요.
그래서 시스템 베를로그에서는 Q라고 부르지만 뭐 실질적으로는 벡터에 가까운 그런 자료구조입니다.
그래서 요거를 쓰게 되면은 이제 요런 벡터 같은 그런 역할을 하는 데이터 구조를 이제 그거를 이제 프로그래머가 직접 만들어줄 필요가 없이
여기 시스템 베를로그에서 기본적으로 제공하는 이 자료구조를 쓸 수가 있어서 상당히 편리하게 쓸 수가 있고요.
어소시에이티브 어레이도 있습니다.
어소시에이티브 어레이라고 하는 개념은 일단은 기본적으로는 원래 소프트웨어 쪽에서 있는 개념이고
물론 C나 C++ 같은 그런 뭐 전통적인 스트럭셔럴 랭기지에는 이런 어레이가 없고
뭐 조금 뭐 최근에 나오는 파이썬이나 뭐 이런 그 스크립트 기반의 랭기지 쪽에서
이런 것들을 지원을 하기 시작을 했죠.
그러니까 어소시에이티브 어레이 같은 경우에는 말하자면은 메모리에 이게 얼로케이션이 될 때
일반적인 어레이는 모든 그 어레이의 크기만큼 연속된 메모리 공간에
걔네들이 다 할 땅이 되잖아요.
그래서 예를 들어갖고 내가 100개짜리 엘리먼트 100개의 엘리먼트를 갖는 어레이를 내가 하나 선언을 했다.
그러면은 그 100개의 엘리먼트를 다 쓰던 안 쓰던 어쨌든 그 100개의 엘리먼트에 해당하는 메모리가
연속적인 메모리 공간에 다 할 땅이 됩니다.
근데 어소시에이티브 어레이는 그렇지 않아요.
어소시에이티브 어레이는 말하자면은 일종의 스팔스 어레이라고 볼 수가 있고
얘는 사용하는 엘리먼트만 메모리에 저장이 그때그때 되고
그렇기 때문에 얘가 항상 연속적인 공간에 다 저장이 되는 건 또 아닙니다.
그래서 이거 같은 경우에는 인덱스는 굉장히 커가지고
큰데 실질적으로 사용되는 엘리먼트는 몇 개 없는
그런 스팔스한 어레이 같은 경우에는 이런 어소시에이티브 어레이를 쓸 수가 있죠.
그래서 그런 거를 쓰는데 이제 이런 어레이를 활용을 할 수가 있습니다.
그 다음에 이 어소시에이티브 어레이에도 이런 여러 가지 지원해주는 펑션들이 있어요.
얘는 이 연속적인 공간에 이 메모리가 할 땅이 되는 게 아니고
그러다 보니까 여기에 있는 인덱스들이 순차적으로 배열되어 있지 않아요.
그러니까 모든 인덱스가 다 엘리먼트를 갖고 있는 건 아니기 때문에
모든 인덱스에 대해서 다 메모리 공간이 할 땅이 되는 건 아닌 거죠.
그러니까 일반적인 4룹을 돌면서 물론 여기서 보시면은
얘는 이런 for each를 쓰면은 뒤에 보이는 이게 그냥 자동으로 돼요.
그러니까 이 for each가 생각보다 굉장히 쓸모가 많아요.
그런데 어쨌든 여기서 이제 이 for each가 실질적으로 해주는 거는
이거를 한다고 보시면 돼요.
그러니까 어떤 어소시에이티브 어레이에서
첫 번째 인덱스에서부터 시작을 해가지고
그 다음 다음 다음 인덱스들을 하나씩 하나씩
아이터레이션을 돌면서 억세스를 해주는 거를
이 for each가 해주는 거라고 보시면 되겠습니다.
그런데 그거를 for each를 안 쓰고
이제 프로그래머가 직접 이거를 룹을 돌려고 그러면
그때는 이런 first라든가 next라든가
이런 것들을 이용을 해가지고
이제 이 어소시에이티브 어레이를 억세스를 해야 됩니다.
그 다음에 이 어소시에이티브 어레이가 또 좋은 점 중에 하나는
이런 인덱스를 꼭 숫자로 하지 않아도 된다는 거예요.
그래서 이거 같은 경우에는 c++로 치면은
딕셔너리 같은 그런 기능이라고 보시면 되겠습니다.
여기서 보시면은 스위치라고 하는 어소시에이티브 어레이가 있는데
이 어레이에는 인덱스가 민 어드레스라고 하는 스트링을
얘는 지금 인덱스로 받고 있어요.
그러니까 이 민 어드레스라고 하는 하나의 스트링이
인덱스의 역할을 하는 거죠.
그리고 이것만 있는 게 아니라
뭐 맥스 어드레스라든가 그런 여러 가지 것들을
다 이 어레이에다가 이제 저장을 해놓을 수가 있습니다.
그래서 이거를 사용을 하게 되면은 이제
여기 같은 경우에는 지금 일종의 컨피규레이션 파일을
읽어갖고 그거를 이런 스트링으로 인덱스를
인덱싱을 하는 어레이에다가 넣어놓은 거예요.
그래서 그 어떤 베리어블이 있는데
그 베리어블 설정 변수가 있으면
그 설정 변수의 값을 어소시에이티브 어레이에다가 집어넣고
이거는 설정 변수의 이름을 인덱스로 쓰고
그 설정 변수의 값을 그 엘리먼트의 값으로
이렇게 활용을 한 예인 거죠.
그래서 이거를 이제 이런 식으로 쓸 수 있다는 얘기고
이거 말고도 어찌됐든 간에 어떤 어레이가 있을 때
인덱스를 스트링으로 쓸 수 있으면
여러 가지 용도로 쓸 수가 있습니다.
그리고 어레이의 리덕션 펑션을 지원을 합니다.
사실 이 리덕션 자체는 베리로그에도 있는 문법이죠.
그런데 베리로그에 있기는 하지만
그 어레이에도 이거를 적용을 할 수가 있다는 거예요.
대신에 어레이에다 적용을 할 때는 이런 식으로
함수를 호출을 하는 형식으로 여기에 적용을 합니다.
그래서 예를 들면 여기 보시면
이제 뭐 이런 썸이라고 하는 그런 그게 있어요.
리덕션이 있어요.
그러면 이 어레이가 있을 때
그 어레이가 가지고 있는 각각의 엘리먼트들을 다 더한 값이
여기에 이제 출력으로 나오게 되겠고
뭐 프로덕트 같은 경우에는 다 곱한 값
엔드는 모든 엘리먼트를 빛, 와이즈, 엔드를 한 값
O와 XO와 다 마찬가지고요.
그래서 이거는 기본적으로는
이제 베리로그에서 지원하는 리덕션을
어레이에도 사용할 수 있다.
뭐 이렇게 이해를 하시면 되겠습니다.
그 다음에 어레이에도 또 이렇게 몇 가지
좀 유용한 기능들이 있어요.
그래갖고 이거는 뭐 시스템 베리로그에서만
쓸 수 있는 기능들이기는 합니다.
예를 들어갖고 어떤 어레이가 있는데
그 중에서 최소값을 찾거나 최대값을 찾거나
뭐 이런 것들은 이 함수 하나 호출을 하는 걸로
다 구현이 되어 있습니다.
그 다음에 이 유닉 같은 경우에는 뭐냐면
어레이 같은 경우에는 얘는
그 뭐야 집합은 아니기 때문에
중복되는 엘리먼트가 있을 수 있잖아요.
여기 보시면은 f라고 하는 어레이에 보면
1, 6, 2, 6, 8, 6 해가지고
6이 세 번이나 나와요.
그런데 얘를 유닉이라고 하는
이 함수를 호출을 하게 되면
얘를 집합처럼 만들어줍니다.
다시 말해서 중복되는 엘리먼트들을 다 제거를 해줘요.
그래서 이 f라는 것을 유닉을 호출을 하게 되면
여기 보이시는 것처럼 1, 6, 2, 8이라고 하는
그런 중복된 엘리먼트가 제거된 집합으로
이게 그 값이 리턴되게 됩니다.
그래서 이런 것들을 또 이제 시스템 베리로그에서
기본적으로 제공을 해주고요.
그 다음에 그 밑에 보시면은
인라인으로 어떤 리덕션을 할 때
조건을 줄 수가 있어요.
그래서 예를 들어갖고 내가
sum이라고 하는 그런
리덕션 함수가 있다고 말씀을 드렸는데
sum을 호출을 하게 되면은
이 어레이에 있는 모든 엘리먼트들을
다 더해주는 기능인데
이거를 그냥 더하지 말고
어떤 특정한 조건을 만족하는 엘리먼트만
더하도록 그렇게 할 수가 있습니다.
그래서 그때 쓰는 키워드가
with라고 하는 키워드를 쓰고요.
이 with 뒤에 조건을 이런 식으로 주게 되면
7보다 큰 엘리먼트들에 대해서만
sum을 수행을 해라.
라고 하는 명령이 되겠고
그 다음 거는 8보다 작은 것들에 대해서만
sum을 해라.
라고 하는 그런 의미가 되겠습니다.
그래서 이런 편리한 기능들이 있다는 얘기고요.
근데 제가 이제 한 가지 조금
제가 잘 이해가 안 가는 부분은
제가 이걸 설명하기가 좀 어렵기는 한데
여기서는 sum이라고 하는
리덕션을 썼는데
실제로는 카운트를 해줘요.
이게 잘 이해가 안 가더라고요.
왜 그런지 솔직히 잘 모르겠어요.
설명하기가 좀 어려운데
아이템이 7보다 큰 거에 대해 갖고
sum이라고 하는 리덕션 함수를 호출하면
결과가 2가 나와요.
그러니까 여기 있는 이름만 놓고 보면
7보다 큰 거 9랑 8을 더해 갖고
17이 나와야 될 것 같은데
그냥 개수만 나와요. 개수만.
이게 참 저도
이게 뭐라 설명을 해야 될지 모르겠는
이게 뭐
뭐 타입이라도 비트면은 모르겠는데
비트도 아니고
이게 sum이
이 d가 지금 인티저인데
인티저를 sum을 했는데
이게 왜 카운트가 리턴이 되는지
하여튼 그건 잘 모르겠습니다.
그래서 이거는 조금 제가 아직까지도
풀리지 않는 의문이고
근데 어쨌든 간에 이런 것들을 호출을 할 때
이렇게
인라인 조건을
줄 수가 있다는 게
뭐 이게 그냥
여기 시스템 베리로그에서
지원을 한다는 것 정도로만
이해를 하시면 될 것 같고요.
자 그 다음에 또
엑서사이즈를 하나 더 해보도록 하겠습니다.
이거는 간단한 거니까
시간은 그냥 잠깐만 드릴게요.
그래서 파인드라고 하는 게 있어요.
그래서 그걸 한번 사용해 보는 예를
간단하게 한번 실행을 한번
해보시기 바랍니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
네 이거는 뭐 금방 하셨을 거라고 생각을 하고요.
이거는 여기 나와 있는 이 의미대로
뭐 찾아줍니다.
그러니까 그 아이템이 3보다 큰 거에 대해 갖고
찾아주는 뭐 그런 기능을 하고 있고요.
그러니까 이게 뭐 어쨌든
뭐 필요할 때
이런 기능들이 있다는 걸 기억을 하시면은
이제 그 어떤 어레이에 대해 갖고
뭔가 내가 원하는 걸 찾거나 할 때
뭐 사용을 하실 수가 있습니다.
그 다음에 여기서도 보시면은
뭐 꼭 그 해당 조건에 만족하는
엘리먼트를 찾아주는 거 외에도
이런 식으로 뭐 인덱스를 찾거나
아니면은 여러 개의 엘리먼트가 있을 때
첫 번째 거를 찾거나
아니면 첫 번째로 찾아진 거에 인덱스만을 리턴을 하거나
뭐 마지막 거를 찾거나 이런 식으로
다양한 파인드에
뭐 일종의
뭐 일종의
뭐 이런 그 유사한 그런 시리즈의
그런 그 도구들이 있습니다.
그 다음에 이제 타입 데피니션이라고 하는
또 새로운 키워드를 제공을 하는데요.
뭐 베릴로그에서는 일반적으로 이런 식으로 쓰죠.
디파인을 씁니다. 디파인.
그래서 디파인을 쓸 수도 있기는 하지만
이제 파라미터라든가
타입 데피니션 같은 거를 써서
이것도 이제 뭐 C랑 유사한 그런 소프트웨어 쪽에서 나오는 스타일인 거죠.
그래서 뭐 이런 식으로 쓰는 것도 이제 뭐 가능하다는 얘기고요.
그 다음에 스트럭쳐도 이제 쓸 수가 있습니다.
그래서 이런 식으로 스트럭쳐를 쓸 수가 있고
그 다음에 팩트라고 하는 거를 쓰게 되면
이것도 이제 뭐 그 C랑 이런 소프트웨어 쪽에서 나오는 거랑 개념이 기본적으로 똑같은데
이 팩을 안 쓰면
이 스트럭쳐 안에 들어가 있는 각각의 엘리먼트들은
그냥 32b씩 메모리를 차지를 하게 됩니다.
왜냐하면 이제 기본적으로 우리가 돌리는
그 머신이 이제 32b 머신이라고 가정을 하면
그 32b을 이제 사용을 하게 되고요.
근데 여기 보시면은 RGB 각각의 엘리먼트들은
8비트씩밖에 필요가 없거든요.
근데 메모리는 32b씩 차지를 하고 있게 되는 거죠.
이렇게 32b씩 차지를 하게 되면 어쨌든
이게 억세스 속도가 좋으니까
이제 퍼포먼스 측면에서는 이득이 있는데
근데 이제 메모리 공간의 효율성 측면에서는 낭비가 있으니까
이 팩트라고 하는 이 키워드를 사용을 하게 되면은
여기에 딱 필요한 만큼만 메모리 공간이 할당이 되게 됩니다.
대신에 근데 이게 R이나 G나 B 같은
하나의 엘리먼트를 억세스를 하게 되면
실질적으로는 얘를 하나만 딱 읽어오는 게 아니라
그 32b을 통째로 읽어온 다음에
거기서 필요한 부분만 이렇게 추출을 하는 형식으로
그런 식으로 실제로 구현이 될 수밖에 없어서
이거를 억세스하는 데는 조금 더 시간이 걸립니다.
그 다음에 유니언은 이것도 C 같은 데서 쓰이는 유니언이랑
동일한 의미입니다.
그래서 예를 들면 여기서 보면
인티저 I랑 리얼 F라고 하는 게
유니언의 멤버로 선언이 되어 있으면
I랑 F가 결국 동일한 메모리 공간을 공유를 하는
그런 상황을 그런 거라고 보시면 되겠습니다.
그 다음에 이누머레이션 타입도 지원을 하는데요.
이런 식으로 이것도 이제 기본적으로는
C에서 쓰이는 이누머레이션 타입하고
동일한 문법을 가집니다.
그리고 이것도 마찬가지고요.
어떤 이누머레이션 타입에다가는 숫자를 지정을 안 해주면
그냥 디폴트로 0, 1, 2 이렇게 순서대로 어사인이 되는데
내가 특정한 엘리먼트를 특정한 숫자로 어사인을 하고 싶으면
이렇게 어사인을 하는 이 오퍼레이터를 써가지고
숫자를 내가 지정을 해줄 수가 있습니다.
그래서 이렇게 되게 되면
이닛은 0, 디코드는 2,
그 다음에 아이들은 디코드가 2니까 그냥 더하기 1을 해서 3
이런 식으로 이제 숫자가 부여가 되죠.
근데 여기서 한 가지 또 이제 주의사항은 뭐가 있냐면
이누머레이션 타입을 1번부터 시작하도록 예를 들어서 만들었어요.
그러면은 퍼스트는 1, 세컨드는 2, 서드는 3
이런 식으로 어사인을 하게 되는데
이 이누머레이션 타입을 갖는 변수를 이렇게 딱 선언을 하게 되면
이 변수는 시스템 베릴로그에서는 일단 무조건 0으로 이니셜라이즈가 됩니다.
이게 이제 C나 이런 데서는 보통은 다 얘가 그냥 쓰레기 값으로 이니셜라이즈가
이니셜라이즈가 안 되는 거죠. 기본적으로.
안 되는데 시스템 베릴로그에서는 변수를 선언을 하면은
뭐 0으로 기본적으로 이니셜라이즈가 됩니다.
근데 문제는 얘가 이누머레이션 타입인데
0이라는 값은 이누머레이션 타입에 정의가 되어 있지 않잖아요.
이렇게 되면은.
왜냐하면 얘는 1, 2, 3만 갔는데
이니셜밸류는 여기에 정의되어 있지 않은 0이라는 값을 갖게 되니까
이게 뭐 문제가 있을 수도 있고 없을 수도 있지만
어찌됐든 간에 이게 바람직한 상황은 아니기 때문에
이렇게 하고 싶으면 어쨌든 0이라고 하는 값을
이런 식으로 이누머레이션 타입에다가 정의를 해 줄 필요는 있다는 겁니다.
그래서 이런 게 약간의 사소한 거기는 하지만
주의사항이라고 말씀드릴 수가 있겠고요.
그 다음에 이누머레이션 타입도 이런 식으로 여러 가지
그런 멤버 함수들을 가지고 있습니다.
그래서 첫 번째 엘리먼트라든가 다음 거라든가
이런 식으로 몇 가지 이런 유용한 펑션들을 제공을 하고 있고요.
그래서 그거 관련해가지고 한번 또 엑서사이즈를 해보도록 하겠습니다.
바로 이어갖고 다음 엑서사이즈도 나오니까
그거 두 개 한꺼번에 진행을 한번 해보시죠.
이 여섯 번째 엑서사이즈 실습은
이제 이누머레이션 타입에 관련된 거고
다음 거는 이제 그 뭐야
문자열에 관련된 겁니다.
그러면 실습하시고 제가 또 그거에 대해서
코드에 대해서는 또 설명을 드리도록 하겠습니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
감사합니다.
이 여섯 번째 실습에서는 이누머레이션 타입을 타입 캐스팅하는 거에 대해서 몇 가지 얘기가 나오는 게 있는 겁니다.
그러니까 이누머레이션 타입은 기본적으로 문자와 숫자가 약간 이렇게 서로 왔다 갔다 하면서 쓸 수 있게 해주는 그런 편리한 기능이기는 한데
이렇게 타입 캐스팅을 할 수가 있다는 거죠.
그래서 사실은 이거를 숫자를 그러니까 이누머레이션 타입을 인티저 타입으로 캐스팅하는 거는 별 문제가 없습니다.
왜냐하면 뭐 이 인티저 타입이 훨씬 더 표현할 수 있는 숫자의 범위가 크니까요.
근데 이걸 거꾸로 인티저 타입을 이누머레이션 타입으로 타입 캐스팅을 하게 되면
잘못하면 이 이누머레이션 타입이 없는 숫자가 타입 캐스팅이 되는 수가 있어서 이 경우는 좀 조심이 필요하다는 거죠.
그래서 이런 식으로 그냥 캐스팅을 그냥 체크를 하지 않고 하게 되면은 할 때는 문제가 없는 경우도 있지만 문제가 생길 수도 있으니까
이 밑에 있는 것처럼 이런 캐스트라고 하는 그런 오퍼레이터를 써가지고 하게 되면 얘는 이제 캐스팅이 정상적으로 되는지까지도 확인할 수 있게 해주기 때문에
이게 더 안전한 방법이다. 그렇게 이해를 하시면 되겠습니다.
그 다음에는 이제 스트링에 관련된 겁니다. 스트링도 이제 여기서는 시스템 베릴로그에서는 기본적으로 제공을 해주는 그런 기능 중에 하나입니다.
그래서 굉장히 뭐 이것도 실제로 그 뭐 테스트 디버깅 같은 거를 위해 갖고 아무래도 디버깅 메시지 같은 것들을 출력을 하게 되는데
테스트 벤치를 짜다 보면은요. 그러니까 그런 디버깅 메시지를 잘 이렇게 뭐 이렇게 조작을 해가지고 디버깅 메시지를 만들 때
이런 기능들을 사용을 할 수가 있습니다. 그래서 이거는 뭐 모든 스트링에 관련된 그런 함수들을 다 지금 보여주고 있는 것은 아니고
이거는 이제 뭐 시스템스 레퍼런스 매뉴얼 같은 거를 검색을 해보시면 거기에 그 뭐 특정한 시뮬레이터가 지원하는 모든 함수들이 다 나와있기는 할 거거든요.
여기는 이제 뭐 대표적인 것들만 좀 해놓은 거고요. 많이 쓰는 거라고 제가 보여지는 거는 이런 거 뭐 서브 스트링 같은 거.
그러니까 어떤 문자율이 있는데 그 중에서 일부를 이렇게 추출해내는 뭐 그런 것들 좀 많이 쓸 수 있고
그 다음에 이거는 그 프린트 F인데 그 포맷에 맞춰 갖고 프린트 F를 할 수가 있잖아요.
근데 그거를 프린트 F를 하는 게 아니라 프린트 F를 한 포맷티드 스트링을 반환해주는 뭐 그런 함수가 있습니다.
그래서 이거를 사용을 하게 되면은 뭐 C 같은 경우에는 S프린트 F 같은 뭐 유사한 역할을 한다고 볼 수 있겠죠.
대신에 S프린트 F는 이제 그 첫 번째 인자에다가 이 포맷티드 스트링이 그 뭐야 저장이 되는데
근데 여기 같은 경우에는 아예 리턴 값으로 그 포맷티드 스트링이 리턴이 되게 됩니다.
그래서 그런 식으로 하는데 이제 활용할 수 있는 함수들이 있고요.
그래서 어쨌든 스트링에 관련된 것도 시스템 베리로그에서 많이 보강이 돼가지고
굉장히 뭐 필요한 거는 하여튼 필요한 것들을 편리하게 사용을 할 수가 있습니다.
자 그래서 여기까지가 이제 그 데이터 타입에 관련된 것들을 쭉 한번 설명을 드렸고요.
오늘 이제 계획된 강의 계획에 따르면 하여튼 해야 될 거는 다 했고
그래서 오늘 그 계획을 보시면 1일차 때 디자인 베리피케이션 메소드에 대해서 전반적으로 말씀을 드렸고
베리피케이션 가이드라인 설명 아까 뭐 인트로덕션에서 간단하게 설명을 드리고
데이터 타입을 한번 쭉 설명을 드렸습니다.
그리고 이제 내일부터는 이제 문법들 중에서 뭐 스테인먼트라든가 뭐 OOP
그 다음에 뭐 인터페이스 랜더마이제이션 뭐 이런 것들에 대해서는 내일 배우도록 하겠습니다.
자 그래서 오늘 수업은 이 정도로 이제 시간이 다 돼서 마치려고 하는데요.
시간이 조금 남았는데 혹시 질문 있으신 분 있으세요?
네 온라인으로 참여하시는 분들 중에서도 혹시 질문 있으신 분 있으신가요?
네 온라인으로 참여해주세요.