강의출처
39m
Synchronous and Asynchronous
요즘의 버스는 전부 Synchronous이다.
즉, 모든 동작이 하나의 클럭에 동기화되어 동작한다는 뜻이다.
서로 다른 클럭을 가진 두 IP가 통신을 하게 되면 Clock Domain Crossing 이라고 한다.
만일 Clock 동기화이지만, 어느정도의 Phase 지연은 허용하면 Synchronous도 아니고 Async 도 아닌, IsoChronous라고 한다.
똑같은 100MHz 크리스탈 각각을 가진 IP 라고 해도, 그 둘은 완벽히 동일할 수 없기 때문에 Async 라고 취급해야한다.
Metastability
서로 다른 클럭을 가지는 두 IP가 소통할 때, 0도 아니고 1도 아닌 상태 또는 Tsu Th 가 만족되지 않은 input이 들어올 때 Metastability 가 발생한다.
Metastability 가 발생하는 예는 위와 같다.
Multi Flipflop 을 만들었는데, sig_a 가 하강할 때 clkb 가 rising edge 하는 바람에 이게 B 입장에서는 0으로 해석해야할지 1로 해석해야할지 모호한 상황에 처해버렸다.
어떻게 해결하느냐?
동일한 클럭을 공유하는 중간단계인 Multi-Flipflop Synchronization 을 삽입함으로써 거의 해결가능하다.
CDC Problem(Clk Domain Crossing)
높은 주파수에서 낮은 주파수로 Crossing 한다고 해보자.
보낸 데이터가 증발하는 경우가 있다.
이런 경우를 반드시 테스트케이스에 삽입을 해야 문제가 발생하지 않는다.
잡기 힘든 Edge-Case 중 하나이기 때문이다.
Address 가 데이터가 많은데, Clk Crossing 할 때 64, 128비트씩이나 되는 라인을 전부 Multi FF 로 매칭해야할까?!
이는 비용이 너무 크다.
Valid 신호를 M FF 로 매칭을 하는 식으로 해결한다.
1-3 On-Chip Bus For SoC
On chip Bus 가 많은데, 간략히 개요를 살펴보도록 한다.
On Chip Bus란?
SoC 내부에서 interconnection 을 유지하는 메커니즘으로, SoC 내부의 IP를 연결하는데 사용된다.
OCB
OCN
NoC란?
Network on Chip 으로, Bus 프로토콜은 유지하지만 패킷단위로 통신할 수 있도록 다양한 종류의 기술을 사용하여 네트워크를 활용하여 뭐시기뭐시기 하는 것...
OCB 의 발전
싱글버스에서 멀티버스에서 Matrix 버스에서 NoC 의 추세로 발전 중.
프로토콜 관점에서는 1개의 M이 S를 연결할 때 선점당하는데,
아예 선점당하는건 비효율이므로 Pipelined, Transaction , Split Protocol 이 이를 보완하고
아직 작업이 완료되지 않아도 다른 트랜잭션을 이슈하는 Multiple Outstanding Transaction 이라는 기술도 등장했다.
OCB 표준기술 목록
AMBA
Core Connect
Wishbone
Avalon
...
이 모든 것이 동일하게, Central Arbitration 및 Synchronous 가 주류이다.
ASB(95)
APB(95)
AHB(99)
AXI(03)
AXI-4(09)
AHB는 MUX도 적게 쓰고, 여러 신호가 있으며 정보전달자체는 복잡한데, 프로토콜은 간단하다. 예를 들어, Arbitration 시 어떤 알고리즘을 쓰라는 명세는 되어있지 않다. Round Robin 이든 Greedy 이든, ...
AXI는 MUX도 많이 쓰고, 적은 신호가 있으며 정보전달자체는 간단한데, 프로토콜은 약간 복잡하다.
BFM-based Verification Method
Testbench란?
기능적, 타이밍적 정확성을 검증하기위한 Design Under Verification을 수행하기 위한 환경을 의미한다.
테스트벤치는 해당 디자인에서 벌어질 수 있는 모든 가능성을 포함한 test vector 를 포함해야한다.
Coverage
얼마나 테스트가 수행되었는지를 정량화시켜줌.
예를 들어, 100줄의 .v 중 50줄만 테스트기간동안 수행되었다면 나머지 50줄의 모듈은 사실상 검증이 안된 것과 마찬가지 => code coverage
Functional coverage
+연산과 연산은 따로따로 테스트를 해야하는데, 연산 테스트 0*0=0을 테스트한줄알았는데 0+0을 2번 테스트한거면 Functional coverage 가 불량한 것.
Self-Checking Testbench
복잡한 시스템을 가진 시스템의 경우(ex. FFT, 암호화, 복호화) expected value 를 만드는 것 자체가 쉽지않다.
따라서 자동으로 Expected Value 를 가지는 시스템을 만들고,
그 둘의 출력을 비교하는 것이다.
이 때, Exp. Val 을 만드는 시스템은 적당히 구글링해서 긁어오든지 한다.
이를 Golden Model 또는 Reference Model 이라고 한다.
처음에는 C나 Python 으로 짜고, 그 뒤 원하는 범위의 출력이 나오도록 RTL 코딩을 한다.
여기서 문제가 나오는데,
타이밍은 어떻게 체크할 것이냐?
Golden Model 은 타이밍의 정보를 따로 넣어줘야 하는데, C나 System C 로 코딩이 되어있다면 난감해진다.
BFM이란?
시스템 개발에는 이러한 일련의 테스트가 필요한데,
만약 Bus-Based System, 즉 버스를 매개로 소통을 하는 시스템의 경우 어떻게 테스트를 할까?
버스를 중심으로 프로세서, 메모리, Peripheral 블록 및 테스트하고자 하는 블록 등등 이렇게 여러 블록이 있을테지만,
결국 버스 그자체를 테스트하는 것이 아닌 한, 주변블럭을 테스트하는 입장인 우리가 버스에게 요구하는 것은 그저 "제대로 동작하는 것" 이다.
따라서 BUS 를 그대로 모델링한 BFM 에 테스트하고자하는 블럭을 부착함으로써 테스트를 하게 된다.
Bus를 대신하는 의미로 쓰이기도 하고,
Processor 를 대신하는 의미로 쓰이기도 하는 등
BFM은 좀 버즈워드적인 감이 있는 용어라고 한다.
BFM의 활용
앞선 IDEC 시간의 질문에 ISS 가 뭔지 몰랐는데 드디어 나왔다.
Instruction Set Simulator 인데, 검증에 쓰인다.
이는 Processor 를 모사한다.
예시 프로젝트 - Arbiter Test
Stimulus 블록이 여러 Master 를 상정한 request 를 날리고, arbiter로부터 grant 신호의 적절성 여부를 판별한다.
Check 블록은 추가적인 output 도 테스트하고자 할때 쓴다.
1-4 Introduction to APB 및 BFM testbench 구현예시
기본적으로 주변장치를 위해 사용되는 프로토콜.
시스템버스를 위한 Low-Power Extension이다.
Sync 이며 Low bandwidth이다. 또한, Unpipelined 이므로 하나의 리퀘스트가 들어오면 처리하는 동안 다른 리퀘스트를 전혀 처리할 수 없다.
AMBA 2.0 - APB Signal
간단한 Timing Diagram
더도말고 덜도말고 무조건 32비트씩만 전송가능하다.
AMBA 3.0 - APB Signal
AMBA 3.0에서는 아래 파란 글씨가 추가된다.
AMBA 3.0 APB - Timing Diagram
Slave 가 준비가 덜되었을 때 1 사이클 더 지연시킬 수 있음을 보여준다.
또한, R/W시 Error의 처리 또한 가능하다.
따라서 3사이클 지연된다.
에러를 어떻게 처리하느냐는 따로 명세되어있지 않다. 알아서 처리해야한다.
ㄹ
AMBA 4.0 APB - Timing Diagram
PSTRB, PWDATA 신호가 추가된다.
자세한 설명은 생략한다.
AMBA APB BFM
우리는 주어진 Task 를 통해 BFM을 만들어야한다.
Task는 테스트를 위해 정의된 일종의 Subroutine이다.
Function은 Timing control이 안되기 때문에 Task를 쓴다.
자세한 차이는 아래와 같다.
우리가 하고자 하는 것은
이런 Scenario 이다.
파란색이 BFM_APB 이며, 이것이 우리가 테스트하고자하는 mem_apb, mem_apb 두 개의 모듈에 입력을 인가하고 출력을 테스트한다.
대충 선언은 요렇게 한다. 나중에 참고하면 좋을 듯 하다.
동작 task 정의는 아래처럼 하면 된다.
task ~ endtask 블록에 이처럼 선언함으로써 이루어진다고 한다.
task 문법은 써본 적이 없는 생소한 문법이라, 따로 공부가 필요할 듯 하다.
위처럼 memory_test 라는 task 를 선언한 뒤
위처럼 initial begin ~ end 블록에 여러번 선언하여 Testing Scenario 를 작성할 수 있다.
BFM의 testbench 가 들어가는 top module 의 경우, 아래와 같이 선언한 뒤
모듈을 아래처럼 배선하고,
slave 를 3개 설정하는 과정에서 귀찮음을 방지하기 위해 generate 를 사용하였다.
선 배선까지 전부 자동으로 이루어지니 편하다고 할 수 있다.
인스턴스를 전부 만들었으니
테스트 부분을 구현해준다.
VCD ifdef 를 쳐준 이유는, 이게 켜져있으면 속도에 매우 큰 차이를 주기 때문에 취사선택을 제공하기 위함이다.
testbench까지 직접 만들어 본 경험이 전무해서, 이런건 따로 메모를 해뒀다가 반드시 추후 공부 및 실행을 해봐야 한다.
1-5 Verification of UART using APB BFM
UART 구현은 이전 포스트를 참조하도록 하자.
포스팅은 아직 안했는데, 이미 Rx Tx 모두 구현해본 경험이 있다.
다만, 기존에 구현했을때는 Transmit FIFO 를 구현했었는지 잘 모르겠는데
실제로는 사용된다고 한다.
HW를 설계할 때 고려할 사항의 고려 순서
- 어떤 입출력핀을 가질까?
- 어떤 레지스터를 내부에 가질까?
UART 원리
강의에 잘 설명되어있는데, 일단 생략하고 주 목표인 '테스트 방법' 에 집중하도록 한다.
HW 엔지니어는 put_char 및 get_char 에 해당되는 .c 함수를 SW 엔지니어에게 제공해야한다.
아니면 비트하나하나에 대한 의미를 SW엔지니어에게 설명해놓은 명세를 엄청 상세하게 적어놓던지.
APB에 물린 UART 의 테스트방법
좌: 이상적인 방법
우: 간편한 방법(선호)
BFM 모듈 선언
마찬가지로 BFM에는 BFM 모듈 인자 선언 및 BFM 모듈이 수행할 시나리오를 작성하고
시나리오에 사용되는 task를 정의하고
APB task 모듈 선언?(이 코드는 BFM에 들어가야하는지, 아니면 별도로 APB의 .v 파일에 들어가는건지 잘 모르겠다.)
task의 정의는 아래처럼 선언한다.
TTY model(텍스트로 나와야 터미널로 읽을 것 아닌가, 그 용도라고 한다.)
내가 저번에 구현한건 이것 같은데? 보레이트를 사용하는 것 보니까.
Testbench 선언
잡다한 의문사항
task 를 현업에서 많이 쓰는가? 아니면 그냥 지엽적인 문법인가?
솔직히 아직도 test의 workflow 가 어떻게 돌아가는지 잘 이해가 되지 않는 면이 있다.
- bfm은 그저 테스트하고자하는 모듈 이외의 것들을 모사하며, 테스트하고자 하는 모듈에 stimulus 를 인가하고, 그 출력결과를 체크해주는 용도일 뿐인가?
- 소위 'FPGA에 Program되지 않는 코드' 즉 initial 블록이나 task 문 등등은 testbench에도 들어가고, BFM 모듈에도 들어가고, 테스트하고자했었던 APB 모듈에도 들어가고, 다 들어간다고 보면 되나?
