AMBA 3.0 AXI protocol에 대한 잦은 질문

2주 전부터 몸 상태가 메롱메롱한데, 지난주에 그 상태로 IT-SoC 강좌를 하고 왔더니 평상시 보다 더 못한 강의를 하고 와서 멀리 누리꿈 스퀘어까지 찾아주신 분들께 죄송한 마음이 많습니다. 제가 수원 월드컵 경기장 앞에 살고 누리꿈 스퀘어는 상암에 있으니 수원 월드컵 경기장에서 서울 월드컵 경기장까지 이동하고 나면 정신이 하나도 없더군요.


AXI 강좌를 맡아서 하게 된지 벌써 2년인데, 항상 듣는 이야기들 중의 하나가 학교에서 공부하시는 분들께서 AXI 버스 자체, 그리고 peripheral들을 구하기가 어려워서 많은 분들께서 고생하시고 있는 듯 합니다. ARM에서 university program을 운영하고 있는데, 거기에 AXI 관련 RTL이나 model에 대한 지원이 원활하지는 않은가 봅니다. 저희 회사에서도 일종의 university program을 운용 예정인데요. 실은IDEC의 MPW 프로그램과 연계를 통해서 적극적인 운용을 할 예정입니다. AHB based platform/AXI based platform 모두를 가지고 있습니다만, 일단 AHB 기반으로 출발해서 사용자 요구가 있으면 확대할 예정이지요.


아.. 잡설은 이쯤하고 ^^;


AXI 강좌를 할 때 많이 받는 질문들을 좀 정리해보겠습니다.










AXI의 channel이란 무엇이며, 장점이 뭔가요?


AXI에서 channel은 기존의 protocol에서 양 방향으로 많은 신호가 흐르면서 복잡도가 증가하던 것을 ready 신호 이외의 신호는 한방향(driver-> target)으로 흐르게 해서 전반적인 설계 복잡도를 줄인 것이지요. (신호 자체가 bidirectional이었다는 건 아니니 오해마시길..)


Channel을 채용하여 transaction뿐만 아니라 channel간의 dependency도 줄어 들었다는 점이 첫 번째 장점이고, 위의 설계 복잡도 문제가 두번째 장점이고, register slicing이 쉬워졌다는 점이 장점이 되죠










AXI 에서 multiple outstanding transaction의 장점이 뭔가요?


AXI의 가장 큰 장점은 slave에서 자신의 상황에 맞게 처리 순서를 바꾸어 줄 수 있다는 것이 되겠습니다. 즉, 필요에 따라 out-of-order를 할 수 있다는 거죠. 그런데, 이런 처리는 다수의 transaction에 대한 정보가 있어야 하는데요, 이러한 다수의 transaction 정보를 slave로 전달하는 것이 바로 multiple outstanding transaction이라는 보시면 되겠습니다. 다수의 트랜젝션 정보를 미리 보낼 수 있으니 slave가 이 중의 하나를 선택적으로 먼저 처리할 수 있는 거죠.. OK?










ID는 왜 사용하나요?


AXI에서 ID는 실질적으로 interconnection에서 routing을 할 때 사용됩니다. 즉, 해당 data transaction이 어떤 방향으로 흘러가야 할지에 대한 정보로 사용되는 거죠. 통신에서 IP주소라고 생각해도 그리 다르지 않을 것 같습니다. 실질적으로 ID가 존재하므로 AXI는 다양한 형태의 interconnection network을 쉽게 형성할 수 있다고 생각됩니다. (만들기 쉽다는 건 아니구요.)










AMBA 3.0 = AXI 인가요?


AMBA 3.0에서 AXI가 도입된 건 맞는데, AMBA 3.0은 AXI, AHB lite, APB 3.0을 포괄합니다. AXI의 경우 대역폭을 많이 제공해 줄 수 있는 다양한 형태의 interconnection network (bus matrix 형태를 주로 사용하죠..) 에서 상당히 괜찮은 결과를 보여줄 수 있어요.










만들기 어렵나요?


개인적인 소견으로는 어렵지는 않고 좀 귀찮게 해요.. script로 짜면 많이 편해져요 ^^;


—-

역시 MS word 2007로 쓰는 것이 가장 편하군요.. ^^; tag를 못 잡는 것 제외하구요..

p.s 실수 잘하시는 것들 몇개 더.. AXI는 당연히도 input과 output간의 combinatorial feedback이 있으면 안됩니다. 즉, input과 output 신호는 반드시 한번은 f/f을 거쳐야 합니다. reset은 반드시 synchronous deassdert 입니다.

Built-In Self Test

질문 게시판에 질문해 주신 분이 계셔서 적습니다.

제가 DFT쪽의 전공은 아니라서 개론적인 사항만 간략히 설명드리겠습니다. 더 자세한 부분은 책을 참고하시는 것이 좋을 것 같습니다.

BIST는 말 그대로 Built-in self-test를 통하여 block을 check하는 방법을 의미합니다. 말 그대로 test vector generator와 result checker가 logic으로 내장되어 있어서 외부의 동작 없이 해당 블럭에 대한 검사를 수행하는 방법입니다.

이 방법은 대부분의 SoC에서 많이 사용하는 full scan과 같은 방법을 통한 functional check가 test vector를 scan chain을 통과시켜서 입력시키고, 그 결과를 역시 scan chain을 통과시켜 비교하는 방법을 사용하는 것과 비교하면, scan chain 통과에 걸리는 시간이 없기 때문에 해당 블럭에 대하여 in-speed test가 가능하고, 비교적 빠르게 검사할 수 있다는 장점이 있습니다.

하지만, 장점이 있으면 단점이 있는 것이 이 세상사는 이치라.. ^^;

입력 시켜야 하는 test vector의 복잡도와 checking logic의 복잡도에 따라 built-in 시켜야 하는 로직이 엄청 커질 수도 있다는 점이 단점이지요. 그래서, test vector generation과 checking이 간단한 메모리 검사등에는 널리 사용되나 일반적인 logic에는 잘 사용되지 않고 있습니다. (물론, 일반적인 로직들에서 이러한 test vector generation과 checking을 어떻게 하면 효율적으로 수행할 수 있을 것이냐?? 하는 것이 재미있는 주제로 많이 연구되고 있고.. 후배 중에 한명이 arithmetic BIST와 같은 알고리즘을 시도해본 적도 있습니다만..^^;)

Scan과의 연관은 뭐 간단히 생각하실 수 있어요.

BIST를 제어하고, 결과에 문제가 없는지 체크하기 위해서는 적어도 입/출력이 필요한데 이걸 scan chain에 엮어서 제어하는 거죠. 그렇게 안해도 관계는 없습니다만.. ^^;

일반적으로 많이 사용하는 Memory BIST의 경우 대부분 CAD tool에서 생성시켜 주거나 공정에서 같이 제공해주고요.. 다른 것은 만들어야 겠지요? (이건 일반적으로 사용되는 방법이 아니라 전 잘 모르겠습니다. ^^;)

DFT쪽에 재미난 주제들이 많지요. 특히 재미있는 알고리즘과 엮이기도 하구요. 공부하시기 좋은 분야라 생각됩니다.


Technorati : ,

Coding style; 잘 사는 방법

예전에 C 언어를 한참 할때, 코딩스타일이란 이야기를 처음 들었었습니다. K&R style이라느니, ansi style이라느니.. 그런 것이지요. indent를 2를 써야 한다.. 아니다 4를 써야 한다 등등도 있었구요.
Windows API에 와서는 이게 좀 더 복잡해져서 hungarian 표기법이 등장했습니다.
그런데, Verilog HDL에서는 이 Coding Style이라는 것이 아주 중요한 요소로 등장하고 있지요.

코딩 스타일이란 쉽게 이야기하자면, 어떤 설계를 하고자 할때, 혹은 어떤 표현을 하고자 할때 사용할 수 있는 방법이 여러가지가 있겠지만, 이런 형태로 표현 하는 것이 어떠냐~ 라는 식의 일종의 가이드입니다.
HDL에서는 FSM에서 one-hot을 표현하는 방법이라던지, mux를 합성하는 방법이라던지와 같은 언어적인 특성을 잘 표현하기 위한 가이드도 있고, negative edge신호는 n으로 끝나고, 플립플롭의 출력은 _r로 끝난다는 등의 이름 정하기 규칙(네이밍 룰), 그 이외에 indent(들여쓰기)는 tab이 아닌 2칸의 공백 문자로 한다는 등등일 일반적인 가이드를 포함합니다.

HDL에서 코딩 스타일이 중요한 이유는 여기에서도 간단히 말씀드렸습니다만, 생각하면서 따져나가야 하는 약간은 미묘한 문제들을 쉽게 (머리쓰지 않고 기계적으로.. 혹은 습관적으로) 해결할 수 있는 방법이 되는 경우가 많기 때문입니다. 또한, HDL의 경우 궁극적으로 “하드웨어를 만들기 위한 언어”이므로, 어떤 방식으로 기술하는 것이 로직 합성기에서 가장 잘 이해하도록 만들어서 원하는 하드웨어의 형태로 가장 효과적으로 만들어질 수 있도록 잘 기술하는 것이 필요한 것이지요.

대부분의 문제는 좋은 코딩스타일로 해결 가능합니다. 그리고, 코딩 스타일과 코딩 가이드를 적절히 조합한 문서가 제 블로그에서 몇번 소개해 드린바 있는 Reuse Methodology Manual 입니다.

하지만, 가끔은 코딩 스타일로 부족할 때가 있지요. 이럴 때 보통 synthesis directive를 줍니다.
synopsys툴은 ‘//synopsys 어쩌구’.. synplify는 ‘//synthesis’ 로 시작되고, verilog 2001에서는 이 synthesis directive주는 방법이 통일 되었지요.. 그래도 저는 synopsys를 사용할 때 //synopsys 어쩌구를 계속 사용하고 있습니다..  ^^;

가장 유명한 synthesis directive는 바로 Donny님의 posting에 나온 SNUG99논문(Sunburst의 Cumming씨 논문으로 기억되는데요..Cumming씨의 SNUG논문들은 synopsys툴을 이용해서 verilog를 사용하시는 분들에게 아주 좋은 아이디어를 많이 제공해 줍니다. – 설계적인 측면이 아니라 코딩의 기술적인 측면에서 말이지요)에서 언급된 case문을 지배하는 evil twins이지요.
case문에서 parallel case는 MUX와 같이 priority가 없는 로직을 만드는 순서 없는 case를 만들어 낼 때 사용이 되고, full case는 그야 말로 fully covered case를 나타내지요.. 근데, 좋은 약도 남용하면 독이 되듯, 이 좋아보이는 synthesis directive도 잘 알지 못하고 쓰면 오히려 독이 되어 불필요한 latch를 만들 수도 있는 법이지요. 자세한 것은 도니님이 남겨주신 문서를 참조하세요. ^^;

제가 회사에서 강조하고 있는 건, “합성시에 case문에 대한 분석이 auto로 나오도록 만들 것입니다.”
auto 로 나온다는 것은 코딩 자체에서 “parallel case”혹은 “full case”를 cover 하고 있다는 의미이거든요. 즉, one-hot FSM과 같이 특별한 케이스로 directive의 사용을 제한하고 있지요.

이런 코딩 스타일은 궁극적으로 설계자들에게 불필요한 고민을 줄여주어, 1분이라도 시간을 더 확보하게 함으로써 삶의 질을 높일 수 있는 기회가 될 수 있겠습니다. (혼자만의 논리적 비약일까요?)
귀찮고, 당연한 이야기 같더라도 코딩 스타일.. 꼭 숙지하세요.

p.s. 여담인데, 저의 경우 excel도 훌륭한 코딩 툴로 사용됩니다. 약간 복잡한 case를 다룰때 말이죠 ㅎㅎ, csv format으로 뽑아내는 재미가 쏠쏠하죠.